Est-ce que vous dites que vous aviez auparavant des règles qui créaient des fils de discussion, et qu’avec la dernière mise à jour, cela ne fonctionne plus ? Ou bien est-ce que vous vous attendiez à ce que la mise à jour commence à créer des fils de discussion, mais que cela ne se produit pas ?
Je exécute Discourse 093ee1d80c et discourse-chat-integration da91061 (à jour) et mon canal avec des règles thread crée correctement des fils de discussion, uniquement pour les canaux configurés avec des règles thread.
Pouvez-vous montrer votre configuration pour une règle de fil de discussion ? Dans Admin → Plugins → Intégrations de chat, vous devriez voir des règles indiquant
alors ces règles n’utiliseront pas de fils de discussion.
Vous verrez ci-dessus la justification du fait qu’il s’agit d’une configuration par règle et non par site.
Lorsque vous configurez une règle via la commande /discourse dans Slack (ou la commande que vous avez choisie lors de la configuration de l’intégration), vous utilisez thread au lieu de watch ou follow, comme documenté dans Discourse Chat Integration
D’accord, je dois donc passer en revue les intégrations Slack et remplacer chaque occurrence de : Tous les messages et réponses < Tous les messages avec réponses en fil.
Pour l’instant, nous affichons tous les messages et réponses sur la plupart des intégrations de canal. Est-ce que cela va causer des problèmes si nous affichons à l’avenir uniquement tous les messages avec réponses en fil ? Je pose la question car j’ai beaucoup de canaux à reconfigurer, donc il vaut mieux que je les réaffecte correctement dès le début.
Si je comprends bien votre question : non, cela ne va « rien casser » — c’est conçu pour être sûr dans le sens où cela n’empêchera jamais l’envoi d’une nouvelle notification sur Slack. C’est simplement que si l’intégration connaît un fil de discussion, elle l’envoiera dans ce fil plutôt que dans le canal. Si, pour une raison quelconque, elle ne connaît pas le contexte d’un fil, elle l’enverra dans le canal tel que configuré dans la règle.
« Tous les messages avec des réponses en fil » signifie que :
Lorsqu’un nouveau message est ajouté à un sujet existant :
Si un ID de fil a été enregistré pour le sujet, utilisez-le pour publier dans un fil.
Si aucun ID de fil n’a été enregistré pour le sujet, après avoir envoyé la notification sur Slack, utilisez l’ID de fil de ce nouveau message Slack pour les messages suivants sur le sujet. Le fil de discussion commencera à partir de ce point.
Lorsqu’un nouveau sujet est publié sur Slack, enregistrez son ID de fil résultant afin que les messages supplémentaires sur ce sujet soient envoyés sur Slack sous forme de réponses en fil.
Je résumerais cela ainsi : « agissez exactement comme l’option « surveiller », sauf si vous connaissez un fil vers lequel publier, faites cela à la place ».
De plus, lorsque vous utilisez la fonctionnalité « transcription » pour publier du contenu Slack sous forme de nouveau sujet dans Discourse, indépendamment de tous les paramètres de règle, cela toujours tente d’enregistrer l’ID de fil, afin que si une règle de threadsoit existe déjà soit est ajoutée à l’avenir, les réponses aux messages sur le nouveau sujet dans Discourse soient annoncées dans le fil Slack approprié.
Je suis sûr que vos règles existantes pourraient être modifiées en tapant quelques commandes dans bin/rails c, mais je ne veux pas le faire sur mon site en production où j’ai intentionnellement choisi quels canaux filer et lesquels non. Je suis beaucoup trop débutant en Ruby pour taper du code Ruby au hasard en guise de conseil sur un forum et m’attendre à ce que cela ne vous fasse pas exploser en plein visage. À part le fait que cela commence probablement par DiscourseChat::Rule.where(, je ne pourrai pas vous aider davantage. Désolé !
@sunjam au passage, je vous remercie pour la validation du fait que vous trouviez cette fonctionnalité souhaitable et précieuse ! (Surtout compte tenu de l’ironie que je n’aime pas particulièrement les fils de discussion Slack moi-même et que j’ai fait ce travail pour d’autres qui les trouvent plus précieux que moi !)
Je peux imaginer qu’il serait logique d’ajouter un bouton dans l’interface utilisateur pour convertir toutes les règles watch en règles thread. Cependant, je ne connais pas assez bien le sujet pour le faire et je ne l’utiliserais pas moi-même. Je suis vraiment un développeur backend qui s’amuse avec Discourse, donc je ne serais même pas un réviseur utile pour une PR visant à ajouter un tel bouton. Tout ce que je peux faire, c’est être un supporter inoffensif si quelqu’un d’autre souhaite mettre en œuvre une telle fonctionnalité.
J’ai trouvé un problème @mcdanlj. Lors de la création d’une nouvelle intégration de canal, les réponses threadées n’apparaissent pas dans les tests-pass de la version bêta 1.2 pour les filtres. Une fois l’intégration créée, cette option devient disponible lors de la modification de l’intégration.
Je vois la même chose maintenant ; je n’avais même pas remarqué l’interface utilisateur pour cela, et j’ai créé mes règles avec des commandes slash depuis Slack.
Dans la mesure de ma compréhension limitée du code front-end, je pense que c’est un artefact du code demandé par @david pour masquer thread des autres types d’intégration :
Mais je suis vraiment un développeur back-end et je ne sais pas comment corriger cela. Je ne sais pas pourquoi channel.provider serait slack uniquement lors de la modification d’une règle existante, et pas lors de la création d’une nouvelle.
@sunjam Au fait, après avoir décidé de déplacer la plupart, mais pas la totalité, de mes règles d’intégration Slack de watch vers thread, j’ai ressenti ta douleur. Mes yeux se sont vraiment embués et j’étais ravi d’en avoir fini. Donc, je ne suis pas sûr que j’aurais fait quoi que ce soit différemment dans mon travail, mais je ne minimise pas le travail nécessaire pour la conversion. Au moins, c’est un coût ponctuel.
S’il existait une commande en une ligne que l’on pourrait exécuter dans la console Rails pour convertir toutes les règles watch normales en règles thread, je ne l’aurais pas encore trouvée — sinon je l’aurais utilisée, puis j’aurais reconverti les quelques règles que je souhaitais conserver en règles watch.
Les réponses aux discussions s’affichent-elles dans Tous les non lus et Discussions sur votre barre latérale Slack ? J’ai vu de nouveaux messages apparaître, mais les réponses aux discussions ne semblent pas déclencher ces notifications.
Les messages publiés par Discourse ne déclenchent pas de notifications différentes de celles des autres threads Slack, mais cela dépasse le cadre de Discourse pour toucher au fonctionnement des notifications de threads dans Slack. Je pense que les règles de notification des threads Slack ne sont pas idéales, mais Slack n’est pas un projet open source auquel n’importe qui peut contribuer pour apporter des améliorations. Il faut participer à un thread Slack ou s’y abonner pour recevoir des notifications concernant les nouveaux messages dans ce thread. Du moins, c’est la règle cette semaine. Je crois que, lorsqu’ils ont été introduits pour la première fois dans Slack, les threads suivaient les règles de notification des canaux. Je ne trouve rien dans Slack permettant de configurer les notifications des threads pour qu’elles suivent celles des canaux, et cela me rend folle, car je rate ainsi des informations importantes au travail.
Je déteste tant l’implémentation des threads par Slack que c’est vraiment ironique que ce soit moi qui aie implémenté cette fonctionnalité. Mais je pense aussi être dans la minorité, et je l’ai implémentée pour rendre Discourse plus accueillant pour la majorité des utilisateurs qui apprécient vraiment les threads de Slack.
Merci pour les précisions. Il semble que les personnes impliquées dans ThreadExample verront les réponses en fil, ce qui fonctionne assez bien. Dans les deux cas, c’est une option très utile pour désencombrer les choses côté Slack, et j’espère qu’elle inspirera d’autres intégrations de chat à incorporer des variantes similaires de ce concept !
C’est exact, ce qui inclut ceux qui ouvrent le menu des trois points verticaux dans le fil de discussion et sélectionnent « Suivre le fil » (la première option).
Je viens de réaliser qu’il y avait des maquettes plus tôt dans le fil, mais je n’avais jamais partagé d’exemple de cela en action. Donc, à partir d’aujourd’hui, dans le canal Slack pour https://forum.makerforums.info/c/k40, nous avons ceci :
Un grand merci à @david pour avoir corrigé mon bug qui empêchait la publication des transcriptions de respecter le paramètre thread_id et les envoyait à la place dans le canal !
Un grand merci d’avoir activé la synchronisation des fils de discussion Discourse sur Slack. J’ai remarqué un problème : si je colle un lien sur sa propre ligne pour générer un onebox, ce lien est complètement supprimé dans le message affiché dans le fil Slack, et je ne vois qu’une ligne vide. Dans mon cas, le lien était encadré par deux lignes de texte, qui ont été affichées correctement.
Rien de ce que j’ai fait n’a modifié le contenu du message publié, cela définit simplement parfois un fil de discussion cible.
Je suggère de créer un rapport de bug séparé, dans un fil de discussion distinct, pour les problèmes de mise en forme des messages publiés sur Slack. Je n’ai ni regardé ni touché à cela.
TL;DR : Déplacer des sujets pose problème lors de la liaison des réponses avec Slack.
J’ai remarqué que le déplacement d’un sujet entre les catégories dans Discourse semble rompre la liaison des réponses dans les canaux Slack. Cela concerne notamment le cas où quelqu’un crée un sujet dans une catégorie, puis le déplace vers une autre catégorie configurée pour un canal Slack différent.
Comme le premier message a été déplacé, il n’envoye plus les réponses threadées au même endroit sur Slack. Cela signifie que les réponses ne sont plus visibles du tout sur Slack. Si vous conservez les réponses individuelles (non threadées), vous éviterez ce problème potentiel.
Je ne suis pas sûr, mais je pense qu’il est utile de le noter. Une solution de contournement consiste à rendre l’intégration disponible dans un canal Slack supplémentaire spécifique sans fils de discussion, simplement pour qu’elle apparaisse dans au moins un canal.
À part le fait que cela commence probablement par 
