Nova Role Manager Laravel Package

Product Decisions This Supports

• Access-governance build-vs-buy for admin tooling. This package covers role/permission administration (including bulk grant/revoke) inside Laravel Nova, which is the kind of internal capability teams often build ad hoc. Decisions it informs: whether to standardize admin RBAC editing on this package instead of custom Nova screens, and where it sits relative to Spatie's underlying permission tables.
• Protecting privileged roles as a product requirement, not a code convention. The protected_roles concept (e.g. locking SUPER_ADMIN) is now a first-class policy enforced across all write paths. That makes it a decision you can defend in a security review: "no admin UI action can alter a protected role," rather than "the save form doesn't offer it."
• Delegated administration and least privilege. Because edit_permission is now checked by a single shared guard on every write endpoint, PMs can approve a roadmap item like "let team leads manage non-privileged roles" without granting broad admin rights.
• Schema/model flexibility as a rollout decision. The role_id fix means the tool validates against role-manager.role_model and honors a renamed Spatie roles table or a custom role model. This removes a migration blocker for teams with non-default schema conventions, and affects whether the package fits an existing install versus a greenfield one.
• Risk triage of the current release. This is a patch release with no new features or breaking changes — so it supports a "upgrade now, no redesign needed" decision rather than a roadmap slot. The security item is the one that should drive priority.

When to Consider This Package

Consider it when:

• You run Laravel Nova and use Spatie permissions, and you want role/permission editing (including bulk operations) without writing and maintaining custom Nova endpoints.
• You need privileged-role protection (e.g. an unassignable/uneditable SUPER_ADMIN) enforced at the API layer, not just visually hidden in the UI. Prior to v1.2.1 this guarantee was incomplete; on v1.2.1+ it is consistent across all three write endpoints.
• You have non-default schema — a renamed roles table via permission.table_names.roles, or a custom role model — and need the tool to respect that configuration.
• You want a delegated admin surface where an edit_permission gate constrains who can change role-permission mappings.
• You value test coverage as a trust signal: v1.2.1 adds a Pest + Orchestra Testbench suite for the role-permission endpoints, which is a reasonable bar for a security-adjacent admin tool.

Look elsewhere (or build in-house) when:

• You are not on Nova — this is a Nova vendor-route tool; the value proposition largely evaporates outside that stack.
• You don't use Spatie permissions, or you've replaced its tables/models in ways beyond the configuration hooks described here.
• You need approval workflows, audit trails, time-bound access, or change history for permission grants. Nothing in these notes indicates that; bulk toggle with a single guard is an operational convenience, not an auditable workflow. Plan to pair it with your own logging.
• You need SSO/SCIM-driven role provisioning or multi-tenant role scoping — this is a manual admin UI, not an identity pipeline.
• You require a stable, feature-rich surface today: this is a v1.2.x patch line, and the headline of this release is a fix for a gap in its own authorization guard. Treat maturity accordingly.

How to Pitch It (Stakeholders)

For executives: This is a small, configurable admin tool that lets authorized staff manage who can do what inside our Laravel admin panel, instead of engineers doing it by hand in the database. The release we're reviewing is a security hardening patch: it closes a path where a privileged role like SUPER_ADMIN could have permissions changed by a direct API request that bypassed the intended protection. It also makes the tool work with customized database schemas, and adds automated tests. No new features, no breaking changes — low-risk upgrade that reduces an access-control exposure.

For engineering leads: v1.2.1 consolidates authorization into a single shared guard applied to the save, toggle, and bulk-toggle endpoints, so edit_permission and protected_roles can no longer diverge between write paths — a direct-request bypass of protected_roles is closed. role_id validation now resolves through role-manager.role_model rather than a hard-coded exists:roles,id, so renamed Spatie role tables and custom role models validate correctly. A Pest + Testbench suite now covers these endpoints, giving us regression coverage on the security-critical surface.

Recommended action: Upgrade to v1.2.1 promptly given the security fix, verify your protected_roles and edit_permission configuration still behaves as intended, and confirm a custom role_model (if used) validates. Treat audit logging and approval workflows as separate workstreams if they're required — they are not addressed here.