Evolution #104

Accèder aux fiches animateurs/coordinateurs sans accéder aux fiches usagers

Added by Grégory MARIGOT - TEICEE about 11 years ago. Updated over 10 years ago.

Status:Fermé Start date:04/21/2011
Priority:Normal Due date:
Assignee:Grégory MARIGOT - TEICEE % Done:

100%

Category:-
Target version:ProxyEPN 2.1
Version ProxyEPN:2.0.0

Description

La gestion des permissions fait cas à part des animateurs et coordinateurs (distinction avec les opérations pouvant être effectuées sur des usagers standards).

Cela laisse supposer qu'on peut par exemple interdir l'accès aux fiches d'usagers tout en définissant un droit d'accès aux fiches des animateurs. Mais dans les faits ce n'est pas le cas : l'application de la politique de droits sur le module 'Usager' ne tient pas compte des exceptions qui peuvent exister avec les droits sur les animateurs/coordinateurs.


Related issues

related to Evolution #78: Nouveau module d'administration des droits Fermé 12/13/2010

Associated revisions

Revision 452
Added by Grégory MARIGOT - TEICEE about 11 years ago

FIX #104: Gestion plus fine de l'application des politiques de droits sur la gestion des animateurs/coordinateurs (listes et fiches en particulier)

Revision 453
Added by Grégory MARIGOT - TEICEE about 11 years ago

FIX #104: (suite r452) Filtrage strict sur les listes usagers par rôles (usagers / animateurs / coordinateurs).
NEW #105: Application de filtres persistents sur l'export CSV des usagers (choix de l'EPN) + rôle.

Revision 455
Added by Grégory MARIGOT - TEICEE about 11 years ago

NEW #104: Gestion affinée des permissions sur les fiches animateur/coordinateur basée les EPN de leurs rôles et non sur leur EPN de rattachament (pour LIST et SHOW)

Revision 456
Added by Grégory MARIGOT - TEICEE about 11 years ago

NEW #104: Evolution sur la gestion des droits avec la prise en charge de contexte multiples sur les objets cibles

History

Updated by Grégory MARIGOT - TEICEE about 11 years ago

  • Status changed from Nouveau to In Progress
  • % Done changed from 0 to 80

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.

Updated by Grégory MARIGOT - TEICEE about 11 years ago

  • % Done changed from 80 to 90

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é.

Updated by Grégory MARIGOT - TEICEE about 11 years ago

  • Status changed from In Progress to Résolu
  • % Done changed from 90 to 100

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.

Updated by Grégory MARIGOT - TEICEE over 10 years ago

  • Status changed from Résolu to Fermé

Also available in: Atom PDF