Novatoolpermissions Laravel Package

Technical Evaluation

Architecture fit. silvanite/novatoolpermissions is a Laravel Nova tool that renders an admin UI over spatie/laravel-permission. It manages roles, permissions, and which Nova tools appear in navigation for a given user. It is not an authorization engine — enforcement stays in Laravel gates, policies, middleware, and application-level hasPermissionTo checks. The strategic read for a TPM is that this is a thin, replaceable presentation surface sitting on top of a durable schema. If the tool dies, the Spatie tables survive and can be driven by seeders, Artisan commands, or in-house screens. That containment is the primary reason to evaluate it at all; it means the blast radius of adopting a dormant dependency is a UI replacement, not a data migration.

Integration feasibility. Mechanically simple: composer require, register the tool in NovaServiceProvider::tools(), publish config, run Spatie migrations, and gate the tool itself behind a permission. The real work is dependency resolution, guard-name alignment, and reconciling whatever currently owns role data into Spatie as the single source of truth. A TPM should also frame the "hide unauthorized tools from the Nova sidebar" feature correctly for stakeholders: it is an admin UX improvement, not a security boundary. It reduces clutter and accidental discovery; it does not stop a determined user who can hit the underlying resource routes directly.

Technical risk. The core risk is momentum, not capability. Last release 2019-04-28, ~100 stars, zero dependents, effectively one maintainer, MIT. It tracks two of the fastest-moving dependencies in the ecosystem — Nova and Spatie — both of which have changed substantially since 2019. Installability against a current stack is a coin flip until proven. The documented v1.0.9 change is the tell: a patch release changed slug semantics from field name to attribute name and required slug field ^1.2.3. That is a breaking parameter change shipped as a patch, and its failure mode is silent — wrong or missing slugs rather than an exception. For a permissions-adjacent tool, silent wrongness in an admin UI that writes role data is the worst class of defect.

Key questions before commitment.

1. What exact Nova, Laravel, PHP, and Spatie versions are we pinned to, and does composer require --dry-run resolve against them?
2. Is spatie/laravel-permission already our system of record, or would this create a second place where authorization data is defined?
3. Who owns role/permission data today — seeders, config, direct DB edits, another admin surface — and what is the backfill plan?
4. Which gates, policies, and middleware will consume these permissions? If enforcement is thin, the UI is premature.
5. How many guards or tenants exist? Does the tool model them, or assume a single default guard?
6. If upstream never ships again, who owns an MIT fork, and is that realistic given the small code surface?
7. What is the in-house estimate for the same three screens, so "buy" has a concrete number to beat?

TPM stance. Proceed only as a time-boxed pilot with a written kill criterion. Acceptable as a convenience UI behind our own authorization logic; unacceptable as load-bearing security infrastructure.

Integration Approach

Stack fit. Only a fit for a Laravel + Nova shop that has already standardized on Spatie for roles/permissions. Poor fit if Nova is not already the admin surface, if roles are developer-authored and rarely change, if we are mid-migration to a newer Nova major, or if we need a maintained dependency in the authorization path. There is no reuse outside Nova — the entire value is the Nova screens.

Migration path. Time-boxed spike with explicit exit criteria, not a rollout.

1. Feasibility gate (½–1 day). Branch, install against exact constraints, boot Nova, confirm the tool registers and renders. If Composer cannot resolve, or it 500s on current Nova, stop and move to fork-or-build.
2. Data reconciliation. Declare Spatie tables the single source of truth. Map existing roles into Spatie's schema and verify guard names match application guards exactly — mismatched guards are the classic cause of "permission exists but access denied."
3. Wire enforcement before exposing the UI. Land gates, policies, and middleware first. Shipping a permission editor with nothing enforcing those permissions invites admins to grant access that does nothing, eroding trust in the surface.
4. Slug audit. Grep resources, seeders, imports, and API payloads for slug; confirm each passes an attribute name, pin the slug field to ^1.2.3, and add regression tests asserting stable slugs on create and update.
5. Admin rehearsal in staging. Exercise create/edit/assign flows, including a permission rename, and verify resulting access end-to-end with a real user account.
6. Cutover with cache rebuilds. Run config:clear, cache:clear, optimize:clear. Cached config is the classic way this change hides until production.

Compatibility. Four constraints must hold simultaneously: Nova major, PHP version, Spatie major, and slug field ^1.2.3. They interact — bumping Spatie to a supported release is likely to break the tool regardless of the slug issue. Sequence dependency work before the tool install so we fail fast on the expensive constraint.

Sequencing rationale. Enforcement before UI; audit before upgrade; spike before ticket. Each step is cheap to reverse. The expensive mistakes — a double source of truth, unenforced permissions exposed to admins, blind patch upgrades — are all avoided up front.

Operational Impact

Maintenance. Assume we own it. A 2019 package with zero dependents will not receive fixes for current Nova or Spatie releases. A TPM should name a fork owner, pin versions explicitly, and budget a small maintenance reserve. MIT plus a small code surface makes a fork realistic — but only if someone is actually named to carry it. "Someone will fix it if it breaks" is not a plan, and this is the single most likely failure of the whole initiative.

Support. No vendor support, no issue-response expectation, and no security advisories channel. Internal support means the owning team fields questions from admins using the screens and handles the eventual version-compatibility incident. Treat this as an internal tool with an internal SLA, not a purchased product.

Scaling. Two axes. First, permission cardinality — the Spatie permission cache is per-user, and permission sets that grow into the hundreds with frequent edits make cache invalidation the operational hotspot; plan a rebuild step into any bulk edit workflow. Second, guards and tenancy — the tool's model must match ours. If we run multiple guards or per-tenant role scoping, verify behavior before committing; retrofitting tenancy into a UI that assumes a single default guard is custom work, which collapses the build-vs-buy saving.

Failure modes to plan for.

• Silent slug wrongness — permissions written with incorrect slugs that appear fine in the UI but never match in checks. Mitigate with regression tests, not review.
• Guard mismatch — role exists, user lacks access. Mitigate with an end-to-end staging rehearsal per guard.
• Cached config masking changes — works in staging, broken in production. Mitigate with a documented cache-clear step in the runbook.
• Double source of truth — seeders and the UI diverge. Mitigate by declaring Spatie authoritative and retiring other paths.
• Unenforced permissions — admins grant access that no gate reads. Mitigate by shipping enforcement first.
• Abandonment — a Nova or Spatie upgrade breaks the tool with no upstream fix. Mitigate with pinned versions and a named fork owner.

Ramp-up. Low technical ramp for admins — the value proposition is precisely that non-developers can manage roles without a deploy. The ramp that matters is organizational: documenting who may grant what, establishing an approval habit before the screens go live (the tool provides no approval workflow or audit trail — those remain ours), and training admins that hiding a Nova tool is convenience, not security. Budget a short enablement pass and a written permission-administration policy alongside the pilot; the tool removes the developer bottleneck, which means it also removes the informal checkpoint that bottleneck provided.