Authentication Bundle Laravel Package

Getting Started

This is a Symfony bundle, not a Laravel package — smartbooster/authentication-bundle ships a Bundle class, DI extension, and Sonata Admin integration. If you are working in a Laravel codebase you cannot composer require it and expect it to boot; treat this assessment as "what would it take to borrow the idea" unless you are in a Symfony app.

For a Symfony app that already uses SonataAdminBundle:

1. composer require smartbooster/authentication-bundle
2. Register SmartBooster\AuthenticationBundle\AuthenticationBundle in config/bundles.php
3. Clear cache: bin/console cache:clear
4. Look first at src/Admin/Extension/ (that is where action_send_account_creation_email lives) and the bundle's README for the required service/tag wiring.

First use case (and the whole point of v1.1.3): your UserAdmin class needs a "Send account creation email" action in the Sonata admin UI. Before 1.1.3 you had to copy the getExtension()/configure() plumbing by hand; now you use SendAccountCreationEmailTrait; in your Admin class and inherit the action wiring.

Minimal shape:

use SmartBooster\AuthenticationBundle\Admin\Extension\SendAccountCreationEmailTrait;

final class UserAdmin extends AbstractAdmin
{
    use SendAccountCreationEmailTrait;
}

Then verify the action appears in the admin's action dropdown (/admin/user/), not in a form.

Implementation Patterns

Trait-in-Admin (the intended v1.1.3 path). Add the trait to the Admin class that manages your user entity. Keep the trait alongside your own configure()/getBatchActions() overrides, and call parent::configure() where the trait expects it. This is the least-surprise integration: one use statement, no service definitions.

Compose, don't inherit. If you already extend a base AbstractUserAdmin shared across projects, apply the trait on that base class so every user admin inherits the action — one change, N admins. Avoid trait-on-trait chains more than one level deep; debugging get_class_methods() gets unpleasant fast.

Keep the email template out of the bundle. The action almost certainly renders a mail via Symfony Mailer/Twig. Override the template in templates/bundles/AuthenticationBundle/... rather than editing vendor files, and put the subject/body in your app's translations so you can localise per user locale.

Pair the action with an idempotency guard. "Send account creation email" is a button an admin will double-click. Wrap the send in your own flag (e.g. user->getInvitationSentAt()) and make the trait's call site a no-op when already sent — the bundle gives you the action, not the policy.

Porting the idea to Laravel. If you are evaluating this as a Laravel developer: the reusable concept is "admin-triggered invitation email", not the code. In Laravel the equivalent is a Nova/Filament action (TextEntry/Action::make('sendAccountCreationEmail')) plus a Notification/Mailable and a queued job. Do not try to shim Symfony's DI tagged services into Laravel's container; the effort far exceeds rewriting ~40 lines.

Version discipline. This is a patch-level release (1.1.3) adding a trait — additive and safe. Pin ^1.1.3 and run your admin smoke tests after the bump; trait additions can still collide with your own method names (see below).

Gotchas and Tips

Trait method collisions are the real risk of this release. Adding use SendAccountCreationEmailTrait; to an Admin class that already defines sendAccountCreationEmailAction(), configure() or getExtension() will either silently override or fatal with a conflict. PHP resolves traits after the class's own methods, so your class method wins — which means the trait's implementation can be shadowed and appear "not working". Check with bin/console debug:container and a dd(get_class_methods(UserAdmin::class))-style dump before assuming the bundle is broken.

This is Symfony-only. No ServiceProvider, no config/*.php, no Laravel auto-discovery. Any Laravel-side assessment has to be a port, not an install.

Sonata coupling. The action only makes sense inside Sonata Admin. If your admin layer is EasyAdmin, Nova, Filament, or custom CRUD, the admin.extension.action_send_account_creation_email extension point is inert. Confirm SonataAdminBundle is installed before spending time here.

Mailer config is yours, not the bundle's. A missing MAILER_DSN, an unverified sender domain, or a dev environment with mailer: null://null will make the action appear to succeed while sending nothing. Debug in this order: bin/console debug:config framework mailer, then bin/console messenger:failed:show if mail is queued, then the Symfony profiler's Mailer panel.

Cache is the usual suspect. After adding the trait, bin/console cache:clear (and cache:warmup in prod). Sonata caches admin metadata aggressively; stale metadata is the #1 reason a new action "doesn't show up".

Extension points if the trait isn't enough. Decorate the bundle's extension service, or override the Twig template and translation keys. If you need a different email per role, subclass the Admin and override the send method rather than forking the bundle.

Upgrade note. Since there is no lockfile evidence of your current version, assume you may be jumping from an unknown 1.0.x/1.1.x. Run composer update smartbooster/authentication-bundle --with-dependencies and diff the vendor CHANGELOG for any unreleased-in-notes changes before deploying to production admins.