Produits Entr'ouvert » Calebasse

Pourrais-tu lister les évènements qui doivent être pris en compte ?

• login
• logout
• modification/création d'un objet en base ? avec le détail ? tous les
  objets ? certains ?
• suppression des objets ?

Est-ce que ce système d'historique doit être accessible via plusieurs
entrées (là tu demande de pouvoir lister pour un User, mais est-ce qu'on
pourrait vouloir filtrer par dossier par exemple, et voir qui a fait
quoi sur un dossier ?) ?

Est-ce qu'il doit contenir des évènements sans lien avec un utilisateur
(par exemple quand on pousse vers la facturation vers la sécu. en tâche
de fond) ?

Regardez https://pypi.python.org/pypi/django-journal c'est ce que j'ai développé pour docbow, il y a des paquets dans nos dépôts.

C'est assez simple à utiliser:

import django_journal
django_journal.record('my-tag', '{user} did this to {that}',
           user=request.user, that=model_instance)

Des index sont créés sur les variables de template, il est par exemple possible de retrouver tous les logs qui utilisent '{user}' dans leur template pour un utilisateur donné. Le tag permet d'indiquer une grande famille d'évènement 'act-creation', 'act-delete', etc.. Si on utilise le middleware, on a automatiquement l'ip et l'utilisateur qui sont renseignés en passant par la méthode installée sur request.record().

        act.last_validation_state = last_validation_state
+       get_request().record('new-act','{obj_id} created by {user} from {ip}', obj_id=act.id)
        act.save()

Est-ce qu'on n'obtient pas le act.id uniquement après l'appel à save() ?

+        self.request.record('new-act',
+                            '{obj_id} created by {user} from {ip}',
+                            obj_id=self.object.id)

Le même message de log est produit à deux endroits différents, d'expérience c'est utile d'avoir une info différente.

Ou, autre commentaire, ces lignes de log sont enregistrées au mauvais endroit, et il ne devrait y en avoir qu'une, dans le save().

+ get_request().record('act-update', '{obj_id} updated by {user} from {ip} with: {changes}', changes=changes)

obj_id n'est pas défini.

Ça a été commité sans doute par erreur. (et en tout cas avec des erreurs)

Poussé trop vite.

Frédéric Péters a écrit :

[...]

Est-ce qu'on n'obtient pas le act.id uniquement après l'appel à save() ?

[...]

Le même message de log est produit à deux endroits différents, d'expérience c'est utile d'avoir une info différente.

Corrigé, merci.

Ou, autre commentaire, ces lignes de log sont enregistrées au mauvais endroit, et il ne devrait y en avoir qu'une, dans le save().

Initialement j'étais parti sur ça, mais je voulais avoir plus de détails sur les modifications effectuées sur les modèles, et logguer en dehors du save me permet de voir ses modifications sans analyser les modifications sur l'objet.

[...]

obj_id n'est pas défini.

Je fais un nouveau patch

Il manque également la dépendance sur django-journal dans le requirements.txt et le setup.py.

Idéalement il ne vaut mieux pas logger les id des objets et plutôt directement l'objet c'est toute la magie de la bibliothèque de gérer ça proprement et de mettre des liens vers les vues d'admin dans les logs, donc plutôt que

        act.last_validation_state = last_validation_state
+       get_request().record('new-act','{obj_id} created by {user} from {ip}', obj_id=act.id)
        act.save()

faire plutôt ça

        act.last_validation_state = last_validation_state
+       get_request().record('new-act', '{act} created', act=act)
        act.save()

L'utilisateur et l'IP sont déjà sauvés et affichés dans les listing, pas besoin de les sauver explicitement. Si l'objet est effacé on verra dans les logs l'ID de l'objet avec l'anotation "deleted" au lieu d'un lien vers sa vue.

Les messages de log ne sont pas assez explicites.

Par exemple lors de la création de rendez-vous il faudrait avoir les détails des champs de ce rendez-vous.
Lors de la modification, il faudrait avoir le détail de ce qui a été modifié.

Je peux stocker les détails lors de l'ajout ou modification d'un modèle sous forme d'un dictionnaire.
Si le journal doit être consultable par les secretaires, je pense qu'il faudrait repenser les logging afin d'avoir une interface plus épurée et claire.

Pour stocker des informations variables avec un message on peut toujours faire ça (en vrai python sur un pseudo example):

    template = "created object" 
    kwargs = {}
    if info1:
        template += " with info1 {info1}" 
        kwargs['info1'] = info1
    if info2:
        template += " with info2 {info2}" 
        kwargs['info1'] = info2
    request.record(template, **kwargs)

Le dico kwargs est automatiquement transformé en clé-valeurs dans les tables du journal.