Bug #34888
form_status_changed vs commentaires sur le même statut
0%
Description
La documentation dit "Un booléen précisant que le formulaire vient de changer de statut" mais si des commentaires sont posés à répétition sur le même statut, sa valeur est pourtant à False True. (alors qu'il n'y a pas eu de changement de statut).
Fichiers
Révisions associées
Historique
Mis à jour par Frédéric Péters il y a presque 5 ans
- Fichier 0001-forms-don-t-set-form_status_changed-on-evolutions-in.patch 0001-forms-don-t-set-form_status_changed-on-evolutions-in.patch ajouté
- Statut changé de Nouveau à Solution proposée
- Patch proposed changé de Non à Oui
Mis à jour par Thomas Noël il y a presque 5 ans
Je me demande dans quelle mesure ça marche depuis #22236 (ajout de Evolution.last_jump_datetime). Dans le cas d'un saut auto qui n'a pas changé le statut, on ne va pas avoir de nouvelle évolution, mais form_status_changed peut se retrouver à vrai quand même car on compare les deux dernières évolutions. Peut-être faudrait-il ajouter une condition, du genre "evolution[-1].last_jump_datetime is None" ?
Mis à jour par Frédéric Péters il y a presque 5 ans
- Statut changé de Solution proposée à En cours
J'étais d'abord parti en pensant à last_jump_datetime et puis sur ce cas précis ce n'était pas ça mais oui ce serait quand même quelque chose à considérer.
Mis à jour par Frédéric Péters il y a presque 5 ans
- Fichier 0001-forms-don-t-set-form_status_changed-on-evolutions-in.patch 0001-forms-don-t-set-form_status_changed-on-evolutions-in.patch ajouté
- Statut changé de En cours à Solution proposée
Ça devient confus mais je pense que c'est ok ainsi.
Mis à jour par Thomas Noël il y a presque 5 ans
- Statut changé de Solution proposée à Solution validée
Bon, pourquoi pas.
Mais je suis mal à l'aise : on se retrouve avec la possibilité que form_status diffère de form_previous_status, mais que form_status_changed soit faux... Ça semble difficile à expliquer, non ? En tout cas il faut s'en souvenir désormais. Et peut-être documenter, dans le genre « form_status_changed est plus intelligent que "form_status != form_previous_status" » (et en écrivant ça, si on rentre dans ces détails, on va perdre tout le monde, ça va être aussi confus que ce patch...)
Allez, ack.
Mis à jour par Frédéric Péters il y a presque 5 ans
(en vrai il y a un test, uniquement en sql, quand ils sont tous exécutés, qui ne passe pas, je creuse ça avant de pousser)
La documentation,
Un booléen précisant que le formulaire vient de changer de statut
Il faut y mettre emphase sur "vient de". Alors que form_previous_status c'est statut précédent.
Mis à jour par Frédéric Péters il y a presque 5 ans
- Statut changé de Solution validée à Résolu (à déployer)
(en vrai il y a un test, uniquement en sql, quand ils sont tous exécutés, qui ne passe pas, je creuse ça avant de pousser)
(sessions existantes qui "verrouillaient" la demande)
commit f8da77c8f9eb70021bf2041d8b3839ad3381460a
Author: Frédéric Péters <fpeters@entrouvert.com>
Date: Tue Jul 16 09:53:56 2019 +0200
forms: don't set form_status_changed on evolutions in same status (#34888)
Mis à jour par Frédéric Péters il y a presque 5 ans
- Statut changé de Résolu (à déployer) à Solution déployée
forms: don't set form_status_changed on evolutions in same status (#34888)