ProxyEPN

La gestion des droits sur l'ensemble de l'applicatif EpnAdmin a été réétudié pour s'assurer qu'il puisse répondre efficacement aux besoins en étant fiable et cohérent.

2 postulats sont établis :

• Un utilisateur est caractérisé par un unique profil type (admin, directeur, animateur, usager ou anonyme) malgré les différentes assignations de rôles pouvant être effectuées sur diverses structures.
• L'accès sur EpnAdmin enferme l'utilisateur dans la sphère de son GEPN, les autres GEPN et entités relatives lui sont totalement étrangers (donc invisibles et inaccessibles, inutile de définir des droits particuliers)

Dans ces conditions la gestion des droits sur les modules d'EpnAdmin (Administration / Réglages...) peut trouver son sens :

• la politique appliquée à l'utilisateur est celle de son profil général
• les notions ME et OTHERS sont suffisantes, ME pour les éléments qui nous sont propres (ex: EPN de rattachement d'un usager ou EPN sur lesquels le rôle d'un directeur/animateur s'applique), OTHERS pour le reste sachant qu'on reste cloisonné dans l'univers du groupement.

La notion du ME est importante et nous apportons ici une subtilité qui a son importance pour les directeurs et animateurs. Dans leur cas, la notion d'EPN de rattachement n'a aucun intérêt à part les relier à leur GEPN. Ce qui nous interesse pour leur ouvrir des droits sont bien les structures cibles des assignations de rôles.

Pour refaire le point sur la définition des permissions :

• L'interface web permet d'administrer les droits (éditer/voir/aucun) pour chaque profil (admin/directeur/animateur/usager/anonyme) et pour chaque module (avec distinction ME/OTHERS)
• Chaque utilisateur dispose d'un profil type qui déterminera ses droits sur les modules en posant des Credentials. Puisque 'éditer' implique 'voir', un credential 'w' crée explicitement le 'r' correspondant pour simplifier les tests.
• Les règles de sécurité de Symfony s'appliquent en premier pour filtrer l'accès vers les actions des modules. Elles sont définies dans les fichiers conf/security.yml
• Pour affiner les contrôles des permissions, des tests sont ensuite fait aussi bien dans les actions que les templates. La méthode hasCredentials() permet d'interroger les droits de l'utilisateur sur les modules.
• Des méthodes spécifiques permettent de simplifier les controles, telles que isSuperAdmin() et les nouvelles isStructureAdmin() et isStructureGroupAdmin(). Ces dernières controlent les credentials sur une structure en vérifiant de pair les assignations de rôles

Un autre postulat a été établi pour décider des permissions des animateurs/directeurs assignés sur un groupement : leur rôle s'étend implicitement à tout EPN du GEPN.
Si ce comportement n'est pas celui attendu et qu'on souhaite qu'un rôle sur un GEPN n'implique aucun rôle sur les EPN, celà peut être modifié simplement en retirant l'appel à isStructureGroupAdmin() qui est fait depuis isStructureAdmin()

Note: une fois les contrôles correctement appliqués dans le code de l'applicatif, des ajustements sont nécessaires dans les réglages de l'admin web

Modifications publiées sur le svn (r256 et r257) :

L'ensemble des controles sur les structures ont été revus pour fixer les autorisations et interdictions comme attendu.