Nova Permission Tool Laravel Package

Technical Evaluation

What it is. A Laravel Nova "tool" — a custom Vue SPA mounted into Nova's router — that provides CRUD screens for spatie/laravel-permission roles, permissions, and their assignment to users/models. Critically, it owns no authorization logic. Spatie remains the source of truth; this package is a presentation layer over tables Spatie already defines. That is the single most important architectural fact for a TPM: the coupling is shallow and the data is portable.

Architecture fit. Conceptually clean for any Laravel + Nova + Spatie shop. It slots in via NovaServiceProvider::tools() and published assets, alongside Nova's own resources. No service provider hijacking, no middleware replacement, no custom guards. If the team already runs Nova as the admin surface, the mental model matches.

Integration feasibility. Constrained almost entirely by version alignment on two independent axes:

• Nova major version — Nova has broken its tool/Vue API repeatedly (2.x → 3.x → 4.x → 5.x, including the Vue 2 → Vue 3 transition). A 2019-04-21 release targets the Nova 2.x / Laravel 5.8 era. Composer require constraints will almost certainly refuse to resolve on a current stack.
• Spatie major version — laravel-permission has since moved through multiple majors with schema, cache-key, teams, and multi-guard changes. Assumptions the tool makes about columns, pivot tables, and cache invalidation may no longer hold.

Realistic install target: a legacy Nova 2.x / Laravel 5.8–6 application, or a fork. Not a greenfield project.

Technical risk: high.

• Abandoned since April 2019, 14 stars, no visible maintainer community. For a package that sits on a privileged admin surface, that means no security response path.
• The composite score (0.93) against an opportunity score of 0.38 is a mismatch worth flagging to stakeholders: the high number is a heuristic artifact, not evidence of fitness. Low stars + a five-year-old last release in a fast-moving ecosystem is the signal that matters.
• Highest-severity unknown is permission-cache invalidation. Spatie caches permissions per guard; a UI that mutates roles without triggering php artisan permission:cache-reset produces silent authorization drift — edits appear saved but don't take effect until cache expiry.

Key questions to resolve before any commitment:

1. What is our mandated Nova / Laravel / PHP version matrix, and does this package resolve against it without --ignore-platform-reqs?
2. Does it invalidate Spatie's permission cache after every mutation? (Testable in an hour; treat a "no" as a blocker, not a nit.)
3. Does it handle teams and multiple guards, or only the default guard?
4. Who can open the tool — is access gated by a Nova gate/permission, or merely by being logged into Nova? A permission-management UI reachable by any Nova user is an escalation vector.
5. Do we have an audit-logging requirement for permission changes (SOC 2 / ISO style)? If yes, this package won't satisfy it out of the box.
6. Is there a maintained alternative that covers the same ground (vyuldashev/nova-permission) or is two Nova resources plus a belongsToMany field sufficient? At this scope, in-house is often cheaper than a fork.

Integration Approach

Stack fit. Narrow: Laravel + Nova (2.x-era) + spatie/laravel-permission. It is not a candidate for Laravel 10/11 + Nova 4/5 without forking and rewriting the Vue layer.

Migration path — and the good news. The data is the easy part. Roles, permissions, and pivots live entirely in Spatie's schema; this tool contributes only UI. Swapping it out is a UI-layer swap: composer remove, remove the tool from NovaServiceProvider::tools(), install the replacement. No data migration, no authorization code changes, no changes to @can checks in application code. Before relying on that, confirm the tool ships no migrations of its own — if it does, that's a red flag and a cleanup task.

Compatibility testing. Treat the two axes separately. Pin a Nova version and a Spatie version, then verify: role create/edit/delete, permission attach/detach, user-role assignment, cache invalidation, and behaviour under a non-default guard. Nova's Vue 2 asset bundle is the most likely hard failure on Nova 4+.

Sequencing (recommended).

1. Decide the target matrix first. If the project is not already pinned to Nova 2.x, the default answer is "do not adopt."
2. Timeboxed spike (≤1 day) in a throwaway branch: install, click through role CRUD and user assignment, verify cache reset, check guard/teams behaviour, review the tool's access control.
3. Parallel evaluate the maintained alternative (vyuldashev/nova-permission) against the same checklist. It has broader version support and an active maintainer — the comparison is likely to be decisive.
4. Fallback: build it. Two Nova resources (Role, Permission) plus a belongsToMany field on the User resource is roughly a day of work, fully owned, with our own access control and audit hooks. At 14 stars, "own it" beats "depend on it."
5. If either package is adopted: gate the tool behind an explicit permission, add write-side audit logging, and roll out to non-production first.

Decision rule. Adopt only if the target stack is already Nova 2.x-equivalent and the spike passes cleanly. Otherwise, use this repo as a reference implementation for the screens we build ourselves.

Operational Impact

Maintenance. Zero upstream. No releases in five years, no dependency bumps, no PHP 8 compatibility work, no Laravel major upgrades. The only sustainable posture is fork-and-own — which converts a "free" package into an internal codebase with an owner, a review process, and a place in the upgrade checklist. Budget for that explicitly, or avoid it.

Support. No maintainer triage, no issue response, README-level documentation only. Internal ownership is required from day one; there is no escalation path.

Scaling. Modest concern. This is an admin surface with low request volume. The real scaling questions are (a) Nova index performance with large permission sets — N+1 risk and pagination behaviour on role/permission listings — and (b) runtime cost, which Spatie's permission cache already absorbs. The tool's only scaling obligation is to invalidate that cache correctly on every write.

Failure modes, ordered by likelihood and severity:

• Composer resolution failure at install — most likely, immediate, and cheap to discover. Resolve in the spike.
• Stale permission cache after edits — highest severity, hardest to notice. Authorization silently drifts from what admins believe they configured. Mitigate with a test that asserts cache reset after each mutation.
• Nova boot / asset failures after a Nova upgrade — tool disappears or breaks the admin panel wholesale. Isolate by pinning, and treat any Nova upgrade as requiring re-validation.
• Guard or teams mismatch — permissions applied in the wrong context, producing over- or under-permissioning that looks correct in the UI.
• Missing audit trail — a compliance gap for any regulated environment, and unrecoverable retroactively.
• Access-control gap on the tool itself — anyone with Nova access can rewrite the permission graph.

Ramp-up. Low for engineers. Anyone fluent in Nova and Spatie is productive within hours; the screens are conventional. The cost is not skill, it's version archaeology — figuring out which Nova/Laravel/Spatie combination this was written against and whether our project can meet it. That work lands on whoever owns the spike, and it is the reason to timebox rather than explore.

Bottom line for the roadmap. Treat as a reference implementation and a one-day spike, not a dependency. The permission data model is portable, so the cost of choosing the maintained alternative — or of building two Nova resources in-house — is small and fully under our control. The opportunity score of 0.38 is the more honest number here.