Produits Entr'ouvert » Combo

une mise à jour peut contenir des informations importantes

Il faut sans doute établir que non; on ne réutilise pas une notification pour y rajouter des informations importantes.

Ok, si c'est notre position ça me va, mais sur un double appel à notify() ou au web-service en utilisant le même publik_id() (.external_id/.id) on interdit de modifier tout sauf end_timestamp ?

Je décris quand même le cas d'usage que j'envisageais qui ressemble un peu à celui de nos factures, je lance une notification demandant une action x, sans date de fin réelle, tous les deux jours tant que ça n'est pas fait, je refais le même appel et même si la personne a fait ack() je dé-ack parce que la personne n'a rien fait.

Actuellement si on veut faire pareil, on doit avant chaque appel lister les notifications existantes voir qu'il y en a une qui correspond à notre notification et qui n'est pas acké, et s'abstenir d'en créer une nouvelle. Le fait de dé-acker une notifications existante me semblait plus simple à gérer. Si on ne fait pas ça on va créer une ribambelle de notifications qui s'accumulent (sachant que si on ne veut pas dé-acker il suffit de ne pas mettre acked: False dans l'appel).

Même sur le cas qui nous intéresse je dé-ackerai les notifications tant que les gens ne payent pas, il n'y a pas de raison de leur cacher l'information, ça les dessert plus qu'autre chose il me semble (dans mon premier jet pour ré-implémenter je faisais cela, en changeant le summary quand on passe en phase "reminder" mais j'ai changé mon fusil d'épaule parce que justement ça va dé-acker la notification tant que la personne ne payait et comme j'ai bien vu que ce n'était pas ce qui était souhaité je n'ai pas gardé ce comportement et je suis revenu à la solution précédent utilisant deux notification_id différents, mais je trouve ça moins joli). Bon par contre pas la peine de créer une notification toutes les 10 minutes, une fois par jour suffit.

Pour référence mon modèle pour les notifications c'était la notification-spec de freedesktop (https://developer.gnome.org/notification-spec/); sur la réutilisation "The optional notification ID that this notification replaces. The server must atomically (ie with no flicker or other visual cues) replace the given notification with this one. This allows clients to effectively modify the notification while it's active." (l'important ici étant "while it's active").

_~~

En tant qu'usager j'ai dit "merci j'ai vu" à une notif, je n'ai pas envie de la voir revenir.

Ce que j'ai fait justement c'est de remettre ce mode freedesktop qui me va très bien par défaut, via ce commit:

http://git.entrouvert.org/combo.git/commit/?h=wip/13222-invoice-notififications-bd&id=ad3a44d64c0b29ce806b050d93cedeee0c72b160

Donc par défaut on ne touche jamais au champ "acked" mais si explicitement demandé par un appel à notify() ou au WS on peut obtenir le comportement que je décris. Après mon avis c'est que autant la spec freedesktop est une bonne base autant c'est uniquement pensé desktop et notifications intempestives par des applications diverses et variées, ce n'est pas pensé pour un portail citoyen sur le web.

Je note tout de suite que si on ajoute un canal mail ou sms au système de notifications il faudra faire attention (autant nodifier ou dé-acker une notification online ce n'est pas bien grave, autant renvoyer un sms ou un mail ça sera un peu chiant et fera vite matraquage, mais de toute façon je pense qu'il faudra fonctionner plutôt en mode "digest" pour ces canaux là, surtout le mail et limiter les SMS aux notifications qui le méritent, mais ça sort du cadre de ce ticket et du #13122).