Acltree Bundle Laravel Package

Product Decisions This Supports

• Scoping the "inherited permissions" feature. If any roadmap item reads like "permissions should cascade," "sub-folders inherit the parent's access," or "a manager sees what their reports see," this repository is a useful requirements artifact. It makes the true cost visible: you are not buying a checkbox, you are buying tree storage, an ACL resolution layer, inheritance semantics (nearest-ancestor vs. deny-overrides vs. depth limits), cache invalidation on tree moves, and the admin UI to manage it all.
• Build vs. buy vs. port. With 17 stars, 0 dependents, and an opportunity score of 0.38, the honest framing is reference implementation, not dependency. The decision this informs is "extract the pattern and build it natively," not "add to composer.json." Zero dependents is the load-bearing signal — nobody has run this in production that we can learn from.
• Framework-fit triage (the fastest decision here). This is a Symfony2 bundle, not a Laravel package. It cannot be installed into our Laravel codebase: it is bound to the Symfony2 DI container, Doctrine ORM entity mapping, and symfony/security-acl (deprecated in Symfony 3.0, removed in 4.0). That one fact should close any "let's just pull it in" ticket before an engineer spends a sprint discovering it. The PM outcome is a redirect, not an evaluation.
• Legacy portfolio assessment. If we still operate any Symfony2 service, this is a plausible low-cost fit there — and simultaneously a canary. A candidate dependency that only targets Symfony2 is evidence the surrounding stack is EOL and should be on the modernization roadmap.
• Prioritizing the security-critical path. ACL inheritance is a path where a bug is silent privilege escalation or silent lockout, not a visible UI defect. Surfacing this package as a design reference lets us argue for test budget and a deny-by-default posture up front, rather than discovering it in a pentest.
• Use cases worth prototyping on our own stack: multi-tenant organizational hierarchies (org → team → member), document/DAM folder permissions, CMS category-level editorial rights, project/workspace nesting in SaaS tools, and approval chains where a manager inherits a report's visibility.

When to Consider This Package

Consider it only if all of the following hold:

• The target application is Symfony2 (or a very close legacy line) with Doctrine ORM entities. Anything else and it is a non-starter.
• You need both an entity hierarchy and ACL permissions in one unit. The differentiator is the combination; either half alone is solved better elsewhere.
• The organization accepts an unmaintained, low-traffic artifact (17 stars, 0 dependents, no maintainer of record) and is prepared to vendor and own it.
• The permission model is simple — single-inheritance, nearest-ancestor-style — such that the semantics can be read out of the source in an afternoon and frozen in a test suite.
• The alternative (a native build) is genuinely more expensive than a fork, which is rarely true on a modern stack.

Look elsewhere when:

• You are on Laravel. This is not installable, and a shim is more expensive than a rewrite. The native path is spatie/laravel-permission for grants, kalnoy/nestedset (read-heavy taxonomies) or staudenmeir/laravel-adjacency-list (write-heavy org charts, recursive CTEs) for the tree, and Laravel Gates/Policies to enforce inheritance. Lift exactly one idea from the bundle: a permissions pivot with an explicit inherit boolean.
• You are on modern Symfony (5/6/7). The ACL component it depends on no longer exists. The contemporary path is voters + security.yaml, with a tree library for the hierarchy.
• You need a maintenance guarantee, security advisories, or an SLA. None exist here, and none will be issued for the pinned, removed ACL component.
• Permission semantics are non-trivial — deny-overrides, per-node exceptions, cross-tree grants, delegated administration, audit trails. You will outgrow a 17-star bundle immediately; a first-party resolver is the correct investment.
• The requirement is hierarchy traversal only. Then the package is irrelevant and a nested-set library closes the ticket alone.

How to Pitch It (Stakeholders)

To executives: godisco/acltree-bundle is a small MIT-licensed Symfony2 bundle for hierarchical entity permissions. It is not a candidate dependency for our Laravel platform — wrong framework, negligible adoption (17 stars, zero dependents), no maintainers of record, and built on an ACL component the PHP ecosystem removed years ago. Its value is as a design reference for any roadmap item involving inherited access (org trees, folder permissions, category rights). Recommendation: do not adopt; budget a small, well-understood first-party implementation on our existing stack. We would have had to fork and own this dependency anyway — so the "buy" option saves nothing and adds abandonment risk to a security-critical code path.

To engineering: Treat the repository as a pattern library, not a dependency. The reusable idea is the composition of a tree-traversal strategy with an ACL resolver that walks ancestors and memoizes effective permissions per request. The implementation does not port — the DI container and Doctrine mapping are load-bearing, and symfony/security-acl is gone. On Laravel, replicate the concept with spatie/laravel-permission + kalnoy/nestedset (or adjacency-list CTEs), enforce inheritance in a single service class behind Gates/Policies, and cache resolved permission sets with invalidation tied to tree-mutation events rather than TTL. Sequence the work after hierarchy move/delete semantics are settled — inheritance rules are meaningless until then.

Proposed next step: a one-week spike whose deliverable is not code but a semantics spec — executable tests for nearest-ancestor resolution, deny/allow precedence, depth limits, and orphaned-subtree behavior. Implement natively against that spec. Instrument the four failure modes that matter: silent privilege escalation, orphaned nodes resolving to nothing or everything, stale cache after a subtree move, and depth-limit truncation. Approve the build only once the spec and its test suite exist.