mirror of
https://gh.wpcy.net/https://github.com/discourse/discourse.git
synced 2026-06-19 02:05:37 +08:00
0914b9fb32
Discourse Workflows is a visual automation plugin for admins. A workflow is a versioned graph made of trigger, condition, action, and utility nodes. ## Architecture The plugin has three main responsibilities: - Store and version workflow graphs. - Render an admin editor from node metadata. - Execute published workflow versions and record their results. The graph is stored as workflow nodes plus connections. Each node has a stable type, a type version, editor position, configuration parameters, optional credential references, and direct runtime settings. Published workflows create immutable versions that executions can safely use even after the draft changes. ## Runtime Flow A normal execution follows this path: 1. A trigger produces initial data from a Discourse event, schedule, webhook, or manual run. 2. Trigger data is wrapped as workflow items. 3. The executor queues downstream nodes from the graph connections. 4. Each node receives input items and returns one array per output. 5. The executor records the step, stores node output for expressions, and routes each output array to connected downstream nodes. 6. The execution finishes, fails, or enters a waiting state. Waiting nodes persist enough execution context to resume later. Resume requests continue from the waiting node using the workflow snapshot saved with the execution, not the latest draft. Expressions are resolved at runtime against the current item, node parameters, workflow variables, previous node outputs, and execution context. The editor stores expression values in parameters; node code should read them through the execution context instead of parsing parameter values directly. ## Adding nodes - Workflow nodes, registered with `DiscoursePluginRegistry.register_discourse_workflows_node`. Core nodes live in `lib/discourse_workflows/nodes` and are registered during plugin initialization. Other plugins can add their own nodes when `DiscourseWorkflows` is loaded. ## Node API Nodes inherit from `DiscourseWorkflows::NodeType`. A node class is responsible for two things: - Declaring its contract with `description(...)`. - Implementing the runtime entry point for its node kind. The description is the public contract between the node, editor, validator, and runtime. It should include: - `name`: stable identifier, usually prefixed by `trigger:`, `action:`, `condition:`, or `flow:`. - `version`: implementation version used by stored workflow nodes. - `defaults`: editor metadata such as icon and color. - `group`: palette category. - `inputs` and `outputs`: graph ports. - `properties`: configuration fields rendered by the property engine. - `credentials`: credential slots the node can use. - `webhooks`: public or resume webhook declarations. - `events`: Discourse events that should activate a trigger node. - `capabilities`: feature flags such as manual triggering, waiting, or current user access. - `available`: optional availability gate for nodes backed by another plugin or site setting. Description data should stay declarative. Put business logic in the runtime entry point or helper classes. ### Action, Condition, And Flow Nodes Action-like nodes implement `execute(exec_ctx)`. They receive input items through the execution context and return positional output arrays. A one-output node returns one outer array; a branching node returns one inner array per branch. ### Trigger Nodes Trigger nodes start executions. Event triggers declare `events` and usually implement: - `valid?` to ignore events that should not run workflows. - `matches?(trigger_ctx)` to compare event data with node configuration. - `output` to produce the initial workflow item data. ### Webhook And Waiting Nodes Webhook trigger nodes declare webhook metadata and produce initial data from the incoming request. Waiting nodes pause an execution and resume it through a later interaction or webhook. ### Dynamic Options Nodes can provide dynamic property options with `self.load_options_context(context)`. Use the context object to access current parameters, filtered credentials, the search filter, the current user, guardian, and shared helpers. ### Errors And Logs Raise `DiscourseWorkflows::NodeError` for failures admins can act on, such as invalid configuration or missing Discourse records. Unexpected exceptions fail the current execution. --------- --------- Co-authored-by: Renato Atilio <3530+renato@users.noreply.github.com> Co-authored-by: Martin Brennan <martin@discourse.org> Co-authored-by: Jordan Vidrine <30537603+jordanvidrine@users.noreply.github.com>
44 lines
1,020 B
Ruby
Vendored
44 lines
1,020 B
Ruby
Vendored
# frozen_string_literal: true
|
|
|
|
module DiscourseWorkflows
|
|
class WebhookRequest
|
|
attr_reader :method, :path, :headers, :params, :query, :body, :raw_body, :ip, :ips, :webhook_url
|
|
|
|
def initialize(
|
|
method:,
|
|
path:,
|
|
headers: {},
|
|
params: {},
|
|
query: {},
|
|
body: {},
|
|
raw_body: nil,
|
|
ip: nil,
|
|
ips: [],
|
|
webhook_url:
|
|
)
|
|
@method = method.to_s
|
|
@path = path.to_s
|
|
@headers = headers.to_h.deep_stringify_keys
|
|
@params = params.to_h.deep_stringify_keys
|
|
@query = query.to_h.deep_stringify_keys
|
|
@body = body
|
|
@raw_body = raw_body
|
|
@ip = ip
|
|
@ips = Array.wrap(ips).map(&:to_s)
|
|
@webhook_url = webhook_url.to_s
|
|
end
|
|
|
|
def item_json
|
|
data = {
|
|
"body" => body,
|
|
"headers" => headers,
|
|
"params" => params,
|
|
"query" => query,
|
|
"method" => method,
|
|
"webhook_url" => webhook_url,
|
|
}
|
|
data["raw_body"] = raw_body if raw_body.present?
|
|
data
|
|
end
|
|
end
|
|
end
|
