openxiangda 2.21.0 → 2.21.2
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/documentation/appspec.md +8 -1
- package/documentation/backend.md +38 -0
- package/documentation/data-authz.md +35 -0
- package/documentation/declarations-cheatsheet.md +7 -1
- package/documentation/development.md +2 -2
- package/documentation/frontend.md +8 -1
- package/documentation/getting-started.md +41 -9
- package/documentation/manifest.json +14 -14
- package/documentation/public-access.md +16 -6
- package/documentation/reference/cli.md +3 -0
- package/documentation/reference/mcp.md +12 -6
- package/documentation/testing.md +2 -0
- package/documentation/upgrading.md +1 -1
- package/documentation/workflow-events.md +42 -0
- package/package.json +21 -22
- package/releases/2.21.1.json +36 -0
- package/releases/2.21.2.json +34 -0
- package/skills/manifest.json +1 -1
- package/skills/openxiangda-v2/SKILL.md +4 -4
- package/skills/openxiangda-v2/references/appspec.md +8 -1
- package/skills/openxiangda-v2/references/backend.md +38 -0
- package/skills/openxiangda-v2/references/cli.md +3 -0
- package/skills/openxiangda-v2/references/data-authz.md +35 -0
- package/skills/openxiangda-v2/references/declarations-cheatsheet.md +7 -1
- package/skills/openxiangda-v2/references/development.md +2 -2
- package/skills/openxiangda-v2/references/frontend.md +8 -1
- package/skills/openxiangda-v2/references/getting-started.md +41 -9
- package/skills/openxiangda-v2/references/mcp.md +12 -6
- package/skills/openxiangda-v2/references/public-access.md +16 -6
- package/skills/openxiangda-v2/references/testing.md +2 -0
- package/skills/openxiangda-v2/references/upgrading.md +1 -1
- package/skills/openxiangda-v2/references/workflow-events.md +42 -0
|
@@ -58,6 +58,46 @@ events: {
|
|
|
58
58
|
外部 Webhook 和自定义代码仍使用已有签名、回执、重试及接收端幂等协议,按至少
|
|
59
59
|
一次投递处理。轻量操作历史仍通过已有审计 API 查询,不依赖是否订阅了事件。
|
|
60
60
|
|
|
61
|
+
## 定时与日期触发
|
|
62
|
+
|
|
63
|
+
除订阅平台数据事件外,`events` 还能声明两类自有时程触发器;两者都只负责在到期时
|
|
64
|
+
发出应用事件,业务效果仍由订阅(含 `execution: native-data`)或应用后端处理。
|
|
65
|
+
|
|
66
|
+
`events.timers` 按 cron 周期发事件。`code` 为 kebab-case 且唯一;`eventType` 必须是
|
|
67
|
+
`events.schemas` 已声明的应用事件;`cronExpression` 为六段 cron(秒 分 时 日 月 周),
|
|
68
|
+
`timezone` 使用 IANA 名称(如 `Asia/Shanghai`),最短触发间隔为 60 秒;`misfirePolicy`
|
|
69
|
+
目前仅支持 `coalesce_one`(错过合并为一次);`payload` 是普通对象,必须完整满足所引用
|
|
70
|
+
事件的 JSON Schema 且不超过 64 KiB。定时声明属于环境中立的 AppVersion,不写
|
|
71
|
+
`environmentKey`;启用/暂停和下次触发时间由平台按环境管理。
|
|
72
|
+
|
|
73
|
+
```ts
|
|
74
|
+
events: {
|
|
75
|
+
schemas: [{
|
|
76
|
+
eventType: 'app.report.digest.v1',
|
|
77
|
+
dataSchemaVersion: '1',
|
|
78
|
+
jsonSchema: {
|
|
79
|
+
type: 'object', additionalProperties: false,
|
|
80
|
+
required: ['kind'], properties: { kind: { type: 'string' } },
|
|
81
|
+
},
|
|
82
|
+
}],
|
|
83
|
+
timers: [{
|
|
84
|
+
code: 'daily-digest',
|
|
85
|
+
eventType: 'app.report.digest.v1',
|
|
86
|
+
cronExpression: '0 0 9 * * *',
|
|
87
|
+
timezone: 'Asia/Shanghai',
|
|
88
|
+
payload: { kind: 'daily' },
|
|
89
|
+
}],
|
|
90
|
+
},
|
|
91
|
+
```
|
|
92
|
+
|
|
93
|
+
`events.dateTriggers` 相对记录的 date/datetime 字段发事件:字段值加 `offset`(ISO-8601
|
|
94
|
+
时长,十年内,如 `-PT1H` 表示提前一小时)到达时触发。适合到期提醒、超期升级等场景;
|
|
95
|
+
同一条记录的字段更新后按新值重算。`code` 唯一,`eventType` 同样引用已声明应用事件。
|
|
96
|
+
|
|
97
|
+
两类触发器各最多 100 条。事件 Schema 用 `events.schemas` 声明
|
|
98
|
+
(`{ eventType, dataSchemaVersion, jsonSchema, sensitiveFields? }`),`eventType` 遵循
|
|
99
|
+
`xxx.yyy.v1` 版本后缀模式;触发器只发事件,不直接写数据或调用流程。
|
|
100
|
+
|
|
61
101
|
## 标准详情与当前用户入口
|
|
62
102
|
|
|
63
103
|
普通记录、流程记录、任务和实例复用同一详情框架。流程详情提供申请内容、审批历史和变更记录三个标签页;管理员在当前抽屉或页面中切换到普通表单编辑,直接保存并自动留下变更记录,审批结果保持不变。PC 子表在表格内编辑,父表提交时统一校验。
|
|
@@ -113,6 +153,8 @@ Workflow 发起只接受 `{ resourceCode, id }` 形式的 `dataRef`,并要求
|
|
|
113
153
|
|
|
114
154
|
首期只支持 `approval`、`condition`、`end`,以及 `single`、`any`、`all`、`sequence` 审批模式。标准操作为提交、同意、拒绝、退回、重新提交、转交、委托、前/后加签、撤回、管理员改派、管理员终止和不改变流程状态的催办。
|
|
115
155
|
|
|
156
|
+
除命令集之外,平台为实例管理员提供两个维护动作:`admin_jump`(把处于运行或退回状态的实例跳转到指定节点)与 `admin_delete`(删除实例,可选同时删除表单数据、是否触发自动化)。两者走平台管理端点的预览/执行两步流程并要求同源浏览器请求,不属于应用声明的工作流命令,也不占用 `commandToken` 命令合同。
|
|
157
|
+
|
|
116
158
|
复杂业务状态机继续放在应用领域服务。不要把任意 JavaScript、Service Task、BPMN、通用长事务或业务记录复制进 Workflow。
|
|
117
159
|
|
|
118
160
|
所有页面和消息动作必须来自后端 Workflow Surface 的 `operations[]`。前端、模板和渠道 Adapter 不自行推断操作权限。
|