Ajout d'une notification lorsqu'un commentaire est ajouté à une discussion sur une observation

[mvergez]

Bonjour,

Dans le cadre d'une prestation pour l'Agence Régionale de la Biodiversité Ile de France, nous souhaitons implémenter un nouveau type de notification : une notification lorsqu'un commentaire est ajouté à une discussion sur une validation.

J'ouvre une PR dans ce sens si cela vous convient.

[camillemonchicourt]

La notification serait déclenchée si je suis Observateur de l'observation commentée ?

Si j'ai commenté une observation est qu'un autre commentaire est ajouté ?

PS : les discussions concernent les observations, pas spécifiquement leur validation

[mvergez]

Pour l'instant, si tu es abonné, la notification est envoyée à l'id_digitiser quand une de ses observations reçoit un commentaire.
On pourrait effectivement prévoir de s'abonner à une discussion à laquelle on a participé mais cela n'est pas prévu ici.

Ah oui bien vu, je change le titre. Merci !

[camillemonchicourt]

OK ça me semble pertinent.

Mais il ne faut pas se baser seulement sur le id_digitizer mais aussi sur les id_role des observateurs car je ne crois pas que l'on renseigne l'id_digitizer quand tu sais avec Occtax-mobile (à vérifier).

Et en effet ça semble cohérent et utile aussi d'être notifié quand quelqu'un a répondu à un commentaire que tu as fait.

[camillemonchicourt]

Bon en vérifiant, Occtax-mobile renvoie bien un id_digitiser avec l'id_role de la personne qui saisit le relevé sur mobile, donc c'est une bonne chose.

select id_digitiser, meta_device_entry  from pr_occtax.t_releves_occtax
order by date_min desc 
limit 1000

Le fait de prendre en compte les id_role des observateurs d'un relevé et pas seulement l'id_digitiser est donc moins importantr, mais se discute quand même ?

[mvergez]

Merci beaucoup @camillemonchicourt pour tes retours.

Effectivement ça se discute, mais ça devient je pense un peu plus complexe comme mentionné dans la PR

[camillemonchicourt]

Fait dans #2461 et élargit aux observateurs et aux commentateurs :

• Si "admin" fait une obs avec "agent" et que "validateur" commente : "agent" et "admin" sont prévenus
• Si "admin" rajoute un commentaire : "agent" et "validateur" sont prévenus

[camillemonchicourt]

Un autre sujet qui n'a pas été discuté est le sujet des notifications par défaut.
Quand les fonctionnalités de notifications ont été développées dans la 2.11.0, elles se concentraient sur le fait de pouvoir être notifié quand une de nos observations voit son statut de validation modifié.

Pour être notifié par email ou dans l'application, un utilisateur doit aller s'abonner explicitement à un type de notifications.
C'est un peu une limite, car il faut que l'utilisateur sache que ces notifications existent et qu'il s'y abonne manuellement (et qu'il trouve comment s'y abonner, ce qui n'est pas forcément hyper explicite).

Quand on a étendu le système de notifications aux imports terminés, on s'est dit que ce serait peu ou pas utilisé si l'utilisateur devait s'abonner lui-même.
Un mécanisme de notifications par défaut a alors été mis en place et intégré dans la 2.12.0 :

Possibilité de définir des règles de notifications par défaut, s’appliquant aux utilisateurs n’ayant pas de règle spécifique. Pour cela, il suffit d’insérer une règle dans la table gn_notifications.t_notifications_rules avec id_role=NULL (#2267)

Ce mécanisme a alors été mis en place pour que les utilisateurs reçoivent par défaut des notifications quand leur import est terminé (auxquelles ils peuvent se désabonner) : #2267

Il me semble qu'il faut faire pareil pour les notifications lorsqu'une observation est commentée, sinon 95% des utilisateurs ne sauront pas qu'ils peuvent s'abonner à ses notifications et donc ne les recevront pas.

Cela consiste en :

INSERT INTO
            gn_notifications.t_notifications_rules (code_category, code_method)
        VALUES
            ('OBSERVATION-COMMENT', 'DB'),
            ('OBSERVATION-COMMENT', 'EMAIL')

PS : Ça pourrait aussi être l'occasion d'ajouter ces notifications par défaut sur le changement de statut de validation, car là aussi peu de chance que les utilisateurs sachent et pensent qu'ils peuvent s'abonner à cela.

[DonovanMaillard]

D'accord avec toi, c'est d'ailleurs ce que j'ai fait manuellement sur l'une de mes instances en mettant tous les id_role sur la 2.11.

Mais du coup, si activé par défaut, je pense qu'on peut se limiter aux notifications "DB" sans forcer l'envoi de mails, qui peut vite être pénible je trouve quand tu n'as rien demandé...

[camillemonchicourt]

Avec la 2.12, pour appliquer une notification par défaut à tous, on lui met ID_ROLE = null et ainsi tout le monde est abonné.

Oui on s'est demandé si on activait par défaut que DB ou que EMAIL, mais c'est discutable (si tu vas peu dans l'application tu ne seras pas alerté sans les emails, ou que tu ne vois pas que tu as des notifications dans l'application), donc on a préféré mettre les 2 et ceux qui veulent ne gardent que DB ou EMAIL ou se désabonnent complètement.

[DonovanMaillard]

oui, je corrigerai ça en passant sur la 2.12 :)

ca marche pour les notif par défaut, je supprimerai les mails chez nous !

[camillemonchicourt]

Intégré dans la 2.13.0.