Rbac Bundle Laravel Package

Product Decisions This Supports

• Choosing an authorization model. The bundle encodes hierarchical RBAC — roles inheriting from roles, permissions resolved through the hierarchy — plus a flat alternative (roles with directly attached permissions). It is most useful as a requirements specimen when deciding how granular access control should be: flat roles, inherited role trees, or per-object policies.
• Build vs. buy vs. borrow. The real decision is not "should we install this?" but "do we build RBAC, adopt a maintained library, or borrow an existing design?" Verdict for this package: borrow the schema and semantics, not the code.
• Roadmapping admin and user-management features. The role-hierarchy pattern helps scope delegated administration, role templates, least-privilege defaults, and permission-management screens — features that stay under-specified until enterprise or multi-team customers ask for them.
• Validating B2B/commerce use cases. Sylius is an e-commerce platform, so buyer roles (purchaser, approver, finance), vendor segmentation, and admin scoping are directly analogous. It pressure-tests whether a product needs hierarchical roles or a handful of static ones.
• Pricing legacy risk. Archived status, Symfony2-only targeting, 11 stars, and zero dependents are portfolio data points for deciding whether to keep legacy Symfony2 components or budget a migration.

When to Consider This Package

Consider it — narrowly — as a reference implementation or timeboxed stopgap when:

• You maintain a legacy Symfony2/Sylius application already on the Sylius security stack and need hierarchical roles with minimal integration effort, accepting the code as-is and prepared to vendor/fork it with named in-house ownership.
• You need to prototype or demonstrate role inheritance quickly to settle a product question, not to ship.
• The use case is internal and low-blast-radius (an admin console behind SSO) where an unmaintained dependency is a documented, tolerated risk.

Look elsewhere — and default to doing so — when:

• You are on Laravel, Symfony 5/6/7, PHP 8+, or any greenfield project. This is a Symfony2 bundle: no service provider, no Eloquent, no publishable config, no migrations, no Laravel compatibility to assess. Every integration point would be hand-written.
• You require security patching, CVE response, or vendor support. Archived/read-only means none, which is disqualifying for anything customer-facing or compliance-relevant — and authorization is the worst place to carry an unpatched dependency.
• You need ecosystem validation: 11 stars and zero dependents provide essentially no production signal.
• You need modern authorization — policy/attribute-based access control, per-resource permissions, audit logging, multi-tenant scoping — where Laravel's Gate/Policies, Symfony's voters, or spatie/laravel-permission plus a thin hierarchy layer are better fits.
• Procurement or architecture review requires an actively maintained dependency with a release cadence.

How to Pitch It (Stakeholders)

Bottom line: do not adopt this as a dependency; use it as a design reference. It is an archived, read-only Symfony2 integration for hierarchical roles with negligible adoption (11 stars, zero dependents) and no maintenance path. Shipping it would place an unpatched, unpatchable dependency in the most sensitive part of the product — authorization — and it does not run in our Laravel stack without a rewrite of every integration point.

For executives: access control is a recurring enterprise requirement, and hierarchical roles are a known, solvable pattern. This bundle gives us a concrete, zero-cost starting spec and confirms the pattern is tractable. Recommendation: fund a small spike to extract the role-hierarchy requirements, then implement on a supported foundation. That avoids both a from-scratch authorization system (expensive, risky) and an abandoned dependency (cheap now, costly later). The role-hierarchy logic itself is small — a graph traversal with cycle detection plus a cached permission expansion — so build-versus-buy favors building behind our existing Gate/Policy layer.

For engineering: treat the repository as a specification, not a library. Capture its schema (self-referencing role table with parent_id, role-permission pivot), its upward-traversal inheritance semantics, and its cache-invalidation expectations. Implement with Laravel Gates/Policies and Eloquent migrations; if a hierarchy is genuinely required, pair spatie/laravel-permission (active, Laravel-native, team already knows it) with an explicit hierarchy resolver as a domain service. Budget a 2–3 day spike, not an integration. If any team is currently pulling this in, flag it for replacement and add it to the legacy-dependency migration list. Known failure modes to design against: uncached permission expansion on every request, silent cycles in the hierarchy causing recursion, and upgrade blockers from Symfony2-era PHP constraints.