Ist eine Community-Workflow-Vorlage geplant? Ich denke, sie könnte dieser fantastischen Implementierung einen großen Mehrwert bieten.
Mir sind die technischen Einschränkungen nicht bekannt, aber ich bin der Meinung, dass Discourse Discovery diese Funktion aktivieren/deaktivieren und die Verbindung zum Discourse-Ökosystem wiederverwenden kann.
Okay, das habe ich vermutlich übersehen, weil ich ein Update durchführen muss. Danke.
[Edit] Nach dem Update ist alles in Ordnung, vielen Dank für diesen manuellen Bump 
Hallo @j.jaffeux, wenn ich den Trigger „neuer Benutzer“ verwende, möchte ich, dass die folgende Aktion nur dann ausgeführt wird, wenn das neue Benutzerkonto aktiviert wurde (um Bots, die neue Benutzer registrieren, auszuschließen). Muss ich dafür den Status „genehmigt“ als Filter verwenden? Vielen Dank.
Und falls meine Annahme oben richtig ist: Wie gebe ich den TRUE-Wert an? Als „True“ oder „T“? Vielen Dank?
Es hat jetzt wohl doch funktioniert! Freue mich sehr über die Funktion
Anstatt user.approved per Drag & Drop zu verschieben, bleiben Sie im normalen Modus und wählen Sie user.approved in der Liste aus. Sie sollten dann Folgendes sehen:
Ist es möglich, Folgendes einzurichten:
Auslöser: Ein gestufter Nutzerpost antwortet in einer bestimmten Kategorie
Aktion: Das Thema, auf das der gestufte Nutzer geantwortet hat, wird automatisch geschlossen – ähnlich wie
Nein, hier fehlen noch ein paar Details.
Danke – meinst du damit, dass in Workflows noch einige Details oder Datenpunkte fehlen, um diesen Anwendungsfall zu unterstützen?
Danke, das habe ich gemacht, aber der Filter user.approved scheint nicht die Benutzer zu filtern, die sich registriert und ihr Konto bestätigt haben.
Ich habe seit Stunden versucht, mit den Workflows etwas auf die Beine zu stellen. Ich bekomme die KI einfach nicht dazu, ohne dass ein Fehler gemeldet wird. Vielleicht wechsle ich das KI-Modell und versuche es dann erneut.
Was ich erreichen möchte, ist etwas in dieser Art: (und das passt sehr gut zur aktuellen Diskussion!)
Im Grunde versuche ich nur, einen Workflow zu erstellen, der versucht, bei veralteten Beiträgen, die möglicherweise eine Nachfolgemeldung erfordern, wieder etwas Engagement zu wecken.
Hat jemand eine Idee? Ich konnte die Beiträge mit dem Data Explorer abrufen und eine Zusammenfassung von der KI erhalten. Die Datentabellen habe ich nicht zum Laufen gebracht und es nicht bis zur Phase des automatischen Postings geschafft. Aber ich war recht nah dran.
Mein Gedanke war, es in mehrere Workflows aufzuteilen:
Ich bin mir nicht sicher, ob ich das mit der Nutzung richtig verstanden habe, aber dieses Plugin hat ein enormes Potenzial!
Es ist im Output, wo du die JSON-Daten selbst definieren kannst.
@j.jaffeux Als Nachtrag zu meiner Frage oben: Ich habe einen PR eröffnet, der eine Event-Aktion für Workflows hinzufügt:
Er fügt Folgendes hinzu:
Die Aktion nimmt eine Topic-ID entgegen, löst das Event aus dem ersten Beitrag des Topics auf und aktualisiert das Event über den normalen Pfad für Beitragsbearbeitung/Event-Synchronisation.
Ich habe die ursprüngliche Richtung des Use Cases mit folgendem getestet:
Beitrag erstellt → Event / Event schließen
mit Input → topic.id.
Eine Antwort auf das Event-Topic schließt dann das Event, während das Topic selbst offen bleibt, und die Änderung wird live in der UI angezeigt.
Der PR enthält Unit-/Integrationstests, und der vollständige discourse-events-Testlauf bestand mit 1124 Beispielen / 0 Fehlern.
Dies deckt die Event-Aktionsseite des oben genannten Use Cases ab. Die Bedingungen für Benutzer/Kategorie/E-Mail-Herkunft können dann separat durch den Workflow-Trigger/die Bedingungen behandelt werden.
Hast du Tipps zum automatischen Verschlagworten von Antworten eines KI-Agenten? Ich versuche gerade den folgenden Workflow, aber er erkennt die Antworten des Agentennutzers nicht.
Nur zur Info: Dies ist ein versteckter Tag, aber der Agent befindet sich in einer Gruppe, die ihn sehen kann.
{
"id": "6",
"name": "My workflow",
"nodes": [
{
"id": "a8490306-e7e7-42e4-b909-851f3c4fbcba",
"type": "trigger:topic_created",
"typeVersion": "1.0",
"name": "When a new personal message is created",
"parameters": {
"topic_type": "personal_messages"
},
"credentials": {},
"webhookId": null,
"position": {
"x": 178.6210678807947,
"y": -18.94519916824343
}
},
{
"id": "a80813a3-35cf-414e-98b8-9892f3eab496",
"type": "condition:filter",
"typeVersion": "1.0",
"name": "Keep PMs from Navigator",
"parameters": {
"combinator": "and",
"conditions": [
{
"id": "sender_is_navigator",
"operator": {
"type": "string",
"operation": "equals",
"singleValue": false
},
"leftValue": "={{ $json.post.username }}",
"rightValue": "Navigator"
}
]
},
"credentials": {},
"webhookId": null,
"position": {
"x": 290.515625,
"y": -18.281249999999993
},
"notes": "",
"notesInFlow": false,
"alwaysOutputData": false
},
{
"id": "acfcf305-1a04-4d2e-876c-48b015dc038c",
"type": "action:topic_tags",
"typeVersion": "1.0",
"name": "Add onboarding-initiated tag",
"parameters": {
"topic_id": "={{ $json.topic.id }}",
"operation": "add",
"tag_names": "onboarding-initiated",
"actor_username": "Navigator"
},
"credentials": {},
"webhookId": null,
"position": {
"x": 513.1770833333333,
"y": -27.32031249999998
},
"notes": "",
"notesInFlow": false,
"alwaysOutputData": false
}
],
"connections": {
"Keep PMs from Navigator": {
"main": [
[
{
"node": "Add onboarding-initiated tag",
"type": "main",
"index": 0
}
]
]
},
"When a new personal message is created": {
"main": [
[
{
"node": "Keep PMs from Navigator",
"type": "main",
"index": 0
}
]
]
}
},
"settings": {},
"staticData": {},
"pinData": {},
"versionId": "6271bac1-9349-4594-8bc5-2b1aeb154fcc",
"activeVersionId": "6271bac1-9349-4594-8bc5-2b1aeb154fcc",
"versionCounter": 31
}
Ich würde mir sehr wünschen, dass bei der Erstellung eines Events automatisch eine Aktion ausgelöst wird: Der Autor sollte standardmäßig direkt angemeldet sein. Das würde es ermöglichen, auf alle möglichen Szenarien einzugehen – und das ist gerade für meinen Anwendungsfall besonders wichtig! 
wir haben nächste Woche einen Knoten für die kommende Veranstaltung
Ja, ich denke, das könnte natürlich in denselben Event-Bereich von Workflows passen.
In meinem aktuellen PR, FEATURE: Add event actions to workflows - Pull Request #42932 - discourse/discourse - GitHub , habe ich einen Event-Abschnitt im Workflow-Builder hinzugefügt. In dem Screenshot in der PR-Beschreibung bietet das Öffnen dieses Event-Menüs derzeit zwei Operationen:
Das sind in diesem PR absichtlich die einzigen beiden Operationen, da dies der Umfang der Änderung ist, die ich zur Überprüfung einreichen möchte.
Dein Anwendungsfall könnte möglicherweise eine weitere Operation zu diesem selben Event-Menü hinzufügen, zum Beispiel Teilnahme festlegen / Teilnehmer hinzufügen. Ein Workflow könnte dann den Event-Autor als Benutzer verwenden und seine Teilnahme auf Gehe hin setzen, wenn das Event erstellt wird.
Ich denke, es wäre besser, dies generisch zu implementieren – indem man den Benutzer und den Teilnahmezustand auswählt – anstatt eine Sonderfall-Aktion nur für „Autor automatisch registrieren“ zu haben.
Ich werde mir das als Nachfolgeaufgabe ansehen, wahrscheinlich als separaten PR, damit der aktuelle PR für Event öffnen/schließen fokussiert bleibt.
Ich hatte deine Antwort noch nicht gelesen, bevor ich meinen Beitrag oben gepostet habe.
Da du erwähnt hast, dass nächste Woche ein Event-Knoten kommt, werde ich meinen aktuellen PR auch lokal gegen die anderen offenen discourse-events- bzw. Workflows-PR-Zweige testen, die denselben Bereich betreffen, anstatt mich nur auf die CI gegen main zu verlassen.
Falls ich eine echte Überschneidung oder einen Konflikt feststelle, werde ich dies im entsprechenden GitHub-PR melden, anstatt dieses Thema unnötig zu überladen.
Ich denke, das liegt daran, dass dieser Benutzer in pm_tags_allowed_for_groups enthalten sein muss. Man könnte argumentieren, dass die Fehlermeldung besser formuliert sein könnte… Ich werde sie verbessern.
EDIT: Wird durch FIX: provides a better error when user can't tag PM - Pull Request #43019 - discourse/discourse - GitHub verbessert