角色与授予
Owner、Editor、Viewer 三种角色,四档开放程度;Object Type 继承父资源权限,只有 Owner 能改分享。

本课目标
读完这一课,你将能够
- 说出 Owner、Editor、Viewer 各自能做什么,并解释「访问」与「角色」的区别
- 说出四档开放程度,并解释 Object Type 如何继承父资源权限
- 设计谁能执行
approve-purchase-order,说清角色、roles与提交条件各管哪一层
先有访问,再有角色
上一节把控制分成强制与自主两类,这一节讲自主控制里最常用的一种:角色。官方把权限拆成两步。第一步是「访问」:你能不能知道这个资源存在,由组织、 Markings 这类强制要求决定。第二步才是「角色」:满足访问要求之后,你能拿它做什么。
拿示例工厂来说:外部审计师所在的公司没有被分享,他连 purchaseOrder 存在都不知道,这是访问没有通过。采购员是本组织的成员,看得到 purchaseOrder,但只有 Viewer,改不了,这是角色不够。两种情况,要补的东西完全不同。
- 01Viewer(查看者)查看、使用
- 02Editor(编辑者)还能改内容、执行 Action;不能改分享
- 03Owner(所有者)还能改分享与访问设置、加别的 Owner、删除分享只有它能改
角色是一组操作,不是头衔。本体(Ontology)上的角色继承到每个 Object Type。类型自己的授予只能加,不能减;Object Type 不能单独设为 Private。本组织开发者是 Owner,但仍受 Markings 约束。
开放程度:从窄到宽
Private(私有)
只有 Owner。
Group(指定范围)
指定的人、部门,或整个本组织;邀请链接也属于这一档。
Public(登录即可读)
所有登录的 AIDC 账号,只读,不含匿名;只能给 Viewer。
Open to Internet(不登录也可读)
任何人不登录只读。文件、应用、组织 Applications 和 Space 条目支持;只有 Owner 能开。
- 只有 Owner 能改分享:授予、收回、生成邀请链接、改开放程度,都是 Owner 的事。Editor 能改内容,却不能把内容分享出去,扩大受众只有 Owner 能拍板。
- Public 与 Open to Internet 只能给 Viewer:所有人都能改的东西不该存在。
- Open to Internet 只管读取:开放应用内的 Custom widget 可调用允许的匿名读接口。匿名访客不能执行 Action,也不能查询 SQL。
在示例工厂里,可以把 supplier 的 Viewer 授予整个本组织。也可以把客户信用数据分享给财务组,再用列策略限制信用额度。Object Type 继承父资源权限,不能单靠少授予来收紧继承权限。
aidc resources share <rid> --user <账号 id> --role editor
aidc resources share <rid> --group <财务组 id> --role viewer
aidc resources unshare <rid> --user <账号 id> --role editor
aidc resources link <rid> --days 7
上面四条命令依次是:授予一个人 Editor,授予财务组 Viewer,收回一条授予,生成 7 天有效的邀请链接(缺省 30 天)。只有 Owner 能改分享。
示例:谁能执行 approve-purchase-order
在示例工厂里,采购主管批准采购订单。「谁能批准」不是一个开关,而是三层依次把关:
- 身份与角色
先验证身份与权限。Viewer 和匿名访客不能执行 Action。Agent Key 可按主体权限和 restrictions 执行获准 Action。
- Action 自己的 roles
定义里的
roles可以再收窄允许的角色,缺省是 developer、member、editor。 - 提交条件
按参数、对象属性、当前用户判断,不满足就返回你写的失败信息。这是最细的一层。
三层是「与」的关系,任何一层不过,就执行不了。所以别指望角色去表达「这一张订单」这样的细节:角色回答「你能不能做这一类事」,提交条件才回答「这一张你能不能做」。
AIDC 已有 Groups。可以建采购主管组,维护成员,再把资源分享给组。下面的提交条件另管一件事:订单创建人不能批准自己的订单。ownerId 记录创建人。
{
"kind": "actionType",
"apiName": "approve-purchase-order",
"title": "批准采购订单",
"schema": {
"parameters": [
{ "name": "purchaseOrder", "type": "object", "objectType": "purchaseOrder", "required": true }
],
"rules": [{ "type": "modifyObject", "objectType": "purchaseOrder", "object": "$purchaseOrder", "values": { "status": "approved" } }],
"submissionCriteria": [{
"condition": { "type": "comparison", "left": { "user": "id" }, "operator": "isNot", "right": { "param": "purchaseOrder", "property": "ownerId" } },
"failureMessage": "不能批准自己创建的采购订单"
}],
"actionLog": true
}
}
提交条件里,user 取当前执行人,param 取参数或参数对象的属性,literal 是写死的值。先用 aidc semantic apply approve-purchase-order --param purchaseOrder=PO-1001 --validate-only 试一次,再正式提交。
要点
- 先有访问、再有角色:访问由组织与 Markings 这类强制要求决定,角色决定拿资源做什么。
- AIDC 有 Owner、Editor、Viewer 三种角色;只有 Owner 能改分享,Editor 能改内容、执行 Action。
- 开放程度从窄到宽:Private、Group、Public、Open to Internet;Public 与 Open to Internet 只能给 Viewer。
- 角色沿 本体 继承到 Object Type,只加不减;本组织开发者是 Owner,但仍受 Markings 约束。
- 谁能执行一个 Action,由身份与角色、
roles、提交条件三层依次把关。
练一练
为示例工厂设计一张授予表
角色少,靠设计才能用好。先在纸上定,再用命令核对。
为采购员、采购主管、销售、质量、财务,在 supplier、purchaseOrder、customer 上各定 Viewer、Editor 或不授予。标出哪几处只有 Owner 才设得了。
在上面的定义里再加一条:只有 status 等于 pending 的采购订单才能被批准。写出这一条的 condition 与 failureMessage。
对你的一个 Object Type 跑 aidc resources roles RID,看有哪些授予、哪些是继承来的,判断你会收回哪一条。
小测
选一个答案,马上看解析。
Q1你是某个 Object Type 的 Editor,想让隔壁部门的同事也能看它。你能做什么?
只有 Owner 能改分享。改成 Public 也是改分享,而且会让所有登录的 AIDC 账号都看得见。
Q2要求「谁创建的采购订单,谁不能批准它」。最合适的写法是?
角色只回答「你能不能做这类事」,「这一张订单你能不能批」要看数据,得用提交条件。
Q3Public 这一档最多能给什么角色?
Public 与 Open to Internet 只能给 Viewer:所有账号都能改的东西不该存在。