# 账号和权限功能设计梳理 > TODO: > > [?] 文档状态图例：`线上事实 / 已确认 / 候选方案 / 待确认 / TODO`。 > > [x] 核心实体和基数：组织、成员、组织身份、组成员关系、管理范围。 > > [?] 账号管理动作：邀请、任免管理员、移除、所有者移交。Admin 动作矩阵后置到各模块动作梳理完成后统一处理。 > > [?] 2026-08-20 会议建议裁剪：Admin 分组管理范围及重叠、T2 邀请、邀请首组、通用只读访问、Owner 转交后保留 Collaborator 的快捷勾选。替代路径确认前不直接从基线删除。 > > [x] 组与管理范围：谁属于哪里、谁负责哪里、每组几个管理者。 > > [x] 统一权限计算：硬限制 → 配额/业务准入 → 当前组上下文 → 对象授权来源 → 动作权限。 > > [x] 对象协作：项目型对象使用 Owner/Collaborator，CRM 组属记录使用可空 Assignee/Collaborator；共用查看范围及附加能力，不设置通用 Editor/Viewer。 > > [x] 配额：Scope 类型、可分配型 Scope 的组织/组/组成员上限与 `inherit / capped`、不可分配 Scope 的组织权益继承；支付金额独立处理。 > > [?] 各模块策略：邮件、CRM、内容监控、品牌监控、跨境支付。 > > [?] 生命周期：邀请、转组、离职、数据移交。 > > [?] 线上迁移、审计和待决策清单。 > > [?] 月度配额双周期与组合并是否进入本版本。 > **UI 标记**：`【UI交互】` 表示需要入口、控件或可操作状态；`【UI反馈】` 表示需要提示、确认、进度、结果摘要或通知；`【UI建议】` 表示 Input 阶段的入口复用和复杂度初评。 聚星的账号和权限设计，将一个组织账号按两个不同维度（账号管理维度、业务维度）进行定义和设置：账号管理维度定义组织身份和管理范围，业务维度定义组成员关系、当前业务组和对象协作权限。两个维度除必要的管理设置动作外不相干，组织身份本身不产生业务对象权限。 2026-08-20 会议提出的六项“考虑移除”仍作为待决策记录，不覆盖本文当前基线。其中“只读访问”暂按“考虑裁掉通用显式只读授权框架”理解，不同时删除 CRM 线上读取、资源夹公开/部分可见、支付正式单同组只读等模块既有或已确认范围；邀请首组若移除，还需确定邀请后暂不入组还是自动进入默认组。 配额现状以服务端团队提供的 `scope_quota_product_rules.md` 为事实基线。Scope 可能是按结果消耗、团队去重的一次解锁、资源席位或容量、结果窗口、频率限制、纯功能门禁，不统一等同于可扣减次数。只有经 Scope 矩阵确认可向下分配的 Scope 才新增组级和 GroupMembership 级 `inherit / capped`；不可分配 Scope 随组织 Entitlement 生效，本期不提供成员级禁用或数值输入。Scope 不产生项目 ACL，跨境支付金额继续使用独立的钱包余额、组级追加分配账本、账号人工上限和资金占用模型。 月度配额待确认时应拆开“套餐权益/组织额度的发放周期”和“组/成员的分配控制周期”。企业年付月发直接继承服务端月度窗口；年度组织额度上的月度下级分配可作为不预占年度额度的子周期上限，执行时同时受年度父级剩余与当月下级剩余约束。周期锚点、结转、中途调整和是否进入本版本尚未确认。 ## 账号管理维度 从**账号管理维度**来看，首先一个`【客户】`要有一个`【组织】`实体。`【组织】`内应有1..n个`【成员账号】`，成员账号中有且只有`1`个账号拥有`【组织所有者】`身份，另外还可能有0..N个`【管理员】`身份的账号，其余账号皆为`【普通成员】`。组织身份与账号在各组中的业务身份分开保存。 ### 组织 - 组织是默认创建好的实体。 - 组织拥有**成员账号列表**。 - 组织拥有**组织策略**配置，组织策略默认影响组织中所有成员与业务。 - 组织由当前的组织所有者进行**管理**。 - 组织拥有多个业务组；业务组可以为空，也可以暂时没有组内 T2。 - 组织所有者不能直接解散组织；组织成员移除受生命周期和数据移交约束。组不彻底删除，改为冻结归档并保留 `groupId`、业务对象、成员历史、任务、资金账本和审计。【UI反馈】移出或归档前需展示数据影响。 - 新规则上线时不要求存量客户先配置分组。系统原子创建一个真实默认组，将存量有效成员和已接入的项目型业务对象归入默认组；CRM 记录按最终选定的旧分组迁移方案原子写入稳定 `groupId`，不能在方案未定时一律压入默认组。默认组不是隐藏分组或特殊兼容空间。 - 存量组织初始化时，组织所有者成为默认组 T2，线上原 `adminStatus=2` 的组长迁为默认组 T2，其他成员迁为默认组 T3；组织 Owner/Admin 身份单独保留。 - 存量项目的 `ownerUid`、显式协作关系、查看来源、附加能力、配额有效状态、CRM 普通写权限和支付历史身份必须按迁移真值表无损映射；CRM `ownerUser` 映射为可空 `assigneeUid`，空值保留为合法「未分配」，不补造项目 Owner。不能只保证项目协作关系不丢失。研发确认已证明 CRM 旧分组权限以及正式支付单/草稿可见范围不能仅靠一个默认组机械映射，这两项迁移方案仍需单独确认。 - 存量 Scope 不为补齐 `groupId` 伪造历史归属：组织级用量、占用、已解锁状态和剩余额度保持线上口径；当前容量按迁移后对象组计算，可靠的账号上限和本周期个人用量迁入默认组 GroupMembership，无法可靠归属的事件型历史用量只留在组织层。组织内已经完成的一次解锁继续复用，不重复收费；上线后的新消耗必须记录实际 `groupId + actorUid`。 - 组织策略“组长默认成为组内所有项目协作者”对新组织和存量组织均默认关闭，因此迁为默认组 T2 不会在上线时自动扩张项目权限；后续主动开启才产生 T2 系统协作者来源。 ###### ### 成员账号 - 一个成员账号只能属于一个组织，不支持跨组织复用；同一账号可以通过多条组成员关系加入同一组织内的多个组。 - 未接受邀请或尚未加入任何客户组织的账号，可以没有有效成员关系。 - 组织不能没有成员。 - 组织不能没有所有者。 - 删除最后一名成员、移除当前所有者等操作必须被系统阻止。 - 组织成员关系和组成员关系均需区分 `ACTIVE`、`REMOVING`、`REMOVED`；移出组织不可撤销，Owner 必须保留至少一个 ACTIVE 组成员关系。 | 组织身份 | 数量 | 说明 | | ---------- | -------- | ------------------------------------------------ | | 组织所有者 | 恰好 `1` | 唯一、可移交，拥有所有者专属动作 | | 管理员 | `0..N` | 由所有者任命，可配置管理范围和具体管理能力 | | 普通成员 | `0..N` | 不具备组织管理能力，但可以通过组成员关系参与业务 | #### 组织所有者（超级管理员） - 【UI交互】组织所有者可以向另一个成员账号移交所有者身份。 - 组织所有者可对另一个成员账号进行管理员身份任命/解除。 - 任命时选择其权限范围 - 【UI交互】组织所有者可以邀约/移除成员账号。 - 【UI交互】组织所有者可以**管理组**。管理组的具体定义见业务维度**组**描述。 - 【UI交互】组织所有者可以编辑业务维度配置（组设置）。 - 【UI交互】组织所有者可以修改组织策略配置。 - 组织所有者拥有全组织管理范围，可以为 Admin 配置0..N个管理组范围；多个 Admin 的管理范围可以重叠。 - 【待确认】会议建议同时移除“每个 Admin 配置0..N个管理组”和“多个 Admin 范围重叠”；若确认，需要在 Admin 全组织管理与动作级收缩之间选择替代口径。 - 组织所有者可以查看全组织及各组数据汇总；汇总查看属于管理行为，不自动开放组成汇总的业务明细。 - 组织所有者不因组织身份自动获得任意业务对象的查看、编辑、删除或资金执行权限；参与业务时仍需具备对应组成员关系和对象权限。 #### 管理员 * 管理员角色由组织所有者任命/解除 * 管理员角色拥有部分组织所有者权限，受组织所有者配置；具体动作由管理动作矩阵约束 * 【UI交互】管理员可以配置0..N个组作为管理范围，多个管理员的管理范围可以重叠 * 【UI交互】管理员可以查看管理范围内的组数据汇总；该能力属于组织管理视角，不等于拥有这些组的业务对象明细权限 * 管理员参与具体业务时，仍按自己当前组的组成员身份和对象授权工作 * 管理员管理范围内的汇总查看属于管理行为，不自动开放组成汇总的项目、CRM 记录或支付单明细 * 【待确认】Admin 分组管理范围和范围重叠是否整体移除；在结论明确前仍按上文基线解释 #### 普通成员 * 普通成员由组织所有者/管理员角色邀请加入组织；组织策略开启时，当前组 T2 也可以邀请新账号作为本组 T3 * 普通成员**不能**对组织进行管理 * 普通成员不能自行修改组织身份或既有组成员关系；退组、移出组织和数据移交由有权的组织管理角色发起 ### 成员账号邀约 * 【UI交互】成员加入组织，需经由组织所有者/管理员进行**邀约**；组织策略开启时，T2 可邀请新账号直接进入自己当前组 * 【UI交互】邀约时必须显式确认其首个业务组、组内身份（T2/T3）和可分配型 Scope 配置；不设置分组默认配置模板 * 可分配型 Scope 默认 `inherit`，表示不设个人上限、使用所属组共享额度；邀约者在确认前可以改为允许范围内的 `capped`。不可分配 Scope 只读展示“随组织权益”；跨境支付只读展示目标组当前资金状态，账号支付上限默认 `unlimited`，邀约者可在允许范围内设置具体金额 * T2 邀请时只能将新账号作为当前组 T3 引入，不能维护既有 GroupMembership * 【UI交互】【UI反馈】成员加入目标组本身与其 Owner 名下项目迁移分开处理；是否迁移必须显式选择，不能静默搬迁项目 * 【待确认】会议建议移除“T2 邀请当前组 T3”和“邀请时显式选择首组”。前者确认后邀请只由 Owner/Admin 发起；后者需先选择“邀请只建立组织成员、后续由 Admin 入组”或“自动加入默认组”，否则新成员无法获得正常业务组身份 ### 组织策略 组织策略为一系列配置项，用以决定业务维度中的数据权限与协作行为，以及一些全局的账号管理维度设置。 通常组织策略只有组织所有者可以设置。 #### 业务维度的组织策略配置项 ##### 全局 - 【UI交互】全局持久化当前业务组 `currentGroupId`；切组只改变业务上下文，不授予权限，也不改变已有对象归属。 - 【UI交互】【UI反馈】组织级全局开关“组长默认成为组内所有项目协作者”默认关闭。开启后，本期已接入对象所属组的全部 ACTIVE T2 动态成为普通 Collaborator；关闭后只撤销该系统来源，显式 Collaborator、显式查看授权和附加能力保留。开关变更需要影响预览、二次确认、审计和结果摘要。 - 组织所有者固定可修改该开关；管理员是否可修改以及所需管理范围进入 Admin 动作矩阵；T2/T3 不可修改。开关不支持逐组或逐模块差异化配置。 - 是否允许 T2 管理本组成员的权限配置、是否允许 T2 邀请新账号进入本组，由组织所有者/Admin 配置全局策略。 - 组织策略不得生成跨组协作权限，也不能绕过组织、账号状态、配额准入或组成员关系等硬限制。 - 组织设置、Admin 管理页、全组织汇总、账单和组织钱包等组织级页面不依赖当前业务组；进入某组管理明细时应明确管理目标组。 ##### 邮件邀约和消息 - 邮件项目按项目所属组执行同组 Owner/Collaborator 协作；Collaborator 保持线上常规业务读写，`canManageMembers` 映射为独立附加能力；组长默认协作开关开启时，同组 T2 的系统来源替代旧的 Admin 强制协作。 - 线上邮件项目已有 `email[12]` 强制添加管理员协作者能力；新模型不再按 Admin 身份写入新项目，存量锁定关系需按迁移真值映射为显式 Collaborator。不能依据单模块 `email[12]` 自动开启全模块的组长默认协作开关。 - 消息标签仍是组织共享定义，列表补充创建人和创建组来源筛选，不把筛选升级为标签权限。 ##### CRM - 【现状事实】当前 CRM 记录在同一主账号体系内全员可读；`ownerUser` 非空时 Owner 始终可写，四项设置分别增加团队实际管理员、同组组长、同组成员和全组织成员写权限。直接标签应用和标签定义删除没有复用 CRM 写鉴权。 - CRM 记录是组属业务记录而不是强制 Owner 的项目型对象：固定保存 `groupId`，线上 `ownerUser` 映射为可空 `assigneeUid`；空值是合法「未分配」状态。记录按同组 Assignee/Collaborator、显式查看授权、普通写范围和可开关的 T2 系统协作计算访问；原始“协作人只读”需求使用显式查看授权，不创建只读协作者。 - `groupId` 决定 CRM 记录归属和同组范围，不能由 Assignee 当前所在组动态推导；Assignee 变更不改变记录组。Assignee 只表达对接责任和对应普通写来源，不进入项目 Owner 的转交、迁组或强制移交规则，但天然负责添加/移除记录 Collaborator 和显式查看对象，并可向有效 Collaborator 授予或收回不可传递的 `can_manage_collaborators`。 - 【UI交互】【UI反馈】已有 Assignee 时，当前 Assignee 和记录组内任一 `ACTIVE T2` 都可以使用同一改派动作，为记录指定一个新的同组 ACTIVE Assignee；未分配记录因为不存在当前 Assignee，只能由同组 T2 分配。候选人不要求接收确认，日常动作不允许把非空 Assignee 清空。普通 Collaborator 即使拥有普通写权限或 `can_manage_collaborators` 也不能设置、清空或改派 Assignee；组织 Owner/Admin 也不能仅凭组织身份或管理范围直接操作。改派后原 Assignee 只在另有有效授权来源时继续访问。 - T2 的 Assignee 分配/改派权是独立的固定组内分工动作，不依赖组长默认协作开关。开关关闭时，T2 仍可在分工清单查看记录标识、网红名称、所属组和 Assignee 状态等必要信息并完成分配，但不因此获得完整记录明细、普通写权限或协作者治理。未分配状态下先锁定协作者治理并提示由 T2 分配 Assignee；若记录组没有 `ACTIVE T2`，Owner/Admin 只能先通过组管理任命 T2，再由 T2 分配。 - 【UI反馈】线上四项写权限配置值迁移到统一权限引擎时不清空、不重置，四项分别为：`对接人和管理员可编辑`、`对接人和同组组长可编辑`、`对接人和同组成员可编辑`、`所有人可编辑`；可分配型 Scope 的有效可用量为 `0` 只阻断需要消耗配额的动作，不直接撤销记录读取或 ACL。现有四项设置入口保留，迁移期间给出策略作用范围说明；最终权限结果是否等价取决于组织管理员、旧分组和“所有人”三类范围的迁移方案。 - 在新模型中，前两项分别映射为非空 Assignee + 记录组内有效组织 Admin、非空 Assignee + 记录组内 ACTIVE T2；第三项映射为非空 Assignee + 记录组内具备 CRM 业务资格的 ACTIVE 成员；第四项在严格组隔离下映射为非空 Assignee + 记录组内具备 CRM 业务资格的 ACTIVE 成员。Assignee 为空不影响按记录 `groupId` 计算组范围。 - `对接人和管理员可编辑` 中的管理员按 CRM 对象策略处理，不将组织 Admin 普遍扩展为所有 CRM 记录可写。 - 研发确认权限 `1` 的团队实际管理员当前不要求属于记录组，旧“同组”权限 `2/3` 读取现有单组关系。要求 Admin 属于记录组会缩小权限 `1`；已有多个 CRM 组的组织若全部压入默认组会扩大权限 `2/3`；把“所有人可编辑”收敛为记录组又会缩小权限 `4`。因此默认组迁移不能写成天然等价，旧组映射、迁移范围授权或明确接受权限变化仍待确认。组长默认协作开关保持默认关闭，组织主动开启后产生的 T2 Collaborator 属于单独的权限扩展。 - 【UI交互】【UI反馈】CRM 标签删除继续作为独立高风险动作，不由普通记录编辑权限自动推导；删除前显示影响范围并二次确认。 - 【待确认】直接标签应用当前全组织可调用；是否收敛到 CRM 普通写/对象 ACL 需单独决定。需扫描空 `ownerUser` 的数量和分布以评估「未分配」界面与查询影响，但不做 Owner 兜底。 - 【UI交互】【UI反馈】CRM Assignee 离组或被移出组织时，影响清单按记录所属组汇总。Owner/Admin 作为移交任务操作者可为每个组另选 `0..1` 名同组 ACTIVE 成员，将该账号在该组负责的全部 CRM 记录批量改派；未选择则在最终完成退组时置为未分配。这只是退组/组织移出生命周期中的数据清理例外，不产生 Owner/Admin 的日常改派权。`REMOVING` 期间不改写 Assignee，只有 `REMOVING -> REMOVED` 最终事务执行改派或置空，因此单组退组撤销时无需恢复。 ##### 内容监控 - 【UI交互】内容监控/视频监控范围内，组织所有者/Admin 可配置“是否只有 T2 才能增删编辑标签”，默认关闭。 - 开启后，Owner/Admin 和任一组的 ACTIVE T2（账号状态正常且套餐包含内容监控）可以管理组织共享标签定义，T3 不能增删改；标签在具体项目中的应用仍按项目 ACL 判断。 ##### 品牌监控 - 品牌监控项目按项目所属组执行同组对象协作；组织身份和其他组身份不自动带来项目明细权限。 ##### 跨境支付 - 【现状事实】正式支付单当前全组织可读，服务端正式单写接口也只校验同组织和订单状态；`editFlag` 只是前端创建人展示信号。草稿则仅创建人可读写。创建正式支付单时即冻结组织钱包 `pending`，历史收款账号按组织+频道+平台共享。 - 支付单和草稿固定归属于一个组，接入组长默认协作策略和支付单对象授权；Owner/Admin 不因组织身份自动获得支付单明细或资金执行权限。开关开启时 T2 成为普通 Collaborator，但不自动获得支付执行权限。 - 正式支付单固定对所属组 `ACTIVE` 成员只读，与是否存在 Collaborator 无关；该范围不写入 ACL，也不显示为协作者。草稿只有 Owner 和有效 Collaborator 可见；Collaborator 可以填写和保存草稿，没有 `can_execute_payment` 时不能提交为正式支付单。 - 【迁移边界】存量正式单和全部成员初始化到同一默认组，保持原全组织读取；存量草稿只初始化 Owner、不生成 Collaborator，保持创建人可见。目标模型收紧正式单服务端宽写权限，该变化按安全修复验收，不迁成隐式 Collaborator。 - 【UI交互】【UI反馈】不设置“同组成员可查看支付单”父开关，只保留组织级“同组成员可查看支付敏感信息”，默认关闭。关闭时同组只读范围看到脱敏信息且不能下载回执；开启后可读完整信息和回执，但仍无写权限。支付金额限制继续由组织钱包、组追加分配、账号上限和统一资金校验共同决定。 - 组织层不保存支付金额 `unlimited`，以支付域返回的组织钱包当前可用余额（暂定 `walletAvailableAmount`，已包含支付域对已支付和待支付占用的处理）作为第一层硬上限。组默认使用组织未分配共享余额；每次向组分配金额都新增不可修改的正向记录，普通操作只能增加组上限，且本次增加量不能超过组织未分配余额。账号上限默认 `unlimited`，允许改为具体金额；账号上限之和可以超过组上限，实际提交时仍逐层拦截。 - 组额度减少不提供普通编辑。纠错、组关闭或预算回收通过引用原分配记录的受控冲正/收回交易完成，只能使用该组未支付、未占用余额；原记录不修改，冲正另行留痕并二次确认。预约提交立即形成 `pending` 占用，归属提交时 Owner 的 `fundingUid + fundingGroupId`，审批/放行人不承担额度；取消、失败和退款按原归属冲正。 - 预约提交时即形成资金承诺，`fundingUid` 和 `fundingGroupId` 记录提交时 Owner 与项目组快照；提交人、审批/放行人和实际执行人只记录为 `actorUid`，不承担该笔资金额度。 - 支付 Owner 不能主动转交；草稿可由 Owner 或有效 Collaborator 删除，支付执行需要独立的 `can_execute_payment`，不能从普通 Collaborator、T2 系统来源或组织身份推导。 ##### 后续版本：支付单组长审核放行（TODO） - 每个组单独设置“是否需要组长审核放行”，默认关闭；不设置组织默认值或继承关系。策略实时影响该组尚未开始实际转账的支付单。 - 立即执行在系统审核通过后等待任一 `ACTIVE T2` 放行；定时执行在系统审核通过后、预约时间到达前完成 T2 预审核，逾期复用预约超时并要求重新预约、转立即或作废；手动支付在支付者点击放行后再等待 T2 放行。 - 多个 T2 任意一人处理即可。正式支付单提交人在到达闸门时是同组 `ACTIVE T2`，则无论组长人数都跳过审核；只判断闸门当下身份，提交后升为 T2 可命中豁免，降为 T3 或进入 `REMOVING` 则必须由其他 `ACTIVE T2` 放行。该规则不替代 Owner/Collaborator 的 `can_execute_payment` 提交权限。 - 当前组支付列表增加 `待我放行`、数量和预约时间提示；通知中心跨组汇集 T2 待办，点击后切到对应组。本期不建设跨组审批工作台，也不把 T2 审核权限写成 Collaborator 或 `can_execute_payment`。 #### 非业务维度的组织策略配置项 ##### 管理员（非组织所有者）的权限 - 管理员是否可以邀约子账号 - 管理员是否可以创建和管理组，以及是否可以维护其管理范围内的组成员关系 - 管理员是否可以管理管理范围内的组配额上限 - 管理员是否可以修改“组长默认成为组内所有项目协作者”；该项是全组织策略，是否要求 Admin 拥有全组织管理范围留待动作矩阵确认 - 管理员是否可以修改组织策略中的高风险配置，具体动作留待管理动作矩阵确认 ## 业务维度 **业务维度**主要定义组织成员在使用平台功能时，对数据的读写操作范围，以及以**组**为结构的数据隔离规则，和组内权限层级规则。 ### 组 组是组织内人员划分和业务隔离的形式。一个账号可以加入组织内的多个组；每条组成员关系单独记录其 T2/T3 身份和可分配型 Scope 配置。每个组有0..N个组长（T2），其余为组员（T3），允许先建立空组或暂时没有组长。 对组的操作由组织所有者和有权限的管理员进行。 - 每个组织成员可以**加入**1..N个组 - 每个组成员关系独立保存 T2/T3、状态和可分配型 Scope 的 `inherit / capped`；同一账号在不同组可以拥有不同身份和配置。不可分配 Scope 不保存组成员数值配置。 - 账号必须通过全局当前组切换进入某一组的业务上下文；切组不改变既有项目的归属，也不自动获得其他组的业务权限。 - 账号只能与当前组内的 ACTIVE 成员进行项目协作；不支持跨组协作、跨组 Owner 转交或跨组协作者候选。 - 【UI交互】【UI反馈】移除成员关系只能由组织 Owner/Admin 发起和推进，T2 不可操作；关系必须先进入 `REMOVING`，立即失去该组业务权限，但不立即删除 Owner、ACL 或配额配置；最终完成退组时再进入 `REMOVED` 并按数据移交流程原子清理。成员详情需要展示状态、影响清单和移交任务。 - 组织所有者和有权限的管理员可以**管理组** - 【UI交互】创建组、修改组名 - 【UI交互】将组织成员加入或移出其管理范围内的某个组 - 【UI交互】为每条组成员关系设置 T2/T3 和可分配型 Scope 配置；不可分配 Scope 只读展示组织权益状态 - 【UI交互】将组成员设置为 T2、解除 T2 身份；每组允许0..N个 T2，不强制设置组长 - 将组成员移除出组 - 退组先进入 `REMOVING`，对该账号来说已经是现实退组，不能继续执行需要组身份的动作 - 【现状差异】当前 `/ws/userRelation/setAdmin status=2` 会立即执行同步资产迁移、删除关系并把多类对象转给团队管理员；新流程进入 `REMOVING` 时不得复用该分支，最终移交也必须改为目标同组接收人和独立 `ownerUid`，不能继续改写历史创建人 - 【UI反馈】该账号作为 Owner 的项目型对象留在原组，不因退组自动迁移；由 Owner/Admin 在移交任务中指定同组 ACTIVE 接收人。CRM Assignee 记录单独按组展示影响，每组可另选一名同组 ACTIVE 成员批量改派；未选择则最终置为未分配，不纳入项目 Owner 的强制接收人约束 - 【UI交互】【UI反馈】接收人必须拥有目标组有效 GroupMembership，并确认待移交项目涉及的可分配型 Scope 配置；缺失时默认补为 `inherit`，或由 Owner/Admin 在组织/组上限内改为 `capped`。不可分配 Scope 只校验组织 Entitlement - 【UI交互】【UI反馈】提供“整体移交给一个账号”快捷入口：单组退组时覆盖当前组，移出组织时覆盖全部受影响组；一个接收人统一承接原账号的 Owner、Assignee、有效显式 Collaborator、显式查看授权和 ACL 附加能力。需要不同接收人时返回标准逐组流程 - 接收人可以是组织内已有账号，也可以在流程中输入邮箱新邀请。已有账号缺组时直接补建 GroupMembership；新账号接受邀请前任务停留在 `WAITING_FOR_TARGET`，原账号仍进入 `REMOVING` 并立即失权，接受后先建组织/组关系再按组执行移交。仅退组时新账号需要正常可用席位；全组织移出替换时，任务保留原账号释放的一个席位供受邀接收人接受，避免接受阶段再次被席位上限拦截 - 待补 GroupMembership 默认 T3、可分配型 Scope `inherit`、支付账号上限 `unlimited`，提交前必须逐组确认；不自动继承组织 Owner/Admin、Admin 管理范围、T2 身份或原账号配额。原账号是最后一个 T2 时强提醒并快捷设置新 T2，但允许明确保留无 T2 状态 - 整体移交只替换当前有效业务关系：目标账号已有同对象授权时去重并合并正向能力，成为 Owner/Assignee 后不保留重复 Collaborator/显式查看身份；禁用 ACL 和系统派生来源不复制。`createdBy`、历史操作与用量、既有支付 `fundingUid + fundingGroupId`、组资金账本均不改写 - 全组织整体移交按组原子执行，失败组独立重试，全部组完成后才最终移出组织；任务页展示邀请状态、身份/配额准备、对象数量、进度、失败原因、结果摘要并发送完成通知 - 【UI交互】【UI反馈】仅退组且尚未最终完成时可以撤销；移出组织不可撤销 - 账号仅剩最后一个 ACTIVE 组时可以进入 `REMOVING`，但必须重新加入其他真实组，或升级为不可撤销的组织移出，才能完成该组的 `REMOVED` - 【UI交互】【UI反馈】组不彻底删除，改为冻结归档。归档前展示对象、任务、资金和 `REMOVING` 成员关系影响，但这些内容不阻断归档；归档组不能成为当前组、创建新对象、增加新的 ACTIVE 成员关系或执行普通业务写动作，历史数据和已形成的系统/资金责任继续按原 `groupId` 保留。 - 【待确认】冻结归档只解决“封存旧组”，不能解决“业务继续并入另一组”；组合并是否进入本版本需单独确认。是否允许解除归档也尚未锁定。 - 【UI交互】【UI反馈】只为可分配型 Scope 设置组级 `inherit / capped`；不可分配 Scope 不出现组级数值输入。跨境支付金额的组织级上限由钱包当前可用余额提供；组默认使用组织未分配共享余额，也可通过“追加分配”形成部门上限，每次分配单独留痕且不得超发；账号支付上限默认 `unlimited`，允许设置具体金额。组上限普通操作只能增加，减少必须走受控冲正/收回。 - 【UI交互】【UI反馈】账号加入目标组时，可以选择迁移该账号名下、且原本属于某个来源组的全部项目；本期不支持项目多选，也不触及其他 Owner 的项目 - 如果账号当前仅属于默认组，必须主动询问是否迁移其在默认组名下的全部项目；不迁移则只建立新的组成员关系 - 成员关系建立成功与项目迁移批次独立；迁移逐项执行，失败项留在来源组并可重试 - CRM 记录不属于 Assignee 名下项目，不随 Assignee 进组或切组迁移；记录改组留给合并组或 CRM 专项能力 #### 组长 - 组织策略“组长默认成为组内所有项目协作者”开启时，组长（T2）通过系统授权来源成为本组项目的普通 Collaborator，替代线上旧的管理员强制协作；该授权只对当前组对象生效，提供常规业务读写。策略默认关闭，关闭时 T2 身份本身不产生项目权限。 - 开关开启时，T2 的系统协作来源在协作者列表中锁定展示，不能被项目 Owner 手动移除；开关关闭、T2 降级为 T3 或进入 `REMOVING` 时立即失效，但同一账号的显式授权保留。 - T2 系统来源不自动获得 `can_manage_collaborators`、跨境支付 `can_execute_payment` 或模块高风险治理动作；同一账号另有显式能力来源时，系统来源与显式来源分别保留并合并正向能力。CRM 是固定例外：同组 `ACTIVE T2` 拥有独立于系统协作开关的分工动作，可以为未分配记录设置 Assignee 或改派已有 Assignee；开关关闭时该动作仍不授予记录明细、普通写或协作者治理。记录组没有有效 T2 时，Owner/Admin 只能先任命 T2，不能直接越级改派。 - 【UI交互】组织策略开启“允许 T2 管理本组账号权限”后，任一同组 T2 可以在组上限内修改自己及本组成员的可分配型 Scope 配置；不可分配 Scope 仍只读继承组织权益。所有 T2 权限对等，不设置首席 T2。 - T2 不负责维护既有 GroupMembership 的加入、移除或 T2/T3 身份生命周期；组织 Owner/Admin 负责成员关系管理。 - 【待确认】当前基线为组织策略开启后，T2 可以邀请新账号作为本组 T3；2026-08-20 会议建议移除该能力，确认后只保留 Owner/Admin 邀请。 - T2 可以查看当前组数据汇总；汇总查看不等于跨组或全组织业务明细权限。 #### 组员 - 组员（T3）可以在当前组满足组织 Entitlement、GroupMembership 和对象权限的前提下，作为项目 Owner，或通过项目级 Collaborator 参与项目；可分配型 Scope 的有效可用量为 `0` 不直接撤销已有对象授权，但不能完成对应消耗型业务动作。 - Collaborator 默认获得对象允许的常规业务读写；只读访问通过查看范围或显式查看授权表达，不进入协作者列表。删除、转交、归组、管理协作者等高风险动作按对象类型独立判断。 - 项目 Owner 和组织 Owner 的旧“主账号最高权限”表述统一按当前模型解释为具体授权来源；组织 Owner 身份本身不能绕过对象组边界。 - 【UI反馈】只有可分配型 Scope 才按“组织当前有效上限 → 对象所属组或当前组上限 → 组成员账号上限”逐层拦截；普通 Scope 各层下级 `capped` 之和可以超过父级，实际使用时再校验。`inherit` 表示不追加本层上限、继续使用父级共享额度；每个 Scope 的统计主体、周期、去重、返还或释放规则以 Scope 矩阵为准。不可分配 Scope 只显示随组织权益和当前不可用原因，不伪造个人剩余量。跨境支付金额是资金守恒例外：组级追加分配不得超过组织未分配余额；已分配组取组织钱包、组剩余和账号上限剩余的最小值，共享组取组织未分配余额和账号上限剩余的最小值。 ### 项目 项目是需要持续唯一负责人、可以主动转交责任的业务数据实体接口，提供**项目所有者**、**项目协作人**。邮件项目、资源夹/收藏夹、内容监控项目和支付单/草稿按本节处理；CRM 是允许无个人对接人的组属业务记录，不适用本节强制唯一 Owner 和 Owner 转交流程。 项目直接从属于且只能从属于一个组，保存稳定的 `groupId`；项目同时保存唯一 `ownerUid`，不能通过 Owner 当前所在组动态推导项目归属。 【UI交互】项目创建时使用账号的全局当前组作为 `groupId`。切换当前组只影响之后创建的项目和当前业务上下文，不改变已有项目归属；创建表单展示归属组。 【UI交互】【UI反馈】访问和操作项目时，当前业务组必须切换为项目所属组；从通知、收藏或外部链接打开其他组项目时，应先明确展示目标组并要求显式切换。 #### 项目所有者（Owner） - 项目有且仅有1个Owner，Owner拥有此项目最大权限 - 项目 Owner 必须是项目所属组内的 ACTIVE 成员；待执行具体动作时，再按相应 Scope 类型检查组织 Entitlement，以及可分配型 Scope 的组/成员上限。 - 项目所有者可转交，转交范围为项目所属组内成员；不允许跨组转交。 - 新 Owner 必须是项目所属组内的 ACTIVE 成员，并确认待接项目涉及的可分配型 Scope 配置；缺失时默认补为 `inherit`，或由 Owner/Admin 在组织和组上限内改为 `capped`。不可分配 Scope 只检查组织 Entitlement。可分配型 Scope 的有效可用量为 `0` 不删除对象授权，但相应消耗型动作需等额度恢复后才能执行。 - Owner 转交在同一事务中更新 `ownerUid`，并清理新 Owner 在该对象上原有的显式 Collaborator、显式查看授权及附加能力；其他账号的 ACL、对象 `groupId`、不可变 `createdBy` 和历史数据不变。新 Owner 若同时命中动态 T2 系统协作，权限和界面仍只呈现 Owner，不落重复显式 ACL。 - 【待确认】当前基线为 Owner 主动转交时提供默认不勾选的“转交后将我设为协作者”；2026-08-20 会议建议移除该快捷项。确认移除后，原 Owner 固定不新增 Collaborator，但动态 T2 等其他独立来源仍可生效。 - Owner 主动转交不需要新 Owner 接受，也不产生待接受或双 Owner 状态。原 Owner 二次确认后同步生效；提交时重新校验双方身份和组关系，失败时整次不生效，成功后通知新 Owner 并向原 Owner 反馈结果。 - 【UI交互】【UI反馈】Owner 退组时，项目留在原组，Owner 权限立即失效并进入待移交状态；由 Owner/Admin 指定一名同组 ACTIVE 接收人后完成移交。提交退组时可以不当场完成，`REMOVING` 期间允许后续补充或更换接收人。 #### 项目协作人（Collaborator） - 项目协作人不再分 Viewer 和 Editor。Collaborator 默认具有当前业务对象允许的常规读写，不新增通用 `can_edit`；具体删除、归档、转交、归组、管理协作者和支付执行等动作另行判断，消耗型动作还需通过对应配额校验。 - 【待确认】只读访问不属于协作者。当前基线允许通过组/组织策略形成查看范围，或对具体对象设置显式查看授权；会议建议不建设通用只读访问。建议仅裁掉“对象级显式只读授权”这套新增框架，模块固定查看范围和线上既有只读语义仍需保留，最终边界待确认。 - 【UI交互】显式协作人和显式查看对象由项目 Owner，或被授予不可传递 `can_manage_collaborators` 的 Collaborator 设置，选取范围为项目所属组内的 ACTIVE 成员。 - 【UI反馈】组长默认协作开关开启时，项目所属组的 ACTIVE T2 通过系统授权来源成为协作人；该来源不需要逐项目写入 ACL，不因组织 Owner/Admin 身份自动产生。协作者列表锁定展示该授权来源；开关关闭时不展示、不生效。 - 项目 Owner 可以天然授予或收回 `can_manage_collaborators`；获得该能力的非 Owner Collaborator 不能继续传授该能力；只有 Collaborator 可以获得，显式查看对象不能获得。组织 Owner/Admin 身份本身不因此获得对象权限，具体可授予主体留待动作矩阵统一确认。 - 不允许跨组协作。账号即使同时加入其他组，也必须在当前项目所属组保持 ACTIVE GroupMembership，才能成为候选协作者或使其显式对象授权生效。 - 【UI交互】【UI反馈】项目迁移时，不属于目标组 ACTIVE 成员的显式 Collaborator、显式查看授权和附加能力不删除而是整体禁用。成员之后加入目标组且满足组成员关系等硬限制时，原授权自动恢复；可分配型 Scope 的有效可用量为 `0` 只阻断消耗型动作，有权账号显式删除后不再自动恢复，删除前需二次确认。 #### 跨项目资源 跨项目资源通常指某个功能下的通用资源/配置，可由所有此功能下的项目访问使用。比如内容监控功能的“监控项标签”。 - 跨项目资源在组内共享，跨组隔离。 - 项目迁移到另一组时，资源引用随项目逐项检查；本期只支持 Owner 名下项目整批迁移，失败项留在原组并可重试。 - 对象授权中不属于目标组的协作者、显式查看授权和附加能力不删除而是禁用，目标成员之后进组且满足硬限制时自动恢复；显式删除后不再自动恢复。 - 跨项目资源的共享定义和具体项目内应用分开鉴权。 - 内容监控/视频监控的共享标签定义受组织全局开关限制：默认关闭；开启后 Owner/Admin 和任一有效 T2 可创建、改名、删除，T3 不能执行定义动作。 - 标签应用仍按具体项目的 Owner/Collaborator 或模块普通写范围判断；仅有查看权限的账号不能应用标签，不因标签定义管理权获得项目权限。 - 消息标签继续组织共享，返回 `creatorUid` 和 `createdGroupId`，筛选为“我创建的 / 当前组成员创建的 / 全部”。筛选只改变列表结果，不改变标签权限；创建者离组后历史标签仍留在原创建组来源，不随账号漂移。 - 【UI交互】组织级共享资源（例如频道历史收款账号）不按组隔离时，应单独标记为组织共享主数据；跨境支付本期只允许按网红账号检索和复用。支付金额统一受组织钱包约束，组级可追加分配形成部门上限，账号级可设置个人上限，收款账号共享范围不改变资金归属和额度校验。 ## UI 交互与复杂度初步建议（Input 阶段） 【UI建议】本节只做交互范围盘点和复杂度判断，不替代后续 spec 的页面流程、状态矩阵和接口设计。复杂度按产品交互判断：低为现有页面增加字段/筛选/确认；中为多步表单或跨列表状态；高为全站上下文、异步任务、权限即时变化或资产迁移。 | 交互范围 | 界面上必须体现的内容 | 初步入口建议 | 复杂度 | | --- | --- | --- | --- | | 当前业务组 | 切组、当前组持续可见、项目归属组、深链切组确认、未保存内容告警 | 全站 Header 统一入口，业务页不重复提供组选择器 | 高 | | 成员与组管理 | 建空组、改名、冻结归档影响与历史入口、成员进组/退组、`ACTIVE / REMOVING / REMOVED`、T2/T3；Admin 管理范围是否保留待确认 | 复用子账号成员页，使用组关系侧栏/抽屉；归档组进入单独筛选 | 中 | | 邀请 | 邮箱、首组/T2邀请是否移除待确认；保留时展示 T2/T3、可分配型 Scope 的 `inherit / capped`、不可分配 Scope 的组织权益摘要、目标组支付资金状态、账号支付上限、席位校验、提交摘要 | 先收口邀请后如何入组，再决定是否扩展现有添加成员弹窗 | 中 | | 组和账号配额 | Scope 类型/可分配性、可分配型组上限、`inherit / capped`、批量增加预览和结果、有意义的个人可用量/耗尽层级；不可分配项只读；支付组级追加分配、分配记录、未分配余额、账号上限和受控冲正 | 复用现有配额页，按当前组切换 GroupMembership 视图；支付资金使用独立分区 | 高 | | 组织策略 | 组长默认成为组内所有项目协作者、T2 管理权限/邀请、团队额度可见性、内容监控标签限制、支付同组敏感信息；前者需影响预览和结果摘要 | 复用现有数据管理/配额策略区域；组长默认协作的 Admin 编辑权接 Admin 动作矩阵 | 低-中 | | 协作者与查看授权 | 搜索同组成员、Collaborator、T2 锁定系统来源、`can_manage_collaborators`、同组 Owner 转交；转交后保留 Collaborator 快捷项和通用只读授权均待裁剪确认；禁用对象授权和永久删除确认 | 协作者与 Owner 转交复用现有项目设置入口；待裁剪项确认前不继续细化入口 | 中 | | CRM 与标签 | 保留 CRM 四项设置；展示记录组、可空 Assignee/未分配状态；已有 Assignee 时，当前 Assignee 和同组 `ACTIVE T2` 共用“改派给新 Assignee”动作，未分配时仅 T2 可分配，不提供日常清空；普通 Collaborator 和 Owner/Admin 不提供日常改派入口；无有效 T2 时提示先任命组长；Assignee 管理 Collaborator/显式查看和 `can_manage_collaborators`；离场时按组选择批量接收人或接受未分配；标签删除影响范围和二次确认；消息标签三档来源筛选 | CRM 继续使用线上列表/详情及数据管理入口；T2 分工清单只展示必要标识；离场批量改派复用移交任务 | 中（迁移整体高） | | 跨境支付 | 正式单同组固定只读、同组敏感信息开关、Collaborator、`can_execute_payment`、草稿删除、钱包余额/组剩余/账号上限拦截、历史收款账号按频道检索 | 沿用支付列表、详情和支付弹窗；组分配、冲正和账号上限复用配额管理入口 | 高 | | 项目迁移 | 选择来源组、迁移/不迁移确认、配额补齐、ACL 禁用说明、批次进度/失败/重试/摘要 | 作为加入组流程的后续步骤，不做全量项目搬运中心 | 高 | | 退组与数据移交 | 影响预检、标准逐组接收人、整体移交单一接收人、已有账号/新邮箱邀请、席位校验/替换席位保留、缺失组身份与配额确认、`WAITING_FOR_TARGET`、`REMOVING`、Owner/Assignee/有效显式对象关系替换、邀请和按组进度、失败重试、撤销、不可撤销确认、完成通知 | 成员详情进入移交任务页；整体移交复用逐组任务和邀请流程；不开放给 T2 | 高 | | 存量初始化 | 正常上线无用户操作；失败时显示组织异常和处理提示 | 后台原子初始化，避免上线迁移向导 | 无用户流程 | | 后续版本：组长审核放行 | 组级开关、立即/定时/手动闸门、`待我放行`、预约逾期、跨组通知 | 后续独立进入支付状态机设计，本版本不预埋入口 | 高 | | 待确认：月度下级分配 | 年/月发放周期、下级控制周期、年度父额度上的月度上限、重置锚点和结转 | 仍复用配额页；是否进入本版本确认后再设计 | 高 | | 待确认：组合并 | 源组、目标组、对象、成员、配额、资金与审计整体迁移 | 若本期不做，只提供冻结归档，不能用单账号迁组模拟 | 高 | ### 初步取舍 1. 先做 5 个共享交互原语：当前组切换、组/成员选择器、类型化 Scope 状态与可分配型 Scope 配置、授权来源展示、异步结果摘要/通知。 2. 入口保持收敛：成员/组/策略在子账号页，配额在配额页，CRM/内容监控策略在数据管理页，协作在项目弹窗，支付沿用支付页面。 3. 不在本阶段设计完整权限矩阵、权限模板、自定义角色、全量审计中心、会话级跨项目协作或数据导出入口；组合并先完成“是否进入本版本”的范围决策，再决定是否展开交互。 4. 进组迁移和退组移交不能压缩成单一确认弹窗；需要任务状态、进度、失败重试、结果摘要和系统通知。两者可以共用一套任务交互规范。 5. 所有业务动作至少要能解释五类阻断：无组织 Entitlement、无有效组身份、可分配型 Scope 的组织/组/账号上限不足、对象授权不生效、组织钱包余额不足。前端提示不能替代服务端拦截。