# 账号权限、协作与配额：团队视觉简报讲稿与事实索引

> 版本：v0 / 2026-08-05（历史快照，2026-08-14 起停止生效）
> 
> 定位：历史团队讨论材料，不代表本期最终方案。配套 PPTX 同样是 2026-08-05 静态快照，不应用于当前研发或验收。
>
> 当前生效结论请查看 `input_v0.md` 第 5 节、第 7.3 节和第 9.3 节，以及 `账号和权限功能设计梳理.md`。当前根模型为「组织身份与组内身份解耦 + 多组成员 + 单组项目 + 全局组身份切换」；对象协作采用唯一 Owner + Collaborator，协作者默认拥有模块常规业务读写，只读需求另用查看范围或显式查看授权。“组长默认成为组内所有项目协作者”是默认关闭的组织策略，开启后 T2 才以锁定系统来源成为本组普通 Collaborator。配额按 Scope 产品类型处理：仅可分配型 Scope 增加组和 GroupMembership 的 `inherit / capped`，其余随组织 Entitlement；跨境支付金额使用独立钱包与资金限制模型。
>
> 下文出现的“当前”“已确认”“新候选”均只表示 2026-08-05 当时的讨论状态，不能覆盖上述当前生效结论。

## 使用方式

- PPTX 是当时的会议展示版本，现仅用于追溯旧方案。
- 本文是当时的逐页讲稿、事实来源和开放问题索引，正文不再随当前方案更新。
- 颜色语义：蓝色=线上事实；绿色=已确认；橙色=待讨论；灰色=后置或范围外。

## 一页结论

当前线上已经有团队管理、权限管理、数据管理三个入口，也有角色、分组、配额、CRM 权限和邮件协作等基础能力，但各模块对“管理员 / 组长 / 成员 / Owner / 协作者”的解释不一致。

旧 Spec 的 T1-T2-T3 模型是当前实现设计基线：T1 不归组、T2/T3 唯一归组、每组 0..1 个 T2，T1 可通过隐式策略和特殊例外覆盖全组织。它适合简单组内管理，但无法自然表达“营销负责人 A 管多个平行组、老板 B 看全组织并参与工作、普通小团队无需复杂组织”的组合场景。

新候选方案是：组织身份与业务身份解耦，所有账号都有唯一所属分组，T2 账号通过显式管理范围管理一个或多个扁平分组，范围可以重叠，不引入嵌套组和当前组切换。当前建议是每组允许 0..N 名 T2 管理者，但这一点仍待团队确认。

## 线上全局现状

### 线上页面

线上 /brand/sub-account、/brand/sub-account/quota、/brand/sub-account/data 三个页面并列存在：
2
- 团队管理：成员、分组、角色、席位、邀请记录、操作记录。
- 权限管理：当期使用 / 累计使用、按账号额度配置，代码已有共享团队 / 账号上限和 inherit 雏形。
- 数据管理：CRM 四项写权限、邮件项目“强制添加管理员为协作人”。

2026-08-05 线上截图中，团队管理页显示 46 名成员、已用 45、待邀请 0、剩余 5、总席位 50；该数字是当前登录组织的截图事实，不应外推为全体客户数据。

### 代码事实

- adminStatus=0/1/2 当前对应成员 / 管理员 / 组长。
- 成员页和配额页部分使用 Boolean(adminStatus)，邮件项目的强制管理员协作只认 adminStatus=1。
- 当前邀请弹窗只提交邮箱，不能同时设置分组、模块可用性和配额。
- 当前成员清退没有统一的 Owner / ACL / 资产移交任务。
- CRM 线上四项权限由 crmDataManageCheckList 定义，保存通过 getDataManage/updateDataManage。
- 支付单 / 草稿当前前端没有可证明的统一 Owner、ACL、执行人和资金责任字段。

## 已确认事项

以下内容不依赖旧模型还是新候选：

1. 本轮主线为主子账号和权限；配额只做强关联项；数据导出完整进入 TODO。
2. 账号模块可用性和配额按账号直接配置，不把全部模块权限聚合进 T1/T2/T3。
3. 项目型对象使用 Owner / Editor / Viewer，显式协作至少落到具体项目、CRM 记录或支付单。
4. created_by、当前 owner_uid、实际 actorUid、资金责任账号分开保存。
5. 多来源权限取最高有效权限；模块、套餐、账号状态等硬限制优先。
6. Viewer 不可管理协作者或执行支付；附加能力不可传递。
7. 删除、Owner 转交、协作者管理、支付执行分别判断，不从普通 Editor 自动推导。
8. 项目不绑定独立 group_id，业务归属跟随 Owner 所属分组。
9. CRM 线上四项写权限只做等价迁移，不直接清空或重置。
10. 跨境支付本期不做个人支付额度，保持 shared；预约提交即形成资金承诺，责任归 Owner 快照。
11. 频道历史收款账号在组织内共享，支付单 / 草稿接入对象级协作者体系。
12. 成员转组 / 离职数据移交是必需的独立 P0 议题，支付模块先接口化假设其存在。

## 旧方案：T1-T2-T3

### 结构

- T1：组织所有者 / 超级管理员；不归正式组。
- T2：组长；每个正式组 0..1 名；只能有一个主分组。
- T3：普通成员；只能有一个主分组。
- 未分组 T3 进入隐藏分组。

### 业务效果

- T1 负责成员、分组、策略、账号配置，并可按策略获得组织级业务范围。
- T2 默认管理本组范围。
- T3 依赖自身模块准入、Owner 和显式对象协作。
- T1 可以作为跨组协作者或数据接收人，是普通成员跨组限制的例外。

### 主要问题

- 组织管理身份容易和业务高权限绑定。
- A 管多个平行组但不能看其他组的中间范围缺失。
- T1 不归组，T1 作为 Owner 时对象归属和普通协作者范围不自然。
- 主账号迁移可能附带业务权限变化。

## 新候选：扁平分组 + 管理范围

### 结构

账号拆成四个独立事实：

| 事实 | 含义 |
| --- | --- |
| 组织身份 | 所有者 / 管理员 / 普通成员 |
| 业务身份 | T2 / T3 |
| 所属分组 | 每个账号恰好一个，决定本人对象默认归属 |
| 管理范围 | T2 可管理的一个或多个扁平分组，允许重叠 |

### 候选规则

- 不建立嵌套组。
- 不引入当前组切换。
- 每个账号有且只有一个所属分组。
- 每组允许 0..N 名 T2 管理者。
- 一个 T2 可以管理 1..N 个分组，或选择全部分组。
- 组级业务权限由管理范围动态计算，不批量写入每个项目 ACL。
- 对象归属始终跟随 Owner 所属分组。

### 账号示例

| 账号 | 所属分组 | 管理范围 | 结果 |
| --- | --- | --- | --- |
| A 营销负责人 | 营销管理组 | 营销一组、营销二组 | 管理平行营销组 |
| B 老板 | 默认组 | 全部分组 | 查看和管理全组织业务 |
| C 组负责人 | 营销一组 | 营销一组 | 组内日常管理 |
| D 执行成员 | 营销一组 | 无 | T3，使用自身和对象协作权限 |

### 候选的主要争议

1. 每组 0..N T2 是否接受。
2. T2/T3 是独立字段，还是由是否存在管理范围推导。
3. 管理范围是固定能力包，还是允许逐项配置。
4. 管理范围是否包含项目级业务编辑，还是只包含汇总、配额和组级设置。
5. 管理范围账号是否允许成为其他组项目的显式协作者。
6. 所有者 / 管理员是否必须显式配置业务范围才能看到业务数据。

## 两套方案对比

| 维度 | 旧 T1-T2-T3 | 新扁平候选 |
| --- | --- | --- |
| T1 | 不归组，拥有组织管理和特殊业务例外 | 组织身份与业务范围分离 |
| 账号归属 | T2/T3 一组，T1 无组 | 所有账号一组 |
| T2 | 一组一名，T2 一组 | 多组管理，范围可重叠 |
| 对象归属 | T1 Owner 存在例外 | 所有 Owner 都能派生所属组 |
| 小团队 | 需要隐藏组解释 | 一个默认组即可 |
| A 管平行组 | 缺少中间范围 | 管理范围直接表达 |
| B 看全组织 | 依赖 T1 隐式权限 | 显式“全部分组”范围 |
| 技术变化 | 复用现有 leaderUid 方向 | 新增多对多管理范围关系 |
| 产品认知 | 角色少，但角色语义耦合 | 字段更多，但语义拆得更干净 |

## 影响评估

### 大体保留

- 账号级模块准入和配额。
- 组织 / 分组 / 账号配额层级与逐层消耗拦截。
- Owner / Editor / Viewer 和对象级 ACL。
- can_manage_collaborators、can_execute_payment 独立能力。
- 支付资金责任、审计、幂等、移交任务和通知框架。

### 需要重写

- OrganizationMember 的身份和所属组字段。
- OrganizationGroup.leaderUid 单值模型。
- T1/T2 动态范围权限来源。
- 协作者候选人与跨组限制。
- 成员邀请、组级配额和组级设置的操作范围。
- Owner 转组、离职移交和 T1 特殊接收人规则。
- CRM 四项权限迁移到新业务范围的映射。

## 后端事实阻塞项

- CRM 四项权限 16 种组合的真实写权限真值和读范围。
- 邮件、资源夹、内容监控的真实扣额主体。
- 支付单 / 草稿 flagForMe、editFlag、Owner、可见范围和资金占用语义。
- 成员清退是否已有模块资产副作用。
- 是否已有跨模块审计表 / 服务。

## 会议需要输出的结果

1. 旧方案是否继续作为实现基线，还是切换到新扁平候选。
2. 如果讨论新候选，是否接受每组 0..N 名 T2 和可重叠管理范围。
3. 管理范围的固定能力包边界。
4. 需要由研发补充的后端事实和负责人。
5. 结论进入 Input 的哪些章节，哪些继续留在 Spec 待细化。

## 来源

### 项目内部

- [原始反馈池](<./(【CSM】反馈池)权限账号反馈池.xlsx>)
- [当前 Input](./input_v0.md)
- [事实核验](./fact_check_v0.md)
- [早期 Spec 草稿](./spec_v0.md)
- [CRM 线上权限截图](./crm_write_permissions_online.png)
- ../kol-next/pages/brand/sub-account/
- ../kol-next/assets/script/constant/subAccount.js
- ../kol-next/api/setting/subAccount.js

### 线上页面

- https://cn.noxinfluencer.com/brand/sub-account
- https://cn.noxinfluencer.com/brand/sub-account/quota
- https://cn.noxinfluencer.com/brand/sub-account/data

### 行业参照

- HubSpot teams: https://knowledge.hubspot.com/user-management/create-and-manage-teams
- HubSpot permissions: https://knowledge.hubspot.com/user-management/hubspot-user-permissions-guide
- Salesforce role hierarchy: https://trailhead.salesforce.com/en/content/learn/modules/data_security/data_security_roles
- Asana project teams: https://help.asana.com/s/article/create-projects-in-asana
- Google Workspace scoped admin: https://support.google.com/a/answer/9807615
- GitHub teams: https://docs.github.com/en/organizations/organizing-members-into-teams/about-teams