Doctrine Filters Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for cross-cutting data-visibility rules. Doctrine filters apply a SQL predicate to every query touching an entity — the natural place to enforce tenant isolation, soft-delete exclusion, "published-only" catalog views, or role-based row visibility without relying on every developer to remember a where clause. This package is a thin bundle around that native capability, so the real decision it informs is whether to centralize these rules at the persistence layer or keep them in repositories/services.
• Multi-tenancy architecture. If tenant scoping is enforced as a filter, "did we leak another customer's row?" moves from a code-review question to a framework guarantee. That is a roadmap-shaping decision for any SaaS pivot.
• Compliance / data-retention roadmap. GDPR-style soft deletes and audit retention are filter problems: mark rows deleted, filter them out of normal reads, expose them through an explicit escape hatch. Useful for scoping compliance work.
• Admin and support tooling. Filters give a clean, auditable way to grant elevated visibility (support impersonation, back-office views) without forking query code.
• Risk assessment, not just adoption. At 0 stars and 0 dependents this is primarily a reference implementation — it tells you the pattern is small enough to own in-house, which is itself a build-vs-buy answer.

When to Consider This Package

• Only if the stack is Symfony + Doctrine ORM. Despite being labeled a PHP package, this is a Symfony bundle. It does not apply to a Laravel/Eloquent codebase at all — the equivalent there is Eloquent global scopes or a tenancy package. Confirm the platform before spending any evaluation time.
• Only as a reading reference. The underlying API (Doctrine\ORM\Query\Filter\SQLFilter plus a config flag) is a few dozen lines; skim this repo for the shape of the solution, then implement it yourself. A dependency with no release history and no downstream users adds supply-chain and maintenance risk for near-zero code savings.
• Look elsewhere for production adoption:
  • Need soft deletes, timestamps, blameable, or translations → stof/doctrine-extensions-bundle (Gedmo) or knplabs/doctrine-behaviors, both battle-tested.
  • Need multi-tenancy → a dedicated tenancy bundle, or a first-party SQLFilter with tests around tenant leakage.
  • Need row-level security → arguably push it into the database (Postgres RLS) rather than the ORM.
• Look elsewhere regardless if you require maintained dependencies, security review, or an SLA — 0 stars / 0 dependents / no visible cadence fails a default OSS intake bar.

How to Pitch It (Stakeholders)

Executive summary: This package is a small Symfony helper for enforcing data-visibility rules (tenant isolation, soft deletes, published-only content) inside the ORM layer so they cannot be forgotten in application code. The pattern is genuinely valuable — it converts "we hope every query is scoped" into "every query is scoped by construction," which materially lowers breach and compliance risk.

But do not adopt this repository. It has no stars, no dependents, and no visible maintenance, and it is Symfony/Doctrine-specific — it does not fit a Laravel codebase. Recommendation: treat it as a design reference, allocate a short engineering spike to implement the same behavior with Doctrine's native SQLFilter (or Eloquent global scopes on Laravel), and adopt a maintained library if we need broader soft-delete/audit features. Cost: days, not weeks. Risk of adopting the package as-is: unnecessary and asymmetric.