Doctrine Extensions Bundle Laravel Package

Product Decisions This Supports

• Audit-trail / data-attribution features. Blameable behaviour auto-stamps created_by / updated_by (and, combined with soft-delete, deleted_by) from the authenticated user. This is the classic substrate for "who changed this record" UI, admin activity logs, and support/troubleshooting tooling.
• Build vs. buy for compliance-adjacent features. If your roadmap includes SOC 2 / ISO 27001 evidence, GDPR data-access trails, or internal change-history requirements, "do we write attribution logic ourselves or take a library?" is a real scoping decision. This package is the buy option — but see the risk notes below before it becomes the plan.
• Soft-delete policy decisions. Pairing blameable with soft-delete lets you answer "who removed this and when" without a separate audit table — a product-level answer to "do we need a full event-sourced audit log, or is per-row attribution enough?"
• Admin/back-office use cases. Approval workflows, record ownership, and "last touched by" columns in internal tooling are cheap to ship with attribute-level stamping and expensive to retrofit later.
• Roadmap framing for stack choice (the bigger decision). This is a Symfony bundle, not a Laravel package, and it wraps Doctrine2 — not Eloquent. The product-relevant conclusion is that it does not apply to a Laravel codebase. The decision it informs is which audit-trail approach fits your actual stack: gedmo/doctrine-extensions with a listener (Symfony/Doctrine), or spatie/laravel-activitylog / an Eloquent observer trait (Laravel).
• Maintenance-burden triage. Archived status, 11 stars, and 0 dependents make this a "do not introduce" signal for new work — useful as a data point when auditing or planning to retire legacy dependencies.

When to Consider This Package

Consider it only in a narrow legacy context:

• You are already on a Symfony 2.x/3.x + Doctrine2 codebase, PHP version is pinned to that era, and the bundle is already installed or a near-identical fork is already vendored.
• You need blameable timestamps quickly for an internal, low-risk tool where the audit trail is convenience rather than a compliance control.
• You are doing archaeology — reading it to understand how attribution was implemented, or as a reference for writing your own Doctrine listener.
• The alternative is a larger migration you are not ready to fund this quarter, and you accept the orphaned-dependency risk explicitly.

Look elsewhere — do not adopt — when:

• Your stack is Laravel / Eloquent. Different ORM, different bundle model; this package is structurally unusable. Use spatie/laravel-activitylog, an Eloquent observer + trait, or model events.
• You are on modern Symfony (5/6/7) with Doctrine ORM 2.14+/3.x. The ecosystem moved to gedmo/doctrine-extensions directly (often as stof/doctrine-extensions-bundle); this archived wrapper is not the path.
• The audit trail is a compliance or security control. Archived + no maintainer + no dependents means no CVE response, no PHP 8.x guarantees, no support. You need a maintained dependency or in-house code you own.
• You are starting greenfield. Never introduce an archived bundle for new functionality; the attribution logic is ~100 lines of listener/observer code and fully within your team's ability to own.
• Any requirement for event-level auditing (before/after values, per-field diffs, immutable log). Row-level updated_by stamping does not satisfy this; you need an activity/audit log or event store.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a small, single-purpose utility that records which user created or last updated a database row. It is archived, has 11 stars, no downstream dependents, and no maintainer — the practical read is that it is not a strategic asset and should not appear in any new roadmap. The underlying capability (audit attribution) is worth having and cheap to build; the package is not worth buying. Recommendation: treat it as a reference implementation at most, and budget a small amount of engineering to own this logic in-house, or use the maintained equivalent for whichever stack we actually run on.

For engineering: Heads-up on a scoping mismatch — this is a Symfony bundle for Doctrine2, not a Laravel/Eloquent package, so it is a non-starter for the Laravel services regardless of its quality. Where we do run Doctrine, we should depend on gedmo/doctrine-extensions directly (or stof/doctrine-extensions-bundle) rather than this archived wrapper. If we find it already in the tree, put it on the dependency-retirement list: no maintainer means no PHP-version or security upkeep. For Laravel, the equivalent is a model observer plus a small trait, or spatie/laravel-activitylog if we want a queryable activity history.

For product: Worth ~1 sprint-day of scoping, not a workstream. Decide explicitly: (a) do we need only "who touched this row" (cheap, per-model attributes), or (b) do we need an auditable history of changes (costs more, but is the thing compliance will actually ask for)? Pick (b) if audit is on the compliance roadmap; otherwise implement attribution ourselves and keep the dependency count down. Do not let an archived MIT utility become a hidden single point of failure in a path we later have to defend to an auditor.