Journal des modifications non alimenté en cas de mise à jour par code

Tags: #<Tag:0x00007f80f75b2690>

Bonjour,

Nous n’arrivons pas à mettre en place le journal des modifications.
L’option est bien cochée sur l’objet mais rien n’est tracé lors des modifications.

Avez vous ouvert le tuyau général dans les param systèmes ?

  1. Pour conserver toutes les sessions utilisateur en base :
LOG_SESSION
{
	"database": true,
	"prune": 7,
	"unit": "day",
	"logger": true
}
  1. Pour chaque session, garder toutes les mises à jour des objets concernés ?
LOG_ACTIVITY
{
	"database": true,
	"prune": 7,
	"unit": "day",
	"logger": false
}
  • avec prune = 365 si à conserver 1 an an base (ou 1 et unit=year)
  • logger = true pour avoir aussi l’info dans des appender log4j dédiés

Ensuite l’info est stockées dans m_session et m_redolog, et donc accessible par objet Simplicité / Exploitation.

J’ai bien les paramètres comme indiqués :

en explorant la table m_session, nous avons bien des lignes par contre la table m_redolog est vide.

La sérialisation des REDOLOG a changée et effectivement il y a une petite régression lors de la sauvegarde du journal, il faudra mettre à jour l’instance.

De mon côté ça fonctionne :

image

Ensuite vous devez avoir des redo log accesibles via Exploitation/Journal des modifications

Bonjour,

Est-il est possible de cacher la vue sur le journal des modifications au niveau du formulaire de l’objet configuré avec cette option :


On activé le journal des modifications dans l’objet SIOFEMere mais je ne vois rien dans les fonctions ou relation qui me permet de cacher cette vue au niveau du formulaire de cet objet

Le besoin ici est d’activer le journal des modifications et d’y accéder que depuis le l’objet RedoLog directement.

A priori en implémentant le hook canReference()

Merci David, donc tu confirmes que par paramétrage d’objet ce n’est pas possible pour l’instant ?

Non à ma connaissance ce n’est pas possible de masquer un lien type “metaobject” par paramétrage. @francois tu confirmes ?

  1. Les champs meta-objects peuvent se paramétrer comme des FK dans l’attribut d’objet, de façon globale ou surchargeable par hook canReference.

  1. Dans votre copie d’écran on voit des champs non modifiés être archivés dans le bloc de modif. Ce n’est pas normal, l’archive ne prend normalement que les “hasChanged”, comment avez-vous produit ce redolog (via un update par code ou par la UI) ?

update par code mais ça ne le fait plus.

D’ailleurs comment forcer le journal des modifications lorsqu’on met à jour un ObjectDB par code avec un update ?

Je laisse @francois regarder le “update par code mais ça ne le fait plus”

Sur l’autre question : un update programmatique sur un objet qui fait l’objet d’une historisation doit, je pense, se faire en chargeant/valorisant les old values

quand je dis que ça ne le fait plus, c’est que je n’ai plus le problème sur la version actuelle, donc rien à faire.
Merci @david je vais tester.

@david je n’arrive toujours pas à voir de lignes s’ajouter dans le journal des modifications, au niveau du paramétrage de l’objet, dans historique des données j’ai activé seulement la case “journal de modifications”.
Une modification par UI m’ajoute bien la ligne c’est seulement par code ou j’ai rien.
Est-ce qu’il y a autre chose à valoriser une fois qu’on récupère l’ObjectDB et avant de faire l’update() ?

Tu fais bien un select(rowId) avant l’update ? Le select valorise les old values.

Perso je ferais un truc du genre:

ObjectDB obj= getGrant().getTmpObject("MyObject");
BusinessObjectTool objt = new BusinessObjectTool(obj);
objt.selectForUpdate(myRowId);
obj.setFieldValue("myField", myValue);
objt.validateAndSave();

Dans un try/catch bien sûr

Je viens de tester @david avec un objet simple, ça n’a pas l’air de marcher chez moi.
La modification par formulaire alimente bien le journal des modifications mais toujours rien en modification par code même en utilisant le select ou en valorisant des oldValue.

[Platform]
Version=4.0.P24
BuiltOn=2020-10-08 16:30 (revision e7d0f2f103310b42db2fa87b3b365118badd3462)

Ok on va retester la journalisation par mise à jour via code en V4.
Il y a peut être une subtilité sur les instances non UI car il faut avoir un working Id dans m_session.

Suite à analyse, l’archivage d’une mise à jour en session (redolog) est bien end-user donc sur la mise à jour via un appel de la UI, ça fonctionne avec le undo/redo de ce qu’il vient de faire.

Donc si on fait une mise à jour par code, ce n’est pas archivé un peu comme si on avait fait du SQL par code. L’utilisateur n’est pas responsable de ce que le système fait indirectement pour lui / ce n’est pas à tracer dans son journal des modifications.

Il va donc falloir :

  1. soit abandonner le besoin de tracer dans le journal les mises à jour indirectes (par code)
  2. soit ajouter un verbe pour permettre d’archiver un objet par code (au cas par cas)
  3. ou tracer toutes les mises à jour indirectes/par code (comme le fait la table historique par objet)

@khalil
A mon avis comme vous êtes les seuls à avoir ce besoin de façon un peu globale sur vos objets, il faudrait mieux partir sur l’évolution 2 si vous êtes sur que :

  • ça ne va exploser la volumétrie de la base (archive sur 1 an de mémoire)
  • et que l’utilisateur ne viendra pas dire que c’est pas lui qui a fait cette mise à jour, c’est le système…

Pour nous c’est bon.
L’utilisateur veut surtout tracer les modifications réalisées sur l’objet et même si c’est la modification est réalisée par code dans certain cas, il reste à l’origine de la modification.

Ok il y a un peu de boulot alors.
Il va falloir ajouter un choix de paramétrage pour être compatible ascendant comme toujours.

Vous devrez reparamétrer vos objets à ce niveau car il y aura une 4eme options “Redo-log full” incluant les mises à jour indirectes = tout le redo log d’une mise à jour (celui qui sert au undo) et pas juste l’objet modifié par l’utilisateur.

image

Ok pas de problème, on attend ton retour sur la disponibilité de l’évolution