Table historique + journal de modification dans le cadre d'un héritage

Request description

Bonjour,

Dans le cadre d’un héritage, je souhaiterai avoir une table d’historique et un journal de modification communs entre l’objet père et l’héritier.

Steps to reproduce

Pré-existant : L’objet père avait déjà une table d’historique et un journal de modification associé

image

Dans un premier temps, un objet héritier a été créé sans cochées les options d’historisation et de journal de modification, pensant que ces options seraient héritées de l’objet père avec une table physique commune pour le journal de modif et pour la table d’historique.

Première constatation : L’historisation des versions des records et le journal de modification ne fonctionnait que sur l’objet père. Toute modification en passant par l’objet héritier n’étaient pas sauvegardées, qu’il s’agisse des versions ou des modifications apportées au record.

Nous avons donc fait le choix de cocher les deux options au niveau de l’objet héritier. Cette fois ci, Nous constatons deux choses :

1- Nous constatons que l’objet père à toujours son journal de modification. Nous constatons aussi que l’objet héritier a un journal de modification, différent de celui de l’objet père.
→ Nous souhaiterions avoir un journal de modification, commun à un objet père et son/ses héritiers

2- Nous constatons que la table historique est bien partagée par les deux objets. Cependant, quand une modification est faite sur l’objet père, seuls les attributs de l’objet père sont historisés. Quand on réalise une modification sur l’objet héritier , seuls les attributs propres à l’objet héritier sont historisés.
→ L’unicité de la table d’historisation nous convient, mais nous aimerions que l’ensemble des champs (ceux de l’objet père et ceux propres à l’objet héritier) soient renseignés dans la version historisée du record.

Quelle démarche conseillez-vous pour que nous obtenions le comportement souhaité ?

Cordialement,
Joffrey

Bonjour,

Il faut bien préciser tous les champs, un objet n’hérite pas des cases à cocher sinon il serait impossible de surcharger pour dire “non coché” si le parent était “coché”. L’héritage est surtout là pour factoriser les champs en commun entre différents objets ou distinguer des types/catégories d’objets avec des attributs dédiés.

Historique :

La table historique est donnée par la nom de la table suffixé par “_hist”
Si vous répétez bien le même nom de la table dans l’héritier, vous aurez bien la même table d’historique. Par contre comment voulez vous historiser des champs qui sont inconnus de l’objet ?

  • Il est plutôt conseillé de n’autoriser la mise à jour que sur les héritiers et pas l’objet parent.
    et d’utiliser le hook getTargetObject sur l’objet/liste père pour toujours rediriger vers l’objet fils (en fonction du type ou autre).

  • sinon vous pouvez ajouter du code dans l’objet historique pour compléter/renseigner les champs manquant :

    • Vérifiez les champs de vos objets <NomPere>Historic et <NomHeritier>Historic ils sont générés une fois quand on coche la case “historique”, il manque donc peut être les champs ajoutés après
    • dans le preValidate de l’historique parent renseignez les champs manquants en fonction du fils

Un objet historique est un objet comme un autre (habilitable, modifiable, hookable…) pour Simplicité, la seule différence est que le “save” de l’objet X force un “create” (si isHistoric retourne true) dans l’historique XHistoric avec recopie des champs qui existent dans l’objet X.

Journal / redolog

  • L’usage est bien par objet métier pour traçabilité des champs qui correspondent à l’objet, donc passez par un getTargetObject pour ne modifier vos objets qu’au niveau des héritiers
  • Sinon il faudrait créer un objet ou un lien virtuel qui liste ce que vous voulez voir de la table des redolog en fonction du getParentObject.

Votre modèle est problématique au sens large, si vous avez une règle de gestion “les carottes sont oranges” dans le fils/héritier, il faudrait l’appliquer sur le père si vous pouvez le modifier “un légume de type carotte est orange”. En général, le père est en lecture seule et redirige vers le fils en mise à jour. Pour une mise à jour en masse, il faudra utiliser la liste fille, etc.

1 Like