ImproveLogEvent

  • tout stocker en DB ? meme traces SQL et PHP ?
  • Notion de réussite ou pas de l'action

yllen :
Le premier problème à mon sens est celui de la multi-entités. En effet, actuellement, pour les multi-entités, le log ne peut pas être délégué.
Proposition : ajouter le champ entities_id dans la table glpi_logs

Ensuite, il faut définir en détail pour un objet, ce qui doit être tracé dans l'historique dudit objet et/ou dans les journaux
Historique :
tous les évènements liés à vie de l'objet
Journaux :
les évènements majeurs intervenus sur l'objet (création, transfert, suppression)

Pour les journaux, il faut définir le niveau de traçage de chaque évènement (afin que chaque entité puisse paramétrer le niveau qu'elle veut voir)
Je sais que les niveaux vont de 1 à 5 mais je ne sais plus quel est le niveau le plus détaillé.
On pourrait par exemple ne tracer au niveau le plus bas que les évènements réussis et au niveau suivant ceux qui ont également échoués

Et surtout, pour chaque niveau, il faudrait définir la chaine de $LANG à utiliser (création de l'item, échec de modification de l'item + auteur...)

Une fois la table fractionnée par entité, il faut qu'elle soit requêtable, donc il faut adapter le moteur de recherche en ce sens.

Et pour finir, comme chaque entité doit pouvoir définir le niveau de traçage souhaité, elle doit aussi pouvoir définir la profondeur de conservation

Voilà, c'est une première réflexion qui attends vos commentaires pour faire avancer ce sujet qui traite un peu.