Discourse Workflows

Thanks, that did solve it!

3 Likes

@gilles I’ve now implemented the follow-up I mentioned above:

It adds a generic Event → Set attendance operation, with:

  • attendee
  • attendance state: Going / Interested / Not going / Remove attendance
  • topic ID
  • optional actor

So your original use case can be built as:

Post created → If first post → Event / Set attendance

using the event author as the attendee and setting them to Going.

I tested that exact pattern locally in the Workflows GUI, stacked on #42932, and confirmed the user is automatically registered as Going on the event.

The PR is currently a draft only because it depends on #42932. Once #42932 merges I’ll rebase it onto main, which will leave the attendance-only diff.

2 Likes

@Ethsim2 Thanks, you’re the best :+1: :clap:

1 Like

Is there a way to retry a workflow (with the same event), similar to how, with a webhook, you can resend a payload?

No sorry we don’t support this atm

2 Likes

Is there a trigger/event that fires when a NEW tag is created?

When a new tag is created by a user, is there a way to automatically
add it to a specific tag group? If not, what’s the recommended approach?

1 Like

No we don’t have any of this. Can you expand your use case please?

Could you have it:

  1. Look at all new topics
  2. Check tag against existing ones
  3. If new tag, <insert action>
1 Like

There is “Topic Tag Changed”. You could then call the Discourse API and see how many times the tag is used. If it’s one / if it’s on that specific topic, you know the tag is new.

Alternatively and maybe easier: you could setup a webhook for “tag is created” and point it to a workflow webhook trigger.

1 Like

Use case: I have an “artist” tag group. New artists debut all the time, so
new artist tags keep appearing when users create them. I want those new
tags to be automatically added to the “artist” tag group, instead of me
having to manually add them. Is there a good way to get
this result with Workflows?

how do you know it’s an artist tag and not another random tag?

That’s exactly what the AI step handles. The AI agent first determines whether a new tag belongs to any of the defined groups (artist / member / region / event-type / release-type); if it matches none, it’s skipped and never filed into a group. So random tags are filtered out, and only correctly classified tags get auto-added to a tag group.

1 Like

ok will add some trigger for tag created and a node for add tag to tag group

4 Likes

We have added the following to workflows:

7 Likes

I want to tag a topic if it’s created with certain text. Is there any way to use lower case for {{ $JSON.topic.title }} so this evaluates to true for “pub run”, “Pub Run”, “pUb rUn”?

(excerpt)

{
      "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"
          }
        ]
      },

have you tried {{ $JSON.topic.title.toLowerCase() }}?

1 Like

thanks – that worked!

what templating language is used?

It appears to be Discourse Workflows’ own JavaScript expression system, evaluated server-side in a sandbox rather than a separate templating language such as Liquid or Handlebars.

So, for example:

={{ $json.topic.title.toLowerCase() }}

works because the contents of {{ ... }} are evaluated as JavaScript, and toLowerCase() is the normal JavaScript string method.

The implementation is in plugins/discourse-workflows/lib/discourse_workflows/expression_resolver.rb; it exposes workflow-specific globals such as $json, $input, $itemIndex, $trigger, $execution, and $().

The syntax and concepts are quite n8n-like. There is actually an explicit n8n reference elsewhere in the Workflows source:

the oneboxed commit below added the merge-node combine behavior and includes a test described as:

defaults clash handling to add_suffix (matches n8n position combine)

So there is evidence that parts of Workflows deliberately match n8n behavior, although I couldn’t find anything explicitly saying that the expression language itself is copied from or based on n8n. I’d therefore describe it as sandboxed JavaScript expressions provided by Discourse Workflows, with some n8n-like conventions.

3 Likes