Doctrine Row Permission Bundle Laravel Package

Technical Evaluation

The 0.1.0 release is a pre-1.0 version bump for tourze/doctrine-row-permission-bundle, with no substantive changelog beyond a diff link. From a TPM perspective, this is a signal release rather than a feature release: it confirms active development but provides no evidence of API stability, security review, or production hardening. Treat everything as subject to change.

Architecture fit. Despite being framed as a "Laravel/PHP package," this is a Doctrine bundle. Row-level permissions are implemented at the Doctrine ORM/DBAL layer (filters, listeners, metadata), not at Eloquent. Any Laravel integration therefore requires the laravel-doctrine bridge or a hybrid Eloquent+Doctrine architecture. That is a material architectural constraint, not a footnote. The package fits naturally into Symfony/Doctrine applications; in a Laravel-first codebase it introduces a second ORM and a second persistence mindset.

Integration feasibility. Feasible for greenfield Doctrine-backed services where row-level access control must be enforced close to the database. Infeasible as a drop-in for typical Eloquent-based Laravel apps without rewriting models and repository assumptions. Enforcement is query-time, so raw SQL, native queries, and non-Doctrine access paths will bypass it unless separately constrained.

Technical risk.

• High: pre-1.0 semver means breaking changes are permitted at any minor version; 0.0.2 → 0.1.0 may already contain API changes we cannot verify from the notes.
• High: row-level security is a security-critical control. A bundle at this maturity level has no visible security posture, CVE history, or audit evidence.
• Medium: Doctrine filter bypass via raw/native SQL is a known class of failure; correctness depends on team discipline and code review, not on the package.
• Medium: query-time permission predicates can degrade performance on large tables without careful index design.

Key questions for the maintainer/vendor.

1. What changed between 0.0.2 and 0.1.0 (API, behavior, metadata schema)?
2. Is there a documented support/versioning policy and a target date for 1.0?
3. How are filters enforced against raw SQL, native queries, and DBAL-level access?
4. What is the test coverage for permission edge cases (multi-tenant, hierarchical roles, soft deletes)?
5. Is there a security disclosure process?

Integration Approach

Stack fit. Best fit: Symfony 6/7 + Doctrine ORM 2/3. Conditional fit: Laravel with laravel-doctrine and a willingness to run Doctrine alongside Eloquent. Poor fit: Laravel-idiomatic apps that rely on Eloquent scopes, policies, and Gate for authorization. If the team's mental model is Laravel policies, this package asks them to learn a parallel authorization model.

Migration path.

• Greenfield Doctrine services: low friction; register the bundle, annotate entities, define permission metadata, wire the filter into the DBAL configuration, and validate with integration tests.
• Existing Eloquent apps: high friction. Options are (a) dual-ORM with a bounded Doctrine domain, (b) incremental model migration, or (c) reject the package and implement row-level scoping with Eloquent global scopes. Option (c) is often the cheaper and more maintainable answer for Laravel-native teams.
• Existing Doctrine apps without row-level controls: moderate; start with a single non-critical entity, verify filter behavior, then expand.

Compatibility. Pin the version explicitly and avoid floating constraints given pre-1.0 status. Verify PHP version support and Doctrine ORM/DBAL major-version compatibility against the project's actual dependency graph before committing. Check transitive dependency weight and whether the package pulls in Tourze-specific abstractions that complicate upgrades.

Sequencing. (1) Spike: one entity, one permission rule, one integration test proving a denied row is filtered. (2) Verify bypass resistance with raw SQL and native query tests. (3) Benchmark query plans and add indexes for permission predicate columns. (4) Roll out to a bounded domain behind a feature flag. (5) Only then consider broader adoption, and only after a version-pinning and upgrade-review policy is in place.

Operational Impact

Maintenance. Pre-1.0 packages shift under you. Budget for upgrade reviews at every minor release and maintain a pinned version with a documented upgrade log. The sparse release notes increase the cost of each upgrade because diffs must be read manually. Assign a named owner for this dependency.

Support. No visible commercial support, SLA, or maintainer responsiveness guarantee from the release data. Escalation path is the upstream GitHub repository. For a security-critical authorization component, that is a risk to record explicitly in the risk register with an owner and a mitigation (fork, vendor, or in-house implementation fallback).

Scaling. Row-level predicates execute per query. At scale this affects query planning and index requirements. Expect to add composite indexes covering tenant/permission columns, and to monitor slow-query logs after rollout. Caching is a specific hazard: cached result sets keyed without the permission context will leak rows across users. Any cache layer in front of these queries must include the permission identity in the cache key.

Failure modes.

• Silent over-permission: filter not registered on a connection or entity, exposing all rows. Detection requires integration tests asserting denied rows are absent, not just that allowed rows are present.
• Bypass: raw SQL, native queries, or a second DB connection skipping the filter.
• Cache leakage: permission-scoped data cached without identity in the key.
• Upgrade breakage: minor version silently changes metadata semantics.
• Performance cliff: unindexed permission predicates degrading under load.

Ramp-up. Engineers need working knowledge of Doctrine metadata, DBAL configuration, and filter/listener lifecycles — a non-trivial ramp for a Laravel-native team. Estimate one to two weeks of focused effort before productive contribution, plus additional time for security review of the enforcement model. Document the permission model and the bypass risks in the team's runbook; the package will not document them for you.

TPM recommendation. Proceed only as a spike for a bounded Doctrine domain. Do not adopt in a Laravel/Eloquent core path at 0.1.0. Gate broader adoption on: a readable changelog for the next two releases, a demonstrated bypass test suite, a named maintainer contact, and a documented upgrade policy.