Project

General

Profile

Project management #19938

Nouvelle organisation pour les OU (agents/usagers) (?)

Added by Frédéric Péters about 3 years ago. Updated about 3 years ago.

Status:
Nouveau
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
07 Nov 2017
Due date:
% Done:

0%

Estimated time:
Patch proposed:
No
Planning:
Demande du club utilisateur:

Description

Discussion "Systématiser l'usager d'une collectivité "Usagers" même sur du mono-collectivité ?" sur la liste.

De Benjamin :

Non, les rôles ne peuvent ni ne doivent servir au rangement, c'est le but des OUs qui vont certainement s'appeler de nouveau unité d'organisation [...]
[...]
Ce qui manque pour avoir un système d'OU du niveau de LDAP c'est la hiérarchisation [...]

Si on s'accorde sur le sujet, ce ticket peut servir à lier les différentes implications techniques, à contenir un plan d'évolution de l'existant, à pointer la documentation à faire évoluer, à tenir une date à communiquer au club utilisateur, etc.

History

#1

Updated by Mikaël Ates about 3 years ago

Voici les notes sur le sujet lors de l'EO camp, session fonctionnelle :

"""Avant les usagers n'avaient pas de collectivité associée. Dans un déploiement avec une unique collectivité. Les agents sont créés dans cette OU. Mais les droits racines d'accès aux comptes vaut pour tous les comptes et donc dans la vue de recherche tous les comptes sont mélangés.

Dans un déploiement multicollectivité, un agent dans une collectivité peut être administrateur des utilisateurs uniquement dans son OU et donc ne voir que les utilisateurs dans cet OU, les agents et donc ne pas voir les usagers. Il faut avoir le rôle utilisateur racine pour voir les usagers dans le BO.

Désormais les usagers sont créés dans la collectivité par défaut. (Migration existant ?) Donc il faut avoir le rôle utilisateurs dans la collectivité par défaut pour voir les usagers. Dans un environnement multicollectivité, il faut donc avoir le rôle utilisateurs de son OU pour voir les agents de sa collectivité, et le rôle utilisateur de la collectivité par défaut pour voir aussi les usagers.

La collectivité par défaut peut être la collectivité qui représente le mutualisateur. Donc pour donner le droits de voir les usagers il faut donner le rôle utilisateurs dans cette OU. Donc on donne le droit de voir les usagers, les agents du mutualisateur à un agent d'une collectivité d'une commune. Donc un agent de Castries à qui on veut donner le droit de gérer des usagers en backoffice, obtient par effet de bord le droit de modifier le compte des admins de la métropole.

Donc dans l'objectif de pouvoir donner des accès aux usagers indépendamment des comptes agents, il faut créer une collectivité dédiée aux Usagers, la collectivité 'Usagers', qui sera la collectivité par défaut, dans laquelle seront créés tous les comptes usagers.

--> Objectif tangible si on considère le backoffice authentic doit servir aux agents pour des opérations fonctionnelles de gestion des comptes usagers, par exemple en guichet.
--> migration de l'existant possible ?

Le role utilisateurs de l'ou Usagers sert à donner le droit de gérer les usagers.

Pour gérer ce rôle dans cette OU il faut avoir ce rôle dans l'OU Usagers ou avoir le rôle d'administration de ce rôle. Dans le cas d'un administrateur d'une collectivité qui peut gérer les comptes agents et leur donner des rôles il faut donner ce(s) rôle(s) également, pour qu'il puisse ensuite donner à des agents le droit de gérer les usagers. Pour donner ces rôles, lors de la création de ces administateurs de collectivité, il faut aller chercher ces rôles dans l'OU Usagers.

Choix fait pour le CUT : le rôle d'administration des utilisateurs dans l'OU Usagers est créé dans toutes les collectivités ce qui facilite la recherche et la compréhension. Un agent qui est administrateur dans une collectivité peut de fait gérer ce rôle. Pour créer un agent qui peut gérer les usagers, il suffit pour l'agent qui administrate de donner le rôle administrateur des usagers à cet autre, rôle qu'il trouve dans sa propre OU. Il n'a ainsi pas besoin de chercher dans une autre OU. Dans le cas général, l'agent ne connait qu'une OU, sa collectivité, donc on conserve ainsi le fait qu'il n'a pas à se poser des questions sur l'existence et le parcours des OU.

--> Porter le rôle administrateur des usagers dans toutes les ou autres que l'OU usagers partout ?
--> migration de l'existant possible ?"""

#2

Updated by Mikaël Ates about 3 years ago

Voici les notes sur la migration des déploiements existants vers une OU unique lors de l'EO camp, session technique :

"""
Trier les agents et les usagers :
  • Sur un rôle propre aux usagers ? très peu de déploiement publik différencie actuellement les usagers grâce à un rôle -> non retenue
  • Sur un rôle propre aux agents ? Sur le saas, seulement 7/17 wcs ont un rôle agent -> non retenue
  • L'usager ou l'agent a ou n'a pas d'OU ? il arrive que des agents n'ai pas d'OU ou que des usagers en est une -> non retenue
  • sur le domaine de l'email -> piste envisageable, à analyser davantage.
    """
#3

Updated by Frédéric Péters about 3 years ago

Le ticket #19979 gagne une échéance à la semaine prochaine alors qu'il me semble que les conséquences sont toujours aussi peu mesurées, que personne n'a pris sur lui ne fut-ce que la configuration et/ou migration manuelle de la démo de dev.

À précipiter les choses ainsi, ça viendrait en plus se mêler à une mise à jour d'authentic qui depuis deux mois ne parvient pas à s'organiser.

Bref, pour avancer, avant d'avoir en recette, et encore moins en prod, un Publik configuré de la sorte, il faudrait quelqu'un pour s'en occuper, tester, mettre en place, développer les patchs qui se trouveraient être nécessaires, etc.

#4

Updated by Pierre Cros about 3 years ago

Le jeudi 16 novembre 2017 à 19:52 +0100, a
écrit :

Bref, pour avancer, avant d'avoir en recette, et encore moins en
prod, un Publik configuré de la sorte, il faudrait quelqu'un pour
s'en occuper, tester, mettre en place, développer les patchs qui se
trouveraient être nécessaires, etc.

En ce qui me concerne je peux participer, sur les tests uniquement bien
entendu.

Pierre

#5

Updated by Stéphane Laget about 3 years ago

Comme je viens de le modifier sur le ticket #19979, l'échéance pour Grenoble n'est pas novembre 2018 mais mars 2018.
Contrairement à ce que l'échéance initiale pouvait laisser à penser, il n'y a pas lieu de précipiter les choses pour Grenoble.

Also available in: Atom PDF