ProxyEPN

Modifications publiées sur le svn (r452 et r453) :

Les fiches des usagers ayant un rôle (animateur ou coordinateur) sont désormais traitées à part.

Les droits correspondants (LIST/SHOW MANAGER ou LIST/SHOW COORDINATOR) sont utilisés dans leur cas, plutôt que les droits applicables aux fiches usagers (LIST/SHOW USER). Ces droits deviennent donc à la fois nécessaires et suffisants :

• On peut ne pas avoir accès aux fiches d'usagers mais avoir les droits d'accès aux fiches d'animateurs ou coordinateurs.
• Les droits d'accès aux fiches d'usagers ne permettent pas à eux seuls l'accès aux fiches d'animateurs ou coordinateurs.

Une conséquence de ces modifications : les comptes animateurs/coordinateurs n'apparaissent plus dans la liste des usagers. Ils sont visibles uniquement dans les listes dédiées. Techniquement cette séparation n'est pas obligatoire, mais elle semble intéressante... après tout un compte animateur n'a pas vraiment sa place dans le lot des usagers.

A noter une adaptation dans le menu de l'interface : le lien "Activités / Usagers" n'est pas présent pour un utilisateur qui n'a pas le droit de lister les usagers, mais s'il dispose des droits pour lister les animateurs ou coordinateurs, alors les liens correspondant seront mis à la place. Par contre si la liste des usagers est permise, seul ce lien reste pour ne pas surcharger le menu.

Modifications publiées sur le svn (r455) :

Mise en place de méthodes de recherche dans la classe sfGuardUserProfilePeer¶

De manière semblable aux méthodes classiques (apportées par MyPropelBehaviorFilters), de nouvelles méthodes adaptées aux recherches selon les rôles prennent place : criteriaFromContextForRole(), criteriaFromFiltersForRole(), retrieveByContextForRole() et retrieveByFiltersForRole().

La différence se situe essentiellement dans la construction du criteria de base dans criteriaFromContextForRole(), qui doit se charger de la jointure vers la table Structure. Ici la notion d'appartenance à un EPN ne se fait plus sur l'EPN de rattachement du compte, mais avec les EPN sur lesquels le compte exerce son rôle (d'animateur ou coordinateur).

De plus toutes ces méthodes ont un paramètre supplémentaire : le nom du rôle concerné qui est toujours à spécifier.

Détermination plus subtile du contexte d'une fiche animateur/coordinateur¶

Pour tester les droits d'accès de l'utilisateur sur une fiche d'animateur ou de coordinateur, il faut d'abord déterminer le contexte (EPN/GEPN) de l'objet cible. La méthode PeerHelper::getContext() se charge de cette tâche.

En général pour un compte usager cela se fait via son EPN de rattachement. Pour un compte ayant un rôle, ce sont les EPN concernés par le rôle qui doivent être considérés. Cependant ce changement n'affecte que l'action SHOW. Pour les actions EDIT et DELETE, c'est toujours l'EPN de rattachement qui est utilisé.

Modifications publiées sur le svn (r456) :

Le cas particulier des objets "animateur" et "coordinateur", en utilisant leurs assignations pour déterminer leur contexte, n'est initialement pas prévu par le système d'application des politiques de droits.
Pour tout objet cible est déterminé son contexte d'appartenance. Celui-ci se résumait alors à une simple paire de valeurs : les identifiants de l'EPN et du GEPN qui le "contiennent".

Mais les derniers changements pour les fiches animateur/coordinateur change la donne : en se basant sur les assignation, le contexte d'appartenance devient multiple ! Ainsi un animateur sur 2 EPN doit être considéré "contenu" dans 2 EPN (alors que traditionnellement tout objet n'appartient qu'à un unique EPN).

Le système de "contexte objet" a donc dû évoluer, pour pouvoir contenir une liste d'identifiants d'EPN et GEPN.