Nova Permissions Laravel Package

Product Decisions This Supports

• Build vs. buy for the admin-plane permissions screen. The package answers one narrow question: do we spend two to four weeks building a grouped role/permission matrix in Nova, or vendor roughly 150 lines of community code and redirect that sprint to product work? Release 1.0.6 (2019-09-09) is a dependency bump — spatie/laravel-permission v3, PHP 7.2+, Laravel 6 — not a feature release, so it doesn't change the calculus; it only makes the upgrade ceiling explicit, which is the number the buy side of the ledger must be priced against.
• Whether delegated administration moves up the roadmap. "Let the customer's admin manage their own users' access" is a recurring enterprise and prosumer ask, and a grouped permission UI is the enabling screen. Cheap enough adoption can pull this forward a quarter — with the caveat that the package adds no tenant scoping, so per-tenant roles remain a separate build item regardless.
• Back-office UX investment for internal ops and support. Grouping permissions by resource (users.view, users.create, posts.publish) instead of a flat list of hundreds of strings measurably reduces misconfiguration and the ticket volume that follows it. That's a support-cost lever with a defensible ROI story independent of the package's maintenance status.
• Enterprise readiness and compliance positioning. Any RBAC surface falls in scope for least-privilege review and access-control attestations (SOC 2 CC6). Adoption or rejection is one small input into "can we demonstrate controlled, auditable access changes" — and must be weighed against what this does not do: no audit log, no approval workflow, no separation-of-duties enforcement, no change history.
• Multi-tenant roadmap constraint discovery. If per-tenant or per-team roles are planned, the abstraction this assumes — global Spatie-style roles, edited per role rather than per user-team relation — is a limitation better surfaced now than eighteen months post-adoption.
• Where it genuinely fits: agency and client admin panels on Nova, internal tooling where the admin UI is developer-adjacent, and early-stage products that need a credible permissions screen before there's headcount to build one — all conditional on the fork cost being acceptable.

When to Consider This Package

Consider it when:

• You are already committed to Laravel Nova and spatie/laravel-permission. This is a UI convenience over an authorization model you already run; it ships no permission engine, so it is worthless as a reason to adopt either.
• The user is an internal operator or trusted admin, not a customer-facing surface with adversarial users.
• You need the screen this sprint and are willing to vendor the field into app/Nova/Fields/ rather than depend on upstream. Treat composer require as a way to read the source, not as a long-term install.
• Your permission set is large enough that a flat list hurts — roughly 30+ permissions across several resources. Below that, Nova's built-in tooling is fine and this adds risk for no gain.
• Your permission names already follow a resource.action dot convention, or you will rename them before adoption. Grouping is a literal explode('.') on the first segment; the naming convention is load-bearing.
• You will supply your own enforcement (policies, gate checks) and audit logging. The matrix hides and shows checkboxes; it does not stop a crafted request.

Look elsewhere when:

• Your stack is Nova 4/5, PHP 8, or Laravel 9/10/11. The newest advertised combination is Spatie v3 / PHP 7.2 / Laravel 6, and Spatie v3 does not extend to Laravel 8+. There is no supported path forward without raising the Spatie constraint and absorbing a v3 → v5/6 migration yourself.
• You are on Spatie v5/v6. Guard handling and the permissions() return shape shifted between majors; verify every call the field makes before trusting results.
• The maintenance signal is disqualifying for your context: 126 stars, zero dependents, last release September 2019, no community pressure driving an upgrade. Assume a fork is mandatory and budget for it, or decline.
• You need tenant scoping, audit trails, approval workflows, or per-user-team role editing. All of that is build work on top; none of it ships here.
• Your permission set is heading past ~100 entries. The single-matrix UI degrades badly at that scale — you want per-resource tabs or a different tool, not more of this field.
• The surface is customer-facing and the permissions screen is part of your security boundary. It is not.

How to Pitch It (Stakeholders)

To executives: This is a small, free UI component that turns an unreadable list of 200 permission strings into a grouped checkbox matrix, so an admin can grant a role the right access in one screen. It buys us a permissions management screen for roughly one to two engineering days of vendor-and-test work, against an estimated two to four weeks to build the equivalent ourselves. It is not a security product — it does not log changes, does not enforce access, and does not isolate tenants — so it does not by itself make us enterprise-ready or close any compliance control. The honest framing is: a cheap internal admin convenience with a known expiration date.

To engineering: Read the field class end-to-end before installing — it is one file and ten minutes. Pin 1.0.6 exactly; do not use a ^ constraint on a package whose next commit could be anything or nothing. The cleanest integration leaves Nova's default Role resource untouched and ships our own App\Nova\Role with the field added, so upgrades stay survivable and the dependency stays isolated. Budget for three specific failure modes: guard mismatch (checkboxes save, hasPermissionTo still returns false — set guard_name explicitly in the seeder and on the role), sync semantics (permissions granted outside the matrix are silently dropped on the next save from Nova — decide and document whether the matrix is the source of truth or override the fill logic to merge), and the Spatie permission cache (put permission:cache-reset in the deploy script, or new permissions won't appear and you'll debug code that isn't broken). Also gate the screen with a RolePolicy and exclude the manage-roles permission itself from the matrix, or an admin can self-escalate through the UI. Test the saved state ($role->hasPermissionTo(...)), not the browser — that covers roughly 90% of what breaks here.