Anomalie #1
ferméModification de données administratives d'un EPN
Ajouté par Denis LIARD il y a environ 14 ans. Mis à jour il y a presque 14 ans.
100%
Description
Log : animateur
Fenêtre : Administration/EPN/Modification
Objet : non possibilité pour un animateur de modifier les informations autres que son EPN de rattachement
Mis à jour par Denis LIARD il y a presque 14 ans
- Assigné à mis à Grégory MARIGOT - TEICEE
Mis à jour par Marc CARLUCCI il y a presque 14 ans
En reprenant la notation de Jerome Lamache je crois qu'ici il s'agit du Bug #066
Un animateur ou directeur d'un GEPN (Structure_Group dans le code) ne peut pas modifier d'EPN, sauf son EPN de rattachement.
Le probleme se situe a la ligne 121 du fichier apps/frontend/modules/structure_group/actions/actions.php
Il faut verifier que l'utilisateur authentifier a les droits de modifications sur les autres EPN.
Cela signifie faire une verification
($user->hasCredential('SITES_ME_w') && $epn_id==$requested_epn_id)
||
$user->hasCredential('SITES_OTHERS_w')
pour modifier la valeur de SITES_ME et SITES_OTHERS a w il faut suivre les liens suivants
pour les animateurs:
admin.php?operation=display_facilities&id_type=facilitator&form=true&id=
pour les directeurs:
admin.php?operation=display_facilities&id_type=manager&form=true&id=
et choisir les valeurs pour Structure a modification
Mis à jour par Grégory MARIGOT - TEICEE il y a presque 14 ans
- Statut changé de Nouveau à In Progress
- % réalisé changé de 0 à 10
Mis à jour par Grégory MARIGOT - TEICEE il y a presque 14 ans
- % réalisé changé de 10 à 50
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)
- 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
Mis à jour par Grégory MARIGOT - TEICEE il y a presque 14 ans
- Statut changé de In Progress à Résolu
- % réalisé changé de 50 à 100
Mis à jour par Grégory MARIGOT - TEICEE il y a presque 14 ans
- Statut changé de Résolu à Fermé