Produits Entr'ouvert » Publik

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.

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

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

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 ?

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.

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

Le CD13 dispose d'un cas d'usage pour cette fonctionnalité qui est actuellement contournée avec un champs texte d'une fiche désignant le rôle et réutilisé dans l'action "Liaison fonction/role".