Im Berufsalltag nutzen wir Slack sehr häufig. Es gibt Inhalte, die auf Slack zugänglich sein müssen, aber gleichzeitig organisiert und durchsuchbar sein sollten – beides ist eine Stärke von Discourse. Wir haben bereits einige wiki-ähnliche Optionen ausprobiert, die jedoch alle veralten, unter anderem wegen der fehlenden Verbindung zu Slack. Deshalb treibe ich eine Evaluierung von Discourse voran, das parallel zu unserem bestehenden Slack laufen und mit diesem verbunden sein soll, da ich bereits ein Community-Discourse-Forum betreibe.
Allerdings haben wir viele Kanäle, die Threads intensiv nutzen. Dazu gehört auch der höchste Priorität besitzende Slack-Kanal, der bidirektional (sowohl „watch“ als auch „post“) mit Discourse integriert werden soll.
Wäre es eine Überlastung für das Chat-Integrations-Plugin, einen nicht standardmäßigen Modus einzuführen, der neue Themen als Nachrichten in Slack postet, die Zuordnung zwischen der Slack-Nachrichten-ID und dem Thema speichert und dann neue Kommentare zu diesem Thema als Thread-Nachrichten an Slack sendet? Für meinen Anwendungsfall könnte dies der entscheidende Unterschied zwischen Erfolg und Misserfolg sein.
Update: Für meinen Anwendungsfall wäre dies eine Option zum „watchen“ und keine siteweite Slack-Chat-Konfiguration, da die Präferenz für „Threads bevorzugen“ oder „Threads nicht bevorzugen“ eine kanalbezogene Einstellung ist, die vom Zweck (und den typischen Teilnehmern) eines Slack-Kanals abhängt.
Nein, es geht nicht darum, einen einzelnen Thread bidirektional zu synchronisieren, sodass man auf beiden Seiten posten kann und die Änderungen auf der anderen Seite erscheinen. Ich war für die Implementierung einer vollständig bidirektionalen Synchronisierung im Rahmen einer Active-Active-Synchronisierung über zwei sehr aktive Domänen verantwortlich und bin mir der Risiken und Fehlerquellen dabei voll bewusst.
Unser Szenario ist ein Kanal, in dem:
Threaded Antworten die Norm sind, da der Kanal dazu neigt, gleichzeitige Gespräche zu unterschiedlichen Themen zu sammeln (der Kanal dient einem geschäftlichen Zweck, nicht einem bestimmten Thema; die unpraktische Alternative wäre, die Hälfte der Entwickler täglich in dutzende neue temporäre Kanäle einzuladen).
Viele, aber nicht alle dieser Thread-Gespräche als Antworten auf Fragen identifiziert werden sollten, die später jemand anderes nachschlagen möchte. Die Integration wird genutzt, um diese als vertrauenswürdig in die zugehörige Kategorie in Discourse zu überführen (jemand wie ich kuratiert aktiv nützliche Antworten).
Neue Themen in dieser zugehörigen Kategorie in Discourse zu Slack-Posts in diesem Slack-Kanal führen sollen.
Zusätzliche Kommentare zu diesen neuen Themen sollten als Thread unter dem ursprünglichen neuen Slack-Post in Slack veröffentlicht werden.
Unsere Benutzer angewiesen werden, zuerst in Discourse zu suchen, bevor sie in Slack fragen.
Außerdem lässt mich Ihre Frage darüber nachdenken, dass es als verwandte Funktion wünschenswert wäre, beim Zusammenfassen eines Slack-Threads in einen Discourse-Beitrag die Möglichkeit zu haben, dass die Integration einen Verweis auf das neue Discourse-Thema ans Ende des ursprünglichen Slack-Threads postet, der gerade zusammengefasst wurde. Das würde uns helfen, die Konversation an einem Ort zu halten.
Das hängt tatsächlich mit der ursprünglichen Ideen für diese Funktion zusammen: Wenn wir beides hätten, wäre es sinnvoll, beim Zusammenfassen nicht eine neue Slack-Nachricht zu posten, sondern die Nachricht in den zusammengefassten Thread zu schreiben und diesen Thread als Ort für zusätzliche Discourse-Kommentare zu kennzeichnen. Zusätzliche Slack-Kommentare in diesem Thread würden nicht nach Discourse übernommen; stattdessen sollte die Konversation auf Discourse zu diesem Thema gelenkt werden. Das erscheint mir logisch:
VORAUSSETZUNG: Es gibt einen Ort, um die mit einem Thema verknüpfte Slack-Nachrichten-ID zu speichern.
UND: Neue Kommentare zu einem Thema werden als Kommentare zur gespeicherten Slack-Nachricht veröffentlicht.
DANN: Setzen Sie die Slack-Nachrichten-ID für ein Thema, wenn Sie die Slackbot-Integration „post thread“ verwenden, sodass neue Discourse-Kommentare zu diesem Thema in diesem Thread angekündigt werden, einschließlich Verweisen zurück auf das Discourse-Thema/den Discourse-Kommentar.
Das würde die Idee „Zuerst Discourse prüfen, bevor man fragt“ wirklich fördern.
@riking Ein bisschen, aber mit einigen Unterschieden.
Die Ankündigung würde nicht ganz so aussehen; sie würde von der watch-Seite der Integration veröffentlicht werden. Sie würde nicht erwähnen, dass etwas verschoben wurde. Hier ist ein Beispiel für die aktuelle (nicht verschachtelte) Benutzeroberfläche, wie sie von der Slack-Integration stammt, die ich für makerforums implementiert habe:
Im verschachtelten Modell würde der erste dieser Beiträge einen Slack-Thread starten, und Nedmans Kommentar wäre stattdessen eine verschachtelte Slack-Antwort. Wenn post thread :thread_url verwendet wird, würde die :thread_url mit dem neuen Thema gespeichert, und die watch-Seite der Chat-Integration würde den ersten Themenbeitrag und alle weiteren Kommentare in diesen Slack-Thread posten, wobei der Inhalt derselbe bliebe.
Die watch thread-Integration leitet dich zu Discourse weiter, wo du den Titel eingeben und die Möglichkeit haben musst, den neuen Themenbeitrag vor dem Veröffentlichen zu bearbeiten. Die Ankündigung, die in Slack veröffentlicht wird, würdigt also bereits die Person, die post thread ausgeführt hat, als Autor, enthält dann eine Zeile mit dem Thementitel als Linktext, der zu Discourse führt, und schließlich ein Zitat aus dem Anfang des Beitrags. Die hier vorgeschlagene Änderung besteht darin, dass diese Inhalte mit einer nicht standardmäßigen, pro-Kanal-Konfiguration (also einer watch-Option, nicht einer plugin-weiten Chat-Integration-Konfiguration) in den Thread statt in den Kanal gepostet würden. (Nicht „auch an den Kanal senden
Ich habe darüber nachgedacht und die chat.postMessage Slack-API-Dokumentation gelesen, und ich glaube, ich kann meine Wortflut auf etwas viel Einfacheres reduzieren.
Nur watch und nicht follow hat die Möglichkeit, Thread-Antworten zu wählen, durch einen Mechanismus, den ich noch herausfinden muss. Alternativ, @david, was hältst du von einem neuen thread-Regelfilter mit der Priorität mutethreadwatchfollow und dem Durchreichen der Regel über trigger_notification, um regelabhängiges Verhalten zu ermöglichen?
Wenn watch so konfiguriert ist, dass es Threads erstellt (alternativ, wenn eine thread-Regel definiert ist), wird beim Senden einer neuen Post-Benachrichtigung an einen Slack-Kanal, falls das Post-Thema eine Slack-ts (Timestamp) zugeordnet hat, in diesen Slack-Thread gepostet, indem thread_ts auf den bereitgestellten ts-Wert von Slack gesetzt wird.
Beim Senden einer neuen Post-Benachrichtigung an einen Slack-Kanal, falls das Post-Thema keinets zugeordnet hat, wird die zurückgegebene Antwort-ts für das Thema gespeichert (damit zukünftige Posts zum Thema in Threads gepostet werden können, wenn watch für Threads konfiguriert ist).
Beim Verwenden des Befehls post thread :thread_url wird die Thread-ts im erstellten Thema gespeichert, das nur von Thread-watch-Regeln verwendet wird.
Hier sind meine aktuellen Gedanken und Bedenken:
Wie man entscheidet, ob auf Thread-Ebene pro Regel gepostet werden soll. Ein neuer Filter erscheint mir im Moment am einfachsten, aber vielleicht übersehe ich etwas.
Das Durchreichen der ursprünglichen Slack-Post-URL und der Thread-ID durch den Transcript-Flow ist mir derzeit am undurchsichtigsten. Das sieht so aus, als müsste ich wirklich eine pro-Provider-Thread-ID irgendwo hinzufügen und sie bis zum Speichern des Posts erhalten. Ich würde dies nur für Slack-ts implementieren, aber wahrscheinlich wird es nicht die einzige Chat-Integration mit Threads sein.
Für das Posten denke ich, dass ich die Slack-ts in einem slack-spezifischen benutzerdefinierten Feld im Topic speichern muss, nicht in einem allgemeinen DiscourseChat-benutzerdefinierten Thread-Feld.
Muss der boolesche Wert ‘threading’ wirklich pro Regel sein? Warum nicht eine neue Site-Einstellung erstellen?
chat_integration_slack_thread_responses
Wenn dies aktiviert ist und wir eine Aufzeichnung der Thread-ID des Themas haben, senden wir nachfolgende Benachrichtigungen an den Slack-Thread.
Ja, das finde ich völlig in Ordnung. Verwende einfach ein slack-spezifisches benutzerdefiniertes Themenfeld. Falls wir dies später für andere Anbieter implementieren müssen, können wir die Lösung allgemeiner gestalten.
Ja, das ist sehr knifflig. Als v1 würde ich versucht sein, etwas wie
<!--SLACK_THREAD_ID=abcdefg-->
am Anfang des Beitrags einzufügen. Dann kann das Plugin nach Beiträgen suchen, die mit dieser Zeichenkette beginnen, und das benutzerdefinierte Feld zuweisen. Es ist nicht perfekt, aber vielleicht ein guter Ausgangspunkt?
Gestern Abend habe ich meine ersten beiden ACs implementiert und habe durchgängig Tests in der gesamten Stack bestanden (obwohl ich sie noch nicht live getestet habe), und zwar mit einem benutzerdefinierten Feld in Topic und einer thread-Regel. Der Transkript-Workflow ist jedoch noch nicht enthalten. Ich mache also gute Fortschritte, um Code zumindest in einem vorläufigen PR zeigen zu können.
Ich habe außerdem einen separaten Commit, um die ungenutzte pstore_get aus dem Slack-Provider zu entfernen. Da dies der einzige Verwendungszweck von pstore in der gesamten Stack ist, möchten Sie, dass ich in diesem Bereinigungs-Commit auch alle pstore_*-Aufrufe aus app/initializers/discourse_chat.rb entferne?
[quote=“david, post:9, topic:150759”]
Muss der boolesche Wert „threading
Was wäre, wenn es eine weitere Einstellung gäbe, z. B. cross_post_to_channel_after_hours (Standardwert: 48?), bei der ein Beitrag, wenn die Zeit seit der letzten Antwort länger als x Stunden beträgt, automatisch in den Thread mit dem Flag „auch an Kanal senden
Keineswegs eine verrückte Idee, aber ich plane nicht, sie umzusetzen, da sie meinen Hauptanwendungsfall brechen würde und ich sie nirgendwo anders benötige. Ich verstehe jedoch vollkommen, dass andere Nutzer dies wünschen würden!
Wenn es eine normale Einstellung wäre und keine pro-Kanal-Option, würde sie chat_integration_slack_copy_threads_to_channel_after_hours heißen. Der Standardwert wäre 0 (nicht senden), aber Sie können ihn auf einen beliebigen Wert setzen. Konzeptionell ist es ziemlich einfach, erfordert jedoch mehr Aufwand, da Sie den Thread abrufen müssen (unter Verwendung des Codes, der ursprünglich für Transkripte geschrieben wurde – ich weiß im Moment nicht, ob eine Umstrukturierung erforderlich wäre), um eine Entscheidung über das Setzen eines einfachen Flags zu treffen.
Wenn Sie jedoch daran arbeiten möchten, hoffe ich, dass mein Ansatz eine gute Grundlage bietet. Ich würde nur bitten, es standardmäßig nicht zu aktivieren, denn wenn dies bei einem Upgrade passiert und meine Nutzer von mir als „Spam
@david Ich habe einen Entwurf-PR erstellt, der die von mir geschriebenen Unit-Tests besteht. Ich habe ihn noch nicht live gegen Slack getestet, daher möchte ich ihn erst zusammenführen, wenn das erledigt ist. Aber zumindest bestehen alle Unit-Tests bei mir, und ich habe versucht, aussagekräftige Tests dafür hinzuzufügen.
Ich habe den ID-Kommentar auch ans Ende statt an den Anfang des Beitrags gesetzt, da ich denke, dass er dort eher bestehen bleibt und weniger wahrscheinlich verfälscht wird, und ich habe versucht, beim Parsen konservativ vorzugehen.
Danke für deine Arbeit an diesem Plugin!
Ich habe meine anfänglichen Linting-Fehler behoben, aber jetzt schlagen Tests fehl, die ich nicht geändert habe. Ich arbeite auf Basis des neuesten Masters, und die Tests laufen lokal durch. Hast du eine Ahnung, warum die Tests fehlschlagen?
Ich habe den PR schon stark bereinigt, aber er ist noch nicht ganz bereit für den Merge. Ich habe bisher zwei oder drei Dinge, die mir Schwierigkeiten bereiten, und ich weiß noch nicht, wie ich sie beheben soll.
Ich versuche, fa-arrow-circle-o-right als Thread-Icon zu verwenden, aber es wird in der UI auf meiner Live-Website leer angezeigt. (Nach dem Auschecken meines Branches auf der Live-Website führe ich su discourse -c 'bundle exec rake assets:precompile' && sv restart unicorn aus, um es auf dem Live-Server zu testen.) Ich habe es sowohl in plugin.rb hinzugefügt als auch referenziert, aber ich bin ratlos, was die nächsten Schritte sein sollen. Gibt es eine Liste der Font Awesome-Icons, die für die Verwendung in Discourse genehmigt sind? Ich habe lib/svg_sprite/svg_sprite.rb gefunden, und chevron-right sieht für diesen Zweck großartig aus.
Die Tests laufen bei mir lokal alle durch, aber in Travis erhalte ich konsistente Fehler, die anscheinend nichts mit meinen Änderungen zu tun haben. Das macht es für mich natürlich schwer, sie zu untersuchen oder zu analysieren. 13 Fehler mit einem 404 statt eines erwarteten Codes (z. B. 200) in spec/lib/discourse_chat/provider/slack/slack_command_controller_spec.rb Behoben, indem ich isolate_namespace nicht mehr blind nachgebaut habe, und jetzt kenne ich rake routes.
Ich finde hier ständig neue Lernmöglichkeiten. Jetzt weiß ich, wie man yarn prettier ausführt, und als Nächstes lerne ich, wie man Frontend-Tests aktualisiert…
Fehler: Assertion fehlgeschlagen: Die Eigenschaft `channel` (von <(unknown):ember3806>) muss mit set() auf `<(unknown):ember3799>` gesetzt werden.
Ich schätze eure sehr hilfreichen Bewertungen! Wie versprochen habe ich den offiziellen Integrations-Wikibeitrag aktualisiert. Wenn ihr die Änderungen lieber anders hervorheben möchtet, ist das völlig in Ordnung – ich habe kein Autoren-Ego oder ähnliches.
Wir haben vor einigen Tagen auf die aktuelle 2.6 beta1a aktualisiert, die Tests bestanden. Soweit ich feststellen kann, werden seit dem Upgrade jedoch keine Slack-X-Beiträge als Threads angezeigt. Wir sehen weiterhin Themenbeiträge und Antworten einzeln in den Slack-Kanälen.
