权限由平台执行，不用每个系统各写一遍。

应用声明自己有哪些对象、操作和权限点；平台按部门、角色、数据范围和字段规则统一判定；组织在自己的角色里决定谁能做什么。同一条记录，不同的人看到不同的那一份，助手也一样。

预约演示角色与权限

Declare, enforce, customize

权限分三步：应用声明，平台执行，组织定制。

应用不实现权限判定。对象引擎、平台的数据接口和应用 SDK 在同一处判定，判定的输入是成员、部门、角色、资源、动作和数据属性。

应用声明

清单里写对象（entities）、操作（ops）和权限点（permissions），随版本审核。

应用不建自己的授权表。

平台执行

部门、角色、权限点、数据范围、字段规则由平台判定。

数据范围在 SQL 里过滤，范围外的记录回答「不存在」（404）。

组织定制

管理员在「权限 → 业务角色」里定义角色，分配权限点、数据范围和字段规则，再开启「精细权限」。

在「我的组织」里打开业务角色

manifest.json（节选）

{
  "protocol": "k3/1", "id": "crm", "version": "1.2.0", "level": 3, "name": "客户",
  "nav":      [{ "label": "客户", "route": "/customers" }],                 // Agent 只能链接到这里声明的页面
  "entities": [{ "type": "customer", "route": "/customers/{id}", "listRoute": "/customers",
                 "filterable": { "stage": ["lead","won"] },                  // app_read 能按这些字段筛
                 "context": { "redact": ["phone"] } }],                      // 对 Agent 读取打码的字段
  …
  "opsApi": "/k3", "dryRun": "full",
  "permissions": [{ "id": "crm.write", "label": "编辑客户" }],
  …
}

对象、打码字段与权限点都写在清单里开发文档 →

GET /app/v1/access

acc, err := c.App.Access.Check(ctx, &raise.AppAccessCheckParams{Point: "app.shop-sync.orders.read"})
if err != nil {
	return err
}
fmt.Println(acc.Allowed, acc.Units)

结果与数据范围由平台给出应用接口 →

Scope & fields

数据范围细到部门，字段可以遮盖或隐藏。

五种数据范围
本人、本部门、本部门及下级、全部、指定部门。总数、分页和游标都遵守范围。
字段规则
字段可以遮盖，也可以整个隐藏。受限字段不能写，也不能当筛选或排序条件，避免反推。
多个角色叠加
范围取并集；字段只有在每个可读角色都限制时才受限，取较轻的一种。
导出也是一次读取
只带范围内的行，遮盖的字段保持遮盖，隐藏的字段连列名都没有。
管理员与审计员
开启精细权限后，成员只看到角色授予的数据；管理员不会被锁在外面，审计员只读全部。
助手是成员权限的子集
助手以成员本人的范围读取，字段规则同样生效；它只读和起草，什么都不直接写。

Runtime checks

应用在运行时向平台问权限，一次最多 100 个权限点。

应用自己的页面和服务也要知道「这个人能不能做」。答案来自平台，与组织的角色设置一致。

单个判定。GET /app/v1/access 回答调用者在本应用一个权限点上的结果与数据范围。
批量判定。POST /app/v1/access/points 一次问 1 到 100 个权限点，答案与逐个调用相同，不缓存。
SDK 里现成。Go SDK 的 AccessMany 与 Authz.CheckMany。
找人也按范围。GET /app/v1/org/members 只列出调用者数据范围内的成员，不含联系方式。

应用接口

谁在问	得到什么
应用自己的令牌	清单 uses 里写的范围，在每个安装了它的组织里自带
页面会话里的成员	这位成员在本应用权限点上的范围
缺少范围	HTTP 403，错误码 scope_required

Resource access

共享、继承和到期由平台的访问内核保管。

图表、看板、文件夹、敏感记录这类「单个资源给谁看」的名单，应用在清单的 resources 里声明类型，名单只在平台的访问内核里改。

应用不自己做分享界面或访问控制表，门禁会检查。

查看、评论、编辑、管理。取最大，没有拒绝项；授权不超过授权人自己的级别；所有者恰好一个，可以转让。
树形资源继承，授权可以限时。文件夹下的节点继承上级名单，可以停止或恢复继承；限时授权到期即不生效。
访问申请由决定人审批。成员可以申请访问，决定人批准或拒绝。名单变化后，平台向资源所属的应用发 access.changed。

分享「门店看板」

谁能访问

周明（你）所有者
华东区（含下级）可查看来自「区域报表」
陈静可编辑到 11 月 30 日

通用访问

仅受邀的人

只有上面名单里的人能打开完成

示意

平台提供统一的分享对话框；助手对资源只读，范围外的资源一律 404，不泄露是否存在。接口说明

Three layers

开发者看不到组织的数据。

组织、开发者、平台三层的数据互相隔离。应用的代码运行时会处理组织的数据，所以平台把它当作不可信的第三方：

数据只经平台接口；
凭据短期有效；
出网默认拒绝。

层	里面有什么	谁能看
组织	业务数据、成员、组织架构、角色、安装配置、审计	组织自己；平台只在组织批准时限时、只读进入
开发者	应用代码、版本、清单、模板、市场资料、收款与分账	开发者；平台审核人员
平台	账户与计费、许可证、市场目录、运行遥测	平台运营，按角色

开发者没有生产环境 shell、没有数据库凭据，看不到原始日志与请求内容；拿到的只有应用级指标和脱敏错误。安全与信任

用组织真实的部门和角色看一遍权限。

约一次演示，按组织的部门树和角色配一遍：同一条记录，前台、康复师、店长和助手各看到什么。

预约演示开发文档