mirror of
https://github.com/nocobase/nocobase.git
synced 2026-09-21 05:44:51 +08:00
docs(tutorial-v2): update ch06 scenario 2 to use custom action event
This commit is contained in:
Albert Ma
@@ -204,24 +204,24 @@ NocoBase 支持多种通知渠道类型：
|
||||
回到工作流管理页面，点击新建：
|
||||
|
||||
- **名称**：填写"工单完成自动记录时间"
|
||||
- **触发器类型**：这次我们熟悉一下其他类型的触发器，选择 **操作后事件**（执行了某个操作之后才触发）
|
||||
- **触发器类型**：选择 **自定义操作事件**（用户点击绑定了该工作流的按钮时触发）
|
||||
- **执行模式**：同步
|
||||
> 关于同步和异步：
|
||||
> - 异步：操作之后，我们可以继续做其他事情，工作流自动执行后通知我们结果
|
||||
> - 同步：操作之后，界面会处于等待模式，等待工作流执行完毕之后我们才能干其他事情
|
||||
|
||||
|
||||
|
||||
|
||||
### 第二步：配置触发器
|
||||
|
||||
打开触发器配置：
|
||||
|
||||
- **数据表**：选择「工单」
|
||||
- **触发模式**：选择「局部模式，绑定该工作流的操作执行完毕后触发」
|
||||
- **执行模式**：选择 **单行模式**（每次只处理当前点击的那一条工单）
|
||||
|
||||
> 这里更推荐「全局模式」并勾选相关操作，不过为了熟悉触发器和操作绑定的机制，我们先采用「局部模式」作为教学。后面大家可以自行改回全局模式。
|
||||
|
||||
|
||||
|
||||
<!-- TODO: 补充触发器配置截图 -->
|
||||
|
||||
|
||||
### 第三步：添加条件判断
|
||||
@@ -230,47 +230,49 @@ NocoBase 支持多种通知渠道类型：
|
||||
|
||||
|
||||
|
||||
我们推荐选择 「“是” 和 “否” 分别继续」，以便于后续的扩展。
|
||||
我们推荐选择 「”是” 和 “否” 分别继续」，以便于后续的扩展。
|
||||
|
||||
- 条件：**触发数据 → 状态** 等于 **已完成**，注意此处必须复制字段配置中的 “选项值” 过来，否则判断会失败。
|
||||
- 条件：**触发数据 → 状态** 不等于 **已完成**（即只有未完成的工单才会通过，已完成的不再重复处理）
|
||||
|
||||
|
||||
|
||||
这样只有状态变为"已完成"时才继续执行，变成其他状态（如"处理中"）不会触发后续动作。
|
||||
|
||||
|
||||
### 第四步：添加更新数据节点
|
||||
|
||||
点击 **+**，选择 **更新数据** 节点：
|
||||
在条件判断的”是”分支上，点击 **+**，选择 **更新数据** 节点：
|
||||
|
||||
|
||||
|
||||
- **数据表**：选择「工单」
|
||||
- **筛选条件**：ID 等于 触发数据 → ID（确保只更新当前这条工单）
|
||||
- **字段值**：完成时间 = **系统变量 / 系统时间**
|
||||
- **字段值**：
|
||||
- 状态 = **已完成**
|
||||
- 完成时间 = **系统变量 / 系统时间**
|
||||
|
||||
|
||||
|
||||
|
||||
### 第五步：创建"完成"操作按钮
|
||||
> 这样一个节点就同时完成了”改状态”和”记时间”两件事，不需要在按钮上单独配置字段值。
|
||||
|
||||
工作流配好了，但"操作后事件"需要绑定到一个具体的操作按钮上才会触发。我们在工单列表的操作列中创建一个专用的"完成"按钮：
|
||||
### 第五步：创建”完成”操作按钮
|
||||
|
||||
工作流配好了，但”自定义操作事件”需要绑定到一个具体的操作按钮上才会触发。我们在工单列表的操作列中创建一个专用的”完成”按钮：
|
||||
|
||||
1. 进入 UI 编辑器模式，在工单表格的操作列中，点击 **「+」**，选择 **「触发工作流」** 操作按钮
|
||||
|
||||
|
||||
|
||||
1. 进入 UI 编辑器模式，在工单表格的操作列中，点击 **「+」**，选择 **「更新数据」** 操作按钮
|
||||
2. 点击按钮的配置项，将标题修改为 **「完成」**，并选择一个完成相关的小图标（如对勾图标）
|
||||
|
||||
|
||||
3. 配置“字段值”，设置 “状态 = 已完成”。这样用户点击按钮时，就会触发这个赋值操作。
|
||||
|
||||
|
||||
|
||||
4. 给按钮配置 **联动规则**：当工单状态已经是"已完成"时，隐藏这个按钮（已完成的工单不需要再点"完成"）
|
||||
3. 给按钮配置 **联动规则**：当工单状态已经是”已完成”时，隐藏这个按钮（已完成的工单不需要再点”完成”）
|
||||
- 条件：当前数据 → 状态 等于 已完成
|
||||
- 动作：隐藏
|
||||
|
||||
|
||||
|
||||
4. 打开按钮配置项中的 **「绑定工作流」**，选择我们刚才创建的「工单完成自动记录时间」工作流
|
||||
|
||||
5. 打开按钮配置项中的 **「绑定工作流」**，选择我们刚才创建的「工单完成自动记录时间」工作流
|
||||
|
||||
|
||||
|
||||
|
||||
### 第六步：启用并测试
|
||||
|
||||
@@ -283,7 +285,7 @@ NocoBase 支持多种通知渠道类型：
|
||||
|
||||
|
||||
|
||||
是不是很方便？这就是工作流的第二种常见用法——**自动更新数据**。而且通过"操作后事件 + 局部模式 + 绑定按钮"的方式，我们实现了一个精确的触发机制：只有点击特定按钮才会执行工作流。
|
||||
是不是很方便？这就是工作流的第二种常见用法——**自动更新数据**。而且通过"自定义操作事件 + 绑定按钮"的方式，我们实现了一个精确的触发机制：只有点击特定按钮才会执行工作流。
|
||||
|
||||
## 6.4 查看执行历史
|
||||
|
||||
|
||||
@@ -199,25 +199,23 @@ Congratulations, your first automation is up and running!
|
||||
Go back to the workflow management page and click New:
|
||||
|
||||
- **Name**: Enter "Auto-record ticket completion time"
|
||||
- **Trigger type**: This time let's try a different trigger — select **Post-action event** (fires after a specific action is performed)
|
||||
- **Trigger type**: Select **Custom action event** (fires when a user clicks a button bound to this workflow)
|
||||
- **Execution mode**: Synchronous
|
||||
|
||||
> About synchronous vs asynchronous:
|
||||
> - Asynchronous: After the action, you can continue doing other things while the workflow runs in the background
|
||||
> - Synchronous: After the action, the UI waits for the workflow to finish before you can do anything else
|
||||
|
||||
|
||||
|
||||
|
||||
### Step 2: Configure the Trigger
|
||||
|
||||
Open the trigger configuration:
|
||||
|
||||
- **Collection**: Select "Tickets"
|
||||
- **Trigger mode**: Select "Local mode — triggers after the action bound to this workflow completes"
|
||||
- **Execution mode**: Select **Single record mode** (processes only the current ticket each time)
|
||||
|
||||
> "Global mode" (checking both operations) is generally recommended. However, to familiarize ourselves with how triggers bind to specific actions, we'll use "Local mode" for this tutorial. Feel free to switch to global mode later!
|
||||
|
||||
|
||||
|
||||
|
||||
### Step 3: Add a Condition
|
||||
|
||||
@@ -227,46 +225,47 @@ Unlike the collection event trigger which has built-in conditions, we need to ad
|
||||
|
||||
We recommend selecting "Continue on 'Yes' and 'No' separately" for easier future expansion.
|
||||
|
||||
- Condition: **Trigger data → Status** equals **Completed**. Note: you must copy the exact "option value" from the field configuration here, otherwise the condition check will fail.
|
||||
- Condition: **Trigger data → Status** does not equal **Completed** (only incomplete tickets pass through; already completed tickets won't be processed again)
|
||||
|
||||
|
||||
|
||||
This way, only when the status is "Completed" will the subsequent actions execute. Other statuses (like "In Progress") won't trigger anything.
|
||||
|
||||
|
||||
### Step 4: Add an Update Record Node
|
||||
|
||||
Click **+** and select an **Update record** node:
|
||||
On the "Yes" branch of the condition, click **+** and select an **Update record** node:
|
||||
|
||||
|
||||
|
||||
- **Collection**: Select "Tickets"
|
||||
- **Filter condition**: ID equals Trigger data → ID (to ensure only the current ticket gets updated)
|
||||
- **Field values**: Completion time = **System variables / System time**
|
||||
- **Field values**:
|
||||
- Status = **Completed**
|
||||
- Completion time = **System variables / System time**
|
||||
|
||||
|
||||
|
||||
|
||||
> This way, a single node handles both "change status" and "record time" — no need to configure field values on the button separately.
|
||||
|
||||
### Step 5: Create a "Complete" Action Button
|
||||
|
||||
The workflow is configured, but a "Post-action event" needs to be bound to a specific action button to trigger. Let's create a dedicated "Complete" button in the ticket list's action column:
|
||||
The workflow is configured, but a "Custom action event" needs to be bound to a specific action button to trigger. Let's create a dedicated "Complete" button in the ticket list's action column:
|
||||
|
||||
1. Enter UI Editor mode. In the ticket table's action column, click **"+"** and select a **"Trigger workflow"** action button
|
||||
|
||||
|
||||
|
||||
1. Enter UI Editor mode. In the ticket table's action column, click **"+"** and select an **"Update data"** action button
|
||||
2. Click the button settings and change the title to **"Complete"**, then select a completion-related icon (e.g., a checkmark icon)
|
||||
|
||||
|
||||
|
||||
|
||||
3. Configure "Field values" and set "Status = Completed". This way when the user clicks the button, the status update operation is triggered.
|
||||
|
||||
|
||||
|
||||
4. Configure **linkage rules** for the button: hide it when the ticket status is already "Completed" (completed tickets don't need a "Complete" button)
|
||||
3. Configure **linkage rules** for the button: hide it when the ticket status is already "Completed" (completed tickets don't need a "Complete" button)
|
||||
- Condition: Current data → Status equals Completed
|
||||
- Action: Hide
|
||||
|
||||
|
||||
|
||||
5. Open **"Bind workflows"** in the button settings and select the "Auto-record ticket completion time" workflow we just created
|
||||
4. Open **"Bind workflows"** in the button settings and select the "Auto-record ticket completion time" workflow we just created
|
||||
|
||||
|
||||
|
||||
|
||||
### Step 6: Enable and Test
|
||||
|
||||
@@ -279,7 +278,7 @@ Then open a ticket with "In Progress" status and click the **"Complete"** button
|
||||
|
||||
|
||||
|
||||
Convenient, right? This is the second common use case for workflows — **automatically updating data**. And by using the "Post-action event + Local mode + Button binding" approach, we've created a precise trigger mechanism: the workflow only runs when a specific button is clicked.
|
||||
Convenient, right? This is the second common use case for workflows — **automatically updating data**. And by using the "Custom action event + Button binding" approach, we've created a precise trigger mechanism: the workflow only runs when a specific button is clicked.
|
||||
|
||||
## 6.4 Viewing Execution History
|
||||
|
||||
|
||||
Reference in New Issue
Block a user