openxiangda 1.0.134 → 1.0.136

package/lib/design-gates.js

@@ -112,28 +112,51 @@ const DESIGN_GATE_TOPICS = [
   },
   {
     code: 'permissions',
-    title: '角色 / 页面权限 / 表单数据范围',
-    triggers: ['权限', '角色', '数据范围', '只看自己', '部门数据', '页面权限', '字段权限'],
+    title: '账号 / 角色 / 页面权限 / 表单数据范围',
+    triggers: ['权限', '角色', 'RBAC', '账号权限', '平台账号', '组织账号', '角色治理', '数据范围', '只看自己', '部门数据', '页面权限', '字段权限', '查询参数权限'],
     mustAsk: [
-      '角色清单及成员来源：固定成员、组织部门、外部角色',
-      '页面、菜单、公开路由分别开放给哪些角色',
-      '每个表单的 submit/view/manage 操作和字段权限',
-      '数据范围是全部、本人、部门、自定义条件还是公开 grant',
-      '验收时需要模拟哪些角色和拒绝场景',
+      '权限模式选择：managed-platform-account、existing-platform-user-assignment、static-role-permission、query-param-context 中哪一种，为什么',
+      '账号来源是什么：应用创建平台账号/部门、选择已有平台用户、固定角色成员，还是仅使用低风险查询参数上下文',
+      '是否创建或维护平台账号/部门；如果是，哪些 App Function/organization SDK 负责创建、更新、重置密码和同步审计',
+      '角色成员如何维护：角色分配表、平台角色手工维护、静态 roles manifest、还是公开访问 externalRoleCodes',
+      '哪些角色可以设置应用角色、分配角色成员、给角色分配接口权限；这些角色是否需要 `app:role:manage`',
+      '哪些角色可以维护页面权限组、表单权限组、组织账号；是否需要 `app:page-permission-group:manage`、`app:form-permission-group:manage`、`app:organization:manage`',
+      '业务范围字段是什么，哪些可见字段需要派生隐藏 scalar key 供表单权限条件匹配',
+      '页面/菜单/路由、表单 submit/view/manage/fieldAccessPolicy/dataScope 的权限矩阵如何落到 resources',
+      '查询参数是否参与授权；如果参与，只能做上下文、筛选或 ticket 输入，敏感数据必须由 public-access grant、角色、表单权限组或 App Function 校验',
+      '验收时需要模拟哪些角色、账号状态、业务范围、查询参数篡改和拒绝场景',
     ],
     recommendedDefaults: [
-      '角色写 src/resources/roles，页面组写 permissions/page-groups',
-      '表单权限组写 permissions/form-groups，显式声明 dataScope/operations',
-      '公开访问不要复用内部管理员权限组',
+      '正式后台优先选择 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',
+      '能管理角色或给别人分配角色的应用角色必须在 roles manifest 声明 apiPermissionCodes；至少包含 app:role:manage，按需加入 app:page-permission-group:manage、app:form-permission-group:manage、app:organization:manage',
+      '由校区管理员等委托管理员创建的新角色，如果还具备继续管理账号/角色/权限的能力，也必须同步声明并发布对应 apiPermissionCodes',
+      '账号治理闭环使用 organization_unit、system_account、role_assignment 等业务表，加 roles、page groups、form groups、sync App Functions 和 PermissionBoundary',
+      '平台账号创建、更新、重置密码只走 sdk.organization/ctx.organization；操作者必须具备 app:organization:manage',
+      '公开访问不要复用内部管理员权限组；公开数据仍需 public-access grants 与外部角色权限组双重覆盖',
     ],
     antiPatterns: [
+      '不能只做前端权限隐藏，必须有后端角色、表单权限组、public-access grant 或 App Function 校验',
+      '查询参数不能作为敏感授权依据，只能作为上下文、筛选或 ticket 输入',
       '只配菜单可见，不配后端数据权限',
       '为了省事授予全部数据再在前端过滤',
+      '在页面里硬编码角色、账号、部门或权限范围',
+      '只给用户挂业务角色但没有给该角色绑定角色设置接口权限，导致后续新增账号/角色时运行时报无权限',
+      '让普通管理员创建带管理能力的新角色，但没有同时发布新角色的 apiPermissionCodes',
+      '前端模拟权限通过、mock role、假账号、假 ID 或空数组兜底',
+      '直接绕过 SDK 调平台账号/组织写接口，或用旧 /user、/department 接口写账号',
       '公开角色和内部角色混用',
     ],
     acceptance: [
       'permission audit 输出无高危缺口',
+      '设计文档写明权限模式、账号来源、角色成员来源和权限矩阵',
+      '角色资源中声明了管理型角色的 apiPermissionCodes，并说明由谁首次授予',
       '内部角色允许项可用，未授权项拒绝',
+      '用非授权角色验证角色创建/成员分配/权限组维护会被拒绝，用授权角色验证可成功',
+      '敏感 App Function 包含服务端 role/scope checks，且不信任页面传入的 roleCodes',
+      '平台账号治理路径验证当前操作者拥有 app:organization:manage',
+      '查询参数篡改不会扩大敏感数据访问范围',
       '公开访问受 public-access grant 和权限组双重约束',
     ],
   },
@@ -236,6 +259,13 @@ const DESIGN_GATE_TOPIC_ALIASES = {
   permission: 'permissions',
   role: 'permissions',
   roles: 'permissions',
+  rbac: 'permissions',
+  'role-governance': 'permissions',
+  'account-permission': 'permissions',
+  'organization-account': 'permissions',
+  'org-account': 'permissions',
+  'account-role': 'permissions',
+  'query-param-permission': 'permissions',
   workflow: 'workflow-automation',
   automation: 'workflow-automation',
   function: 'workflow-automation',