Access Control Reference

Capgo 使用 基于角色的访问控制（RBAC） 来管理每个团队成员可以做什么。角色按 范围 — 从整个组织到单个捆绑包。

For a visual walkthrough of managing members in the dashboard, see __CAPGO_KEEP_0__ 组织.

---

角色权限

每个角色都属于一个范围，决定它可以访问的资源。

范围	适用范围	示例用例
组织	整个组织及其所有应用	你的合伙人获得超级管理员；你的会计获得Billing Manager
应用	一个应用及其通道	一个开发者在一个应用上工作，会获得 App Developer
通道	一个应用中的一个通道	一个 QA 工程师只管理一个 staging 通道
捆绑包	一个捆绑包版本	一个需要读取一个特定发布的审阅者

一个成员可以在 一个范围目标中持有 一个角色，例如一个组织角色，一个 App A 角色，和 App B 上的不同角色。

---

组织角色

邀请成员时分配的角色，赋予对整个组织的访问权限

角色	内部名称	描述
超级管理员	org_super_admin	拥有全权，包括删除组织、管理账单、转移应用。自动授予组织创建者
管理员	org_admin	拥有完全管理权限，包括管理成员、应用、频道。无法删除组织、更新账单、转移应用或提升用户为超级管理员
账单管理员	org_billing_admin	仅有账单访问权限：查看和更新账单信息、发票和账单审计日志。无应用或成员访问权限
成员	org_member	只读访问组织和所有应用。

组织权限矩阵

权限	描述	超级管理员	管理员	账单管理员	成员
org.read	查看组织	✅	✅	✅	✅
org.update_settings	编辑组织名称、Logo、管理邮箱	✅	✅	❌	❌
org.delete	永久删除组织	✅	❌	❌	❌
org.read_members	查看成员列表	✅	✅	❌	✅
org.invite_user	邀请新成员	✅	✅	❌	❌
org.update_user_roles	修改成员角色（管理员无法提升为超级管理员 — 角色层级阻止）	✅	✅	❌	❌
org.read_billing	查看账单信息和当前计划	✅	✅	✅	❌
org.update_billing	更新支付方式和计划	✅	❌	✅	❌
org.read_invoices	查看发票	✅	✅	✅	❌
org.read_audit	查看组织活动日志	✅	✅	❌	❌
org.read_billing_audit	查看账单相关审计日志	✅	✅	✅	❌

注意

组织角色继承了应用、频道和包角色下方的所有权限。一个 超级管理员 可以做所有的 应用管理员 或 频道管理员 可以做的所有事情，跨所有应用和频道。

---

应用角色

仅限于一个应用。使用这些角色时，团队成员只应在一个应用中工作，而不是整个组织。

角色	内部名称	描述
App 管理员	app_admin	__CAPGO_KEEP_0__
App 开发者	app_developer	上传包裹、管理设备、触发原生构建、更新渠道设置。无删除、无应用设置修改、无渠道创建。
App 上传者	app_uploader	读取访问 + 上传新包裹版本。
App 阅读者	app_reader	只读 — 统计、包裹、渠道、日志、设备。

App 权限矩阵

权限	描述	App 管理员	App 开发者	App 上传者	App 阅读者
app.read	查看应用详细信息、统计和元数据	✅	✅	✅	✅
app.update_settings	编辑应用设置	✅	❌	❌	❌
app.read_bundles	查看已上传的包列表	✅	✅	✅	✅
app.upload_bundle	上传新包版本	✅	✅	✅	❌
app.create_channel	创建新频道	✅	❌	❌	❌
app.read_channels	查看频道	✅	✅	✅	✅
app.read_logs	查看更新分发日志	✅	✅	✅	✅
app.manage_devices	分配、覆盖或解除绑定设备	✅	✅	❌	❌
app.read_devices	查看设备列表	✅	✅	✅	✅
app.build_native	触发本地云构建	✅	✅	❌	❌
app.read_audit	查看应用级活动日志	✅	✅	✅	✅
app.update_user_roles	管理应用范围角色分配	✅	❌	❌	❌
bundle.delete	删除一个捆绑包	✅	❌	❌	❌

注意

app.delete 并且 app.transfer 是 组织级操作 — 只有 org_super_admin 无论应用级角色如何，都可以执行它们

---

频道角色

仅限于一个频道。有助于为特定的发布频道提供目标访问。

注意

当前频道角色功能 仅通过 API 和 CLI 可用 — 在控制台中没有 UI 来分配它们。在控制台中， 请使用频道权限覆盖 代替以细化每个用户的频道访问。

角色	内部名称	简介
频道管理员	channel_admin	完全控制一个频道：设置，推广/回滚捆绑包，管理强制设备。
频道浏览器	channel_reader	只读 — 当前捆绑包，历史记录，强制设备，审计日志。

频道权限矩阵

权限	简介	频道管理员	频道浏览器
channel.read	查看频道及其当前捆绑包	✅	✅
channel.update_settings	编辑频道设置（平台开关，更新策略…）	✅	❌
channel.delete	删除频道	✅	❌
channel.read_history	查看捆绑包分配历史	✅	✅
channel.promote_bundle	在频道上设置活动捆绑包	✅	❌
channel.rollback_bundle	回滚到之前的捆绑包	✅	❌
channel.manage_forced_devices	强制特定设备使用此频道	✅	❌
channel.read_forced_devices	查看强制设备列表	✅	✅
channel.read_audit	查看频道活动日志	✅	✅

---

捆绑包角色

仅限于单个捆绑包版本。很少需要 — 大多数团队使用应用级别角色代替。

注意

目前角色捆绑包仅在 __CAPGO_KEEP_0__ 和 __CAPGO_KEEP_1__ 中可用 via API and CLI only 角色

内部名称	描述	捆绑包管理员
读取、更新元数据和删除特定捆绑包	bundle_admin	捆绑包查看者
对特定捆绑包的只读访问	bundle_reader	渠道权限覆盖（控制台）

---

渠道权限覆盖（控制台）

在仪表盘中，用户的应用角色默认决定了通道访问权限。为了更细致的控制，您可以 override specific channel permissions 为每个用户或组单独设置通道权限，而不改变他们的应用角色。

Overrides 是从应用的 Access 选项卡中配置的，通过点击用户旁边的通道权限按钮（shield icon）来配置。请参阅 Organization — Overriding channel permissions 了解详细步骤。

Overridable permissions

权限	描述	默认行为
阅读	__CAPGO_KEEP_0__和当前包	从应用角色继承
历史	__CAPGO_KEEP_0__分配历史	从应用角色继承
__CAPGO_KEEP_0__	设置或更改通道的活动包	从应用角色继承

每个权限可以设置为:

• Default — 从应用角色继承（默认）
• 允许 — 无论应用角色如何，explicitly 授予
• 拒绝 — 无论应用角色如何，explicitly 拒绝

这让您可以，例如，给 App Reader 权限将 bundles 关联到 channel 上，而不将它们提升为 App Developer。 staging 角色层级

---

Section titled “角色层级”

继承所有权限__CAPGO_KEEP_0__。 __CAPGO_KEEP_0__ 的子项。 这意味着一个 org_admin 可以做一个 app_admin 可以，反过来又可以做一个 channel_admin 可以，依此类推。

Super Admin (org_super_admin)
  └── Admin (org_admin)
        └── App Admin (app_admin)
              ├── App Developer (app_developer)
              │     └── App Uploader (app_uploader)
              │           └── App Reader (app_reader)
              ├── Bundle Admin (bundle_admin)
              │     └── Bundle Viewer (bundle_reader)
              └── Channel Admin (channel_admin)
                    └── Channel Viewer (channel_reader)

实际操作中的工作原理：

• 一个 管理员 在组织级别可以做一个 应用管理员 可以在组织中的每个应用上做一个
• 一个 App 管理员 在某个应用中可以做到所有一个 频道管理员 可以在该应用中的每个频道中做到所有一个
• 一个 应用开发者 可以做到所有一个应用上传者可以做到，plus 更多 管理层级别只会 向下

— a __CAPGO_KEEP_0__ __CAPGO_KEEP_1__ channel_admin 无论他们是否还持有应用级别角色,他们也不会获得组织级别权限。

---

组

您可以创建组,而不是为每个用户分配角色,并将角色赋予组。组中的每个成员都会自动继承这些角色。 组的工作原理 关于组的工作原理

一个组属于

• 它不能跨越多个组织。 组可以在其中持有角色绑定 组
• 关于组 任何范围: 组织、应用、频道或捆绑包。例如，一个组可以被赋予 App 开发者 角色在 App A 上，并且 频道管理员 角色在 App B 的频道上。 staging 当用户的权限被评估时，所有他们的组成员身份都会透明地被解析。如果他们的任何组授予所需的权限，访问将被允许。
• 一个用户可以属于
• 多个组 , 并且所有组的权限都是累积的。基于组的权限仅适用于
• App 开发者 用户主体 — API 键不继承组角色。

使用组的时机

场景	没有组	有组
5 名 QA 工程师需要对 3 个应用程序拥有开发者访问权限	15 个单独的角色绑定	1 组 + 3 个角色绑定
有人加入 QA 团队	手动添加 3 个角色绑定	添加他们到组中
有人离开QA团队	手动删除3个角色绑定	从组中移除他们

通过API管理组

所有组端点都需要身份验证并在 /private/groups.

列出组

curl -X GET "https://api.capgo.app/private/groups/<ORG_ID>" \
  -H "authorization: <API_KEY>"

需要 org.read_members 权限.

创建组

curl -X POST "https://api.capgo.app/private/groups/<ORG_ID>" \
  -H "authorization: <API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "QA Team",
    "description": "Quality assurance engineers"
  }'

需要 org.update_user_roles 权限（超级管理员 或 管理员).

更新组

curl -X PUT "https://api.capgo.app/private/groups/<GROUP_ID>" \
  -H "authorization: <API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "QA Team",
    "description": "Updated description"
  }'

删除组

curl -X DELETE "https://api.capgo.app/private/groups/<GROUP_ID>" \
  -H "authorization: <API_KEY>"

删除组也会移除所有其角色绑定。成员不会从组织中删除。

列表组成员

curl -X GET "https://api.capgo.app/private/groups/<GROUP_ID>/members" \
  -H "authorization: <API_KEY>"

将成员添加到组

curl -X POST "https://api.capgo.app/private/groups/<GROUP_ID>/members" \
  -H "authorization: <API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{ "user_id": "<USER_UUID>" }'

用户必须已经是组织的成员。添加现有成员是无操作的。

从组中移除成员

curl -X DELETE "https://api.capgo.app/private/groups/<GROUP_ID>/members/<USER_UUID>" \
  -H "authorization: <API_KEY>"

注意

为组分配角色，请使用角色绑定API和 principal_type: "group" and principal_id 将设置为组 UUID。

---

通过 API Assigning 角色

成员列表

curl -X GET "https://api.capgo.app/organization/members" \
  -H "authorization: <API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{ "orgId": "<ORG_ID>" }'

响应：

[
  {
    "uid": "user-uuid",
    "email": "alice@example.com",
    "image_url": "https://...",
    "role": "org_admin",
    "is_tmp": false
  }
]

邀请成员

curl -X POST "https://api.capgo.app/organization/members" \
  -H "authorization: <API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "orgId": "<ORG_ID>",
    "email": "bob@example.com",
    "invite_type": "org_admin"
  }'

__CAPGO_KEEP_0__ invite_type:

接受的值	值
org_super_admin	分配的角色
org_admin	超级管理员
org_billing_admin	管理员
org_member	账单管理员

成员

curl -X DELETE "https://api.capgo.app/organization/members" \
  -H "authorization: <API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "orgId": "<ORG_ID>",
    "email": "bob@example.com"
  }'

---

通过 CLI Assigning roles

__CAPGO_KEEP_0__ 列表

npx @capgo/cli organization list --apikey <API_KEY>

复制到剪贴板

npx @capgo/cli organization members <ORG_ID> --apikey <API_KEY>

List members

The CLI 目前支持列出成员。要邀请成员或更改角色，使用以下 API 接口。

---

自定义角色

内置角色覆盖了大多数团队结构。自定义角色创建已在我们的路线图上 — 如果您的团队需要此功能，请 联系我们.您的用例将直接帮助我们优先考虑此功能。

继续阅读 Access Control Reference

如果您正在使用 Access Control Reference 来规划仪表板和 API 操作，请将其与 API Overview 为API概述的实现细节， 简介 为简介的实现细节， API密钥 为API密钥的实现细节， 设备 为设备的实现细节，和 捆绑包 为捆绑包的实现细节。