Tutos & Astuces

Sonata AdminBundle : Récupérer l’utilisateur connecté dans une classe Admin

Imaginons que lors de l’ajout d’une entrée via l’interface admin, nous avons besoin d’informations sur l’utilisateur connecté à l’interface lors de l’enregistrement de l’entité. Pour cela, nous avons besoin du contexte...

Imaginons que lors de l’ajout d’une entrée via l’interface admin, nous avons besoin d’informations sur l’utilisateur connecté à l’interface lors de l’enregistrement de l’entité.

Pour cela, nous avons besoin du contexte de securité.
Nous allons donc tout simplement envoyer la classe SecurityContext dans notre classe Admin via un callback.

Voici à quoi ressemble notre class Admin :

<?php

namespace SLLH\BackBundle\Admin;

use Sonata\AdminBundle\Admin\Admin;
use Sonata\AdminBundle\Datagrid\ListMapper;
use Sonata\AdminBundle\Datagrid\DatagridMapper;
use Sonata\AdminBundle\Validator\ErrorElement;
use Sonata\AdminBundle\Form\FormMapper;

use Symfony\Component\Security\Core\SecurityContext;

class TrucAdmin extends Admin
{
    /**
     * @var SecurityContext
     */
    private $securityContext;

    protected function configureListFields(ListMapper $listMapper)
    {
        // Some staff...
    }

    protected function configureDatagridFilters(DatagridMapper $datagridMapper)
    {
        // Some staff...
    }

    protected function configureFormFields(FormMapper $formMapper)
    {
        // Some staff...
    }

    public function postPersist($truc)
    {
        $user = $this->securityContext->getToken()->getUser();
        // A partir d'ici, vous faites ce que vous voulez !
    }

    public function setSecurityContext(SecurityContext $securityContext)
    {
        $this->securityContext = $securityContext;
    }
}

?>

Si nous regardons d’un peu plus près ce qui nous intéresse, nous avons :

  • Un attribut securityContext pour stocker la classe relative.
  • Une fonction postPersist d’exemple où nous pouvons récupérer l’utilisateur. Je vous invite à regarder les différentes méthodes ici.
  • Une méthode setSecurityContext qui va recevoir la classe relative.

Bien évidemment, la méthode setSecurityContext ne va pas s’appeler toute seule ! :p
Nous devons donc le préciser dans la config de notre classe Admin :

<service id="sonata.admin.truc" class="SLLH\BackBundle\Admin\TrucAdmin">
    <tag name="sonata.admin" manager_type="orm" group="General" label="Truc"/>
    <argument />
    <argument>SLLH\MainBundle\Entity\Truc</argument>
    <argument>SonataAdminBundle:CRUD</argument>

    <call method="setSecurityContext">
        <argument type='service' id='security.context' />
    </call>
</service>

Et voilà le travail ! C’est assez simple en fin de compte ! 😉

Vous avez une solution plus rapide ? N’hésitez pas à le faire savoir par commentaire ! 🙂

Ce tutoriel à été réalisé sous Symfony 2.1.6 et Sonata AdminBundle 2.1.x-dev.

Share on Facebook0Tweet about this on TwitterShare on Google+0Share on LinkedIn0
  • Pierre de Lespinay

    Est-ce qu’on ne peut pas injecter le securityContext dans le constructeur en le passant en argument du service ?

  • Pierre de Lespinay

    Re. Autre question: J’ai essayé de faire la meme chose avec mon SonataUserBundle étendu. J’ai ajouté la definition du service dans `MonUserBundle/Resources/config/services.xml` mais il n’est pas lu.