Je viens d’effectuer une action de modification groupée sur près d’un millier de sujets pour nettoyer/réorganiser légèrement une catégorie. Je ne m’attendais pas à ce que cette action envoie des e-mails (sauf peut-être aux créateurs des messages que leurs messages avaient été modifiés), mais les utilisateurs qui surveillaient la catégorie de destination ont reçu près d’un millier d’e-mails chacun !
Notez que cette action de modification groupée n’a pas modifié la date de remontée du sujet — même sur les sujets qui n’avaient pas de réponses. J’ai commencé avec quelques sujets pour confirmer que c’était le résultat avant de faire les mille. C’est exactement le comportement que je souhaiterais, et dans mon modèle mental naïf, une date de remontée rafraîchie est assez étroitement corrélée à une notification par e-mail (mais évidemment, c’était erroné).
C’est un comportement inattendu avec une issue très lourde de conséquences. Ce serait formidable si l’interface utilisateur rendait cela plus évident ou si cela ne se produisait tout simplement pas.
La boîte de dialogue elle-même semble assez anodine, et les points de suspension dans le bouton Définir la catégorie… donnent l’impression qu’il y aura encore un autre panneau avant que l’action ne soit effectuée.
Je ne comprends pas tout à fait ce que vous demandez, mais le statu quo (par défaut), tel que je le comprends, est le suivant :
Jane regarde les nouveaux premiers messages dans la catégorie #foo.
Je modifie en masse 1000 anciens sujets, les déplaçant de #bar vers #foo.
Jane reçoit 1000 notifications (e-mails, bips ou badges) qui lui semblent « périmées » — naviguer vers la catégorie #foo n’affiche aucun de ces sujets comme étant réellement nouveaux, car la date de mise à jour du sujet n’a pas changé.
J’aimerais que ce comportement change d’une ou plusieurs manières. Je pense qu’il serait utile que Discourse signale la possibilité de nombreuses notifications lors de l’étape 2. Il serait encore mieux s’il était possible d’éviter ces notifications avec une case à cocher ou quelque chose de similaire pendant l’étape 2. Et je pense que ce serait tout simplement le comportement par défaut — peut-être est-ce mon manque d’imagination, mais j’ai l’impression que les administrateurs souhaitent généralement effectuer des actions en masse sans envoyer de notifications en masse. C’est un cas très différent du déplacement d’un seul sujet.
Oui, j’ai découvert que le paramètre « Désactiver les notifications d’édition de catégorie sur les sujets » affecte apparemment les notifications watching_first_post après avoir cherché ici et trouvé le sujet lié ci-dessus. Je n’étais pas au courant de ce paramètre avant cela, mais même si j’en avais été conscient, je pense que je m’attendrais à ce qu’il n’affecte que les notifications edit de l’auteur du sujet, compte tenu de sa formulation. C’est certainement utile à savoir, mais je pense que le fait que vous essayiez de vous souvenir de le désactiver pour les actions groupées en dit long.
Je pense qu’il est logique qu’une édition de catégorie manuelle (action non groupée) déclenche une notification watching_first_post. Et cela ne me dérange pas vraiment que l’auteur du sujet reçoive une notification edit lors d’une action groupée (il y en a probablement beaucoup moins et il est beaucoup plus évident de comprendre pourquoi elles se produisent).
Je vois cela comme une demande de fonctionnalité :
Vous êtes sur le point de changer les catégories de 1293 sujets, ce qui notifiera 8000 personnes qui suivent la catégorie new. Souhaitez-vous les notifier ?
Il y a aussi la nouvelle fonctionnalité possible d’une notification « en bloc » pour des cas comme celui-ci qui devrait être développée :
784 sujets ont été changés de categoryA à la catégorie que vous suivez / suivez le premier message.
Cela ne ressemble pas à un bug, mais plutôt à une amélioration possible que nous pouvons apporter.
Il existe également un paramètre disable system edit notifications, qui « désactive les notifications de modification par l’utilisateur système lorsque ‘download_remote_images_to_local’ est actif ».
Je suppose que c’est pour que, lorsque les publications sont automatiquement réécrites pour utiliser les URL de téléchargement locales, cela ne soit pas gênant. (Quelqu’un peut-il confirmer ?) Mais il semble également que vous puissiez apporter des modifications « silencieuses » via l’API si vous utilisez l’utilisateur système…
Il semble que cela se soit produit plusieurs fois. Je pense qu’il y a aussi celui-ci qui soulève un point sur la re-notification des personnes qui ont été @mentionnées dans l’original :
Je vais voir si je peux arranger ça.
(J’ai opté pour une fermeture et une redirection car une fusion aurait pu devenir compliquée)
J’ai cherché des fils de discussion similaires et en ai trouvé quelques-uns, mais bon sang, il y en a beaucoup. Cela ne fonctionne tout simplement pas comme beaucoup de gens s’y attendent. Mes attentes étaient à peu près en phase avec ce sentiment :
Mais ce n’est pas exact. Il est vrai que les modifications groupées ne font pas remonter les sujets, mais elles déclenchent des notifications.
Nous avons d’autres limites, comme le nombre maximum de mentions, qui fournissent simplement un retour d’information du type « vous avez dépassé le nombre maximum de mentions, donc personne ne sera notifié ».
Peut-être que c’est ce que nous faisons ici ? Définir une taille maximale pour les notifications en masse et l’afficher de manière discrète lorsqu’elle est dépassée ?
Nous pourrions choisir une valeur par défaut raisonnable entre 5 et 20. Les sites qui ne souhaitent jamais de notifications en masse pourraient la définir sur 0 et les sites qui souhaitent toujours notifier peuvent la définir sur un très grand nombre.
Oh génial, est-ce que cela a été résolu ? Je vois maintenant une nouvelle case à cocher dans la fenêtre modale « Mettre à jour la catégorie » en masse !
