权限开发

将每个业务权限定义为独立 PERMISSION 资源，用完整 Locator 连接角色授权与 Module 方法。

每个业务权限是一个独立的 PERMISSION 资源，不需要额外的权限定义集。Bundle 组合多个权限和角色，权限本身独立创建不可变版本。它不启动进程，但仍要安装到 Application Runtime 才能作为有效权限参与授权。

本文描述单资源契约。CLI 命令和参数以本机逐级 --help 为准；权限、资源归属及内容协议由服务端在执行请求时校验。

稳定身份与定义

权限身份为完整 environmentKey/bundleId/PERMISSION/resourceKey，来源和 key 使用 Owner 返回值。 displayName、分类和排序只影响展示，不构成身份。示例中的 Module Locator 需替换为实际资源：

{
  "displayName": "查看客户",
  "description": "查询客户资料",
  "categoryPath": [
    {"key": "crm", "displayName": "客户管理", "sortOrder": 10}
  ],
  "sortOrder": 10,
  "methodTargets": [
    {"moduleLocator": "example-origin/example-crm/MODULE/customer", "methodName": "getCustomer"}
  ]
}

categoryPath 是展示分组的完整路径，key 相对于权限所属 Bundle；分类不是单独的安装资源。
methodTargets 使用完整 Module Locator 和精确 methodName，不使用 Runtime businessId，也不能将旧 permissionCode 猜成方法名。
一个权限可以覆盖多个方法；分类 key、方法目标不能重复。空分类路径和空方法目标列表合法。
ROLE.grants 引用本权限的完整 Locator；权限定义不保存哪些成员获得权限。
定义不再使用 permissions 集合、serviceId 或 permissionCode 作为新权限身份。

创建、编辑和交付

将定义保存为 permission.json，使用支持通用资源作者入口的 CLI：

baijimu bundle resource create <bundle> --workspace-id <workspaceId> \
  --resource-type PERMISSION --resource-key customer-read --definition @permission.json
baijimu bundle resource get <bundle> --workspace-id <workspaceId> \
  --resource-type PERMISSION --resource-key <ownerReturnedResourceKey>
baijimu bundle resource update <bundle> --workspace-id <workspaceId> \
  --resource-type PERMISSION --resource-key <ownerReturnedResourceKey> --definition @permission.json
baijimu bundle resource version create <bundle> --workspace-id <workspaceId> \
  --resource-type PERMISSION --resource-key <ownerReturnedResourceKey> --version <exactVersion>
baijimu bundle manifest include-resource <bundle> --workspace-id <workspaceId> \
  --file baijimu.bundle.json --resource-type PERMISSION \
  --resource-key <ownerReturnedResourceKey> --version <exactVersion>

创建时必须由用户指定 resourceKey，Owner 原样保存并返回；省略、空值或非法 key 会被拒绝，作者清单使用当前清单协议的 definition.resources。通过在线预检后审查和提交 Git，创建 Bundle 版本并安装或升级。离线 Schema 验证不能证明方法存在、引用已获授权或目标环境已安装。

角色授权与调用

身份、配置权限、业务权限、服务来源认证与用户委托的选择见权限决策表。

角色定义的 grants 直接引用权限：

{
  "roleName": "销售",
  "description": "处理客户资料",
  "grants": ["example-origin/example-crm/PERMISSION/customer-read"]
}

权限 Owner 校验角色引用的资源和方法目标，Runtime 编排按依赖使权限与角色生效。成员分配、工作区角色和主体直接授权属于工作区运行数据，不写进权限定义。能力可发现不等于有权调用；实际执行还要经过成员身份、角色或直接授权等鉴权检查。

Bundle 作者清单不接受旧 requestedPermissions / providedPermissions 字段；权限必须声明为独立资源，服务调用凭据和 Secret 也不属于本权限目录。

PERMISSION_DEFINITION_SET 与 serviceId + permissionCode 是旧集合模型。升级需要显式拆分每个权限、保留完整分类路径，并为每个方法目标提供 Module 与方法的真实映射，再迁移角色 grant、主体授权和其他引用。不得仅改类型名称、改写历史不可变版本或把未解析引用丢弃。旧集合的创建、更新和版本发布入口已经关闭。历史集合目录只返回旧集合；独立权限使用登记的 PERMISSION Owner 目录。读取和移除历史资源仍按原身份处理，不能把旧集合 Locator 改写成新权限身份。

稳定身份与定义

创建、编辑和交付

角色授权与调用

历史合同迁移

本页内容