Skip to main content
访问控制决定团队里每位成员能做什么、能在哪里做。每个 API Key 都以创建它的成员身份行事，所以同一套规则也决定了 Key 能做什么。通过这组接口，您无需打开控制台就能管理这些规则。

​
权限如何确定

1

角色

每位成员有一个角色。内置角色是 tenant_owner、tenant_admin 和 tenant_member，您也可以添加自定义角色。一个角色包含一组操作，例如 project:modify、member:invite。列出角色返回团队的角色，权限目录列出所有可以授予的操作。
2

权限规则

一条权限规则为某个自定义角色或某位成员额外允许一个操作。内置角色不可更改。
3

用户组

用户组把一组权限（以及可选的资源列表）打包，授予加入该组的每位成员。
4

访问范围

访问范围把角色收窄到某类资源中列出的那几个，例如只允许访问团队的两个工作空间。访问范围只做限制，不会授予超出角色的权限。没有设置访问范围的资源类型不受限。
5

资源访问权限

在单个资源上，您可以给成员设置权限级别（read、write 或 manage），也可以把该资源加入某人受限的访问范围。见下文资源访问权限。
要查看某位成员或某个用户组的最终结果以及每项权限的来源，请使用查看成员有效权限或查看用户组有效权限。要确认您自己的 Key 能做什么，请使用列出我的权限。

​
资源访问权限

可以按单个资源共享的各类资源，都使用同一组资源访问接口。路径中给出资源类型和资源 ID：

​
条件写入

整体替换一份列表的写操作（访问范围、用户组的权限）会返回 ETag 响应头。下次写入时把它放进 If-Match：如果这期间有人改过这份列表，写入会以 412 被拒绝，且不做任何改动。

​
保护管理员

有些改动会影响管理员能做的事：让某人成为管理员，或缩小管理员的访问范围。这类改动只能由团队所有者或管理员执行。其他人尝试时请求会以 403 被拒绝，错误中的 data.operation 指明是哪类改动，参见错误码。