TL;DR :Il semble que les sujets planifiés ne déclenchent pas de notifications de nouveau sujet pour les observateurs au moment de la publication. Le cas d’usage consiste à regrouper un sujet de notification pour les points Scrum quotidiens par jour ouvrable, à les publier à une heure déterminée et à envoyer des rappels aux participants du point.
Reproduire :
Faites en sorte que des utilisateurs non administrateurs observent une catégorie privée spécifique.
Assurez-vous que ces utilisateurs, lorsqu’ils n’ont pas de session active, reçoivent des notifications par e-mail des nouveaux sujets créés manuellement dans la catégorie.
Créez manuellement un nouveau sujet dans la catégorie désignée pour tester le « cas témoin » où un utilisateur recevrait une notification par e-mail d’un nouveau sujet.
Ensuite, créez un nouveau sujet en attente dans une catégorie privée distincte, par exemple dans la catégorie Staff. (Optionnellement, modifiez le propriétaire du sujet ou du premier message.) Planifiez la publication du sujet ultérieurement, par exemple dans 5 minutes.
Attendez l’heure de publication…
Comportement attendu :
Parce qu’ils observent la catégorie spécifique (privée), les utilisateurs non administrateurs qui ne sont pas actifs sur le site doivent recevoir une notification par e-mail pour les deux types de sujets (« réguliers » et planifiés).
Comportement observé :
Les utilisateurs ne reçoivent une notification par e-mail que pour les sujets « réguliers » (non planifiés) créés manuellement dans la catégorie désignée.
Je viens de tester cela sur mon site de développement local. Mon utilisateur n’a pas reçu de notification par e-mail pour un brouillon partagé qui était programmé pour être publié dans une catégorie protégée qu’il suit. L’utilisateur reçoit bien des notifications par e-mail pour les sujets publiés directement dans la catégorie protégée.
En me connectant en tant qu’utilisateur de test, je constate qu’il a reçu une notification de type « modifié » pour le sujet publié à partir de la catégorie des brouillons. Cependant, une notification « modifié » ne génère pas d’e-mail.
Édition : J’ai également essayé de publier manuellement un brouillon partagé en cliquant sur le bouton « Publier le brouillon partagé ». Cela ne génère également ni notification de nouveau sujet ni e-mail de notification. Cela crée simplement une notification de type « modifié » pour les utilisateurs qui suivent la catégorie.
Merci. J’ai eu des utilisateurs qui m’ont demandé hier s’ils devaient recevoir des e-mails lorsque des messages sont modifiés. Maintenant, je peux leur répondre.
Pour clarifier, je pense que le fait qu’une notification de modification se déclenche au lieu d’une notification de « nouveau sujet » est à l’origine du comportement inattendu dans ce cas.
Sauf que, du point de vue des utilisateurs, c’est un nouveau sujet. Le fait que l’horodatage soit mis à jour va dans ce sens. (Et traiter les notifications comme un nouveau sujet serait un comportement cohérent.)
Je suppose que l’expérience utilisateur (UX) est conçue pour fonctionner du point de vue de l’utilisateur, et non du développeur.
Uniquement dans le sens où elle est passée d’une catégorie privée à une catégorie publique. Ce n’est toujours pas nouveau, seule sa catégorie a changé.
Les utilisateurs finaux n’auraient aucune connaissance implicite de ce fait, car le sujet a nécessairement été préparé hors de leur vue et était destiné à être affiché comme « nouveau » à l’heure prévue. En effet, c’est le cas d’usage principal des sujets programmés, d’après ce que j’en vois.
Nous avons vérifié cela attentivement lors de notre premier défi du 3 décembre. Cela reposait entièrement sur des sujets publiés automatiquement et les utilisateurs ont bien reçu une notification à cette époque. Si cela ne fonctionne plus, cela poserait un problème pour nous.
Je suppose que le problème discuté ici concerne ce qui se produit lorsqu’un sujet brouillon est publié dans sa catégorie de destination. Les mêmes règles s’appliquent à la publication d’un brouillon partagé qu’à la recatégorisation d’un sujet, de sorte que les deux cas peuvent être gérés ici.
Avec la fonctionnalité actuelle, les utilisateurs qui surveillent une catégorie recevront une notification de « modification » lorsqu’un brouillon partagé est publié dans sa catégorie de destination, ou lorsqu’un sujet est recatégorisé dans la catégorie surveillée. Les notifications de modification ne génèrent pas d’e-mails, de sorte que les utilisateurs ne seront pas notifiés par e-mail lorsque le brouillon est publié.
Le fait qu’une notification de « publication » ou de « modification » soit créée dépend de la valeur du paramètre new_record utilisé dans l’appel à post_alerter.notify_post_users dans le travail NotifyCategoryChange. Ce paramètre est par défaut à true, mais il est maintenant explicitement défini sur false dans le travail. C’est un changement récent. Il peut y avoir une bonne raison à cela dont je n’ai pas connaissance.
J’aime charger mes sujets comme des sujets programmés dans une catégorie privée, puis les publier automatiquement dans une catégorie publique.
Mais comme toi — même quand je mentionne une équipe avec @ — personne ne reçoit la notification. Il semble que la republication ne génère pas de notification. Comme l’a mentionné @codinghorror, cela doit se comporter comme un sujet modifié lorsque la catégorie change.
Mise à part les complexités techniques, existe-t-il un moyen de programmer un post et de notifier un groupe spécifique de mentions @ (comme @members) ?
Voici ce qui semble être le changement en cause, mais je ne parviens pas à identifier ce qui l’a motivé :
Mise à jour :
Pour ceux qui ont besoin d’une solution de contournement urgente, j’ai pu utiliser l’action Discourse « Nouveau message » dans Zapier pour déclencher des notifications vers le système de chat de notre équipe, en remplacement du plugin Discourse Chat.
J’ai finalement contourné ce bug lié aux sujets temporisés en déclenchant le « Zap » en fonction de l’heure du jour et en publiant directement dans la catégorie de destination. Ainsi, l’API déclenche l’événement « Nouveau », et je peux utiliser le plugin d’intégration Discourse Chat pour envoyer les notifications appropriées.
Il est également possible de surveiller les sujets, puis de filtrer les « nouveaux sujets » (Zapier les considère toujours comme nouveaux) qui apparaissent dans la catégorie de destination souhaitée. J’ai d’abord utilisé cette approche, mais j’ai opté pour la méthode plus simple décrite ci-dessus afin de pouvoir automatiser la création quotidienne de messages pour lancer notre point quotidien.
Fondamentalement, j’ai légèrement amélioré la logique autour des notifications.
Si l’utilisateur a déjà vu le message, le type de notification doit être edited. C’est le cas, par exemple, lorsque l’OP ajoute une catégorie ou un tag surveillé par un autre utilisateur.
Cependant, lorsque l’utilisateur n’a pas encore vu le message, le type de notification doit être « new reply ». C’est le cas, par exemple, lorsque le sujet se trouve dans une catégorie privée et est programmé pour une publication ultérieure. Dans ce cas, nous modifions un sujet existant, mais du point de vue de l’utilisateur, cela ressemble à un nouveau message.
Pourriez-vous confirmer si cela résout le problème mentionné ?
Savez-vous si cette notification doit se déclencher pour les utilisateurs Suivre le premier message ou pour le paramètre de filtre d’intégration de chat Premier message uniquement ?
À ma connaissance, lorsque la catégorie est ajoutée (ce qui se produit lorsque le sujet est déplacé, par exemple, d’une catégorie privée vers une catégorie publique), les deux types d’utilisateurs sont notifiés.
Premièrement, les personnes suivant cette catégorie spécifique reçoivent une notification, et selon qu’elles ont déjà vu le sujet ou non, il est décidé si cela doit être marqué comme modifié ou nouvelle réponse.
Ensuite, les personnes suivant le premier message sont notifiées ; toutefois, pour elles, nous utilisons un type de notification différent appelé suivi du premier message.
