Produits Entr'ouvert » Publik

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 ?"""

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

• 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.
  """

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.

Le jeudi 16 novembre 2017 à 19:52 +0100, redmine@entrouvert.com 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

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.