Acl Bundle Laravel Package

Product Decisions This Supports

• Instance-level (per-object) authorization vs. role-only authorization. This is the build-vs-buy decision behind features like "share this document with Alice," "this client can see only their invoices," or "reviewers approve records they own." Role-based checks (ROLE_EDITOR) cannot express that; an ACL layer can. This package is the glue that makes Symfony's ACL component usable — providers, service wiring, and Doctrine object-identity plumbing — so it informs the decision if and only if your codebase is already Symfony 2.x/3.x (it is not a Laravel package; Laravel's analogue is Gates/Policies plus something like spatie/laravel-permission).
• Roadmap sequencing for collaborative/multi-tenant features. Any roadmap item that implies customer-managed sharing, delegated access, or record-scoped permissions should be triaged against this capability first, because it changes data-model requirements (ACE tables, object identity) and migration cost more than it changes UI.
• Build vs. borrow for the plumbing layer. Adopting this removes a few weeks of "write the Doctrine ACL provider and wire the service container" work. That is a genuine cost saving — the opportunity score (4.72) reflects a real gap — but it is borrowing from a package with 49 stars, zero dependents, and no visible downstream adoption.
• Legacy containment vs. rewrite. If you maintain a Symfony 2/3 application with ACL-based permissions, the live decision is "keep patching, vendor the code, or migrate to voters." This package is a data point in that analysis, not a destination.
• Explicitly not supported: greenfield or Laravel decisions. Symfony's ACL component is deprecated/abandoned upstream; Symfony 5+ and Laravel have no supported path to this bundle. For those, the decision is voters/policies, tenant-scoped permission tables, or an external authorization service (OpenFGA, Keycloak, OPA/Cedar).

When to Consider This Package

Consider it when all of these hold:

• The application is Symfony 2.x/3.x (or 4.x with symfony/security-acl still installed), not Laravel and not Symfony 5+.
• You need per-object ACEs — grants on individual rows/entities — not just roles, and you want them persisted through Doctrine ORM or DBAL.
• You are already committed to the Symfony ACL model (mask builder, security identity, object identity) and need the missing container/provider wiring rather than a new authorization paradigm.
• You are willing to vendor or fork the package. With 49 stars and zero dependents, treat it as code you adopt and own, subject to your own review — not a dependency you inherit and forget.
• Timeline pressure argues against hand-rolling the provider layer, and the alternative (rewrite to voters) is out of scope for the current cycle.

Look elsewhere when:

• You are on Laravel — this bundle is structurally unusable. Use Gates/Policies; add spatie/laravel-permission for persisted role/permission tables, or a tenancy package for team-scoped access.
• You are on Symfony 5/6/7 — the underlying ACL component is abandoned and not in the supported stack. Use security voters + a domain query, which is the maintained idiom.
• Your requirement is actually role/permission-based, not per-object. ACLs add tables, joins, and cache invalidation you will not amortize.
• You need high-scale or audit-grade authorization (millions of objects, explainability, externalized policy). Look at OpenFGA/Zanzibar-style stores, OPA/Cedar, or an IdP that issues fine-grained claims.
• Your security review flags unmaintained, low-adoption dependencies in the auth path — a legitimate and likely outcome here. In that case use this repo as a reference implementation for what to build, not as a runtime dependency.

How to Pitch It (Stakeholders)

To executives (one paragraph): We evaluated oneup/acl-bundle for per-object permissions — the "who can see which specific record" capability behind sharing and multi-tenant features. It solves a real, expensive plumbing problem, but it is a 49-star, zero-dependent, effectively single-maintainer package built on an upstream Symfony component that is no longer maintained. My recommendation is not to adopt it as a strategic dependency. Its value to us is twofold: it is a cheap, low-risk accelerator for an existing legacy Symfony application that already uses ACLs, and it is a worked example of the integration work we would otherwise scope from scratch. For any new build, the supported path is voters/policies (Symfony) or Gates/Policies with a permission table (Laravel), or an externalized authorization service if requirements grow. Budget implication: adopting it saves an estimated few weeks of provider/container wiring but adds unbounded maintenance and audit risk in a security-critical path — a trade we should only accept under a documented legacy-containment exception.

To engineering: This is the wiring layer between Symfony's ACL component and the framework — Doctrine-backed ACL providers, service definitions, object-identity handling. It is competent glue, not a framework. Two hard constraints: it is Symfony-only (no Laravel application), and it targets Symfony versions where symfony/security-acl is still present. Before any use: pin or vendor the source, read it end to end (it is small enough to audit fully), and confirm your Symfony version matrix. If the goal is new functionality, propose voters with an explicit repository query instead — cleaner cache behavior, no ACE tables, no abandoned dependency. If the goal is unblocking an existing ACL-based app this quarter, this package is the shortest path and we should treat it as owned code from day one.