Filament Acl Laravel Package

Product Decisions This Supports

• Build vs. buy the admin authorization layer. The core decision here is whether to fund internal role/permission CRUD screens inside the Filament panel, or adopt. The package is trait-first (HasResourcePermissions, HasRelationManagerPermissions, HasPagePermissions, HasWidgetPermissions) with no required base classes, so integration does not restructure the app. That makes the decision reversible — the strongest argument for buying: low switching cost if you later replace it.
• Admin-surface roadmap (multi-panel, white-label, partner portals). Panel scope is configurable separately for roles and permissions, and the built-in resource supports managing another panel via getManagedPermissionPanel(). That directly underwrites a roadmap where an internal panel and a customer/partner panel have different role catalogs without forking the package.
• Admin UX complexity budget. The "shared owners" feature lets many resources inherit one canonical owner's permissions and disappear from discovery/UI. PM-level effect: fewer permission rows and tabs for admins to reason about. Decide deliberately whether you want a flat permission list or a collapsed one — this is a product decision the package exposes, not one it makes for you.
• Enterprise/security requirements as a feature spec. The protected role is a first-class concept: hidden from normal selects and tables, optionally bypasses package checks via Gate::before(), protected from edit/delete by RolePolicy, assignable only through an admin-user command. That is a break-glass/super-admin model, and it satisfies procurement language faster than a hand-rolled is_admin boolean.
• Feature-level permission granularity without new action classes. The intended contract is native Laravel/Filament: auth()->user()?->can('archive', [$record, PostResource::class]) and ->authorize('archive', PostResource::class). PMs can spec per-record custom actions in the backlog without scheduling a new Filament action class each time.
• Scope discipline: package vs. product differentiation. The package's own rules cap its responsibilities at discovery, subject/key building, syncing, panel scoping, protected roles, and the role/permission resource. Domain policy logic, custom action business rules, and extra role metadata stay in the app. Useful framing for stakeholders: this is not your authorization strategy, it is the admin UI and plumbing for it.
• Dependency governance / vendor scoring. Intake shows 0 stars and a score of ~19.6, while the v2.0.1 notes cite a pre-change Plumb score of 71.76 for v2.0.0. Those are different readings and a PM should not let one stand in for the other. Treat this as an internally-owned dependency, not a community-standard one, and require a re-score before it becomes a gate.
• Upgrade-window planning. Declared floors are PHP ^8.3, Filament ^5.0, Spatie ^8.2. Laravel 13 and PHP 8.5 are explicitly untested. If your platform roadmap assumes "we'll be on the newest Laravel by then," this package is an open dependency with no commitment date — schedule accordingly.
• Engineering tooling standardization. Two Laravel Boost skills ship with the package and are part of its validation matrix. If you are rolling out agent-assisted Laravel workflows, this is a small but real argument in favor; if you have an AI-tooling policy, it is a small argument against.

When to Consider This Package

Adopt when:

• You run Filament 5 on PHP 8.3+ with a Spatie ^8.2 permission layer already in the stack. This is the tested envelope; anything outside it is a bet, not an integration.
• Your need is authorization management UX inside the panel — roles, permissions, assignments, per-resource/action gating — and you have no appetite to build it.
• You want native Laravel policies rather than a bespoke permission DSL. The package ships opt-in checks via ChecksPermission with the permission argument last in the signature, keeping policies readable.
• Multi-panel scoping is on your roadmap, with roles and permissions scoped differently.
• You need an opt-in/opt-out model (require_explicit_opt_in = true by default; shouldRegisterPermissions(): false fully suppresses sync, UI, and checks). Good fit for large codebases where only some resources should be governed.
• You are prepared to own it. Low stars means you are the de facto maintainer in practice, even if MIT lets you call it a dependency.
• You want evidence of CI discipline: 176 Pest tests / 461 assertions, PHPStan, Pint, actionlint, SHA-pinned actions across eight jobs on PHP 8.3/8.4, Ubuntu and Windows.

Look elsewhere or defer when:

• Your roadmap is pinned to Laravel 13 or PHP 8.5. Untested means unsupported; do not infer compatibility from a green build.
• You are on Filament 4 or earlier, PHP ≤ 8.2, or an older Spatie major. The declared constraints rule you out cleanly.
• You want a vendor relationship, SLA, or commercial support. There is none implied here.
• Your intake gates on a numeric health threshold. Current signals (0 stars, ~19.6 score) will not clear it; the release notes' 71.76 figure is a prior-version, pre-change reading that needs to be re-verified before it enters a decision record.
• Your gap is domain policy logic (licensing, entitlement, tenant data isolation) rather than admin CRUD for roles. This package deliberately stays out of that.
• You require capabilities it explicitly does not scope: approval workflows, permission-change audit trails, SSO/SCIM-derived group mapping, or organizational hierarchies beyond roles.
• Your policy forbids AI/agent tooling — the bundled Boost skills are part of the shipped surface and part of what was validated.

How to Pitch It (Stakeholders)

To executives — one paragraph: We are evaluating a small MIT-licensed plugin that adds role- and permission-management screens to our Filament admin panel, so an admin can create roles, attach granular permissions, and assign them to users without our team building or maintaining those screens. The strategic case is cost avoidance and reversibility: it integrates through optional traits rather than base classes, so if it disappoints us, removal is a contained change rather than a rewrite. It also ships a proper break-glass "protected role" model — hidden from the UI, protected from edit/delete, optionally bypassing checks — which is the language security reviews want to hear. Two caveats must be stated plainly. First, adoption is essentially zero (no community traction), so we would be treating this as an internally-owned dependency rather than a market-vetted one. Second, it is only validated on PHP 8.3+ / Filament 5 and has not been tested against Laravel 13 or PHP 8.5, so our platform-upgrade timeline cannot assume it will be ready. Recommendation: approve as a scoped, reversible build-vs-buy win, and carry it on the dependency watchlist with an owner and an exit plan.

To engineering — the short version: This buys us the role/permission admin surface on top of an existing Spatie setup, with no required BaseResource/BasePage/BaseWidget classes. Integration is four optional traits plus per-class overrides (getPermissionSubject(), shouldRegisterPermissions(), getSharedPermissionOwner(), getPermissionCustomActions(), getPermissionActions(), getPermissionPanel()). Attribute resolution is concrete-class only — no inheritance — so permission metadata must be redeclared or overridden on each child class; that is a real ergonomic cost in deep resource hierarchies and worth a spike. Policies stay native Laravel, with ChecksPermission as an opt-in helper and the permission argument last in the signature so domain rules can follow. Custom actions use standard can() / authorize() — do not build wrapper action classes. Watch three behavioral contracts before touching config: opt-out must fully suppress sync, UI, and checks; shared owners must inherit and disappear from discovery; panel-scope changes must be applied consistently across sync, resource queries, hidden-role helpers, permission lookups, and protected-role assignment. Validation evidence is respectable for a package this size — Pest/PHPStan/Pint/actionlint across eight CI jobs, SHA-pinned actions, three-day update cooldowns with immediate security patches. Open items: Laravel 13 / PHP 8.5 compatibility is unproven, and the health score needs re-reading post-release before we cite any number. Recommendation: adopt behind a feature flag on one internal panel, with a documented removal path.