Rajouter des filtres sur les RedoLog

Bonjour,
j’ai un objet BCSIAppEAPM contenant des champs comme le type, le statut…
Je souhaite voir toutes les modifications effectuées sur tous les objets BCSIAppEAPM.
Pour ça, j’ai fait un objet héritier de RedoLog.
Au passage, pourquoi est-ce écrit System SYSTEM alors que l’utilisateur est bien identifié ? Pourriez-vous corriger ce point svp ?

Mes utilisateurs aimerait pouvoir filtrer les modifications par type, statut.
J’ai essayé de mettre un attribut FK en tant que champ calculé. Evidemment ca ne fonctionne pas, il faudrait qu’après le calcul, on puisse faire un populate.

Auriez-vous une façon de répondre à ce besoin ?
Cordialement
Amandine T.

[Platform]
Status=OK
Version=4.0.P25
BuiltOn=2021-03-11 12:27 (revision 87c63edc550691b4a0f402a31d3841429a9e0476)
Encoding=UTF-8
EndpointIP=21.0.9.3
EndpointURL=http://0843d6d81cfb:8080
TimeZone=Europe/Paris
SystemDate=2021-03-23 22:31:55

Il me semble que le pb du “System SYSTEM” a déjà été corrigé (votre révision est en retard de 24 commits)

D’accord, je vais mettre à jour notre instance.

Pour mon autre besoin, il faut que la solution fonctionne aussi lors de l’export excel des données.

La aussi il me semble qu’il y a eu une correction de “robustesse” récemment sur les exports Excel.

Quand vous détectez une anomalie commencez toujours par vous mettre à jour pour vérifier que c’est toujours d’actualité.

Actuellement il n’y a pas de problème avec l’excel.
C’est jusque que si vous avez une solution à proposer pour répondre au besoin d’avoir des filtres dans le redolog, il faudrait que les données soient visibles dans l’excel.
(Je ne sais pas si votre export Excel fait “juste” de récupérer les données affichées ou s’il fait un recalcul et dans ce cas, il faut que le hook dans lequel la solution sera implémentée, soit aussi appelé lors de l’export).

Je vais laisser @Francois répondre pour ce qui est de filtrer le redolog (l’attribut “activité” contient physiquement du JSON) mais pour des historiques filtrables finement par attribut c’est plutôt l’historisation des objets que j’utiliserais.

Ca marche merci @david .
Notre client souhaiterai voir rapidement l’ancienne et la nouvelle valeur. La présentation du redolog est vraiment ce qu’il souhaitait d’où mon besoin.

Bonjour,

Oui on a rendu récemment l’écriture des RedoLog stateless/asynchrone, et du coup c’est le System qui est apparu, on a bien remis l’utilisateur à l’origine de la modification dans les versions récentes.

Le RedoLog est un meta-objet qui dénormalise les données modifiées en JSON (et affichage HTML pour plus de lisibilité) pour n’importe quel objet métier. Il n’est pas utilisable pour requêter des données du payload/json, on peut requêter le user, la session, la date ou l’objet.

Ce n’est pas un bonne idée de “renormaliser” le JSON dans un héritier de RedoLog avec des colonnes dédiées pour un objet donné, la table de redolog doit rester une méta-table.

Pour le besoin de requêter des colonnes mono-objet BCSIAppEAPM, il faut utiliser l’historisation classique avec tous les champs à historiser BCSIAppEAPMHist. L’objet historique se comporte comme n’importe quel objet métier

  • Simplicité l’alimente juste automatiquement à chaque modification d’un champ historisé
  • C’est une liste avec des colonnes explicites avec tri + recherche
  • vous pouvez ajouter un champ HTML calculé au niveau du preCreate de BCSIAppEAPMHist pour présenter les données qui ont changé uniquement

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.