Coms improvement

[J9rem]

Cette pull-request a pour objectif d'améliorer le fonctionnement des commentaires qui ont été réintroduits dans la version doryphore 4.2.

Proposition de spécifications:

Spécifications pour l'amélioration des commentaires

Gestion des commentaires

• [R01] une nouvelle action {{commentstable}} DOIT être créée
• [R01.1] l'action {{commentstable}} DEVRAIT être accessible dans le bouton composants
• [R01.2] l'action {{commentstable}} DEVRAIT être dans le groupe Gestion du YesWiki dans le bouton composants avec le titre Table des commentaires
• [R02] l'action {{commentstable}} DEVRAIT être un tableau listant tous les commentaires via la librairie Datatables
• pour chaque commentaire listé dans l'action {{commentstable}}
  • [R02.1] un bouton modifier DEVRAIT être présent si on a les droits
  • [R02.2] un bouton supprimer DEVRAIT être présent si on a les droits
  • [R02.3] un message de confirmation DOIT être demander après le clic que le bouton supprimer
  • [R02.4] la modification d'un message PEUT se faire dans une modale après le clic que le bouton modifier
  • [R02.5] une case à cocher DOIT être présente pour sélectionner le commentaire pour des suppressions multiples, si on a les droits
  • [R02.6] le nom de la page mère DOIT être affiché avec un lien vers celle-ci
• [R03] l'action {{commentstable}} DEVRAIT proposer un bouton de sélection multiple avec suppression ajax avec message de confirmation
• [R04] lors de la suppression d'un commentaire, le tableau de l'action {{commentstable}} DOIT dynamiquement se mettre à jour sans avoir à recharger la page
• [R05] l'action {{commentstable}} PEUT être accessible par défaut par tout le monde (un réglage plus fin peut être fait par {{editactionsacls}}),
• [R05.1] l'action {{commentstable}} NE DEVRAIT affichée que les commentaires lisibles par l'utilisateur connecté

Événements liés aux commentaires

• [R06] le service CommentService PEUT utiliser un EventDispatcher pour générer des événements liés aux commentaires
• [R06.1] les premiers événements possibles DEVRAIENT être comments.create, comments.modify, comments.delete
• [R06.2] les événements définis dans [R06.1] sont envoyés après la réalisations des actions par CommentService
• [R07] un nouveau service EventDispatcher peut être créé pour le namespace YesWiki\Core\Service
• [R07.1] YesWiki\Core\Service\EventDispatcher DEVRAIT être un wrapper de Symfony\Component\EventDispatcher\EventDispatcher
• [R07.2] YesWiki\Core\Service\EventDispatcher DEVRAIT exposer les méthodes publiques addListener et dispatch avec les mêmes signatures que celles de Symfony\Component\EventDispatcher\EventDispatcher

Envoi des e-mails

• [R08] un e-mail DEVRAIT être envoyé au propriétaire de la page où un commentaire est déposé
• [R08.1] cet e-mail DEVRAIT être envoyé lors de l'événement comments.create défini dans [R06.1]
• [R08.2] un e-mail NE DOIT PAS être envoyé si le commentaire est écrit par le propriétaire de la page concernée
• [R09] un e-mail DEVRAIT être envoyé au propriétaire d'un commentaire où une réponse est créée
• [R09.1] cet e-mail DEVRAIT être envoyé lors de l'événement comments.create défini dans [R06.1]
• [R09.2] un e-mail NE DOIT PAS être envoyé si le commentaire est écrit par le propriétaire du commentaire père concerné
• [R10] l'e-mail envoyé DEVRAIT contenir les informations suivantes :
  • contenu du commentaire
  • page mère où se situe le commentaire
  • lien vers cette page
  • nom du site concerné
  • nom de l'utilisateur à l'origine du commentaire
• [R11] le contenu des e-mails DEVRAIT être défini par des templates twig
• [R11.1] les templates twig définis par [R11] DEVRAIENT être dans templates/comments

nouvelle action Mes Commentaires

• [R12] une nouvelle action {{mycomments}} DOIT être créée
• [R12.1] l'action {{mycomments}} DEVRAIT être accessible dans le bouton composants
• [R12.2] l'action {{mycomments}} DEVRAIT être dans le groupe Actions avancées dans le bouton composants avec le titre Mes commentaires
• [R13] l'action {{mycomments}} DEVRAIT être un tableau listant tous les commentaires de l'utilisateur via la librairie Datatablesainsi que les réponses à ces commentaires
• pour chaque commentaire listé dans l'action {{mycomments}}
  • [R13.1] un bouton modifier DEVRAIT être présent si on a les droits
  • [R13.2] un bouton supprimer DEVRAIT être présent si on a les droits
  • [R13.3] un message de confirmation DOIT être demander après le clic que le bouton supprimer
  • [R13.4] la modification d'un message PEUT se faire dans une modale après le clic que le bouton modifier
  • [R13.5] une case à cocher DOIT être présente pour sélectionner le commentaire pour des suppressions multiples, si on a les droits
  • [R13.6] le nom de la page mère DOIT être affiché avec un lien vers celle-ci
• [R14] l'action {{mycomments}} DEVRAIT proposer un bouton de sélection multiple avec suppression ajax avec message de confirmation
• [R15] lors de la suppression d'un commentaire, le tableau de l'action {{mycomments}} DOIT dynamiquement se mettre à jour sans avoir à recharger la page
• [R16] l'action {{mycomments}} PEUT être accessible par défaut par tout le monde (un réglage plus fin peut être fait par {{editactionsacls}}),
• [R16.1] l'action {{mycomments}} NE DEVRAIT affichée que les commentaires lisibles par l'utilisateur connecté
• [R16.2] l'action {{mycomments}} DEVRAIT affiché un message d'avertissement si l'usager n'est pas connecté, message l'invitant à se connecter
• [R17] l'action {{mycomments}} PEUT mutualiser du code avec l'action {{commentstable}}
• [R17.1] un nouveau controller CommentController PEUT être créé pour mutualiser ce code

affichage des commentaires

• [R18] : lors de la modification d'un commentaire par un adminstrateur, celui-ci DOIT continuer de s'afficher comme étant écrit par l'auteur initial
• [R18.1] : un message modifié PEUT indiqué un message du type "modifié par"
• [R19] : l'interface de rédaction/affichage des commentaires PEUT être réécrit avec la librairie VueJS
• [R20] : lors de la rédaction d'un commentaire, l'interface DEVRAIT proposer des icônes uft8 par défaut comme ♡, ☺ ou d'autres icônes fontawesome
• [R20.1]: la liste proposée DEVRAIT être configurable via wakka.config.php
• [R20.2]: la liste proposée DEVRAIT être aussi configurable via {{editconfig}}
• ~~[R21][R21.1][R22.2][R22.3][R22.4][R22.5][R22.6]~~

suivi des modifications:

• 25/07/2022, @J9rem
  • [R22][R22.1][R22.2][R22.3][R22.4][R22.5][R22.6] suppression (fonction plier/déplier la zone des commentaires)

---

Ce que fait la branche en l'état

• création d'une action {{commentstable}} et ajout de cette action dans le bouton composants partie Gestion du wiki (titreTable des commentaires)
  • cette action liste tous les commentaires
  • cette action permet de modifier ou supprimer un ou plusieurs commentaires en mode ajax
• utilisation de EventDispatcher pour créer des évènements à la création/modification/suppression des commentaires et simplifier l'usage des pre/post actions
• cette PR peut alors être mise en oeuvre avec la PR associée au sein de l'extension Webhooks : https://github.com/YesWiki/yeswiki-extension-webhooks/pull/19
• gestion des événements liés aux commentaires pour envoyer des e-mails lors de la création d'un commentaire sur une page ou la réponse à un commentaire
• léger correctif de l'action {{comment}} pour garder l'affichage du créateur d'un commentaire même si celui-ci a été modifié par un administrateur
• création d'une action {{mycomments}} et ajout de cette action dans le bouton composants partie Gestion du wiki (titreTable des commentaires)
• la spécification [R20] n'a pas été implémentée pour être conservée plutôt en custom car son usage est assez spécifique selon moi.

Pour tester la branche en l'état

• écrire un commentaire sur une page dont un autre utilisateur est propriétaire et vérifier que celui-ci reçoit bien un e-mail
• vérifier la réception d'un e-mail lors de la réponse à un de nos commentaires
• mettre {{commentstable}} dans une page du wiki

[J9rem]

@mrflos je viens d'ajouter une proposition de spécification d'amélioration des commentaires dans le coeur dans la description de cette PR. Qu'en penses-tu ?

J'attends tes retours sur cette spec. avant d'avancer plus loin dans les développements custom afin d'aller dès le début dans le sens des spec. quand nous les aurons travaillées ensemble

[mrflos]

Hello, j'ai lu vite fait et je suis globalement ok, sauf pour la partie cacher/afficher les commentaires, que je trouve pas top en terme d'ux et graphisme.
D'ou vient cette demande, est ce que cela fait partie de la commande d'un presta? Est ce pour des raisons de performances? J'aimerais plutot un système plus moderne, comme le lazyload des commentaires quand on scrolle vers l'endroit ou ils sont, comme avec discuss. Mais c'est peut être ambitieux...

[J9rem]

Waouh super ton retour dès le lundi.

pour la partie cacher/afficher les commentaires, que je trouve pas top en terme d'ux et graphisme. D'ou vient cette demande, est ce que cela fait partie de la commande d'un presta? Est ce pour des raisons de performances?

C'est SupAgro, financeur de cette partie, qui en faisant des tests sur cette partie a proposé une amélioration de l'interface en permettant de replier les commentaires (mais ça n'est pas une obligation). Donc je l'ai ajouté dans la spec, justement pour le mettre à la discussion avant d'éventuellement travailler dessus. Vu ta remarque, je vais vérifier avec eux si le besoin est toujours aussi fort (dans ce cas, développement custom en surcouche) ou pas (ce qui serait plus simple) et je suis d'accord avec toi pour retirer cette spec.

J'aimerais plutot un système plus moderne, comme le lazyload des commentaires quand on scrolle vers l'endroit ou ils sont, comme avec discuss. Mais c'est peut être ambitieux...

Oh, si j'ai le droit de le faire en VueJS, pas très dur en fait....

[J9rem]

l'action {{mycomments}} a été renommée en {{usercomments}} pour correspondre au nom utilisé sur la page https://ferme.yeswiki.net/WikiDeBase/?MesContenus

[J9rem]

@mrflos

merci pour la relecture. Concernant les soucis de trop de fichiers modifiés, ... je me suis rendu compte que cette PR pointait vers doryphore et non doryphore-dev. Je viens de corriger. Ca doit être plus facile à relire.

Bizarre, j'étais persuadé d'avoir corriger ceci lors de la création de la PR

je me permets de résoudre les remarques liées à ce souci de branche de base

Je réponds aux autres conversations de cette PR dans leur flux dédié

[mrflos]

ok bien recu! j'ai répondu aux différents endroits, on y est presque!