openxiangda 1.0.131 → 1.0.133

package/openxiangda-skills/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: openxiangda
-description: "Use OpenXiangda for any private low-code platform or sy-lowcode-app-workspace work: architecture design, app creation, forms, pages, resources, workflows, automations, JS_CODE, permissions, data views, connectors, notifications, publishing, deployment, diagnosis, feedback, profile/login state, and CLI commands. Trigger on OpenXiangda, 享搭, 私有化低代码, 低代码平台, .openxiangda/state.json, app-workspace.config.ts, or openxiangda CLI usage."
+description: "Use OpenXiangda for any private low-code platform or sy-lowcode-app-workspace work: architecture design, app creation, forms, pages, resources, workflows, automations, JS_CODE, permissions, organization/account management, data views, connectors, notifications, publishing, deployment, diagnosis, feedback, profile/login state, and CLI commands. Trigger on OpenXiangda, 享搭, 私有化低代码, 低代码平台, .openxiangda/state.json, app-workspace.config.ts, or openxiangda CLI usage."
 ---
 
 # OpenXiangda
@@ -30,6 +30,7 @@ OpenXiangda supports two workspace modes. Classic `sy-lowcode-app-workspace` pub
 | App Function / function_call / 可复用后端逻辑            | `openxiangda-workflow-automation`                                                          | declare `src/resources/functions/<code>.json` + `src/functions/<code>/index.ts`                                                                          |
 | 应用登录 / Auth SDK / 手机号验证码 / CAS / 钉钉免登      | `openxiangda-architecture-design` + `openxiangda-page`                                     | design security gate first, then declare `src/resources/auth/<code>.json` and use `createAuthClient` / `LoginPage`                                       |
 | 角色 / 权限组 / 字段权限 / 数据范围                      | `openxiangda-permission-settings`                                                          | `openxiangda permission ...` / `openxiangda settings ...`                                                                                                |
+| 平台部门 / 平台账号 / 重置密码 / 组织账号管理            | `openxiangda-architecture-design` + `openxiangda-page`                                     | check `openxiangda organization capabilities --json`; use `sdk.organization` / `ctx.organization` only after `app:organization:manage` is granted         |
 | 外部人员无需登录访问 / 公开报名 / 公开查询 / public page | `openxiangda-architecture-design` + `openxiangda-permission-settings` + `openxiangda-page` | 先确认公开范围、外部角色、ticket、grants；再声明 `routes` + `public-access`，并用 `OpenXiangdaProvider` + `OpenXiangdaPageProvider` + `PublicAccessGate` |
 | 看应用结构 / 快照 / 对比 / 诊断 / 排查 / 报错            | `openxiangda-inspect`                                                                      | `openxiangda app snapshot <APP_XXX> --profile <name> --json`                                                                                             |
 | 登录 / 切换平台 / profile / token / whoami               | `openxiangda-core`                                                                         | `openxiangda env --profile <name>` / `openxiangda auth status`                                                                                           |
@@ -48,7 +49,7 @@ OpenXiangda supports two workspace modes. Classic `sy-lowcode-app-workspace` pub
 - ✅ For app login/auth requirements, run the auth security gate before coding: enabled methods, registration policy, identity matching keys, provider boundary, default roles, rate limits, audit fields, and third-party ownership must be confirmed.
 - ✅ For public/no-login access requirements, run the public access design gate before coding: public routes, external role codes, guest vs ticket, form/dataView/function/connector grants, backend permission groups, and visible loading/error fallback states must be confirmed. New React SPA apps use `/view/:appType/public/*`, `src/resources/routes/`, `src/resources/public-access/`, and `PublicAccessGate`; route children that use Page SDK hooks must be inside `OpenXiangdaProvider` + `OpenXiangdaPageProvider`.
 - ✅ Public/no-login validation must inspect the JSON envelope, not only HTTP status. HTTP 200 with `code: "PUBLIC_GRANT_DENIED"` is a denied request; success requires `code` `200`, `"200"`, or compatible `0`, and no `success: false`.
-- ✅ Use first-class resource CLI commands for discovery, diagnosis, and small live fixes: `route`, `public-access`, `auth-config`, `function`, `connector`, `notification`, `data-view`, `menu`, and `permission`. For multi-resource formal development, still prefer `src/resources/**` + `openxiangda resource validate|plan|publish`. If a direct CLI write is intentionally used, add `--write-manifest` when the repository should stay the source of truth.
+- ✅ Use first-class resource CLI commands for discovery, diagnosis, and small live fixes: `route`, `public-access`, `auth-config`, `function`, `connector`, `notification`, `organization`, `data-view`, `menu`, and `permission`. For multi-resource formal development, still prefer `src/resources/**` + `openxiangda resource validate|plan|publish`. If a direct CLI write is intentionally used, add `--write-manifest` when the repository should stay the source of truth.
 - ✅ For form-entry UX, pick components in this order: OpenXiangda platform form components → `antd` / `antd-mobile` wrappers → custom component only when neither exists.
 - ✅ In React SPA apps, keep imports on public package entrypoints such as `openxiangda`, `openxiangda/runtime`, and `openxiangda/runtime/react`. The default template already groups large vendor chunks; if a bundle is too large, use route-level lazy loading and Vite `manualChunks`, not `openxiangda/packages/sdk/dist/...` internal paths.
 - ✅ For image thumbnails or lightweight previews, use `imageCompression` on `ImageField` or `AttachmentField`. Keep the original `url` for the source file and use `thumbUrl` / `previewUrl` / `variants` for smaller images.
@@ -154,7 +155,8 @@ When the user provides a root domain such as `https://yida.wisejob.cn/`, use it
 - Put engineering-managed resources in `src/resources/` and use `openxiangda resource validate|plan|publish|pull`. `workspace publish` publishes workspace forms/pages first, then runs non-destructive resource upsert. Only pass `--prune` when the user explicitly wants local manifests to delete platform-side extras.
 - For repeated read-only multi-form queries or predefined dashboard metrics, create a data view manifest in `src/resources/data-views/`. Use `storageMode: "materialized"` for refreshed lists/reports that tolerate delay; use `storageMode: "live"` for bounded real-time joins where source changes must appear immediately. Use row views plus `sdk.dataView.query` for joined lists/lookups; use `viewType: "aggregate"` plus `sdk.dataView.stats` for count/sum/avg/min/max statistics. Add `indexes` only for materialized views. Do not use data views for single-form CRUD, simple linkedForm selects, writes, write-back, unbounded realtime joins, or ad-hoc BI. Read `references/data-views.md` before designing one.
 - For external APIs, create a connector manifest in `src/resources/connectors/` and call it from pages through `sdk.connector`; never put third-party API keys in page source.
-- For reusable backend logic shared by pages, automations, and workflows, create an App Function in `src/resources/functions/<functionCode>.json` plus `src/functions/<functionCode>/index.ts`. Call it from pages with `sdk.function.invoke`, from automation/workflow graphs with `function_call`, or from the runtime endpoint when the caller has app automation management permission. Current App Function MVP exposes controlled helpers such as `ctx.resources`, `ctx.form.queryOne/queryMany/getById/createOne/updateOne/updateById`, `ctx.dataView`, `ctx.connector`, `ctx.notification`, and `ctx.platform.api`; it does not expose raw SQL or Redis. Runtime functions also receive trusted role context on `ctx.operator.roleCodes`, `ctx.operator.currentRoleCode`, `ctx.operator.hasFullAccess`, `ctx.currentUser`, and `ctx.permissions`; use these for server-side business authorization. Do not trust role codes sent in page input for sensitive actions. App Function form writes are trusted backend writes governed by declared `resources.forms` and function invocation authorization; do not grant normal users raw submit permission to internal forms just to let `ctx.form.createOne/updateOne/updateById` run.
+- For reusable backend logic shared by pages, automations, and workflows, create an App Function in `src/resources/functions/<functionCode>.json` plus `src/functions/<functionCode>/index.ts`. Call it from pages with `sdk.function.invoke`, from automation/workflow graphs with `function_call`, or from the runtime endpoint when the caller has app automation management permission. Current App Function MVP exposes controlled helpers such as `ctx.resources`, `ctx.form.queryOne/queryMany/getById/createOne/updateOne/updateById`, `ctx.dataView`, `ctx.connector`, `ctx.notification`, `ctx.organization`, and `ctx.platform.api`; it does not expose raw SQL or Redis. Runtime functions also receive trusted role context on `ctx.operator.roleCodes`, `ctx.operator.currentRoleCode`, `ctx.operator.hasFullAccess`, `ctx.currentUser`, and `ctx.permissions`; use these for server-side business authorization. Do not trust role codes sent in page input for sensitive actions. App Function form writes are trusted backend writes governed by declared `resources.forms` and function invocation authorization; do not grant normal users raw submit permission to internal forms just to let `ctx.form.createOne/updateOne/updateById` run.
+- For app-managed platform departments/accounts, use `sdk.organization.departments.*`, `sdk.organization.accounts.*`, `ctx.organization.departments.*`, or `ctx.organization.accounts.*`. The real current user/audit actor must hold `app:organization:manage` on the app; runtime service principals do not bypass this permission. Do not call legacy `/user` or `/department` write endpoints from apps. Do not include `password` in account updates; reset target accounts with `resetPassword`, and change the current user's password with `changeMyPassword({ oldPassword, newPassword })`.
 - For application login, declare auth resources in `src/resources/auth/<code>.json` and publish them with `openxiangda resource publish`. App Function auth providers may validate external credentials and return only an identity assertion; they must never issue tokens, set cookies, or write platform user/binding tables directly. The platform auth service decides create/bind/reject and issues tokens.
 - For external/no-login pages in React SPA apps, declare `src/resources/routes/<code>.json` and `src/resources/public-access/<code>.json`, put the page under `/view/:appType/public/*`, and use `PublicAccessGate` or `createPublicAccessClient`. The route tree must also include `OpenXiangdaPageProvider` inside `OpenXiangdaProvider` before any `usePageSdk()` / `usePageContext()` / `useDataSource()` call; otherwise pages throw `usePageSdkStore 必须在 PageProvider 内使用`. Always provide `fallback` and `errorFallback` for public routes so slow networks, missing tickets, or expired tickets do not render blank pages. Public guest access to forms, dataViews, functions, and connectors is denied unless policy `grants` explicitly names the resource; backend permission groups still apply.
 - When verifying public access, parse the response body and reject string business errors such as `PUBLIC_GRANT_DENIED` even if the HTTP status is 200. Do not use `response.ok` alone as the success condition.
@@ -194,7 +196,7 @@ Load these references on demand instead of memorizing them. Subskills cite the s
 
 Core CLI / state:
 
-- `references/openxiangda-api.md` — `/openxiangda-api/v1` request and response fields.
+- `references/openxiangda-api.md` — `/openxiangda-api/v1` request and response fields, including app-scoped organization APIs.
 - `references/architecture-design.md` — OpenXiangda architecture design gate, anti-pattern rejection, question gates, final design template, and black-box demo scenario.
 - `references/workspace-state.md` — `.openxiangda/state.json` shape and profile isolation rules.
 - `references/connector-resources.md` — `src/resources` manifests, connector schema, App Function boundary, and platform runtime calls.
@@ -212,7 +214,7 @@ Form authoring:
 Page authoring:
 
 - `references/pages/workspace-structure.md` — `src/pages/<pageCode>/` layout and config.
-- `references/pages/page-sdk.md` — `openxiangda/runtime` data, connector, data view, notification, and App Function APIs.
+- `references/pages/page-sdk.md` — `openxiangda/runtime` data, connector, data view, notification, organization, and App Function APIs.
 - `references/pages/publish-flow.md` — workspace publish steps for code pages.
 
 Workflow / automation / permissions:

package/openxiangda-skills/references/connector-resources.md

@@ -32,7 +32,7 @@ Notification manifests live under `src/resources/notifications/` and contain `te
 
 Data view manifests live under `src/resources/data-views/` and define read-only joined or aggregate query resources. Use `storageMode: "materialized"` for refreshed lists/reports where lag is acceptable, and `storageMode: "live"` for bounded real-time query shapes. Use row views with `sdk.dataView.query` and aggregate views with `sdk.dataView.stats`. Before generating one, confirm freshness tolerance, query bounds, and indexes for materialized filters/sort fields/dimensions/date buckets. Do not use them for single-form CRUD, simple linkedForm selects, writes, write-back, or ad-hoc BI. See `data-views.md` before generating one.
 
-App Function manifests live under `src/resources/functions/`, with source in `src/functions/<functionCode>/index.ts`. Use them for reusable server-side logic that pages, automations, and workflows can share through `sdk.function.invoke` or `function_call` nodes. App Functions expose controlled runtime helpers such as `ctx.resources`, `ctx.form.queryOne/queryMany/getById/createOne/updateOne/updateById`, `ctx.dataView`, `ctx.connector`, `ctx.notification`, and `ctx.platform.api`; they do not expose raw SQL or Redis in the current MVP. Runtime page invocations also expose trusted role context on `ctx.operator.roleCodes`, `ctx.operator.currentRoleCode`, `ctx.operator.hasFullAccess`, `ctx.currentUser`, and `ctx.permissions`; use that context for server-side authorization, and never trust page-submitted role codes for sensitive actions. App Function form writes are trusted backend writes governed by declared `resources.forms` and function invocation authorization, not by direct page-user submit access to the target form. Use JS_CODE V2 only for node-local workflow/automation scripts.
+App Function manifests live under `src/resources/functions/`, with source in `src/functions/<functionCode>/index.ts`. Use them for reusable server-side logic that pages, automations, and workflows can share through `sdk.function.invoke` or `function_call` nodes. App Functions expose controlled runtime helpers such as `ctx.resources`, `ctx.form.queryOne/queryMany/getById/createOne/updateOne/updateById`, `ctx.dataView`, `ctx.connector`, `ctx.notification`, `ctx.organization`, and `ctx.platform.api`; they do not expose raw SQL or Redis in the current MVP. Runtime page invocations also expose trusted role context on `ctx.operator.roleCodes`, `ctx.operator.currentRoleCode`, `ctx.operator.hasFullAccess`, `ctx.currentUser`, and `ctx.permissions`; use that context for server-side authorization, and never trust page-submitted role codes for sensitive actions. App Function form writes are trusted backend writes governed by declared `resources.forms` and function invocation authorization, not by direct page-user submit access to the target form. App Function organization writes require `app:organization:manage` on the real operator/audit actor. Use JS_CODE V2 only for node-local workflow/automation scripts.
 
 Auth manifests live under `src/resources/auth/`. Use them to enable app-level login methods and bind phone-code/CAS/custom providers to App Functions. Auth provider functions are called only by the platform auth flow. They validate external credentials and return identity assertions such as `phone`, `email`, `externalId`, or `unionId`; they must not issue tokens, set cookies, or mutate platform user/binding tables.
 

package/openxiangda-skills/references/notifications.md

@@ -45,6 +45,62 @@ Allowed channels: `inapp`, `email`, `dingding`, `wechat`, `thirdparty_todo`.
 
 Do not include `token`, `secret`, `password`, `authorization`, `auth`, `credential`, or `headers` fields. Platform admins configure channel credentials outside resources.
 
+## DingTalk Cards
+
+DingTalk notifications prefer cards by default when the tenant has a default card template configured. Application resources should not include `appKey`, `appSecret`, or `agentId`; only override non-secret card settings when the app owns a custom DingTalk card.
+
+Standard card example:
+
+```json
+{
+  "channelsConfig": {
+    "dingding": {
+      "enabled": true,
+      "content": "{{title}}",
+      "config": {
+        "deliveryMode": "card_preferred",
+        "fallbackToWorkNotice": true,
+        "card": {
+          "mode": "standard",
+          "cardTemplateId": "${DINGTALK_CARD_TEMPLATE_ID}",
+          "title": "{{title}}",
+          "summary": "{{content}}",
+          "jumpUrl": "{{detailUrl}}",
+          "fieldConfigs": [
+            { "fieldId": "ticketNo", "label": "工单号", "order": 1, "required": false }
+          ]
+        }
+      }
+    }
+  }
+}
+```
+
+Delivery modes:
+
+- `card_preferred`: send a DingTalk card first, then fallback to a work notification if card delivery fails.
+- `card_only`: card failure is a send failure.
+- `work_notice_only`: send only a DingTalk work notification.
+
+Custom cards use the variables defined in the DingTalk developer console:
+
+```json
+{
+  "deliveryMode": "card_only",
+  "card": {
+    "mode": "custom",
+    "cardTemplateId": "${DINGTALK_TICKET_CARD_ID}",
+    "paramMap": {
+      "title": "{{title}}",
+      "ticketNo": "{{ticketNo}}",
+      "status": "{{status}}"
+    }
+  }
+}
+```
+
+Standard card payload variables include `title`, `lastMessage`, `content`, `contentList`, `jumpUrl`, `createTime`, `status`, `operator`, `currentUser`, `formData.current`, `workflowData`, `variables`, and `app`. General notifications do not show approval buttons by default.
+
 ## Runtime Calls
 
 Code pages:
@@ -61,6 +117,27 @@ await sdk.notification.sendByType({
 });
 ```
 
+DingTalk-specific helpers are available when the caller wants to inspect or force the DingTalk channel:
+
+```ts
+const capabilities = await sdk.notification.capabilities();
+
+const preview = await sdk.notification.previewDingTalk({
+  notificationType: "reservation_reminder",
+  payload: {
+    title: "预约提醒",
+  },
+});
+
+await sdk.notification.sendDingTalk({
+  notificationType: "reservation_reminder",
+  recipientId: userId,
+  payload: {
+    title: "预约提醒",
+  },
+});
+```
+
 User-facing in-app message centers should read the platform inbox instead of
 creating app-specific message/log forms:
 
@@ -86,6 +163,10 @@ CLI smoke tests:
 
 ```bash
 openxiangda notification preview reservation_reminder --body-json '{"payload":{"title":"测试"}}'
+openxiangda notification capabilities --json
+openxiangda notification dingding-preview reservation_reminder --body-json '{"payload":{"title":"测试"}}'
+openxiangda notification dingding-preview --template-code reservation_reminder --body-json '{"payload":{"title":"测试"}}'
+openxiangda notification dingding-send reservation_reminder --body-json '{"recipientId":"USER_ID","payload":{"title":"测试"}}' --force
 openxiangda notification send reservation_reminder --body-json '{"recipientId":"USER_ID","payload":{"title":"测试"}}' --force
 openxiangda notification batch-send reservation_reminder --body-json '{"recipients":[{"recipientId":"USER_ID","payload":{"title":"测试"}}]}' --force
 ```
@@ -103,6 +184,11 @@ export default async function notify(ctx) {
       startTime: ctx.formData.current.start_time,
     },
   });
+
+  await ctx.notification.previewDingTalk({
+    notificationType: "reservation_reminder",
+    payload: { title: "预约提醒" },
+  });
 }
 ```
 

package/openxiangda-skills/references/openxiangda-api.md

@@ -318,6 +318,7 @@ Requires Bearer token. Updates menu sorting and parent relationships in batch.
 ### POST `/apps/:appType/notifications/send-by-type`
 
 Requires Bearer token. Sends a notification in the current app scope.
+Each returned message can include `deliveryMeta` with provider message id, outTrackId, card template id, fallback usage, and provider error summary.
 
 ```json
 {
@@ -360,6 +361,45 @@ Requires app admin permission. Upserts an app/form notification template by code
 ### POST `/apps/:appType/notifications/templates/preview`
 
 Requires Bearer token. Body uses `templateCode` or `templateId` plus `payload`. The CLI command is `openxiangda notification preview <templateCode> --body-json '{"payload":{...}}'`.
+If DingTalk is enabled, the response includes `dingding.cardPreview` with `resolvedCardTemplateId`, `cardParamMap`, `outTrackId`, `workNoticeContent`, `missingVariables`, and `warnings`.
+
+### GET `/apps/:appType/notifications/dingtalk/capabilities`
+
+Requires Bearer token. Returns whether the tenant DingTalk channel is enabled, whether app credentials/agent/default card template are configured, and supported delivery/card modes.
+
+### POST `/apps/:appType/notifications/dingtalk/preview`
+
+Requires Bearer token. Body can use a notification binding:
+
+```json
+{
+  "notificationType": "reservation_reminder",
+  "payload": {
+    "title": "预约提醒"
+  }
+}
+```
+
+or a direct DingTalk config:
+
+```json
+{
+  "config": {
+    "deliveryMode": "card_preferred",
+    "card": {
+      "mode": "standard",
+      "title": "{{title}}"
+    }
+  },
+  "payload": {
+    "title": "预约提醒"
+  }
+}
+```
+
+### POST `/apps/:appType/notifications/dingtalk/send`
+
+Requires Bearer token. Sends the resolved `notificationType` through the DingTalk channel only. The CLI command is `openxiangda notification dingding-send <notificationType> --body-json '{"recipientId":"USER_ID","payload":{"title":"测试"}}' --force`.
 
 ### GET `/apps/:appType/notifications/type-configs`
 
@@ -373,6 +413,115 @@ Requires Bearer token. Resolves the active binding by notification type and opti
 
 Requires app admin permission. Upserts a binding with `templateCode` or `templateId`.
 
+## Organization
+
+Organization APIs are app-scoped and require `app:organization:manage` on the target app. Platform admins pass through the same permission service. Runtime service principals are not accepted by themselves: trusted runtime calls must carry a real audit actor, and permission is checked against that user.
+
+Use these endpoints for OpenXiangda app-managed platform departments and accounts. Do not use legacy `/user` or `/department` write endpoints for new app organization management.
+
+### GET `/apps/:appType/organization/capabilities`
+
+Requires Bearer token. Returns whether the current actor can manage organization data for the app, the permission code, and supported operations.
+
+CLI:
+
+```bash
+openxiangda organization capabilities --json
+```
+
+### GET `/apps/:appType/organization/departments`
+
+Requires `app:organization:manage`. Lists platform departments in the current tenant.
+
+### GET `/apps/:appType/organization/departments/:departmentId`
+
+Requires `app:organization:manage`. Returns one platform department.
+
+### POST `/apps/:appType/organization/departments`
+
+Requires `app:organization:manage`. Creates a platform department and runs existing org cache invalidation.
+
+```json
+{
+  "name": "销售部",
+  "parentId": "optional-parent-id",
+  "externalId": "optional-external-id",
+  "corpId": "optional-corp-id",
+  "visibilityScope": "public",
+  "memberViewScope": "self_and_children",
+  "supervisorUserIds": ["user-1"]
+}
+```
+
+CLI:
+
+```bash
+openxiangda organization department-create --body-json '{"name":"销售部"}' --force
+```
+
+### POST `/apps/:appType/organization/departments/:departmentId`
+
+Requires `app:organization:manage`. Updates department metadata, visibility/member scopes, and supervisors.
+
+### GET `/apps/:appType/organization/accounts`
+
+Requires `app:organization:manage`. Lists tenant platform accounts. Supports `ids`, `departmentIds`, `keyword`, `name`, `username`, `phone`, `email`, `jobNumber`, `page`, and `pageSize`.
+
+### GET `/apps/:appType/organization/accounts/:userId`
+
+Requires `app:organization:manage`. Returns one platform account. Password, login failure counters, and lock fields are removed from the response.
+
+### POST `/apps/:appType/organization/accounts`
+
+Requires `app:organization:manage`. Creates a platform account.
+
+```json
+{
+  "id": "optional-user-id",
+  "username": "alice",
+  "password": "initial-password",
+  "name": "Alice",
+  "phone": "13800000000",
+  "email": "alice@example.com",
+  "jobNumber": "E001",
+  "departmentIds": ["dept-1"],
+  "affiliatedDepartmentId": "dept-1",
+  "validFrom": "2026-07-01T00:00:00.000Z",
+  "validTo": null
+}
+```
+
+### POST `/apps/:appType/organization/accounts/:userId`
+
+Requires `app:organization:manage`. Updates account fields except password. If `password` is present, the request is rejected; use the dedicated password endpoint.
+
+### POST `/apps/:appType/organization/accounts/:userId/password/reset`
+
+Requires `app:organization:manage`. Resets the target account password, writes the existing sha512 password hash, and clears `failedLoginAttempts`, `lockUntil`, and `lockReason`.
+
+```json
+{
+  "newPassword": "new-password"
+}
+```
+
+CLI:
+
+```bash
+openxiangda organization account-reset-password user-1 --body-json '{"newPassword":"new-password"}' --force
+```
+
+### POST `/apps/:appType/organization/accounts/me/password/change`
+
+Requires `app:organization:manage` for the current real user. Validates `oldPassword` before changing the current user's password.
+
+```json
+{
+  "oldPassword": "old-password",
+  "newPassword": "new-password"
+}
+```
+
 ### GET `/apps/:appType/workflows`
 
 Requires Bearer token. Lists workflow definitions in the app. Supports `formUuid`, `isPublished`, `page`, and `pageSize` query parameters.

package/openxiangda-skills/references/pages/page-sdk.md

@@ -16,6 +16,7 @@ Guidelines:
 - Use `sdk.function.invoke(code, { input })` for reusable backend business logic declared under `src/resources/functions/` and `src/functions/`. Do not implement multi-form orchestration, connector fan-out, notification orchestration, or permission-sensitive backend rules directly in a page component.
 - Use `sdk.connector.invoke`, `sdk.connector.call("connector.api")`, or `sdk.connector.download` for external services. The SDK calls the platform runtime connector endpoint; it must not call third-party domains directly.
 - Use `sdk.notification.sendByType` and `batchSendByType` for reusable business messages. Custom notification types must be declared in `src/resources/notifications/` and published with `openxiangda resource publish`.
+- Use `sdk.organization.departments.*` and `sdk.organization.accounts.*` only for admin-style app pages that intentionally manage platform departments/accounts. The current user needs `app:organization:manage` on the app. Do not call legacy `/user` or `/department` write endpoints from pages.
 - Use `sdk.workCenter.listItems({ boxType })` and `sdk.workCenter.getStats()` for current-user work center lists and counts. `boxType` is one of `todo`, `done`, `cc`, or `initiated`. This is the end-user task/handled/cc/initiated surface; do not build todo pages by reading workflow operation logs, automation logs, or raw process-task tables.
 - Use `createAuthClient` from `openxiangda/runtime` or `LoginPage` / `useAuth` from `openxiangda/runtime/react` for application login pages. Auth provider App Functions return identity assertions only; platform auth owns create/bind/reject/token decisions.
 - Use `PublicAccessGate` from `openxiangda/runtime/react` or `createPublicAccessClient` from `openxiangda/runtime` for React SPA public pages under `/view/:appType/public/*`. Do not append old `?publicAccess=guest` links in new apps.
@@ -113,6 +114,42 @@ same value is also available as `ctx.input` for compatibility.
 
 Use App Functions when the logic must run server-side and be reusable by pages, automations, or workflows. Runtime invocation requires app automation management permission by default. To let ordinary app users call a function from a page, declare the allowed current app roles in `definitionJson.runtimeInvoke.roleCodes`; keep sensitive admin-only functions without broad grants. Inside the function, authorize sensitive actions with trusted runtime context such as `ctx.operator.roleCodes`, `ctx.operator.currentRoleCode`, `ctx.operator.hasFullAccess`, `ctx.currentUser`, or `ctx.permissions`; do not trust role codes sent in the page input. When the function writes forms with `ctx.form.createOne/updateOne/updateById`, treat the write as a trusted backend operation over declared `resources.forms`; do not open direct submit permission on internal forms just for that page action.
 
+Organization management:
+
+```ts
+const capabilities = await sdk.organization.capabilities()
+if (!capabilities.result?.canManage) {
+  throw new Error("当前用户缺少组织账号管理权限")
+}
+
+await sdk.organization.departments.create({
+  name: "销售部",
+  parentId: rootDepartmentId,
+})
+
+const accounts = await sdk.organization.accounts.list({
+  keyword,
+  departmentIds: [rootDepartmentId],
+  page: 1,
+  pageSize: 20,
+})
+
+await sdk.organization.accounts.create({
+  username: "alice",
+  password: initialPassword,
+  name: "Alice",
+  jobNumber: "E001",
+  departmentIds: [rootDepartmentId],
+  affiliatedDepartmentId: rootDepartmentId,
+})
+
+await sdk.organization.accounts.resetPassword("alice", {
+  newPassword,
+})
+```
+
+Use `ctx.organization.departments.*` and `ctx.organization.accounts.*` inside App Functions or trusted JS nodes for the same capability. Runtime service principals must resolve a real operator/audit actor; permission is checked against that user, not against the runtime service account. Keep password changes on dedicated endpoints: update account metadata with `update`, reset another user's password with `resetPassword`, and change the current user's password with `changeMyPassword({ oldPassword, newPassword })`.
+
 Work center:
 
 ```ts

package/openxiangda-skills/references/resource-manifest-cheatsheet.md

@@ -423,7 +423,20 @@ const stats = await sdk.dataView.stats("ticket_stats_by_customer", {
       "variables": ["title", "instrumentName", "startTime"],
       "channelsConfig": {
         "inapp":    { "enabled": true, "content": "{{instrumentName}} 将于 {{startTime}} 开始" },
-        "dingding": { "enabled": true, "content": "{{title}}" }
+        "dingding": {
+          "enabled": true,
+          "content": "{{title}}",
+          "config": {
+            "deliveryMode": "card_preferred",
+            "fallbackToWorkNotice": true,
+            "card": {
+              "mode": "standard",
+              "title": "{{title}}",
+              "summary": "{{instrumentName}} 将于 {{startTime}} 开始",
+              "jumpUrl": "{{detailUrl}}"
+            }
+          }
+        }
       }
     }
   ],
@@ -450,6 +463,8 @@ await sdk.notification.sendByType({
 
 JS_CODE 调用：`ctx.notification.sendByType({ ... })`。允许的 channels：`inapp` / `email` / `dingding` / `wechat` / `thirdparty_todo`。完整规则见 [`notifications.md`](notifications.md)。
 
+钉钉卡片预览/发送：`sdk.notification.previewDingTalk({ notificationType, payload })`、`sdk.notification.sendDingTalk({ notificationType, recipientId, payload })`；CLI 为 `openxiangda notification dingding-preview` 和 `openxiangda notification dingding-send --force`。
+
 ## 4. App Function — `src/resources/functions/<functionCode>.json` + `src/functions/<functionCode>/index.ts`
 
 ```json

package/openxiangda-skills/references/workflow-v3.md

@@ -389,7 +389,7 @@ For reusable backend logic that should be shared by pages, automations, and work
 
 Use JS_CODE V2 when the script is local to one workflow node.
 
-Scripts can export `export default async function (ctx) {}` or `module.exports = async (ctx) => {}`. The runtime exposes `ctx.triggerEvent`, `ctx.formData`, `ctx.workflowData`, `ctx.operator`, `ctx.app`, `ctx.variables`, `ctx.resources`, `ctx.form`, `ctx.dataView`, `ctx.connector`, `ctx.notification`, `ctx.platform.api.*`, `ctx.utils`, `require`, `process`, and `Buffer`. Prefer `ctx.resources.resolveForm/resolveDataView/resolveConnector`, `ctx.form.queryOne/queryMany/getById/createOne/updateOne/updateById`, `ctx.dataView.query/stats`, and `ctx.connector.call/invoke` for platform-side work. App Function and trusted-node form writes are backend operations over declared resources, not direct page-user submit access; keep internal forms closed to raw user submission unless the business requires it. Legacy data/process bridge methods remain available as `ctx.methods.queryOneData/queryManyData/getDataByFormInstanceId/updateOneData/updateDataByFormInstanceId/updateManyData/createOneData/terminateProcess/getAllParentDepartments`.
+Scripts can export `export default async function (ctx) {}` or `module.exports = async (ctx) => {}`. The runtime exposes `ctx.triggerEvent`, `ctx.formData`, `ctx.workflowData`, `ctx.operator`, `ctx.app`, `ctx.variables`, `ctx.resources`, `ctx.form`, `ctx.dataView`, `ctx.connector`, `ctx.notification`, `ctx.organization`, `ctx.platform.api.*`, `ctx.utils`, `require`, `process`, and `Buffer`. Prefer `ctx.resources.resolveForm/resolveDataView/resolveConnector`, `ctx.form.queryOne/queryMany/getById/createOne/updateOne/updateById`, `ctx.dataView.query/stats`, and `ctx.connector.call/invoke` for platform-side work. Use `ctx.organization.departments.*` and `ctx.organization.accounts.*` only for intentional organization-management flows; the real operator/audit actor must hold `app:organization:manage`. App Function and trusted-node form writes are backend operations over declared resources, not direct page-user submit access; keep internal forms closed to raw user submission unless the business requires it. Legacy data/process bridge methods remain available as `ctx.methods.queryOneData/queryManyData/getDataByFormInstanceId/updateOneData/updateDataByFormInstanceId/updateManyData/createOneData/terminateProcess/getAllParentDepartments`.
 
 Example `src/js-code-nodes/sync_customer/index.ts`:
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "openxiangda",
-  "version": "1.0.131",
+  "version": "1.0.133",
   "description": "OpenXiangda CLI, workspace build tools, runtime SDK, and form components.",
   "private": false,
   "bin": {

package/packages/sdk/dist/components/index.cjs

@@ -12259,7 +12259,7 @@ async function handleApproval(request, params) {
 async function withdrawProcess(request, params) {
   const response = await request({
     url: `/workflow/instance/${params.instanceId}/withdraw`,
-    method: "put",
+    method: "post",
     data: { reason: params.reason }
   });
   return unwrapRuntimeResponse(response);
@@ -12267,7 +12267,7 @@ async function withdrawProcess(request, params) {
 async function transferTask(request, params) {
   const response = await request({
     url: `/workflow/task/${params.taskId}/transfer`,
-    method: "put",
+    method: "post",
     data: { newAssignee: params.newAssignee, reason: params.reason }
   });
   return unwrapRuntimeResponse(response);
@@ -12275,7 +12275,7 @@ async function transferTask(request, params) {
 async function returnTask(request, params) {
   const response = await request({
     url: `/workflow/task/${params.taskId}/return`,
-    method: "put",
+    method: "post",
     data: { targetNodeId: params.targetNodeId, reason: params.reason }
   });
   return unwrapRuntimeResponse(response);