Development #75025
Mis à jour par Benjamin Dauvergne il y a environ un an
Cf. ticket client #74251 où certains envois de mail avec identifiant sont sauvés dans l'historique mais pas d'autre.
J'ai relu le code de l'optimisation de sauvegarde des évolutions et je pense qu'on un trou dans la raquette. Cette optimisation c'est sur un @formdata.store()@ de ne pas sauvegarder les évolutions qu'à partir de la première qui n'a pas de si elles ont toutes déjà un attribut @_sql_id@. Mais si une action précédente a déjà fait un @formdata.store()@ et que l'action en cours (comme ici) ajoute une EvolutionPart à l'évolution en cours, on se retrouve avec un dernier objet Evolution modifié, mais déjà avec un identifiant SQL en base et qui ne sera pas mis à jour.
Je serai d'avis d'ajouter un flag @_dirty@ à Evolution, par défaut à False et qui serait posé à True par @Evolution.add_part()@.
J'ai relu le code de l'optimisation de sauvegarde des évolutions et je pense qu'on un trou dans la raquette. Cette optimisation c'est sur un @formdata.store()@ de ne pas sauvegarder les évolutions qu'à partir de la première qui n'a pas de si elles ont toutes déjà un attribut @_sql_id@. Mais si une action précédente a déjà fait un @formdata.store()@ et que l'action en cours (comme ici) ajoute une EvolutionPart à l'évolution en cours, on se retrouve avec un dernier objet Evolution modifié, mais déjà avec un identifiant SQL en base et qui ne sera pas mis à jour.
Je serai d'avis d'ajouter un flag @_dirty@ à Evolution, par défaut à False et qui serait posé à True par @Evolution.add_part()@.