Rbac Laravel Package

Product Decisions This Supports

• Build vs. buy for authorization: The v1.1.0 hook surface (ap.rbac.abilitiesForUser, ap.rbac.role.assigned, ap.rbac.role.revoked, ap.rbac.checkingAbility) means most custom RBAC requirements can be met by extending rather than forking or writing an in-house permission layer. This tilts the build-vs-buy call decisively toward buy/adopt for teams whose differentiators are not authorization.
• Enterprise and multi-tenant readiness: The abilitiesForUser filter lets external packages graft permissions from LDAP groups, feature-flag services, or tenant-scoped policies. This unlocks roadmap items like SSO/SCIM provisioning, per-tenant role customization, and staged feature rollout by entitlement — without subclassing User or patching the package.
• Compliance and audit roadmap: ap.rbac.checkingAbility fires before every ability resolution, giving a low-friction audit seam for SOC 2 / HIPAA / ISO-style logging requirements. This can be scoped as a thin internal package rather than a platform-level refactor, materially reducing the estimate for "authorization audit trail" work.
• Role lifecycle notifications: role.assigned and role.revoked actions support downstream automation — access reviews, welcome/offboarding flows, Slack notifications, cache invalidation, and analytics on privilege distribution. These are cheap wins to slot into a roadmap.
• Consistent enforcement: Because hasPermissionTo() now resolves through getAbilities(), grafted permissions are honored uniformly by $user->can(), Gate::allows(), and @can. This is a product-quality point: extension authors cannot accidentally create a "works in Blade but not in policies" divergence, which reduces a common class of security bugs and support tickets.
• Platform maturity signal: A stable, documented extension API indicates the package is being positioned as infrastructure rather than a one-off. That is a favorable indicator for multi-year roadmap planning and for standardizing authorization across multiple products.

When to Consider This Package

Consider adoption when:

• You are building on Laravel and need role/permission management that integrates with the native Gate and @can surface rather than a parallel authorization DSL.
• You have or anticipate external sources of truth for permissions — directory services, IdPs, entitlement services, tenant-specific policies, or feature-flag systems — and want them to compose with local roles instead of replacing the model.
• You face audit or compliance obligations that require a record of authorization decisions, and want a supported seam rather than instrumenting your own gate wrapper.
• You need role change events to drive downstream workflows (provisioning, notifications, cache invalidation, access reviews).
• You want to avoid maintaining an in-house RBAC layer and are comfortable adopting a small, opinionated dependency.
• Your team is small and would rather spend engineering capacity on product differentiation than on permission plumbing.

Look elsewhere or proceed with caution when:

• You cannot add the artisanpack-ui/hooks dependency. v1.1.0 makes it a hard dependency — the package no longer works without it, and hook fire sites are called unconditionally. Teams with strict third-party dependency review, air-gapped builds, or a policy of minimal transitive dependency trees should evaluate this explicitly before upgrading.
• You need ABAC or relationship-based (ReBAC) authorization with deep resource-graph traversal; a role/permission model with filters may not express your policies cleanly.
• You require sub-100-microsecond authorization checks at very high volume and cannot absorb an added filter dispatch on every ability resolution. Benchmark before committing.
• You need stable long-term API guarantees; the addition of a hard dependency and unconditional hook calls in a minor version is a signal that upgrade paths may require attention.
• Your authorization needs are trivial (a boolean is_admin flag) — the abstraction cost exceeds the benefit.

How to Pitch It (Stakeholders)

For executives: This package gives us a production-grade authorization layer instead of one we build and maintain ourselves. The new release turns it into an integration point: permissions can be pulled from our identity provider, tenant configuration, or feature-flag system without forking the library, and every permission check can be logged for audit. That converts several roadmap items — SSO-driven entitlements, per-tenant roles, authorization audit trails, and access-review automation — from platform projects into small, low-risk integrations. The trade-off is one added third-party dependency, which we should clear through standard review.

For engineering: v1.1.0 exposes four lifecycle hooks via artisanpack-ui/hooks. ap.rbac.abilitiesForUser is a filter over the resolved ability list, so grafted permissions flow through hasPermissionTo(), getAbilities(), Gate::allows(), and @can consistently — no parallel code paths. ap.rbac.role.assigned and ap.rbac.role.revoked fire from HasRoles after attach/detach with (User, Role), suitable for cache invalidation and downstream events. ap.rbac.checkingAbility fires from the Gate::before shim with (User, ability, arguments) for audit logging. Note the breaking operational change: artisanpack-ui/hooks ^1.3 is now a hard dependency and hook sites are unconditional — there is no no-op fallback, so the dependency must be present in every environment, including CI and air-gapped builds. Upgrading is otherwise additive; existing role/permission behavior is unchanged.

Recommendation: Adopt and pin to v1.1.0, run the dependency change through security/licensing review, benchmark the added filter dispatch in hot authorization paths, and schedule the audit-logging and IdP-graft integrations as near-term roadmap items.