Version actuel : 5.1.36
Problème constaté depuis le passage en V5
Bonjour,
J’ai 04 objets qui utilisent les mêmes transitions d’états, de temps en temps les boutons de ces transitions s’affichent seulement sur l’un de ces objets, pour les réafficher dans un autre objet, il faut vider le cache de ce dernier.
Je constate que la méthode actionEnable (des objets dont les boutons ne s’affichent pas) ne s’exécute pas.
Après un clear cache serveur, le problème disparait !
Merci
Il n’y a pas eu de changement entre la V4 et la V5 à ce niveau…
Les transitions d’états sont elles toutes habilitées à tous vos objets ?
Bonjour François,
nous devons mieux documenter le problème (avec un scénario permettant de reproduire le cas).
Ce qui est observé est que suite au clear cache global, l’ensemble des fonctionnalités est OK (boutons d’actions visibles selon les habilitations définies, transitions d’états,etc.) et que suite à une séquence non déterminée, ces boutons disparaissent pour l’ensemble des utilisateurs jusqu’à ce que nous procédions à un clear cache global.
Il s’agit de la même partie du modèle que celle impliquée dans le problème Problème incompréhensible dans les mécanismes d'héritage d'objets métiers implémentés en Java. Je ne sais pas s’il s’agit d’un problème de cache induit par notre paramétrage (avec l’héritage tel que décrit dans le post cité) ou si ça n’a rien à voir mais de fait ce sont les mêmes objets qui sont impliqués.
Si je crois que ce problème de boutons qui disparaissent s’était déjà produit avant notre upgrade en v5 (mais je ne suis pas catégorique) il se produit souvent depuis l’upgrade.
Je reboucle en interne pour renforcer l’analyse et mieux documenter le cas (en particulier avec un scénario de reproduction).
Ok je me rappelle, le problème d’héritage était lié à un bug dans l’ordre de chargement qui avait été corrigé dans la 5.1.13. Donc ne devrait plus se produire si vous êtes à jour.
Il y a peut-être un autre problème quand on réutilise un diagramme d’états dans plusieurs objets. Il devait exister en V4 car les mécanismes n’ont pas évolués.
A l’origine le cas d’usage était de pouvoir définir un processus général états/transitions :
“On instruit un dossier toujours de la même façon en terme d’étapes”.
Mais pour certains types de dossier (héritier logique), on veut pouvoir redéfinir les rôles qui agissent. Ceci explique la présence de l’objet métier au niveau de l’habilitation des transitions.
“Pour un dossier simple, l’utilisateur pourra le valider, pour un dossier complexe ce sera un responsable, mais le processus général ne change pas, il faut valider”
J’ai perdu votre cas d’héritage, mais ça doit être de cet ordre :
A mon avis les Actions ne sont pas bien remises à 0 à chaque affichage.
Le “isActionEnable” est appelé qui si l’utilisateur avait initialement les droits, ça sert à sur-filtrer, pas à autoriser “en plus”.
Merci beaucoup François pour ton retour.
@Yacinee, peux-tu réunir les éléments demandés ?
Un retour à nous faire ?
@Yacinee
Bonjour François,
Je vous ai envoyé un mail au fgenestin@simplicite.fr
Vous l’avez reçu ?
Exact je ne l’avais pas vu passer.
Je vais regarder votre paramétrage.
Au niveau paramétrage, le champs statut est utilisé dans 4 objets, mais les transitions ne sont pas toujours habilités aux groupes BCSI-BusnObject-ADMIN et/ou BCSI-BusnObject-CONTRIB. Donc à vérifier si ce n’est pas un oubli de déclaration d’habilitations sur toutes les transitions (16).
Le hook isActionEnable n’est appelé que si l’utilisateur est habilité et que l’action n’a pas été désactivée avant via un Action.disabled()
Il faut toujours retourner super.isActionEnable, et non pas juste “true”
car il faut laisser la logique par défaut pour les autres actions (isActionEnable n’est pas vide par défaut, pour appeler d’autres hooks pour les printtemplate…).
Ce hook est surchargé avec beaucoup de code je n’ai pas saisi la logique, il faut s’assurer que celui ci ne fait que de la lecture et ne modifie pas les droits, et retourne “false” s’il faut interdire l’action en fonction du contexte. J’ai vu des accès à des grant.set/removeParameter qui peut être lié à votre combinatoire inter-objets.
Le problème se passe en production ou pendant le paramétrage en dev ? Le clear-cache partiel ne doit pas bien fonctionner pour un state-model partagé sur chaque objet.
Vous avez du code Java static et celui-ci peut être difficile à recharger via un clear-cache sans redémarrer la JVM/Tomcat. Il est préférable d’avoir une classe de méthodes d’utilitaires instanciées via singleton mais “garbageable”.
En dernier recours si on ne trouve pas la cause via scénario reproductible, à titre préventif et en attendant mieux :
Exemple d’accès aux transitions / actions pour débugger dans l’initUpdate si c’est la transition ou l’action de la transition qui est absente :
// State transitions in form
ObjectField state = obj.getStatusField();
List<EnumItem> items = state.getList().getItems();
for (int i=1; items!=null && i<items.size(); i++) { // 0 = état en cours
EnumItem item = items.get(i);
FieldStateTransition tran = item.getTransition();
if (tran!=null) {
Action action = tran.getAction();
if (action!=null) action.enabled();
}
}
Un retour à nous faire ?
@Yacinee
Bonjour François,
Merci pour votre retour, pour le moment je me suis contenté des deux premiers points.
Comme je n’ai pas un scénario de reproduction, je ne peux pas vérifier si le problème est résolu.
Concernant ta question (3), le problème se passe en PROD et en DEV.
Je vous tient au courant
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.