Project

General

Profile

Support #41201

Disposer d'une api permettant de lister les rôles dans un WF

Added by Stéphane Laget about 2 months ago. Updated about 2 months ago.

Status:
Nouveau
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
31 Mar 2020
Due date:
% Done:

0%

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

Description

Pour améliorer la qualité des dispatch dans les WF qui parfois doivent se faire manuellement, avoir la possibilité de créer une source de données qui listerait les rôles de l'instance.

History

#1 Updated by Frédéric Péters about 2 months ago

  • Project changed from Authentic 2 to Publik
  • Demande du club utilisateur set to No

J'étends à Publik pour une discussion plus large. On a déjà côté w.c.s. tous les rôles (via le provisionning). Quel est l'objectif ?

#2 Updated by Stéphane Laget about 2 months ago

Cas d'usage à Roanne.
J'ai une démarche de signalement mutualisée impliquant plusieurs communes ayant chacune leur instance et l'agglo.
Les communes ne sont pas organisées de la même façon pour le traitement de leur demande, je ne peux donc pas imposer les rôles de gestionnaires, en disant la voirie c'est le gestionnaire voirie.
Je voulais éviter le ping-pong de toodego qui amène de fait de la souplesse au niveau de chaque commune mais qui pose d'autres pb.
Il y a donc une démarche mutualisée avec un wf unique.
L'affectation dépend finalement des sous-types de signalement, avec des rôles différents pour chaque commune
Cela est piloté par un fichier csv, et l'action liaison fonction / rôle est paramétrée en allant chercher le nom du rôle stocké dans le fichier csv.
Ce qui fonctionne.
Je me disais que cela pourrait avantageusement est remplacé par des fiches pour gérer ce paramétrage (plus simple, plus facile à mettre à jour, plus robuste). Les fiches permettraient de sélectionner un rôle via une liste déroulante qui ferait appel à cet API.

---
Un autre cas d'usage à Villeurbanne pour les DMI (demandes de moyens informatiques internes).
Le responsable des études doit dispatcher les demandes à ses chefs de projets selon des critères complètement arbitraires.
L'idée serait de pouvoir afficher dans un formulaire de WF la liste des rôles contenant "Chef de projet DSI" (et donc de pouvoir filtrer sur cette api) pour lui proposer la liste des rôles à qui il peut affecter les demandes (on a ici un rôle = 1 chef de projet). La liaison Fonction / rôle viendrait prendre cette valeur pour affecter la fonction.
En termes de maintenance, le responsable des études devra juste mettre à jour authentic (rôles et users) et n'aurait pas à venir à chaque fois modifier les Wfs dès que son organisation change (le nb de chefs de projets est très variable sur une année), ou mettre à jour en plus un fichier csv.

#3 Updated by Thomas Noël about 2 months ago

On peut effectivement imaginer que w.c.s. lui-même propose une source de donnée "Roles" de tous les rôles qu'il connait (mais je vois assez peu d'usage).

la liste des rôles contenant "Chef de projet DSI" (et donc de pouvoir filtrer sur cette api)

Ici je vois une notion de filtre. Et ça fait effectivement penser que c'est Authentic qui pourrait répondre, et on lui demanderait de ne lister que les rôles sous un certain rôle parent (?children-of=...). (plutôt que se filtrer sur "rôles dont le nom contient tels mots").

#4 Updated by Frédéric Péters about 2 months ago

Ok, donc la demande est moins avoir une API dans Authentic et totalement d'avoir une source de données "rôles" dans w.c.s. ? (ou, dans le second cas, "certains rôles").

#5 Updated by Stéphane Laget about 2 months ago

Frédéric Péters a écrit :

Ok, donc la demande est moins avoir une API dans Authentic et totalement d'avoir une source de données "rôles" dans w.c.s. ? (ou, dans le second cas, "certains rôles").

Oui, ce qui veut dire que j'aurais dû faire le ticket sur le projet wcs ?

#6 Updated by Frédéric Péters about 2 months ago

Même si oui, si authentic avait des API sur les rôles compatibles avec les usages évoqués ici, ça marcherait aussi.

Je me dis que si ça semble commun, c'est quelque chose qui pourrait exister direct interne dans w.c..s. et sinon, oui la voie API, qui veut dire qu'Authentic devrait

1/ retourner le format {"data": [...]} plutôt que l'actuel format {"results": [...]} (sur /api/roles/, et vraisemblablement via un paramètre ou une autre URL, pour ne pas casser des utilisateurs actuels).

2/ avoir la possibilité de filtrer (sur le nom et/ou sur le rôle parent)

2b/ ce qui veut sans doute dire la possibilité de voir/contrôler le slug des rôles.

#7 Updated by Benjamin Dauvergne about 2 months ago

Oui on peut imaginer de gérer les slugs comme les noms des agendas dans Chrono et ainsi demander tous les rôles "slug=monbesoin-*".

Also available in: Atom PDF