ProxyEPN

TODO: Possibilité d'assignation par lot¶

Pouvoir effectuer plusieurs assignations de rôle en une seule action peut s'avérer très pratique. En particulier pour des comptes devant avoir des droits sur tout un ensemble d'EPN (ex un coordinateur sur tout un département).

Le formulaire envisagé en partant de la fiche d'un usager pourrait s'y preter : il lui suffirait de proposer la liste des EPN pour l'affectation avec un choix multiple. L'action validée devra se charger de traiter en boucle la liste des assignations à créer.

Amélioration de la récupération des rôles¶

Modifications publiées sur le svn (r446) :

La classe StructurePeer disposait d'une méthode retrieveByUserRole() permettant d'obtenir la liste complète des EPN sur lesquels tel usager dispose de tel rôle. Cette méthode spécifique est supprimé au profit de méthodes plus standards et plus fines.

• StructurePeer::criteriaFromFilters() : déja en place, elle se trouve améliorée avec l'ajout de 2 filtres supplémentaires : 'manager' => user_id ou 'coordinator' => user_id
  Il devient possible de cette manière d'obtenir la liste des rôles d'un usager tout en tenant compte du contexte de l'utilisateur (seuls les rôles sur les EPN qu'il a le droit de lister sont présents).
  Pour autant s'il est nécessaire d'obtenir la liste exhaustive, il est toujours possible de spécifier un Context nul à la méthode (par exemple pour synchroniser la fiche usager dans le LDAP)

• sfGuardUserGroupStructurePeer::criteriaFromFilters() : bien que la table sf_guard_user_group_structure_ ne dispose pas du Behavior Propel MyPropelBehaviorFilters (peu d'intérêt, vu que la notion de contexte n'est pas très utile ici), des méthodes similaires lui sont néanmoins ajoutées.
  Ainsi on trouve à présent retrieveByFilters() et même countByFilters(), qui peuvent être utiles pour récupérer les assignations présentes pour un usager ou un EPN par exemple.

Ces modifications permettent de simplifier le code tout en ayant une prise en compte des permissions des utilisateurs quand cela est pertinent.

Gestion des assignations depuis la fiche usager¶

Modifications publiées sur le svn (r447 et r448) :

La fiche d'un usager propose toujours le détail des assignations qui lui sont attribuées (en bas de page). A présent si l'utilisateur dispose des droits requis, des actions sont possibles :

• Suppression d'un rôle (lien "Destituer")
• Attribution d'un nouveau rôle

Si l'usager dispose déjà d'un rôle animateur ou coordinateur, alors seul une affectation du même type est possible. Sinon s'il s'agit encore d'un usager "standard" les 2 liens de création sont proposés.

L'attribution d'un rôle sur un usager présente un formulaire dont seul l'EPN est à spécifier (l'usager et le rôle étant déjà défini). On trouve ainsi la liste de tous les EPN disponibles (selon les droits de l'utilisateur) sous la forme d'un sélecteur à choix multiple. Un bouton permet d'inverser la sélection pour faciliter les assignations par lot.

Une fois le choix effectué et validé, l'ensemble des EPN sélectionnés sont traités pour y ajouter le nouvel animateur/coordinateur. Si le rôle existait déjà pour un EPN sélectionné, aucune action n'est nécessaire et il sera passé. Ainsi l'info-bulle en retour d'action indique le nombre réel de création d'assignation.

Note : Le formulaire ne fait que des ajouts, pas de suppression de rôle !
Malgré cela tous les EPN possibles sont présents, ceux pour lesquels l'assignation serait déjà existante ne sont pas retirés. Bien que cela ne cause aucun soucis à l'application, ce pourrait être une amélioration à apporter pour l'utilisateur.

Modifications publiées sur le svn (r450) :

Optimisation des exports LDAP¶

Un changement d'assignation (ajout ou suppression) nécessite une synchronisation de la fiche de l'usager concerné : en effet l'annuaire contient la liste des EPN sur lesquels l'usager dispose d'un rôle, de plus le profil d'un usager (son "rôle type") peut être amener à changer (première affectation ou dernière destitution).

Auparavant le déclenchement de l'export LDAP se faisait via des hooks en postSave et postDelete des objets sfGuardUserGroupStructure. Mais dans le cas d'assignation par lot, cela signifie que la fiche de l'usager sera exporté plusieurs fois consécutivement...

Pour ne pas effectuer cette succession d'exports LDAP superflus, ces hooks sont désactivés. Il revient donc aux actions de déclencher les synchro après avoir effectuer des assignations/destitutions. De cette manière lors du traitement d'un lot d'assignation sur un usager, un seul export LDAP ne sera demandé à la fin des opérations.

Modifications publiées sur le svn (r459) :

Le formulaire d'assignation est amélioré en grisant les choix déjà en place.