Current Account And Routes

One of the most useful parts of account-bundle is not the ready-made screens. It is the current-account flow around the /{_account} route parameter.

Once the account is part of the route, the bundle can resolve it before your controller runs and reuse that context in Twig, access checks, and Doctrine filtering.

Keep `_account` In The URL

This is the safest route pattern:

project_list:
    path: /account/{_account}/projects
    controller: App\Controller\ProjectController::list

Several internals still read _account directly:

AccountValueResolver
AccountFilteredEventListener
AccountFilter

That is why _account should be your default route parameter name.

Building Real Account Areas

The pattern becomes more useful when you apply it to whole areas:

_provider:
    resource: 'routes/provider/*'
    prefix: '/{_locale}/provider/{_account}'

_corporate:
    resource: 'routes/corporate/*'
    prefix: '/{_locale}/corporate/{_account}'

This lets your product areas stay account-aware without repeating account-loading code in every controller.

Request Listener Resolution

AccountRequestListener runs after routing. When the request contains the configured route attribute:

it reads the raw route value
it loads the account repository for AccountInterface
it searches with find_field_name
it writes the resolved entity back into the request attribute
it stores the entity in router context
it injects the entity into Twig as app.account by default

That means a route parameter such as /{_account} turns into a real account object before your controller logic starts.

Using The Current Account In Controllers

The simplest pattern is to read the resolved account from the request:

/** @var AccountInterface $account */
$account = $request->attributes->get('_account');

On Symfony versions with ValueResolverInterface, the bundle also registers AccountValueResolver, so controller arguments typed as AccountInterface can be resolved directly:

use Softspring\AccountBundle\Model\AccountInterface;
use Symfony\Component\HttpFoundation\Response;

public function settings(AccountInterface $account): Response
{
    // ...
}

The request listener is still the more flexible runtime mechanism, especially when you rely on find_field_name.

Using The Current Account In Twig

With softspring/twig-extra-bundle installed, templates can use:

{{ app.account.name }}

This is useful for account navigation, headers, breadcrumbs, and account-scoped UI.

Practical Advice

keep _account as the current-account key
use account-aware prefixes early, not only on one page
validate the design by building one real product area such as projects, provider dashboard, or account settings
if that first area feels awkward, review the entity model before adding more screens