EasyAdmin 5.10 enforces permissions on custom actions and adds per-entity confirmation dialogs

EasyAdmin 5.10 is out. According to the release announcement by Javier Eguiluz on dev.to, the Symfony admin bundle now enforces the permissions attached to custom actions, allows confirmation dialogs to change depending on the entity being modified, introduces per-field badge styling, ships a self-styling flag component, adds a form field reference page to the UI Kit, and avoids building its services on requests that have nothing to do with the backend. The release also fixes issues left over from the redesign introduced in EasyAdmin 5.9.

Custom actions finally enforce their permissions

Historically, EasyAdmin verified permissions only for the actions it ships with itself, such as edit and delete. For custom actions, calling setPermission() or disable() merely removed the button from the interface; the underlying route stayed open unless the developer remembered to add a check like denyAccessUnlessGranted() inside the method.

That gap is now closed. A permission declared in configureActions() is the single source of truth: EasyAdmin hides the button and also rejects direct URL access with a 403 response when the user lacks the required role. The enforcement covers actions wired through linkToCrudAction() as well as those using linkToRoute() against a custom action route on the same CRUD controller. Manual checks already written inside those methods keep working and simply become redundant, so no code changes are required.

The announcement stresses that the old behaviour was documented rather than a security flaw, since developers were expected to guard their own routes. Even so, the new default removes a step that was easy to forget.

Confirmation messages that adapt to the row

The askConfirmation() method, which shows a modal before an action runs, previously took one message shared by every row. A contribution from phcorp changes that: the method now also accepts a closure that receives the entity, mirroring how action labels already work.

The closure can return true for the generic message, false to run the action without any confirmation for that entity, or a string or TranslatableInterface object for a bespoke prompt. Custom messages are translated and still support the %action_name%, %entity_name% and %entity_id% placeholders. The announcement gives two use cases: warning that deleting a category also removes its posts, and asking for confirmation only on published content while drafts are archived immediately.

Finer control over badge styles

Since EasyAdmin 5.8, Crud::setBadgeVariant() has set the badge appearance for an entire dashboard or CRUD controller. Version 5.10 adds a setBadgeVariant() method to the individual fields that render badges: AssociationField, BooleanField, ChoiceField, CollectionField, CurrencyField, LanguageField and LocaleField. It accepts a string or a BadgeVariant enum case among light, solid, outline and dot. A field-level variant overrides the controller-level setting, and badges fall back to the light look when neither is configured.

A flag component that carries its own styles

Inside the backend, flag icons get rounded corners and a subtle outline so flags with large white areas, such as those of Japan or Poland, don't blend into the background. Those rules used to live in the bundle's CSS, so reusing the flag Twig component elsewhere in an application meant styling it by hand. The component now bundles its own styles and gains two props, radius and bordered, for configuring corner rounding and the outline.

A form field reference inside the UI Kit

The UI Kit, a set of preview pages inside your own dashboard, gains a new page containing a form with every field type EasyAdmin supports natively, from text inputs and editors to choices, dates, collections and file uploads. Because it renders inside the developer's dashboard, it picks up the project's theme and custom CSS, and toggles let you preview fields with help messages, validation errors or in a disabled state. Like the rest of the UI Kit, the page exists only in debug mode and is not exposed in production.

Less work on non-admin requests

Most applications running EasyAdmin also serve a public website or an API, yet the bundle was constructing many of its own services on every request. The reason, per the announcement, is that Symfony builds event listeners and argument value resolvers before knowing whether they are needed, and EasyAdmin's depended on factories, registries and the route generator. In 5.10 the admin route subscriber receives a single service locator and only pulls services once it confirms the request targets the backend, while the argument resolvers run at a lower priority so Symfony resolves controller dependencies first. Developers get the improvement without changing anything.

Why it matters

The headline change is behavioural: permission enforcement now matches what the UI already suggested, closing a documented but error-prone gap between hidden buttons and open routes, and it does so without breaking existing code. Per-entity confirmations and per-field badge variants are smaller ergonomics wins that cut boilerplate in real admin workflows. The lazy service loading benefits every Symfony application that runs EasyAdmin alongside a public frontend or an API. For teams already on the 5.x series, this looks like a low-friction upgrade worth taking promptly.