Weave Code
Novatoolpermissions Laravel Package
silvanite/novatoolpermissions
A Laravel Nova tool for managing roles and permissions directly from your admin panel. Assign permissions to roles and users through a clean Nova UI, register custom permissions, and keep access control organised without leaving Nova.
Laravel Nova Permissions (Roles and Permission based Access Control (ACL))
Frequently asked questions about Novatoolpermissions
- Does silvanite/novatoolpermissions work with the latest Laravel Nova and Laravel versions?
- The package's last release was 2019-04-28, so compatibility with current Nova majors, Laravel versions and spatie/laravel-permission releases is unproven until you test it. Nova and Spatie have both changed substantially since then, and this tool tracks both of them. Run composer require --dry-run against your exact Nova, Laravel, PHP and Spatie constraints before committing. If Composer cannot resolve, or the tool 500s after registration, treat that as the kill signal for the spike.
- How do I install silvanite/novatoolpermissions in a Laravel app?
- Install with composer require silvanite/novatoolpermissions, then register the tool in the tools() array of your app's NovaServiceProvider. Publish the config, make sure the Spatie migrations are in place, and gate the tool itself behind a permission so only authorized admins can open it. The real work is not the Composer step but reconciling existing role data into Spatie and aligning guard names.
- Does this package require spatie/laravel-permission?
- Yes. It is a Nova UI layered over spatie/laravel-permission, not an authorization engine of its own. Roles and permissions live in the Spatie tables, while enforcement still happens in Laravel gates, policies, middleware and hasPermissionTo checks. That separation is what makes the tool replaceable: drop it and both the schema and your enforcement code are unaffected.
- Is silvanite/novatoolpermissions still maintained?
- No. The last release was 2019-04-28, with roughly 100 stars, zero dependents and effectively one maintainer, under the MIT license. That does not make it broken, but it does mean you carry the compatibility risk. Plan for the possibility of forking or replacing the UI rather than assuming upstream fixes will arrive.
- How do I register custom permissions with this Nova tool?
- Permissions can be registered through the tool's configuration and the Nova UI, so you can define custom permission names without leaving the admin panel. Remember that the package is presentation only — every permission string you create still needs a matching gate, policy or middleware to actually enforce anything. If your enforcement layer is thin, building out this UI is premature.
- Can this package hide Nova tools from users who lack permission?
- Yes. It can hide Nova tools a user is not permitted to access, which cuts sidebar clutter and reduces accidental discovery. That is an admin UX improvement, not a security boundary: a determined user who knows the underlying resource routes can still attempt to reach them directly. Always enforce access with policies, gates and middleware in addition.
- Is this package a replacement for Laravel gates and policies?
- No. It manages roles and permissions data and renders Nova screens on top of it, while enforcement stays in Laravel gates, policies, middleware and application-level hasPermissionTo calls. Treat it as a convenience admin surface sitting behind your own authorization logic. It is acceptable as a UI layer, not as load-bearing security infrastructure.
- Does silvanite/novatoolpermissions support multiple guards or multi-tenancy?
- The package predates much of the current multi-guard and multi-tenant tooling in the Spatie ecosystem, and like most small Nova tools of its era it largely assumes a single default guard. If you run multiple guards or tenants, verify how roles are scoped before adopting, and expect custom work. Settle this during the feasibility spike rather than after rollout.
- What changed in v1.0.9 of silvanite/novatoolpermissions?
- v1.0.9 changed slug semantics from the field name to the attribute name and required slug ^1.2.3 — a breaking parameter change shipped as a patch release. Its failure mode is silent: wrong or missing slugs instead of an exception. For a permissions-adjacent admin UI that writes role data, verify slug behavior explicitly against your Nova fields during testing.
- What happens to my roles and permissions data if I stop using this package?
- Because all data lives in the Spatie tables, dropping the tool is a UI replacement rather than a data migration — you can drive roles and permissions with seeders, Artisan commands or in-house Nova screens. Alternatives include building the same few screens yourself (get an in-house estimate so "buy" has a number to beat), a maintained Nova permission tool, or an MIT fork. That small blast radius is exactly why a time-boxed pilot with a written kill criterion is the sensible way to adopt it.
Weaver
How can I help you explore Laravel packages today?