A la différence de la v4, en v5 on a un récapitulatif des choix réalisé dans un processus métier ce qui est très pratique. Les informations sont correctes sauf dans le cas où une même activité revient plusieurs fois. Si c’est le cas le récapitulatif affiche les informations de la dernière activité réalisée.
Steps to reproduce
Avec le module de Démo, on peut reproduire ce comportement avec le processus de création d’un nouvel utilisateur et l’activité “Choix d’un groupe”.
Dans mon exemple, la première activité “Choix d’un groupe” devrait afficher “ADMIN” au lieu de “APP_ADMIN” dans le récapitulatif et la seconde activité “Choix d’un groupe” devrait afficher “APP_ADMIN” (c’est bien le cas).
En parlant d’index, est-ce que chaque activité à un index ou un id qui lui est propre et qui sera différent même si on rappel la même activité ? Un id qui permettrait de différencer les “instances” d’une même activité.
Quand je log le contenu du paramètre context du hook validate, l’id présent est toujours le même. Je cherche une solution pour différencier l’activité “Choix d’un groupe premier appel” de l’activité “Choix d’un groupe second appel” par exemple ^^
Ce que tu as encadré c’est le row_id de la définition de l’activité,
pas les données de l’instance de cette activité (le context dans les hook qui contient la définition de l’activité et les groupes de data courantes).
Dans un screen-flow les activités sont multi-valuées pour gérer les boucles / les API pour accéder aux étapes ont un index = 0 par défaut).
A priori c’est juste un problème d’affichage qui n’en tient pas compte.
context.getDataFile("Field", "row_id", false)
c’est bien le row_id de l’objet de ton activité courante, le groupe ‘Field’ contient les attributs de ton objet saisi sur la UI.
Dans un screenflow non persistant = un assistant de saisie, c’est toujours la même instance d’activité qui travaille en cas de boucle, ca explique l’affichage erroné mais ça n’empêche pas de créer en boucle des choses (des droits).
Dans le cas d’un processus persistant, chaque activité a un identifiant AID en base avec ses données propres / est donc bien multi-valuées.
Suivant ton besoin, il faut :
soit rendre persistant ton processus (boucle au choix de l’utilisateur) avec une suppression à la fin du process ou un abandon
soit dupliquer ton activité si le nombre d’itération est connu pour avoir N instances distinctes en mémoire via des noms d’activité différentes
De notre côté on va voir si on pourrait empiler des activités distinctes en mémoire sans tout casser dans le cas d’un simple screen-flow : par exemple, laisser le comportement actuel mais juste cloner l’activité dans le process road pour garder l’historique
Le chemin de navigation clonera les données de chaque étape traversée.
Dans un screenflow, on pourra maintenant utiliser les API du ProcessRoad via getProcessRoad() pour avoir l’historique des ActivityFile : avec data + usage info distincts, donc même si l’activité a été traversée plusieurs fois