Danke, das hat das Problem gelöst!
3 „Gefällt mir“
@gilles Ich habe den oben erwähnten Follow-up nun implementiert:
Er fügt eine generische Event → Anwesenheit setzen-Operation hinzu, mit:
- Teilnehmer
- Anwesenheitsstatus: Gehe hin / Interessiert / Gehe nicht hin / Anwesenheit entfernen
- Topic-ID
- optionaler Actor
So lässt sich dein ursprünglicher Use Case wie folgt aufbauen:
Beitrag erstellt → Wenn erster Beitrag → Event / Anwesenheit setzen
wobei der Autor des Events als Teilnehmer verwendet wird und dieser auf Gehe hin gesetzt wird.
Ich habe genau dieses Muster lokal in der Workflows-GUI getestet, gestapelt auf #42932, und bestätigt, dass der Benutzer automatisch als „Gehe hin“ für das Event registriert wird.
Der PR ist derzeit nur ein Entwurf, da er von #42932 abhängt. Sobald #42932 gemerged wird, rebased ich ihn auf main, was nur den Diff für die Anwesenheitsfunktion übrig lassen wird.
2 „Gefällt mir“
@Ethsim2 Danke, du bist ein Chef 
1 „Gefällt mir“
Gibt es eine Möglichkeit, einen Workflow (mit demselben Ereignis) erneut auszuführen, ähnlich wie bei einem Webhook, bei dem eine Nutzlast erneut gesendet werden kann?
Nein, sorry, das unterstützen wir im Moment nicht.
2 „Gefällt mir“
Gibt es einen Trigger/ein Ereignis, das ausgelöst wird, wenn ein NEUES Tag erstellt wird?
Wenn ein Benutzer ein neues Tag erstellt, gibt es eine Möglichkeit, es automatisch einer bestimmten Tag-Gruppe hinzuzufügen? Wenn nicht, welcher Ansatz wird empfohlen?
1 „Gefällt mir“
Nein, wir haben nichts davon. Könntest du deinen Anwendungsfall bitte genauer beschreiben?
Könntest du das bitte so umsetzen:
- Alle neuen Themen prüfen
- Tags mit den vorhandenen abgleichen
- Bei einem neuen Tag:
<insert action>
1 „Gefällt mir“
Es gibt „Topic Tag Changed“ (Thema-Tag geändert). Du könntest dann die Discourse-API aufrufen und prüfen, wie oft das Tag verwendet wird. Wenn es nur einmal vorkommt / wenn es in diesem bestimmten Thema ist, weißt du, dass das Tag neu ist.
Alternativ und vielleicht einfacher: Du könntest einen Webhook für „Tag wird erstellt“ einrichten und diesen auf einen Workflow-Webhook-Trigger zeigen lassen.
1 „Gefällt mir“
Anwendungsfall: Ich habe eine Tag-Gruppe namens „artist“ (Künstler). Da ständig neue Künstler debütieren, tauchen neue Künstler-Tags auf, sobald Benutzer sie erstellen. Ich möchte, dass diese neuen Tags automatisch der Tag-Gruppe „artist“ hinzugefügt werden, anstatt sie manuell eintragen zu müssen. Gibt es eine gute Möglichkeit, dieses Ergebnis mit Workflows zu erzielen?
Woher weißt du, dass es sich um ein Artist-Tag und nicht um irgendein anderes zufälliges Tag handelt?
Genau das übernimmt der KI-Schritt. Der KI-Agent prüft zunächst, ob ein neuer Tag zu einer der definierten Gruppen (Künstler / Mitglied / Region / Event-Typ / Release-Typ) passt; falls nicht, wird er übersprungen und keiner Gruppe zugeordnet. So werden zufällige Tags herausgefiltert, und nur korrekt klassifizierte Tags werden automatisch einer Tag-Gruppe hinzugefügt.
1 „Gefällt mir“
ok, ich füge einen Trigger für die Tag-Erstellung und einen Knoten hinzu, um ein Tag zu einer Tag-Gruppe hinzuzufügen
4 „Gefällt mir“
Wir haben Folgendes zu Workflows hinzugefügt:
7 „Gefällt mir“
Ich möchte ein Thema mit einem Tag versehen, wenn es mit bestimmten Text erstellt wurde. Gibt es eine Möglichkeit, {{ $JSON.topic.title }} in Kleinbuchstaben umzuwandeln, damit der Ausdruck für “pub run”, “Pub Run” und “pUb rUn” den Wert true ergibt?
(Auszug)
{
"id": "db9e2fa2-0008-4110-9c77-f1060124d7e7",
"type": "condition:if",
"typeVersion": "1.0",
"name": "If",
"parameters": {
"combinator": "and",
"conditions": [
{
"id": "29d3ed6c-e984-4d9b-83bf-861bd11b4b0a",
"operator": {
"type": "string",
"operation": "contains",
"singleValue": false
},
"leftValue": "={{ $json.topic.title }}",
"rightValue": "pub run"
}
]
},
1 „Gefällt mir“
hast du {{ $JSON.topic.title.toLowerCase() }} ausprobiert?
1 „Gefällt mir“
danke – das hat geklappt!
Welche Template-Sprache wird verwendet?
Es scheint sich um Discourse Workflows’ eigenes JavaScript-Ausdruckssystem zu handeln, das serverseitig in einer Sandbox ausgewertet wird, anstatt eine separate Template-Sprache wie Liquid oder Handlebars zu verwenden.
So funktioniert beispielsweise:
={{ $json.topic.title.toLowerCase() }}
damit der Inhalt von {{ ... }} als JavaScript ausgewertet wird und toLowerCase() die übliche JavaScript-Stringmethode ist.
Die Implementierung befindet sich in plugins/discourse-workflows/lib/discourse_workflows/expression_resolver.rb; sie stellt workflow-spezifische globale Variablen wie $json, $input, $itemIndex, $trigger, $execution und $() bereit.
Die Syntax und die Konzepte ähneln stark n8n. Tatsächlich gibt es an anderer Stelle im Workflows-Quellcode einen expliziten Verweis auf n8n:
Der unten verlinkte Commit fügte das Kombinationsverhalten des Merge-Knotens hinzu und enthält einen Test, der wie folgt beschrieben wird:
defaults clash handling to add_suffix (matches n8n position combine)
Es gibt also Hinweise darauf, dass Teile von Workflows bewusst das Verhalten von n8n nachahmen, obwohl ich nichts Explizites finden konnte, das besagt, dass die Ausdruckssprache selbst von n8n übernommen oder auf dieser basiert. Ich würde sie daher als von Discourse Workflows bereitgestellte, in einer Sandbox ausgeführte JavaScript-Ausdrücke beschreiben, die einige n8n-ähnliche Konventionen aufweisen.
3 „Gefällt mir“
Es wäre super cool, wenn es für Formulare einen gruppenbasierten Zugriff gäbe 
2 „Gefällt mir“
Ich habe bemerkt, dass der Schritt „KI-Agent“ erfordert, dass für den Agenten die Option „Bot“ aktiviert ist. Warum ist das nötig? Steht das irgendwo in der Dokumentation? Ich habe ein paar Minuten damit verbracht herauszufinden, warum ich einen bestimmten Agenten im Dropdown-Menü nicht auswählen konnte 
1 „Gefällt mir“