Je suis seule sur l’application
Non il n’y a pas de changement de langue
J’ai ajouté la trace
Et par curiosité je suis restée idle 30 minutes pour voir si je reproduisais, mais non :-/
Je regarderai ce qu’il y a dans les logs à la prochaine erreur, merci !
Ok tiens nous au courant de tes tests.
Si tu es en dev/designer en cours de paramétrage, c’est possible de casser le core-cache après des rechargements partiels d’objets, listes…, on ne peut pas y faire grand chose, il faut refaire un CC global. Mais ça ne doit pas se produire en production si personne ne vide jamais le cache.
De mon côté j’ai essayé de reproduire avec un héritage qui utilise le même state model et habilité à 2 objets, mais aucune transition ne se perd.
Il faudra regarder les taches cron qui passent pendant la période d’inactivité, si vous avez des traitements particuliers.
C’est arrivé aussi en production oui, c’est pour ça que je t’embête autant pour tenter de comprendre car c’est environ toutes les semaines.
Là ça n’est pas réapparu sur la dev depuis mon dernier retour, même après une période d’inactivité.
Je viens d’avoir de nouveau le souci après une période d’inactivité.
Voici les traces.
Le cache semble renvoyer les transitions du 3ème objet hérité (qui en effet ne les a pas perdues). Les autres ne sont plus là.
AppLog.info("Loop postSave wkf 1 " + fst.getGroups().size(), getGrant());`
> 2024-12-03 13:27:41,061|SIMPLICITE|ERROR||http://simplicite-dev-67bb8cd5f9-7v6cl:8080||ERROR|system|com.simplicite.util.ObjectHooks|postSave||Event: Implementation error in the postSave hook of object RciAppSub
> java.lang.NullPointerException: Cannot invoke "java.util.List.size()" because the return value of "com.simplicite.util.FieldStateTransition.getGroups()" is null
> at com.simplicite.commons.RCIB.RciWorkflowObject.postSave(RciWorkflowObject.java:385)
> at com.simplicite.objects.RCIB.RciAppSub.postSave(RciAppSub.java:361)
Donc on perd des transitions dans le core-cache pour certains objets hérités.
Ce cache est sensé être static une fois chargé ou désérialisé, donc il doit y avoir un rechargement partiel/tronqué à un moment donné.
rechargement des définitions de transitions : clear-cache partiel d’un des objets (ici RciAccountableAppsub)
mauvaise langue de getGrant().getLang() : changement de langue du user pendant la session, mais dans ce cas je ne vois pas trop pourquoi il ne resterait qu’1 objet et pas 0.
On va améliorer le 1) pour qu’un clear-cache partiel le soit un peu moins au niveau des transitions.
Par contre pour savoir pourquoi ?
il faut regarder si vous faites un select/save sur cet ObjectInternal par code ou alors vous modifiez un ENUM de cet objet à la volée, ou au sens large changez la définition d’une entité reliée à cet objet métier par code…
sinon c’est que qqun fait des modifications applicatives en prod en tant qu’ADMIN (via la UI ou import XML sur un truc relatif à RciAccountableAppsub) et sans vider tous les caches derrière.
Oui RciAccountableAppsub a dû passer en dernier puisqu’il n’y a plus que lui dans les transitions connues.
On va forcer un rechargement global des Transitions même en cas de CC partiel d’un objet métier.
C’est trop compliqué d’aller remplacer qu’une partie des droits de transitions en raison des héritages potentiels à N niveaux.