Journal des événements sur un contenu

[Arnaud-D]

Actuellement, on se sert beaucoup des MP pour notifier des événements sur un contenu, comme par exemple les réservations en validation. Le but de cette PR est de créer un nouveau système permettant d'avoir un historique des événements par contenu, ainsi que, dans un deuxième temps, des notifications sur ces événements.

Techniquement, je rajoute un modèle pour les événements sur un contenu. Les événements sont créés lors de la réception d'un signal spécifique à cet événement. C'est assez facile de rajouter des événements pour toutes sortes d'actions, en ajoutant les signaux correspondants.

À faire

• Tests authors_management
• Tests beta_management
• Test tags_management
• Tests contributors_management
• Tests help_management
• Tests jsfiddle_management
• Tests opinions_management
• Tests validation_management
• Tests model Event
• Tests suggestions_management

Pour une prochaine version

• mettre des notifications pour les événements qui le méritent
• supprimer les notifications par MP pour les événements enregistrés et notifiés via ce nouveau module
• ajouter quelques autres événements moins importants (marquage d'obsolescence par exemple)

QA

Avant toute chose : make migrate-db.

Ensuite, ouvrir un contenu (article ou tuto) et la page "Journal des événements" de celui-ci.

Jouer avec les actions suivantes :

• la gestion de la bêta (mise en bêta, retrait de la bêta)
• toutes les actions de validation (mise en validation, validation, révocation, refus, annulation, réservation, déréservation...)
• la gestion des auteurs (ajout, suppression)
• la gestion des tags
• la gestion des suggestions (ajout, suppression)
• la gestion des aides
• la gestion de JSFiddle (activation, désactivation)
• la gestion de opinions (publication, dépublication)

À chaque événement, regarder que tout se passe bien (événement bien ajouté, bon message avec les bons liens, etc).

Faire pareil pour un billet.

La gestion des catégories n'est pas dans le scope car le formulaire n'est pas séparé pour le moment et ça complique un peu la mise en œuvre.

[coveralls]

Coverage increased (+0.08%) to 87.99% when pulling 2e640f9 on Arnaud-D:historique_événements into 7b8d466 on zestedesavoir:dev.

[Arnaud-D]

Bon, j'opère un changement de plan ici. Au lieu de mettre un nombre limité d'événements avec leurs notifications, je vais mettre un maximum d'événements dans cette PR, mais sans notifications.

En effet, en travaillant sur les notifications, je me suis rendu compte que c'est beaucoup de travail de rajouter ça proprement et ça peut être très long à tester aussi.

Mieux vaut découper la partie enregistrement des événements et notifications en deux PR pour que ça reste gérable.

[Arnaud-D]

@Migwel j'ai corrigé tes remarques, je te laisse vérifier que c'est bon.

[Migwel]

@Arnaud-D Je confirme, la désactivation de la beta fonctionne maintenant. Et j'ai refait quelques actions "au hasard" et je confirme qu'elles fonctionnent toujours également.

[philippemilink]

J'ai parcouru le code et testé rapidement, ça me semble bon. Joli travail @Arnaud-D !

Et bravo pour la QA @Migwel, c'est jamais très simple quand il y a beaucoup de code comme ici.

la gestion de opinions (publication, dépublication)

@Arnaud-D qu'est-ce que tu entends par "opinions" ? Les billets ?

QA OK ✔️