Champ updated_dt toujours mis à jour

Feature request
1

Bonjour,

Simplicité version4.0 patch level P23 (database patch level P23)Built on2019-07-08 21:54 (revision 9610187d6d6bd3925c2b11fcc2c34bde2ed09f85)

Nous avons remarqué que les champs updated_dt et updated_by sont toujours mis à jour suite à enregistrement même si aucune information n’a été changée. Est-ce normal?

2

Ca a toujours été comme ça… mais ça se discute.

Faire un “save” appelle des hooks qui potentiellement font des choses et il faut tracer le passage de l’utilisateur. Pourquoi faire “Enregistrer” si l’utilisateur n’a rien fait… il n’a qu’à “Fermer” pour passer incognito.

A noter :

  • L’historique d’un objet ne s’incrémente que si un des champs historisé a été modifié.
  • Les méthodes save/update ont été enrichies pour pouvoir le faire sans modifier le timestamp car il est parfois souhaitable qu’un hook fasse une mise à jour sans modifier le timestamp utilisateur (comme calculer un total dans un autre objet sans modifier son auteur).
obj.save(false);
obj.update(false);

Par défaut, sans ce paramètre le timestamp sera vérifié et modifié.

https://docs.simplicite.io/4.0/javadoc/com/simplicite/util/ObjectDB.html#save-boolean-

3

Bonjour,

Merci pour ce retour.
Du coup vu que notre client a demandé une confirmation avant enregistrement nous allons cacher le bouton enregistrer du socle et créer le notre.
Derrière notre bouton il faudrait donc qu’on vérifie si un champ a été mis à jour et si non que l’on utilise le paramètre à false pour pas que le timestamp ne soit pas mis à jour.

4

Oui c’est le bon choix pour être libre de changer le comportement du “Save” par défaut.
Du coup vous devrez aussi le faire pour “Enregistrer / Femer”.

Sinon il y a un besoin récurrent qui nous est remonté de pouvoir changer l’accès aux formulaires :

  • en lecture par défaut avec un bouton “Modifier” pour basculer en mode édition
  • puis affichage du formulaire standard avec les actions de mise à jour

Comme Simplicité est conçu pour fabriquer des applications back, en général l’utilisateur ouvre les objets pour les mettre à jour (donc accès en écriture dès l’ouverture), mais pour des utilisateurs dont les actions sont plus occasionnelles, il serait intéressant d’avoir ce mode pour éviter les erreurs.

J’ajoute ce point au backlog de pouvoir paramétrer sur un objet métier :

  • L’accès en lecture par défaut au formulaire (par défaut non pour compatibilité ascendante)
  • Mise à jour du timestamp uniquement si changement d’un attribut (front ou calculé par hook, par défaut non pour compatibilité ascendante)
5

Non en fait refaire un bouton “save” ne marchera pas.
Car une action commence toujours par un “save” standard pour synchroniser les données en back.
L’action a lieu après.

Si vous voulez garder le timestamp, il faudra pour le moment :

  • le lire en preUpdate si un champ a changé this.hasChanged()
  • et le remettre en postUpdate par du SQL direct.