Dynamic Role Bundle Laravel Package

Product Decisions This Supports

• Static vs. dynamic authorization model. It forces the product decision of whether roles are defined at deploy time (config/code) or granted at runtime by admins, support agents, or onboarding flows. Any feature like "invite a teammate as Billing Admin," "temporarily grant Auditor access," or per-account custom roles requires the dynamic model.
• RBAC granularity and customization ceiling. Because roles are persisted rows rather than a fixed enum, it opens the door to customer-defined roles per tenant/organization — a common driver of enterprise upsell and a common source of scope creep. Decide deliberately whether custom roles are a paid tier feature or out of scope.
• Build vs. buy for the role storage layer. The package is a thin persistence adapter (Doctrine DBAL) for Symfony's security role concept. It answers "do we hand-roll a roles table and a user-role join, or adopt an existing adapter?" — a decision worth roughly a few days of engineering, not a quarter.
• Admin surface roadmap. Dynamic roles imply a UI: who can create roles, assign them, audit changes, and revoke them. Adopting this package makes the roles admin panel a near-term roadmap item, not a someday item.
• Audit/compliance posture. Persisted roles mean role changes are data changes and should be logged. If the product sells to regulated buyers, "who granted this permission and when" becomes a requirement this design supports (with added work) but a config-based model cannot.
• Migration and sunset planning. Anything adopted here is a schema commitment. The decision to persist roles is largely irreversible without a data migration, so treat it as an architectural commitment, not a library choice.

Important caveat for a Laravel-focused team: despite the framing of this request, ticketpark/dynamic-role-bundle is a Symfony bundle, not a Laravel package. It will not drop into a Laravel application. It is relevant as a reference design for the role-persistence pattern, not as a dependency.

When to Consider This Package

Adopt only under a narrow set of conditions:

• The application is Symfony, not Laravel.
• It targets the Symfony 2.8/3.x era with Doctrine DBAL — matching the package's last release (December 2017). Modern Symfony (5.x/6.x/7.x) and PHP 8 are effectively out of scope; expect incompatibility with the security component's current APIs.
• You need runtime-assigned roles stored outside security.yaml, and you specifically want a DBAL-level implementation rather than a full entity/ORM-based user-role manager.
• You are comfortable owning the code: zero stars, zero dependents, no release since 2017 means no community, no security response, no upstream fixes. Treat it as vendored source you fork, not a maintained dependency.

Look elsewhere when:

• You are on Laravel. Use spatie/laravel-permission or Laravel's native Gates/Policies; this bundle is architecturally inapplicable.
• You are on modern Symfony. Use an ORM-based user/role entity with a maintained role hierarchy, or Symfony's own role hierarchy plus a custom voter — actively maintained alternatives exist and this one will fight you.
• You need multi-tenancy, role hierarchies, permission-level (not role-level) granularity, or an admin UI out of the box. This package provides none of that.
• Security review is a gate. An unmaintained 2017 auth-adjacent dependency is a hard blocker in most organizations regardless of code quality.
• You want the pattern, not the package. If the only value is "here's how to store roles in a table," read the source for 20 minutes and implement it directly — the surface area is small.

How to Pitch It (Stakeholders)

For executives: "This is a small, unmaintained open-source component from 2017 that solves one narrow problem: letting roles be assigned at runtime instead of hard-coded at deploy time. It is not something we should ship as a dependency — no releases in seven years and no user base means no security support. But the capability it points at — customer-defined roles and runtime permission grants — is worth a roadmap conversation, because it's usually what enterprise buyers mean when they ask for 'flexible permissions.' I recommend we treat it as a design reference and budget the small amount of engineering to build the pattern ourselves on our actual stack."

For engineering: "It's a Symfony bundle providing Doctrine DBAL persistence for Symfony Security roles. Two problems: (1) we're on Laravel, so it doesn't apply at all — the equivalent is spatie/laravel-permission or native Gates; (2) even on Symfony, it's pinned to the 2017 era and won't survive a modern security component. The useful takeaway is the data model: a roles table plus a user-role assignment table, with role checks resolved at authentication time rather than compiled from config. Estimate the pattern at a few days; don't inherit the dependency. If we do build it, include an audit trail on role changes from day one — retrofitting that is expensive."

Bottom line: low adoption value as a package (score 0.13, 0 stars, no dependents, stale), moderate value as a prompt to make an explicit decision about static vs. dynamic authorization. Decide the product question; build the implementation in-house on the stack you actually run.