Cms User Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for user/identity features: this is a "substitute, don't buy" decision. The underlying need — registration, login, profiles, roles, admin-managed users — is a real roadmap item for any product with a back office. But this package is not a credible supplier of it. With 0 stars, 0 dependents, and a score of 0, it is a personal fork of sonata-project/user-bundle, republished under a new name. A PM should treat the metadata as the finding: there is no community, no support contract, and no upgrade path. The decision this supports is "use framework-native auth plus a maintained roles/permissions library," not "adopt this."

• Stack-fit gate for the roadmap. Despite being described as a Laravel/PHP package, this is a Symfony bundle whose entire purpose is wiring user administration into Sonata Admin. It has no Laravel service provider, no Eloquent models, no publishable migrations in the Laravel idiom. If your roadmap assumes the Laravel ecosystem — Breeze/Jetstream/Fortify, spatie/laravel-permission, Filament or Nova for admin — then this package is a false positive from a dependency scan, and dispositioning it as such is itself the product decision.

• Scoping the admin/user-management feature. If the roadmap genuinely includes internal admin tooling (user CRUD, role assignment, profile editing, CMS-backed authentication), this package describes that feature set accurately — and that description is useful as a requirements checklist, even though the implementation is not adoptable. Use it to write the ticket, then build it on maintained components.

• Risk-register input for auth. Authentication and authorization are the highest-blast-radius surfaces in any product. Introducing a single-maintainer, zero-adoption fork into that path is a product-level risk, not an engineering preference. This package supports the decision to put user/auth dependencies on an allow-list, and to add this one to a deny-list so it stops resurfacing in automated scans and consuming review cycles.

• Legacy-portfolio triage. The only world in which this is even legible is a legacy Symfony + Sonata Admin application where the team already owns the fork and it carries a specific compatibility patch. That is a "keep the lights on" budget line, not a feature bet, and it is orthogonal to any Laravel roadmap item.

• Explicitly not supported: customer-facing identity, SSO, MFA, OAuth2/OIDC, fine-grained authorization, or anything with an SLA. The package does not credibly cover these, and the zero-adoption signal means no CVE response path.

When to Consider This Package

Consider it only when all of the following hold:

• You are already running Sonata Admin with the Sonata/FOS user stack, and this fork contains a specific, documented patch you need — verified by diffing it against upstream sonata-project/user-bundle at the pinned version.
• You can vendor or fork it internally, with a named owner, a budgeted patch set, and an upgrade plan for Symfony and Sonata majors.
• The use case is internal/back-office with limited blast radius if the package goes dark.
• Compatibility with your exact Symfony, Sonata Admin, and PHP versions has been confirmed from its composer.json — not assumed from the README.
• There is a contingency plan for abandonment: silent-18-months-then-CVE, version lock to an EOL Symfony major, and undocumented fork divergence are all realistic.

Look elsewhere — and for a Laravel product, this is the default — when:

• You are starting anything new, or building any customer-facing auth flow. Use Laravel's native auth (Breeze / Jetstream / Fortify) plus spatie/laravel-permission, with Filament or Nova for the admin surface.
• You are not already standardized on Sonata Admin. Adopting Sonata just to use this fork inverts the build-vs-buy logic entirely.
• You need maintenance guarantees, community support, or CVE response. Zero stars and zero dependents mean no ecosystem safety net — you are the maintainer from day one.
• You need SSO, MFA, OAuth2/OIDC, or fine-grained authorization. Out of scope for this package; go to a maintained identity provider.
• The package surfaced from an automated dependency scan against a Laravel repository. Close it out as a false positive and record the disposition so it does not reappear.

How to Pitch It (Stakeholders)

For executives: This is a tiny, single-maintainer fork of a Symfony admin bundle, and it has no meaningful adoption — zero stars, zero downstream dependents, zero score. It is also not a Laravel package, despite how it appeared in our dependency report; it belongs to a different framework and cannot be dropped into our stack without running two frameworks side by side, which we should not do for authentication. The risk is asymmetric: the value is a narrow, well-understood feature (admin-managed users and roles), while the cost is permanent ownership of a security-sensitive component with no upstream support. Recommendation: do not adopt. Build the same feature in one normal sprint on maintained Laravel-native components — framework auth, spatie/laravel-permission, Filament or Nova — and add this package to a deny-list so it stops consuming security and architecture review time.

For engineering: Treat this as a Symfony/Sonata artifact, not a dependency, and do not integrate it into the Laravel application. The functional intent — admin-managed users, groups, roles, profiles — is fully covered by Laravel-native substitutes, and this is a replacement, not a migration: there is no schema or data to port because the package was never in our system. If a legacy Symfony/Sonata application genuinely exists in the portfolio, redirect to upstream sonata-project/user-bundle; if the fork carries real customizations, re-fork upstream under our own namespace with a named owner and a visible patch set. Either way, pin versions, verify composer.json constraints against our PHP/Symfony targets, and record the disposition so the next scan does not reopen it. The zero stars, zero dependents, and zero score are not incidental metadata — they are the evaluation.