Rbac Laravel Package

Product Decisions This Supports

• Build vs. buy for authorization: informs whether to hand-roll hierarchical role logic (admin → regional manager → support agent → read-only) or adopt an existing RBAC component.
• Feature scoping for admin/permissions UX: supports decisions about role inheritance, permission inheritance, and "who can do what" screens in back-office products.
• Roadmap sequencing for multi-tenant / enterprise tiers: clarifies whether hierarchical roles are a v1 requirement or a later enterprise differentiator.
• Architecture and dependency risk reviews: flags a low-signal (12 stars), archived, read-only component as a maintenance liability before it enters a dependency manifest.
• Ecosystem fit assessment: distinguishes a framework-agnostic PHP component split out of Sylius from a Laravel-native package, which changes integration cost and ownership.
• Compliance/audit readiness: hierarchical roles are a common input to access-review and least-privilege narratives; useful when scoping SOC 2 / ISO evidence requirements.

When to Consider This Package

• You are already inside the Sylius ecosystem and need the RBAC component that ships with it; treating this as a reference implementation rather than a fresh dependency.
• You need a small, readable model of hierarchical roles (role inheritance trees) to study or port, not to depend on.
• Your team is comfortable owning vendored/forked code and can absorb an archived dependency with no upstream security patches.
• You are prototyping a framework-agnostic PHP service where a lightweight role hierarchy is sufficient and you do not need Laravel's Gate/Policy integration.

Look elsewhere if:

• You are building on Laravel and expect native integration — this is a Sylius/PHP component, not a Laravel package; wiring it into Eloquent, middleware, and policies is bespoke work.
• You need active maintenance, security response, or documentation — the package is archived and read-only, with minimal community signal.
• You need fine-grained, attribute- or resource-level authorization (per-record policies, ABAC, tenant isolation) rather than coarse role hierarchy.
• You want a batteries-included solution — mature alternatives exist in both the Laravel world (e.g., Gate/Policy, community permission packages) and the broader PHP world (Symfony Security, Casbin, OPA-style externalized authorization).
• You require vendor support, SLAs, or a clear upgrade path.

How to Pitch It (Stakeholders)

For executives: sylius/rbac is a small, archived PHP component for hierarchical role-based access control, originally split out of the Sylius e-commerce platform. It is useful as a design reference for how role inheritance can be modeled, but it is not a strategic dependency: it is read-only, unmaintained, and has negligible community adoption. Adopting it would transfer long-term ownership and security-patching responsibility to us. Recommendation: do not add it to the roadmap as a buy decision; keep authorization as a first-class engineering workstream with an actively maintained approach.

For engineering: treat this as a pattern library, not a package. It illustrates hierarchical roles and permission checks in plain PHP, which is helpful for scoping our own model. If we are on Laravel, we should evaluate native Gate/Policy plus a maintained permission package; if we need hierarchy beyond simple roles, we should compare against Symfony Security, Casbin, or an externalized authorization service. Any reuse of this code should be a deliberate fork with an owner, tests, and a documented security-review process — never an unexamined transitive dependency. Decision needed: confirm authorization approach and owner before the next planning cycle.