用户组

用户组是 OPL 数据空间中大规模组织用户与访问控制的核心机制，主要承担两个角色：

1. 权限管理：把细粒度权限高效地授予多名用户
2. 资源访问控制：控制谁可以访问特定的私有资源，例如模型、知识库、Tools

在组织感知部署中，要注意：group 不等于 organization。Group 用于管理权限和协作规则；组织定义的是租户边界。

权限合并逻辑

OPL 数据空间的权限是**叠加式（Union-based）**的。

• 用户属于多个组时，会获得这些组权限的并集
• 如果 Group A 允许图像生成，而 Group B 不允许，那么同时属于两组的用户仍然会拥有图像生成能力
• 没有 “Deny” 权限，只有 “Grant” 权限

Group 管理

用户组可在 管理员面板 > Groups 中管理。

组配置

创建或编辑用户组时，可以配置它在系统中的共享可见性：

• Who can share to this group
  • Anyone：任何用户都能在 Access Control 菜单里看到它，并把资源共享给这个组
  • Members：只有已经属于该组的成员，才会在共享菜单中看到它
  • No one：对非管理员完全隐藏，不出现在共享菜单中

策略：权限组 与 共享组 分离

建议把组按用途分成两类：

1. Permission Groups

   • 用途：只负责授予能力，例如图像生成、网页搜索、API Keys
   • 配置：Who can share 设为 No one
   • 好处：技术型权限组不会污染共享菜单

2. Sharing Groups

   • 用途：按团队、项目组织人，例如 Marketing、Engineering、Team Alpha
   • 配置：Who can share 设为 Members 或 Anyone
   • 最佳实践：尽量不要把功能权限也混在这些组里

这样做的意义在于：如果以后你要全局撤回某个功能权限，只要改默认值或对应 Permission Group 即可，不必逐个清理所有团队组。

组的创建方式

• 手动创建：管理员在 UI 中新建用户组并分配成员
• OAuth 同步：启用 ENABLE_OAUTH_GROUP_MANAGEMENT 后，可以从 OAuth provider 同步用户组
  • ENABLE_OAUTH_GROUP_CREATION=true 时，系统可自动创建本地不存在的组
  • 同步登录时，用户会被严格加进 / 移出与 OAuth claim 对应的组

组结构

一个典型用户组包括：

• Name：组显示名称
• Description：组用途说明
• Permissions：覆写默认用户权限的 JSON 配置
• Members：属于该组的用户 ID 列表

给组分配权限

编辑某个组时，可以打开或关闭具体权限。

• 默认状态：组默认不会额外授予任何权限
• 授予方式：某项权限一旦在组里被打开，该组所有成员都会拥有它，即便全局默认值是关闭的

用组做资源访问控制

你可以通过 Group 或单用户授权来限制某个具体资源（如专有模型或敏感知识库）的访问。

1. 在创建或编辑资源时，把可见性设为 私有 或 Restricted
2. 指定哪些 Groups 或单个用户拥有 Read / Write 访问

模型绑定知识库的作用域

除了可见性之外，知识库访问还会受到模型自身绑定关系影响。一个模型如果已经绑定了特定知识库，它通常只会访问这些知识库，而不是用户全部可见知识库。详见 知识库作用域说明。

Access Grant 的底层逻辑

从底层实现看，资源访问是通过标准化的 access grants 记录到数据库中的。每条 grant 会说明：

• Resource：资源类型与资源 ID
• Principal：获得访问权的是某个 group 或某个 user
• Permission：访问级别，通常是 read 或 write

例如，如果你把某个模型授予 Marketing 组 read 权限，同时授予某个编辑用户 write 权限，数据库里就会有两条独立 grant 记录。

• Read：可以查看并使用资源
• Write：可以更新或删除资源