openxiangda 1.0.137 → 1.0.139

package/lib/cli.js

@@ -6963,6 +6963,21 @@ function validateResourceItem(kind, item, errors, warnings) {
     } else {
       errors.push(`${label}: 不支持的 viewType: ${definition.viewType}`);
     }
+    for (const [index, group] of (item.permissionGroups || []).entries()) {
+      const actions = group.actions || group.operations;
+      if (actions !== undefined) {
+        if (!Array.isArray(actions)) {
+          errors.push(`${label}.permissionGroups[${index}]: actions/operations 必须是数组`);
+        } else {
+          for (const action of actions) {
+            const normalizedAction = normalizePermissionActionValue(action);
+            if (!DATA_VIEW_PERMISSION_ACTIONS.has(normalizedAction)) {
+              errors.push(`${label}.permissionGroups[${index}]: 不支持的数据视图 action "${action}"`);
+            }
+          }
+        }
+      }
+    }
     validateDataViewPerformance(label, definition, errors, warnings, storageMode);
   }
   if (kind === 'storageConfigs') {
@@ -7064,6 +7079,12 @@ function validateResourceItem(kind, item, errors, warnings) {
   if (kind === 'scopeGrantSources') {
     if (!item.name) warnings.push(`${label}: 未声明 name，将使用 code`);
     if (!item.sourceFormUuid && !item.formUuid) errors.push(`${label}: 缺少 sourceFormUuid`);
+    if (
+      item.syncMode !== undefined &&
+      !['on_write', 'manual'].includes(String(item.syncMode))
+    ) {
+      errors.push(`${label}: syncMode 只能是 on_write 或 manual`);
+    }
     const subjectMappings = item.subjectMappings || item.subjects;
     const dimensionMappings = item.dimensionMappings || item.dimensions;
     if (!Array.isArray(subjectMappings) || subjectMappings.length === 0) {
@@ -7104,6 +7125,19 @@ function validateResourceItem(kind, item, errors, warnings) {
   if (kind === 'formPermissionGroups') {
     if (!item.name) errors.push(`${label}: 缺少 name`);
     if (!item.formCode && !item.formUuid) errors.push(`${label}: 缺少 formCode 或 formUuid`);
+    const actions = item.actions || item.operations;
+    if (actions !== undefined) {
+      if (!Array.isArray(actions)) {
+        errors.push(`${label}: actions/operations 必须是数组`);
+      } else {
+        for (const action of actions) {
+          const normalizedAction = normalizePermissionActionValue(action);
+          if (!FORM_PERMISSION_ACTIONS.has(normalizedAction)) {
+            errors.push(`${label}: 不支持的表单 action "${action}"`);
+          }
+        }
+      }
+    }
     if (item.dataPermission?.type === 'scope_policy' && !getScopePolicyCode(item.dataPermission)) {
       errors.push(`${label}: dataPermission.type=scope_policy 时必须声明 policyCode`);
     }
@@ -7131,14 +7165,43 @@ function validateScopePermissionResources(manifest, errors, warnings) {
       .map(String)
   );
   const scopePolicyRefs = [];
+  for (const source of manifest.scopeGrantSources || []) {
+    if (String(source.syncMode || '').trim() === 'manual') {
+      warnings.push(`${resourceLabel('scopeGrantSources', source)}: syncMode=manual，运行时来源表单变更不会自动物化；请确认有显式 scope sync 作业`);
+    }
+  }
   const inspectPermissionGroup = (kind, item) => {
     const groups = kind === 'dataViews'
       ? (Array.isArray(item.permissionGroups) ? item.permissionGroups : [])
       : [item];
     for (const group of groups) {
+      const actions = kind === 'dataViews'
+        ? normalizeDataViewPermissionGroupActions(group)
+        : normalizeFormPermissionGroupActions(group);
       const dataPermission = group?.dataPermission;
+      if (
+        kind === 'formPermissionGroups' &&
+        actions.includes('create') &&
+        (!dataPermission || dataPermission.type !== 'scope_policy')
+      ) {
+        warnings.push(`${resourceLabel(kind, item)}: 声明了 create，但未声明 create 对应的 scope_policy；若新增数据必须落在用户业务范围内，请补充 dataPermission.type=scope_policy`);
+      }
       if (!dataPermission) continue;
       if (dataPermission.type === 'scope_policy') {
+        if (kind === 'formPermissionGroups') {
+          const missing = ['view', 'edit', 'delete', 'export']
+            .filter(action => !actions.includes(action));
+          if (missing.length) {
+            warnings.push(`${resourceLabel(kind, item)}: 使用 scope_policy 但 action 覆盖不完整，缺少 ${missing.join(', ')}；请确认每个角色的 action matrix`);
+          }
+        }
+        if (kind === 'dataViews') {
+          const missing = ['query', 'stats', 'export']
+            .filter(action => !actions.includes(action));
+          if (missing.length) {
+            warnings.push(`${resourceLabel(kind, item)}: Data View 使用 scope_policy 但 action 覆盖不完整，缺少 ${missing.join(', ')}`);
+          }
+        }
         const policyCode = getScopePolicyCode(dataPermission);
         if (!policyCode) {
           errors.push(`${resourceLabel(kind, item)}: scope_policy 缺少 policyCode`);
@@ -10472,11 +10535,20 @@ function normalizeDataViewManifest(bound, dataView) {
     definition: normalizedDefinition,
     refreshConfig: dataView.refreshConfig || dataView.refresh || normalizedDefinition.refresh,
     permissionGroups: Array.isArray(dataView.permissionGroups)
-      ? dataView.permissionGroups.map(group => stripUndefinedValues(withoutResourceMeta(group)))
+      ? dataView.permissionGroups.map(group => normalizeDataViewPermissionGroupManifest(group))
       : undefined,
   });
 }
 
+function normalizeDataViewPermissionGroupManifest(group = {}) {
+  const body = stripUndefinedValues({
+    ...withoutResourceMeta(group),
+    operations: normalizeDataViewPermissionGroupActions(group),
+  });
+  delete body.actions;
+  return body;
+}
+
 function normalizeRouteManifest(route) {
   const code = route.code || route.resourceCode;
   return stripUndefinedValues({
@@ -10549,10 +10621,20 @@ function normalizeScopeGrantSourceManifest(source, bound) {
     effectiveFromField: source.effectiveFromField,
     effectiveToField: source.effectiveToField,
     filterJson: source.filterJson || source.filter,
+    syncMode: normalizeScopeGrantSourceSyncMode(source.syncMode, source.sync),
     enabled: source.enabled !== false,
   });
 }
 
+function normalizeScopeGrantSourceSyncMode(value, legacySync) {
+  const raw = String(value || '').trim().toLowerCase();
+  if (['manual', 'off', 'none', 'disabled', 'false'].includes(raw)) {
+    return 'manual';
+  }
+  if (legacySync === false) return 'manual';
+  return 'on_write';
+}
+
 function normalizeDataScopePolicyManifest(policy) {
   const code = policy.code || policy.resourceCode;
   return stripUndefinedValues({
@@ -11161,10 +11243,12 @@ function normalizeFormPermissionGroupManifest(bound, group) {
     name: group.name || group.code,
     type: group.type || 'view',
     roles: group.roles || [],
+    operations: normalizeFormPermissionGroupActions(group),
   };
   delete body.code;
   delete body.formCode;
   delete body.form;
+  delete body.actions;
   return stripUndefinedValues(body);
 }
 
@@ -11186,6 +11270,52 @@ function sortStringValues(value = []) {
   return [...(value || [])].map(item => String(item)).sort();
 }
 
+const FORM_PERMISSION_ACTIONS = new Set([
+  'view',
+  'create',
+  'edit',
+  'delete',
+  'export',
+  'import',
+  'change_records',
+  'workflow',
+]);
+
+const DATA_VIEW_PERMISSION_ACTIONS = new Set([
+  'query',
+  'stats',
+  'export',
+  'refresh',
+]);
+
+function normalizePermissionActionValue(action) {
+  const value = String(action || '').trim();
+  if (!value) return '';
+  if (value === 'submit') return 'create';
+  return value;
+}
+
+function normalizePermissionActionArray(value, allowed, fallback = []) {
+  const source = Array.isArray(value) ? value : fallback;
+  return unique(source.map(normalizePermissionActionValue).filter(action => allowed.has(action)));
+}
+
+function normalizeFormPermissionGroupActions(group = {}) {
+  if (group.actions !== undefined || group.operations !== undefined) {
+    return normalizePermissionActionArray(group.actions || group.operations, FORM_PERMISSION_ACTIONS);
+  }
+  return group.type === 'submit'
+    ? ['create']
+    : ['view', 'edit', 'delete', 'change_records', 'workflow'];
+}
+
+function normalizeDataViewPermissionGroupActions(group = {}) {
+  if (group.actions !== undefined || group.operations !== undefined) {
+    return normalizePermissionActionArray(group.actions || group.operations, DATA_VIEW_PERMISSION_ACTIONS);
+  }
+  return ['query'];
+}
+
 function pickObjectKeys(source = {}, keys = []) {
   return keys.reduce((acc, key) => {
     acc[key] = source[key];
@@ -11407,7 +11537,7 @@ function normalizeDataViewPermissionGroupsForPlan(groups = []) {
         code,
         name: group.name || code || '默认权限组',
         roles: Array.isArray(group.roles) ? sortStringValues(group.roles) : [],
-        operations: Array.isArray(group.operations) ? sortStringValues(group.operations) : ['query'],
+        operations: sortStringValues(normalizeDataViewPermissionGroupActions(group)),
         fieldPermissions: normalizeFieldPermissionsForPlan(group.fieldPermissions),
         dataPermission: group.dataPermission || undefined,
       });

package/lib/design-gates.js

@@ -124,15 +124,19 @@ const DESIGN_GATE_TOPICS = [
       '哪些角色可以设置应用角色、分配角色成员、给角色分配接口权限；这些角色是否需要 `app:role:manage`',
       '哪些角色可以维护页面权限组、表单权限组、组织账号；是否需要 `app:page-permission-group:manage`、`app:form-permission-group:manage`、`app:organization:manage`',
       '业务范围字段是什么，哪些可见字段需要派生隐藏 scalar key 供表单权限条件匹配',
-      '页面/菜单/路由、表单 submit/view/manage/fieldAccessPolicy/dataScope 的权限矩阵如何落到 resources',
+      '每个角色的 action matrix 是什么：view/create/edit/delete/export/import/change_records/workflow 是否分别授权',
+      '导出/导入是否独立授权；导出范围是否与 view 范围不同，导入是否还需要逐行 create 范围校验',
+      'create 是否需要 scope_policy 校验提交数据，防止新增到未授权业务范围',
+      '页面/菜单/路由、表单 actions/fieldAccessPolicy/dataPermission/scope_policy 的权限矩阵如何落到 resources',
       '查询参数是否参与授权；如果参与，只能做上下文、筛选或 ticket 输入，敏感数据必须由 public-access grant、角色、表单权限组或 App Function 校验',
       '验收时需要模拟哪些角色、账号状态、业务范围、查询参数篡改和拒绝场景',
     ],
     recommendedDefaults: [
       '正式后台优先选择 managed-platform-account；如果平台账号已存在，选择 existing-platform-user-assignment；固定内部门户选择 static-role-permission',
       'query-param-context 仅用于低风险页面上下文、筛选条件或公开 ticket 输入，不作为敏感数据授权依据',
-      '角色写 src/resources/roles，页面组写 permissions/page-groups，表单组写 permissions/form-groups，显式声明 dataScope/operations/fieldAccessPolicy',
-      '复杂业务范围优先写 permissions/scope-dimensions、permissions/scope-grant-sources、permissions/data-scope-policies，并在表单权限组或 data-view 权限组使用 dataPermission.type=scope_policy',
+      '角色写 src/resources/roles，页面组写 permissions/page-groups，表单组写 permissions/form-groups，显式声明 actions/dataPermission/fieldAccessPolicy；平台内部仍兼容存储为 operations',
+      '复杂业务范围优先写 permissions/scope-dimensions、permissions/scope-grant-sources、permissions/data-scope-policies，并在表单权限组或 data-view 权限组使用 dataPermission.type=scope_policy；授权来源默认 syncMode=on_write，由平台在来源表单写入后自动物化',
+      'scope_policy 只表达数据范围，actions 表达操作能力；按钮隐藏只是 UX，后端 action check 才是权威',
       'scope_policy 默认语义是个人授权 + 当前应用角色授权；多维 rules 显式 AND；空授权集合拒绝；管理员绕过但可审计',
       '能管理角色或给别人分配角色的应用角色必须在 roles manifest 声明 apiPermissionCodes；至少包含 app:role:manage，按需加入 app:page-permission-group:manage、app:form-permission-group:manage、app:organization:manage',
       '由校区管理员等委托管理员创建的新角色，如果还具备继续管理账号/角色/权限的能力，也必须同步声明并发布对应 apiPermissionCodes',
@@ -144,6 +148,7 @@ const DESIGN_GATE_TOPICS = [
       '不能只做前端权限隐藏，必须有后端角色、表单权限组、public-access grant 或 App Function 校验',
       '查询参数不能作为敏感授权依据，只能作为上下文、筛选或 ticket 输入',
       '只配菜单可见，不配后端数据权限',
+      '只隐藏按钮但没有表单权限组 actions 或 App Function 服务端校验',
       '为了省事授予全部数据再在前端过滤',
       '为每个客户/项目/区域/学院/班级/门店创建一个角色或一个权限组',
       '把应用表单里的业务范围强行同步成平台部门、平台角色或大量权限组',

package/openxiangda-skills/references/component-guide.md

@@ -64,7 +64,7 @@ AI 在实现成熟交互前必须先判断是否已有可靠组件或库：
 | 富文本编辑 | `EditorField` | 含图片上传集成 | 完整工具栏、平台图床、粘贴清洗 |
 | 数字签名 | `DigitalSignatureField` | 平台级签名 | 签名采集、验证、归档 |
 | 地理位置 | `LocationField` | 接入地图服务 | 定位、地图选点、地址解析 |
-| 数据管理列表 | `DataManagementList` | 接入数据查询 API | 分页、筛选、导出、批量操作、字段权限 |
+| 数据管理列表 | `DataManagementList` | 接入数据查询 API | 分页、筛选、导出、批量操作、字段权限、后端 action summary 按钮控制 |
 
 ### 示例
 
@@ -89,6 +89,12 @@ OSS 浏览器直传所需的 CORS 规则在 `src/resources/storage/<code>.json`
 
 业务应用只能从 `openxiangda`、`openxiangda/runtime`、`openxiangda/runtime/react` 等公开入口导入组件和 SDK。不要为了减小包体积去引用 `openxiangda/packages/sdk/dist/...` 内部文件；React SPA 模板已提供 vendor chunk 分组，SDK 会把 `antd-mobile`、`dayjs` 等大型 UI 依赖交给应用构建器按路由拆分。
 
+`DataManagementList` 默认 `permissionMode="auto"`，进入页面会读取表单 action
+summary，并用 `can.create/export/import/delete/workflow/change_records` 隐藏新增、
+导入、导出、删除、流程等按钮。`readonly=true` 仍会强制关闭新增、编辑、删除和
+导入。`actionOverrides` 只能关闭按钮，不能扩大后端权限；敏感授权必须依赖后端
+form actions、`scope_policy` 或 App Function 服务端校验。
+
 > ✅ 一句话原则：**这些场景看到了，直接抄上表，不要自己写。**
 
 ---

package/openxiangda-skills/references/permission-design-patterns.md

@@ -27,8 +27,8 @@ Required design:
   scalar scope keys, platform role member sync state.
 - `src/resources/roles/*.json`: stable app role codes.
 - `src/resources/permissions/page-groups/*.json`: menu, route, and page access.
-- `src/resources/permissions/form-groups/*.json`: submit/view/manage, data
-  scope, operations, and `fieldAccessPolicy`.
+- `src/resources/permissions/form-groups/*.json`: `actions`, data scope or
+  `dataPermission.type=scope_policy`, and `fieldAccessPolicy`.
 - `apiPermissionCodes` on roles that are allowed to manage roles, role members,
   permission groups, or organization accounts.
 - Sync App Functions or trusted JS_CODE: sync organization units, accounts, and
@@ -142,8 +142,13 @@ The platform keeps RBAC and data range separate:
 
 - Roles decide who can enter pages, submit/view forms, use operations, and
   maintain permissions.
+- Form `actions` decide what a role can do: `view`, `create`, `edit`, `delete`,
+  `export`, `import`, `change_records`, and `workflow`.
+- Data View `actions` decide query capabilities: `query`, `stats`, `export`,
+  and `refresh`.
 - Field access remains `fieldAccessPolicy`.
-- Business scope policies decide which rows a matched role/user can read.
+- Business scope policies decide which rows or submitted scope values a matched
+  role/user can access for the current action.
 - App Functions must still check role/scope server-side before sensitive
   writes.
 
@@ -157,21 +162,47 @@ Default semantics:
 - Authorization source rows should include an explicit status/enabled field and
   grant sources should use `filterJson` or `enabledField` so drafts, disabled
   rows, or rejected assignments are not materialized.
-- Source forms must have a sync path. `sync: true` on the manifest runs during
-  publish; runtime changes need an automation/App Function or platform API call
-  that resyncs the affected grant source after create/update/delete.
+- Source authorization forms are synced by the platform after form
+  create/update/delete/import when the grant source uses the default
+  `syncMode: "on_write"`. Use `syncMode: "manual"` only for externally
+  maintained sources or unusual bulk jobs; `sync: true` still performs an
+  immediate full sync during resource publish.
 - Policy target fields should normally be hidden scalar keys. If targeting a
   JSONB option/person/department field directly, declare `valuePath: "value"` or
   `componentType`; multi-value fields should be normalized into a scalar key or
   a separate authorization row.
 - App Function form read helpers enforce view permission for real callers. Do
   not grant broad form read permission and then filter in function/page code.
+- `DataManagementList` can hide buttons from the backend action summary, but it
+  is not the authority. Sensitive actions must be represented by form actions or
+  App Function server checks.
 
 Do not model a dynamic business object set by generating dozens or hundreds of
 roles or permission groups. Use a business authorization form and `scope_policy`
 when the object set is maintained by users, imported from another system, or
 expected to grow.
 
+Recommended action pattern:
+
+```json
+{
+  "code": "campus_profile_manage",
+  "formCode": "student_profile",
+  "name": "校区管理员档案权限",
+  "type": "view",
+  "roles": ["campus_admin"],
+  "actions": ["view", "edit", "export"],
+  "dataPermission": {
+    "type": "scope_policy",
+    "policyCode": "campus_row_scope"
+  },
+  "fieldAccessPolicy": {
+    "defaultAccess": "readonly",
+    "fields": [{ "fieldId": "remark", "access": "edit" }]
+  }
+}
+```
+
 ## Role Setting Delegation
 
 Setting application roles is itself permission controlled. A user can be a

package/openxiangda-skills/references/permissions-settings.md

@@ -260,6 +260,7 @@ Declare scope resources:
       { "field": "status", "op": "eq", "value": "enabled" }
     ]
   },
+  "syncMode": "on_write",
   "sync": true
 }
 ```
@@ -289,7 +290,43 @@ Reference the policy from a form permission group:
   "name": "学院查看学生",
   "type": "view",
   "roles": ["college_admin"],
-  "operations": ["view"],
+  "actions": ["view", "edit", "export"],
+  "dataPermission": {
+    "type": "scope_policy",
+    "policyCode": "college_data"
+  }
+}
+```
+
+Unified permission model:
+
+- `scope_policy` means data range: which rows this user/current app role can
+  access.
+- `actions` means operation ability: what the role can do to rows in that
+  range. Form actions are `view`, `create`, `edit`, `delete`, `export`,
+  `import`, `change_records`, and `workflow`.
+- The platform still stores actions in the legacy `operations` field. Manifests
+  may use either `actions` or `operations`; prefer `actions` in new resources.
+- `type: "submit"` is the legacy create group and maps to `actions:["create"]`.
+- `export` is independent from `view` for new apps. Old apps may temporarily
+  rely on view-to-export compatibility, but `permission audit` should be used to
+  migrate to explicit `export`.
+- `create` with `scope_policy` validates submitted scope fields; a campus admin
+  cannot create a row for another campus just because the create button is
+  visible.
+- Frontend button hiding is UX only. The backend action check and action-specific
+  data range are authoritative.
+
+Create permission with business scope:
+
+```json
+{
+  "code": "college_student_create",
+  "formCode": "student",
+  "name": "学院管理员新增本学院学生",
+  "type": "submit",
+  "roles": ["college_admin"],
+  "actions": ["create"],
   "dataPermission": {
     "type": "scope_policy",
     "policyCode": "college_data"
@@ -298,7 +335,8 @@ Reference the policy from a form permission group:
 ```
 
 For Data View permission groups, use the same `dataPermission` shape inside the
-view's `permissionGroups`.
+view's `permissionGroups`. Data View actions are `query`, `stats`, `export`,
+and `refresh`.
 
 Default runtime semantics:
 
@@ -317,10 +355,11 @@ Default runtime semantics:
 - `filterJson` filters authorization source rows before materializing grants.
   Use it for enabled/approved/effective authorization rows; unsupported filter
   operations do not match.
-- Source authorization forms must be synced after changes. For formal apps,
-  create an automation/App Function that runs `openxiangda scope sync` or the
-  equivalent platform API after authorization rows are created, updated, or
-  deleted. Publishing with `"sync": true` only syncs during resource publish.
+- Source authorization forms are synced by the platform after create/update/
+  delete/import when the grant source uses the default `syncMode: "on_write"`.
+  Use `syncMode: "manual"` only for externally maintained sources or unusual
+  bulk jobs that explicitly call `openxiangda scope sync`. Publishing with
+  `"sync": true` still performs an immediate full sync during resource publish.
 - App Function `ctx.form.queryOne/queryMany/getById` enforces the caller's view
   permission when there is a real current user. No matching view permission
   group means deny; backend system automations can still use trusted internal

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

@@ -334,6 +334,7 @@ Grant source:
       { "field": "status", "op": "eq", "value": "enabled" }
     ]
   },
+  "syncMode": "on_write",
   "sync": true
 }
 ```
@@ -373,9 +374,12 @@ Data View permission groups use the same `dataPermission` object inside
 default; large grant sets use DB `EXISTS` instead of huge `IN` SQL. Prefer
 hidden scalar target fields such as `collegeCode`; if the target is a JSONB
 option/person/department field, set `valuePath: "value"` or `componentType`.
-Runtime changes to the authorization source form need an automation/App
-Function or explicit platform API call to resync the grant source; manifest
-`sync: true` only runs during resource publish.
+Authorization source form changes are synced by the platform after
+create/update/delete/import when the grant source uses the default
+`syncMode: "on_write"`. Use `syncMode: "manual"` only for externally maintained
+sources or special bulk jobs that explicitly call `openxiangda scope sync`.
+Manifest `sync: true` still performs an immediate full sync during resource
+publish.
 
 ## 3. Connector — `src/resources/connectors/<code>.json`
 

package/package.json

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

package/packages/sdk/dist/{ProcessPreview-Ci8_UsbN.d.mts → ProcessPreview-CZJP8n3e.d.mts}

@@ -1021,6 +1021,12 @@ interface ProcessDefinition {
 interface ViewPermissionSummary {
     fieldPermissions: Record<string, 'FORM_FILED_HIDDEN' | 'FORM_FILED_VIEW' | 'FORM_FILED_EDIT'>;
     operations: string[];
+    actions?: string[];
+    can?: Record<string, boolean>;
+    fieldAccessPolicy?: any;
+    hasFullAccess?: boolean;
+    resourceType?: string;
+    matchedGroupCodes?: string[];
 }
 /** 表单实例数据 */
 interface FormInstanceData {

package/packages/sdk/dist/{ProcessPreview-Ci8_UsbN.d.ts → ProcessPreview-CZJP8n3e.d.ts}

@@ -1021,6 +1021,12 @@ interface ProcessDefinition {
 interface ViewPermissionSummary {
     fieldPermissions: Record<string, 'FORM_FILED_HIDDEN' | 'FORM_FILED_VIEW' | 'FORM_FILED_EDIT'>;
     operations: string[];
+    actions?: string[];
+    can?: Record<string, boolean>;
+    fieldAccessPolicy?: any;
+    hasFullAccess?: boolean;
+    resourceType?: string;
+    matchedGroupCodes?: string[];
 }
 /** 表单实例数据 */
 interface FormInstanceData {