✨ Feat: web notification improvement

[lebouquetin]

First things to do

1. read the french description
2. propose fake screenshots and a (human-driven) demo with PO
3. propose a checklist of atomic tasks
4. validate the task list with PO
5. implement first version of the feature

Feature description

Issue in French - sorry;)

Currently - Aujourd'hui le mur des notifications montre tout et agrège tout ce qui me concerne.

l'intégralité des actions faites sur tracim remontent via les TLM

un algorithme frontend filtre et agrège ce qui doit l'être pour présenter un mur de notification

En gros, l'algorithme frontend est le suivant :

1. un TLM remonte via le socket
2. le frontend applique le filtre pour savoir si le TLM doit être pris en compte dans le mur de notification ou ignoré
3. l'algorithme d'agrégation est ré-exécuté pour savoir comment afficher ce nouveau TLM (nouvel item dans la liste ? ou agrégation dans un bloc existant)

Cela s'applique à l'intégralité des TLM remontant et concernant l'intégralité des espaces dont je suis membre.

Merci de me confirmer que c'est bien ceci qui se déroule côté frontend.
Edit (Skylsmoi at 2024 05 13): I confirm this is what's happening. The point 2 is a bit different though since it is each TLM handler that calls the handleNotification function (from ReduxTlmDispatcher.jsx) to decide whether or not the TLM should be added to the notification wall.

Expected - Idée d'amélioration pour proposer une stratégie plus granulaire

point préliminaire: la config des notifications frontend serait enregistrée dans la table "user_config" qui stocke des clé/valeur sans que le backend ait connaissance de ce qui y est stocké (le backend sait qu'on stocke un truc mais il ne sait pas quoi et il ne l'exploite pas directement).

La configuration serait la suivante :

• pour chaque espace dont je suis membre, un paramétrage par défaut est déterminé:
  • soit je suis notifié par défaut
  • soit je ne suis pas notifié par défaut.
• Le paramètre pourrait s'appeler webui_notify et il vaudrait true ou false et qui serait donc le comportement par défaut pour l'espace
• pour chaque contenu on aurait un paramètre qui "override" le paramétrage par défaut : webui_notify qui vaut true ou false

Rappel : cette configuration est propre à l'utilisateur.

L'algorithme serait ensuite le suivant :

1. un TLM remonte via le socket
2. le frontend applique le filtre pour savoir si le TLM doit être pris en compte dans le mur de notification ou ignoré (c'est le mécanisme actuel, générique, on ne le change pas)
3. le frontend applique un second (nouveau) filtre pour savoir si le TLM doit être pris en compte pour l'utilisateur :
4. si webui_notify de l'espace est à true :
   1. si webui_notify du contenu est à false -> on drop le TLM
   1. sinon -> on garde le TLM
5. si webui_notify de l'espace est à false :
   1. si webui_notify du contenu est à true -> on garde le TLM
   1. sinon -> on drop le TLM
6. l'algorithme d'agrégation est ré-exécuté pour savoir comment afficher ce nouveau TLM (nouvel item dans la liste ? ou agrégation dans un bloc existant)

Avantages :

• on conserve le comportement actuel par défaut. Notamment si on n'a rien configuré de spécifique : les notifications continuent comme aujourd'hui ; et on peut toujours filtrer globalement au niveau de l'instance
• on permet une granularité fine de notification dans l'interface web.

Comment configurer l'abonnement aux notifications ?

Déjà c'est que du frontend donc c'est un bon point (on stocke en backend, mais l'intelligence est "pur JS")

La configuration se ferait donc de deux manières :

• pour la configuration de l'espace, on gèrerait ça sur le tableau de bord avec un paramétrage comme ci-dessous

• pour la configuration liée aux contenus elle serait semi-automatique :
  • dans le menu contextuel d'un contenu on ajouterait deux boutons :
    • un bouton "s'abonner au contenu" qui mettrait à jour la configuration en settant webui_notify à true. note : ce bouton ne s'afficherait pas si on a déjà webui_notify à true pour ce contenu
    • un bouton "se désabonne du contenu" qui mettrait à jour la configuration en settant webui_notify à false. note : ce bouton ne s'afficherait pas si on a déjà webui_notify à false pour ce contenu
  • dès qu'on interagit (création, réaction, commentaire, modification, tâche, etc)
    • si webui_notify existe et est à false, on ne fait rien
    • sinon, le frontend set webui_notify à true (sauf si on a déjà setté webui_notify à false car dans ce cas c'est qu'on a explicitement demandé à ne pas être notifié)
    • la configuration est enregistrée en backend et un TLM est envoyé pour mettre à jour tous les onglets / tous les clients

Un bouton dans l'entête de l'application pourrait  également permettre de s'abonner / se désabonner.

Questions / réponses

Pourrait-on avoir avec ce mécanisme de suivi d'un contenu, les réactions dans le murs des notifications pour les contenus que l'on a décidé de suivre ?

Oui, c'est l'idée.

Les mentions, au moins les personnels, seront-elles prioritaire au réglage de suivi d'un contenu ?

Oui, les mentions devraient toujours passer.

une partie des config gagnerait a se retrouver dans le profil du compte, comme ce que l'on a pour la gestion des espaces. Cela permettrait d'avoir des pages dédié, potentiellement un peu verbeuse, sans impacter la lisibilité des pages courantes.

C'est bien pour une gestion en masse mais pas au quotidien. Au quotidien il faut que ce soit directement dans les contenus

Je pense juste que le webui_notify des contenues devrait avoir trois états ( true, false, undefined ? )

L'idée est qu'on a un statut true, false ou rien de défini (qui correspond à undefined)

Je suis d'accord la dessus, les contenus dont l'etat de suivi n'est pas défini devraient hériter du comportement de leur espace parent (ou juste du parent proche donc son contenu parent ?)

Oui c'est ce qui est attendu.

Pour préciser :

• on ne configure rien par défaut.
• pas de configuration = comportement défini par la config de l'espace .

Ça rejoint ce qui est dit sauf que ça permet de ne pas décrire explicitement chaque contenu :

• si la clé "contenu xxx" existe, on prend la valeur (true ou false)

• sinon on prend la valeur de l'espace.

• dès qu'une interaction est faite par l'utilisateur, on définit la config (donc on n'est plus sur une valeur par défaut)

How it works

La configuration doit être stockée dans "user config" via les routes /api/users/{user_id:\d+}/config

Related PR

No response

[Millefeuille42]

Additionally, the notification wall can be unproperly sorted from time to time. This only happens when handling live messages and not while loading tracim.

This will be looked at during development of this feature and if fixable, we'll include it