Project

General

Profile

Bug #1988

Historique des actions de l'utilisateur.

Added by Mikaël Ates over 11 years ago. Updated over 8 years ago.

Status:
Rejeté
Priority:
Normal
Assignee:
-
Target version:
Start date:
20 November 2012
Due date:
% Done:

50%

Estimated time:
Patch proposed:
No
Planning:

Description

Concevoir un système de log des actions de l'utilisateur, lisible par un non informaticien, qui soit accessible depuis l'icone historique positionnée sur la ligne d'un accès.


Files

Associated revisions

Revision a01d85be (diff)
Added by Serghei Mihai over 9 years ago

logging actions on models with django_journal

Closes #1988

History

#1

Updated by Benjamin Dauvergne over 11 years ago

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) ?

#2

Updated by Mikaël Ates about 11 years ago

  • Target version changed from 0.1 to 0.2

Evénements:

  • login/logout * validation automatique et déverrouillage * création/modification/suppression rendez-vous/actes, dossiers patient, accès et tout objet métier

On doit pouvoir lister par utilisateur et par objet bien que dans l'application il n'est prévue que de voir l'historique des actions de l'utilisateur (dans la partie accès).

Les évènements qui sont sans liens avec les utilisateurs sont à logger ailleurs.
Les rapports de télétransmission seront sûrement stoqués en base avec un model dédié.

#3

Updated by Mikaël Ates about 11 years ago

  • Target version changed from 0.2 to 0.6
#4

Updated by Mikaël Ates about 11 years ago

  • Target version changed from 0.6 to 0.9
#5

Updated by Mikaël Ates over 10 years ago

  • Project changed from APS42 to Calebasse
  • Priority changed from Normal to Bas
  • Target version deleted (0.9)
#6

Updated by Mikaël Ates over 9 years ago

  • Assignee set to Serghei Mihai
  • Priority changed from Bas to Haut
  • Target version set to 1.1.3

Visiblement on aurait tout ce qu'il faut avec reversion ?

#7

Updated by Mikaël Ates over 9 years ago

  • Priority changed from Haut to Immediat
  • Patch proposed set to No

Ca devient critique pour le support.

#8

Updated by Benjamin Dauvergne over 9 years ago

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().

#10

Updated by Serghei Mihai over 9 years ago

  • % Done changed from 0 to 50
  • Patch proposed changed from No to Yes
#11

Updated by Frédéric Péters over 9 years ago

        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.

#12

Updated by Serghei Mihai over 9 years ago

  • Status changed from Nouveau to Résolu (à déployer)
  • % Done changed from 50 to 100

Appliqué par commit calebasse|commit:a01d85be752cd242f076febde54a56d1d9d0f677.

#13

Updated by Frédéric Péters over 9 years ago

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

#14

Updated by Serghei Mihai over 9 years ago

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

#15

Updated by Jérôme Schneider over 9 years ago

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

#16

Updated by Serghei Mihai over 9 years ago

Interception des actions via les signaux post_save et pre_delete.
Le setup mis à jour également.

#17

Updated by Benjamin Dauvergne over 9 years ago

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.

#19

Updated by Mikaël Ates over 9 years ago

  • Status changed from Résolu (à déployer) to En cours
  • Target version changed from 1.1.3 to 1.3

Cela fonctionne bien mais il manque des détails. Avant de préciser lesquels je déplace la demande à la prochaine version et la met en cours.

#20

Updated by Mikaël Ates over 9 years ago

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é.

#21

Updated by Serghei Mihai over 9 years ago

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.

#22

Updated by Mikaël Ates over 9 years ago

  • % Done changed from 100 to 50

Ok pour le stockage du detail.

#23

Updated by Benjamin Dauvergne over 9 years ago

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.

#24

Updated by Frédéric Péters almost 9 years ago

  • Patch proposed changed from Yes to No
#25

Updated by Benjamin Dauvergne almost 9 years ago

  • Priority changed from Immediat to Normal
#26

Updated by Mikaël Ates over 8 years ago

  • Assignee deleted (Serghei Mihai)

Also available in: Atom PDF