Je rencontre un bug dans un processus où le formulaire d’édition ne se met pas à jour après une nouvelle sélection lorsqu’on revient en arrière dans le processus.
Mon processus comporte les étapes suivantes :
ISTOP-SITE : Sélection d’un site géographique
ISTOP-TPLELT : Sélection d’un ISTOP dans une liste filtrée par le site, puis édition dans un formulaire
ISTOP-TPLCHAR : Edition des caractéristiques de l’ISTOP
ISTOP-TPLIDV : Edition des identifiants
Steps to reproduce
This request concerns an 6.2.20 Simplicité instance
Je sélectionne un site
À l’étape suivante, la liste des ISTOP s’affiche correctement. je sélectionne un ISTOP (disons “ISTOP-A”)
Le formulaire d’édition de ISTOP-A s’ouvre, je fais ma modification, tout va bien
Je continue les étapes suivantes
Je reviens en arrière jusqu’à l’étape de sélection de l’ISTOP
La liste s’affiche correctement, avec les bons éléments
Je sélectionne un autre ISTOP (disons “ISTOP-B”)
Problème : Le formulaire d’édition m’affiche toujours ISTOP-A au lieu de ISTOP-B
Le bug ne se produit qu’au deuxième passage (après un retour arrière). Au premier passage, tout fonctionne normalement.
Ce que j’ai essayé dans le code (dans le hook preLock, sans succès) :
Rien de tout ça ne change le comportement. La liste affiche bien les bons éléments, mon code de filtrage fonctionne, c’est uniquement le formulaire d’édition qui s’obstine à recharger l’ancien enregistrement.
Le version 6.2 n’est désormais plus supportée, il faudra passer obligatoirement en 6.3 pour bénéficier de la maintenance.
Par défaut un activité de “création” se repositionne sur le record déjà créé en cas de retour arrière, et l’activité passe en “mise à jour” de ce qui a déjà été créé. Un retour arrière ne supprime pas ce qui a été créé pour ne pas perdre les données saisies.
Votre retour arrière devrait donc être interdit (activité irréversible) ou passer par une étape/action de suppression pour recommencer l’étape de création : supprimer par code le record et remettre l’activité en type NEW, mais bon ça fera perdre tout ce qui aura été saisi.
Sinon votre code doit prévoir la mise à jour de ISTOP-B si un record existe déjà (en testant le row_id dans les data de l’étape) et pas uniquement la création en cas de retour arrière.
Merci pour votre réponse. Rendre le step irréversible n’est malheureusement pas envisageable dans notre cas d’usage car l’utilisateur doit pouvoir revenir en arrière pour corriger sa sélection.
Pour préciser le contexte : il ne s’agit pas ici d’une activité de création. L’étape ISTOP-TPLELT est une activité de sélection puis mise à jour d’un enregistrement existant (un élément topologique ISTOP). Aucun record n’est créé lors de cette étape, l’utilisateur sélectionne un enregistrement existant dans la liste puis le modifie.
Le scénario est le suivant :
L’utilisateur sélectionne ISTOP-A dans la liste, le formulaire s’ouvre, il le modifie et valide
Il avance dans le processus, puis revient en arrière sur l’étape ISTOP-TPLELT
La liste s’affiche correctement, il sélectionne ISTOP-B
Le formulaire affiche toujours ISTOP-A
Suite à votre suggestion, j’ai essayé de détecter le changement de sélection dans postValidate et de forcer un tpl.select(newRowId) quand le row_id est différent du précédent. Le problème est que context.getDataValue(“Field”, “row_id”) dans postValidate retourne déjà l’ancien row_id (celui de ISTOP-A), pas celui de la nouvelle sélection (ISTOP-B).
Dans le cas d’une activité de type mise à jour (et non création), le comportement est-il le même ? Le framework réinjecte-t-il systématiquement le row_id de la précédente validation dans les données de l’activité lors d’un retour arrière ?
Y a-t-il un moyen de purger les données persistées dans l’ActivityFile pour un step donné, afin que le framework ne réutilise pas l’ancien row_id lors du retour arrière ?
Merci pour ces précisions
.
De façon générale les activités traversées conservent leurs données en mémoire / accessible via les DataFile context.get/setDataValue, pour les réutiliser en cas de retour arrière. L’objet métier (instance bpm de ObjectDB) est contextualisé d’après les données de l’activité, ce n’est pas lui qu’il faut changer, mais les données de l’instance de l’étape (ActivityFile qui contient des DataFile).
C’est donc à vous de retirer le “row_id” de l’étape de mise à jour si on change de sélection avant. Par exemple :
@Override
public Message preLock(ActivityFile context) {
// Avant d'afficher l'étape de sélection
if ("STEP-SELECT".equals(context.getActivity().getStep())) {
// Récupérer le contexte de l'étape suivante de mise à jour s'il existe
ActivityFile stepUpd = getContext(getActivity("STEP-UPDATE"));
// Si étape déjà réalisée, réinitialiser le record à recharger en mise à jour
String stepRowId = stepUpd!=null ? stepUpd.getDataValue("Field", "row_id") : "";
if (stepUpd!=null && !Tool.isEmpty(stepRowId))
stepUpd.removeDataFile("Field", "row_id");
}
return super.preLock(context);
}