Je viens de faire plusieurs tests, et si le usr_login est dans le formulaire. Les problèmes 2 et 3 disparaissent.
Dans les précédentes versions, il n’y avait pas besoin de mettre le usr_login dans le formulaire. Il fallait juste en faire un attribut d'objet de l’objet métier sinon on avait des warnings.
Maintenant, il faut en plus le mettre dans le formulaire (en non-visible pour garder le même effet car je ne veut pas de ce champs). Intéressant à savoir.
Si le statut n’était pas modifiable côté front/UI mais quand même modifiable côté back/DB, c’est plutôt la version précédente qui avait un bug. En V4, on pouvait effectivement avoir un statut en lecture seule mais modifiable via le bouton de transition, ce qui représente en fait une faille de sécurité côté serveur.
Dans nos cas de test, le statut est modifiable (via le champ ou via les boutons) : ce sont les statuts suivants qui sont présents ou pas dans la liste. Le champ n’a pas à être en lecture.
Mais effectivement il faut faire quelque chose.
soit on retire les transitions si le statut n’est pas modifiable, ce qui serait à mon sens le correctif.
soit pour reconduire ce fonctionnement historique, on va devoir gérer ce cas particulier de mise à jour du statut en donnant une priorité à la transition sur le caractère modifiable du champ (donc sans retirer les contrôles sur les champs non-modifiables).
On va livrer le 2) au plus vite pour compatibilité ascendante d’un truc louche, en se rappelant bien que le 1) ne devra donc pas être considéré comme un bug (pouvoir faire une transition d’un champ non modifiable).
Effectivement, tous nos modules de notre coté fonctionnent avec la méthode 2). J’attends donc la version 5.2.3. Merci beaucoup .
@FrancoisPetite question : Si il est important pour vous d’avoir la méthode 1), pourquoi ne pas mettre un paramètre uniquement disponible pour les statuts qui nous permettrait de choisir entre la méthode 1) et 2), avec par défaut la méthode 1) ? Exemple :
Ce qui plaide pour le fonctionnement historique 2) c’est de pouvoir contraindre l’utilisateur à passer par une action de transition avec des champs à renseigner (pour compléter le changement d’état avec des données pas forcement liées à l’objet métier, comme un email, un commentaire, une PJ dans un autre objet métier…).
Si on lui autorise de modifier le champ “statut” directement depuis le formulaire, il n’aura pas a saisir ces champs “complémentaires” dans le processus global.
On avait oublié ce cas en renforçant la sécurité des appels des champs read-only dans cette version.
Le correctif est prêt et n’a plus qu’à être livré en v5.2.3.
En attendant, le contournement est de rendre le statut modifiable.
Problème 2 et 3 : ça ne me dit rien, les ID ne sont jamais affichés, il y a un problème de typage de vos champs.
On en revient à un pb de paramétrage sur vos champs clés fonctionnelles manquant dans vos objets.
Il faut vérifier que lorsque vous avez une référence vers un autre objet, que les champs clés soient bien ramenés :
pour lever toute ambiguïté via le ref picker + save avec une clé partielle vers un seul row ID (votre autre post, la back force la FK à null si ça ne matche pas)
idem pour les exports XML ou JSON qui n’ont que la clé fonctionnelle pour retrouver l’ID lié à l’import. dans une base cible, ici sans usr_login, impossible de savoir de qui on parle.
Après analyse, de nombreux vieux paramétrages ont des clés étrangères incomplètes fonctionnellement (par exemple ne ramène que le nom, mais pas la clé complète nom/prenom/date naissance, car trop pensé pour un écran donné et non pas pour une API déterministe).
En 5.1 la UI était “compréhensive” et permettait d’avoir des clés techniques partiellement identifiées par quelques champs clés fonctionnelles ou des row_id. (si la clé est totallement absente, on ne peut rien faire comme ici sans usr_login)
Mais cela posait déjà des problèmes sur les autres interfaces d’import XML ou mise à jour par API (sans aucun row_id ou fk techniques car variables d’une base à l’autre). Une clé pas ou partiellement fournie ne permet pas de retrouver le row_id de l’objet (lié ou principal) de façon sûre et unique pour mise à jour.
La 5.2 ayant renforcé ce point, l’audit permet désormais de le signaler au niveau de la définition de l’objet. Mais comme peu de designers ont été sensibilisés à cela, on va ajouter à la prochaine livraison 5.2.3 un traitement qui ajoutera temporairement les champs manquants (en mémoire) avec des warnings dans les logs.
Cela reste un contournement à un défaut de paramétrage des objets déjà présent en 5.1 ou avant.
Une fois l’objet corrigé le warning disparaitra.
