Refacto des logs

[LaurentGruber]

Log de sécurité (done in #1537)

événement à enregistrer

• [x] tentative de connection échouée
• [x] connection réussie [! mode de connection - ip de connection]
• [x] déconnection (clique sur logout)
• [x] demande de réinitialisation de mot de passe
• [x] changement de mot de passe
• [x] activation / désactivation d'utilisateur
• [x] ajout / suppression de rôle
• [x] Connection avec "voir en tant que"

??? Modération ???

UI

Menu utilisateur > Mon compte : ajouter un onglet sécurité pour afficher les logs de sécurité lié à l'utilisateur.

Administration > tableau de bord : ajouter un onglet sécurité pour arricher l'ensemble des logs de sécurité de la plateforme.

Log fonctionnel

Objectif : Pouvoir suivre la progression des utilisateurs dans une formation (temps passé, score obtenu, élément réalisé,...)

• [x] entré / sortie d'une ressource, un outil
• [x] obtention d'un score à une ressource
• [x] obtention d'un badge
• [ ] Forum : poste dans le forum, création d'un sujet, commentaire d'un post
• [ ] ClacoForm : ajout d'une fiche, commentaire sur une fiche
• [ ] Blog : Ajout d'un post (! date de visibilité - caché), commentaire sur un post
• [ ] Questionnaire : réponse à un questionnaire, (correction de question ouverte)
• [ ] Wiki : ajout d'une section
• [ ] Evaluation : dépot d'une copie, demande de feedback, ajout d'une correction
• [ ] Fin de la ressource

Log opérationnel

Objectif : enregistrer les événement de la plateforme

• [ ] création / suppresion utilisateur, espace d'activité, ressources [contexte : ]
• [ ] Modification utilisateur, espace d'activité, ressources [ élément modifié / diff ]
• [ ] Modification de droits sur une ressource, un outil [ élément modifié / diff ]
• [ ] événement propre à un type de ressource : création / modification / suppresion d'une question ...

Log des communications

• [ ] envoie mail [contexte : ]
• [ ] envoie sms
• [ ] via API...

[chalasr]

Pour ce qui est de revoir le design general, comme vu ensemble:

• On met des event listeners sur des events métier (claroline) ou infra (built-in symfony ou bundles tierces, notamment pour la sécu), et non pas des évenements voués uniquement à créer un log.
• Revoir la partie persistence: On embarque un minimum de relations au sens doctrine, éviter l'effet grosse chaine d'objets, on requête finement quand il s'agit de lire les logs).
• On crée différents models de log en fonction du type, e.g. SecurityLog.
• A définir: stratégie d'archivage/suppression des logs après une période donnée (en fonction du type de log là aussi.
• A discuter: où est-ce qu'on met la logique. A mon sens, les classes d'event et les listeners associés peuvent résider dans les plugins et sous namespaces existants. @Elorfin a évoqué un éventuel plugin log, voir ensemble ce qu'on mettrait dedans.

[Elorfin]

Il faut aussi voir comment on va gérer l'affichage. A l'heure actuel, il y a des templates twig (possibilité d'utiliser des templates custom pour certains logs) qui sont rendus pour chaque log. A vérifier, mais il me semble qu'il y en a plusieurs, un pour l'affichage dans une liste et un pour l'affichage du détails.

Ce qui est lourd. L'intérêt de cette approche étaient de pouvoir afficher une phrase avec un lien intégré.

Pour ce qui est du plugin log, j'aurai mis :

• les entités des logs
• l'API claro des logs (Serializer / Finder)
• la logique de stockage (DB / Redis / Autre ?)
• les stratégies d'archivage/suppression

Le but étant de vider ClarolineCoreBundle de tout le code générique d'une application et de conserver uniquement le noyau LMS dans ce bundle. Il est également possible de mettre le code dans ClarolineAppBundle (qui avait été créé pour ça) suivant la quantité de code requise.

A discuter: où est-ce qu'on met la logique. A mon sens, les classes d'event et les listeners associés peuvent résider dans les plugins et sous namespaces existants

D'accord avec ça. A noter qu'il ne devrait plus y avoir de classes d'event liées au logs étant donné qu'on désire directement écouter les events applicatifs.

[Elorfin]

On met des event listeners sur des events métier (claroline)

A discuter : j'aimerai doucement basculer vers de l'event subscribing, c'est peut être l'occasion de commencer. Comme on va devoir retrouver les évènements claroline pour greffer les logs, on pourrait en profiter pour déjà écrire les catalogues d'events des bundles (voir Symfony\Component\HttpKernel\KernelEvents).

[chalasr]

👍 pour utiliser des subscribers plutot que des listeners, perso ça me pose pas de souci de cohérence qu'on ai les deux approches dans le code et qu'on parte sur du subscriber pour les nouveaux, jusqu'au jour où on a le temps de remettre tout d'équerre