Filament Permission Laravel Package

Product Decisions This Supports

• Privileged-role governance and handover workflows. v1.10.0 changes the privileged role from “nobody can assign it” to “only a current holder can hand it on.” That supports product decisions to expose a deliberate transfer privileged access flow in the admin UI rather than relying on CLI/database surgery or an all-or-nothing super-admin model.
• Delegated administration with guardrails. Revocation is now limited to whoever could have granted the role, and the relation manager no longer offers to detach roles that reach further than the editor. This supports building safer delegated admin panels where mid-level administrators can manage roles without being able to strip or escalate beyond their own authority.
• Lockout prevention as a first-class product rule. “Nobody takes the privileged role off its last holder” plus PrivilegedRole::isLastHolder() lets the product disable destructive actions, show warnings, and require a handover before the last holder can be changed. This is a roadmap-relevant capability for enterprise/self-hosted admin products where a locked-out panel is a support and trust incident.
• Build-vs-buy for RBAC edge cases. The release shows the package is investing in the messy parts of role administration: transfer semantics, grant/revoke symmetry, and last-holder protection. That makes it a stronger candidate to buy/ adopt rather than build custom privileged-role rules around Laravel permissions.
• Upgrade and compatibility decisions. The change is behavioral, not merely additive: existing assumptions that “no one can assign the privileged role” or that any authorized editor can detach any non-privileged role may no longer hold. This affects release notes, admin UX copy, tests, and migration guidance for existing installations.

When to Consider This Package

Consider adoption when:

• You run a Laravel admin panel—especially a Filament-style panel with relation managers—where roles and permissions are managed by humans, not only by seeders.
• You need a privileged/super-admin role that is protected from accidental removal, lockout, or unauthorized escalation.
• You want delegated role administration: multiple admins can manage roles, but only appropriate holders can grant or revoke the privileged role.
• You need a small, explicit API such as PrivilegedRole::isLastHolder() to drive UI state: disable detach buttons, show “transfer access first” messaging, or gate custom actions.
• You are deciding whether to build custom guardrails around spatie/laravel-permission or similar, and the edge cases in v1.10.0 match your product’s governance model.

Look elsewhere or proceed cautiously when:

• You need a fully general ABAC/policy engine, complex conditional permissions, or enterprise IAM integration beyond role-based admin-panel governance.
• Your product intentionally allows unrestricted super-admin grant/revoke behavior, or your existing workflows depend on any authorized editor being able to detach roles regardless of grant authority. v1.10.0 tightens this.
• You do not use a Laravel admin panel/relation-manager UI; the package’s value is concentrated in that operational surface.
• You require built-in audit logging, approval workflows, or segregation-of-duties controls beyond last-holder protection. Those may still need custom build or another layer.
• You cannot absorb a behavioral change in a minor release without upgrade testing. The release is small in API surface but meaningful in authorization semantics.

How to Pitch It (Stakeholders)

For executives: This release reduces the operational risk of admin lockout and privilege sprawl. Instead of a privileged role that nobody can assign—which pushed teams toward worse workarounds—the package now supports controlled handover by an existing holder, prevents the last holder from being removed, and aligns revocation with grant authority. In practice, that means fewer support escalations, safer delegation to operations teams, and less custom code to protect super-admin access.

For engineering: v1.10.0 is a focused governance release. It adds PrivilegedRole::isLastHolder() and changes two important behaviors: privileged-role assignment is now a holder-to-holder handover, not a blanket refusal; and role detachment is limited to actors who could have granted the role. The relation manager also stops offering detach actions that exceed the editor’s authority. Treat this as a behavioral upgrade: review custom actions, tests, and admin UX around role assignment/removal, and add UI handling for the last-holder case.

For security and operations: The package now enforces the important half of the privileged-role rule—non-holders cannot take or assign it—while allowing legitimate transfer. Last-holder protection prevents a panel from becoming unadministrable. Recommend adding an explicit “transfer privileged access” step to runbooks and confirming that break-glass CLI procedures remain documented for disaster recovery.