Produits Entr'ouvert » Publik

Côté a2 ça va sans doute résulter en un nouveau modèle qui fait le lien entre usager et rôle.

Je vois deux options :
· celle que semble indiquer la description de ce ticket, à savoir dans ce modèle on gère simplement un champ d’affichage, et c’est encore w.c.s. qui gère le retrait du rôle.
· celle que je préfère et qui semble la plus naturelle, à savoir on gère directement dans a2 la temporalité des rôles, et cela simplifie la partie w.c.s. qui n’aurait qu’à pousser la date de fin d’octroi du rôle. Il n’y aurait un second appel que si cette date change.

Autre impact : y a-t-il besoin de distinguer dans journal des événements (utilisateur & rôle) si le rôle a été donné par api ou dans l'interface ?

Il faudrait lier ce ticket au(x) ticket(s) clients concernés qu'on sache un peu l'étendu du besoin qui sera satisfait; je parle à la fois de l'aspect rôle (Rouen? Caen?) mais aussi customisation de la barre de droite de la vue sur les utilisateurs (il me semble que ça faisait partie des raisons de ne pas faire ça simplement avec un template dans le thème client, qu'il y avait déjà d'autres modifications de ce genre ailleurs, actuellement ou envisagées).

raisons de ne faire ça simplement avec un template dans le thème client

C'est aussi/surtout l'autonomie ainsi accordée au CPF et/ou à la collectivité.

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

raisons de ne faire ça simplement avec un template dans le thème client

C'est aussi/surtout l'autonomie ainsi accordée au CPF et/ou à la collectivité.

Le plan il y a quelques eocamp plus loin c'était de mettre tout ce qui concerne la gestion des utilisateurs dans les portails, à coup de workflow/formulaires et pages (et ici c'est partiellement le cas). De la même manière que les usagers ne sont plus accédés normalement que via moteur de recherche dans le portail agent. Mais là on revient sur l'idée de faire de /manage/users/ un portail de gestion (pour les agents). On voit qu'il y a plusieurs approches possibles, ça dépend vraiment des cas d'usage, pas simplement d'un désir assez flou d'autonomie.

Si ce formulaire est là pour un chef de service quelconque pour donner des droits à un contractuel pendant une période donnée, à mon avis on ne devrait pas lui ouvrir le /manage/ d'authentic (surtout que dans 99% des déploiements les agents ne sont pas bien rangés dans un OU à part, il verra tout et trop). Si c'est juste pour simplifier la vie des administrateurs fonctionnels, qui y ont déjà accès, soit.