User Bundle Laravel Package

Product Decisions This Supports

• Vendor and dependency diligence for admin/user-management scope. If your roadmap includes an authenticated back office (roles, groups, impersonation, profile editing), this package sits in the decision space of "which bundle provides user CRUD inside SonataAdmin." The assessment outcome is a build-vs-buy-vs-reuse call, and the answer here is neither build nor buy from this fork — it is "reuse upstream or use framework-native security."
• Risk triage on an archived fork. 0 stars, 0 dependents, archived, single-author fork. This informs a no-go for production decision and a re-open only if condition (see below). It does not support any roadmap commitment.
• Framework strategy hygiene. The package is a Symfony bundle (SonataUserBundle bridges FOSUserBundle with SonataAdminBundle), not a Laravel package. For a Laravel-centric portfolio this is a scope mismatch — it should be excluded from Laravel evaluation backlogs entirely, and it flags a gap in how packages are being sourced: an archived Symfony fork surfaced in a nominally Laravel/PHP review queue.
• Migration/legacy posture. If any existing service still depends on Sonata + FOSUserBundle, this surfaces on the roadmap as a modernization item (toward Symfony's native security/make:user + an admin layer, or off Sonata entirely), not as an adoption item.
• Use cases it would theoretically serve: admin-managed user accounts, group/role assignment, impersonation for support staff, profile self-service — all in a SonataAdmin + Symfony 2/3-era application.

When to Consider This Package

Adoption criteria — all would have to be true, and even then you should prefer upstream:

• You are on Symfony with SonataAdminBundle and FOSUserBundle, on a version line this fork targets.
• You have a specific unfixed defect or missing patch in upstream SonataUserBundle that this fork carries — verified by diffing against upstream, not assumed.
• You can accept maintenance ownership: archived means no security response, no PHP/Symfony version bumps, no issue triage. Your team becomes the maintainer.
• You have legal/licensing clearance (Sonata bundles are typically MIT; confirm the fork preserves it) and have audited the fork for unreviewed changes.

Look elsewhere — decisively — when:

• You are on Laravel. This package is not applicable. Use Fortify/Jetstream/Breeze plus spatie/laravel-permission for roles. There is no Sonata equivalent and none is needed.
• You are starting greenfield on Symfony 6/7. FOSUserBundle is end-of-life; the native Security bundle plus symfony/security-bundle user providers is the correct path. SonataUserBundle is legacy-adjacent even upstream.
• You need maintained dependencies. No stars, no dependents, archived: zero ecosystem signal, no CVE stream, no compatibility guarantees.
• You want a supported admin user manager. Evaluate upstream SonataUserBundle if you are already committed to Sonata; otherwise evaluate EA Admin, EasyAdmin, or a thin custom CRUD over Symfony's user provider.

Recommendation: do not adopt. Record as "rejected — archived fork, zero adoption signal, superseded upstream, wrong framework for our stack."

How to Pitch It (Stakeholders)

For executives (30 seconds): A dependency surfaced in our evaluation pipeline that we should decline. It is an abandoned, single-maintainer copy of a Symfony admin-user bundle — zero users, zero downstream projects, archived by its author. Adopting it would transfer all maintenance and security-patching responsibility to us, for functionality that is either already available upstream or better served by framework-native authentication. There is no cost to saying no and a real, ongoing cost to saying yes. The one useful output is a process note: archived Symfony forks should not be reaching a Laravel-oriented review queue, and we are tightening that filter.

For engineering leads: This is rmzamora/user-bundle, a fork of SonataUserBundle — user/group CRUD, roles, and impersonation for SonataAdmin-backed applications. It carries no stars, no dependents, and is archived; upstream SonataUserBundle and FOSUserBundle are themselves in maintenance/legacy territory, with Symfony's native security stack as the forward path. Concrete asks: (1) confirm no team is currently pulling this transitively — the zero-dependents signal suggests none, but verify in composer.lock; (2) if any service still runs Sonata + FOSUserBundle, raise it as a modernization epic, not a package decision; (3) for the Laravel services, close this out — Fortify plus a roles package covers the same ground with active maintenance.

The one-line framing: declining this is free; adopting it means we own an abandoned fork of a legacy bundle for a framework we don't standardize on.