🔐 角色与权限说明 (Roles & Permissions)
在律师事务所，数据的安全性不仅关乎商业机密，更直接关联到客户隐私保护、利益冲突规避以及律师职业道德规范。
本系统采用**“数据权限（谁能看）”与“操作权限（谁能改）”分离的精细化控制模型。核心原则是：“默认隔离，按需授权”**。
1. 角色定义 (Role Definitions)
系统预设了四种核心角色，不同角色拥有不同的基础数据视野：
| 角色 | 定义 | 基础数据视野 (Data Scope) |
|---|---|---|
| 👑 订阅者 (Subscriber) | 律所高级合伙人或管理层，拥有全局视野。 | 查看所有数据：可访问全所所有客户、联系人及子模块信息。 |
| 🛡️ 管理员 (Admin) | 系统运维或风控负责人，拥有全局管理与审计权。 | 查看所有数据：可访问全所所有数据，并拥有最高配置权限。 |
| ⚖️ 团队成员 (Member) | 普通律师、助理或项目组成员。 | 仅限授权数据：仅能查看被分配至**“服务团队”中的客户数据。默认对未分配的客户不可见**。 |
| 🚫 外部/无权限者 | 非团队成员或未分配人员。 | 无数据权限：无法在列表中看到该客户，也无法通过搜索找到。 |
2. 数据权限：可见性规则 (Data Visibility)
数据权限决定了用户能否在系统中“看到”某条记录。
2.1 全局可见层
- 适用角色：
订阅者、管理员 - 规则：无视“服务团队”分配，自动拥有全库所有客户档案、联系人信息及六个子模块（基本信息、决策链、法律问题等）的查看权。
2.2 团队隔离层 (默认规则)
- 适用角色：
团队成员 - 规则：
- 客户级隔离：用户只能看到自己作为成员被加入**“服务团队”**的客户。
- 子模块继承：一旦拥有客户的查看权，自动拥有该客户下所有子模块（如决策链、过往法律问题）的查看权。
- 默认拒绝：若未被加入某客户的“服务团队”，该客户及其所有子模块对该用户完全隐藏（包括搜索不可见）。
💡 示例： 律师 A 被加入“腾讯项目”的服务团队，他可以看到腾讯的所有信息。 律师 B 未被加入，他在列表中看不到“腾讯”，搜索“腾讯”也无结果。
3. 操作权限：功能执行规则 (Action Permissions)
操作权限决定了用户在“看得见”的基础上，能“做什么”。权限分为客户主体操作与子模块数据操作两个层级。
3.1 客户主体操作权限
针对客户档案本身的关键动作。权限来源：“服务团队”中的角色分配。
在“服务团队”子模块中，成员被分配为 读写 (Read-Write) 或 只读 (Read-Only)。
| 操作功能 | 描述 | 读写 权限成员 | 只读 权限成员 | 非团队成员 |
|---|---|---|---|---|
| 编辑客户 | 修改基础档案（名称、行业、级别等） | ✅ | ❌ | ❌ |
| 删除客户 | 逻辑删除/归档客户档案 | ✅ | ❌ | ❌ |
| 新建联系人 | 在该客户下添加新的联系人记录 | ✅ | ❌ | ❌ |
| 修改状态 | 变更成交状态、客户级别等关键状态 | ✅ | ❌ | ❌ |
| 查看客户 | 浏览档案及子模块 | ✅ | ✅ | ❌ |
注意：只有被明确分配为
读写角色的团队成员，才能执行上述修改类操作。只读成员仅能浏览，无法进行任何变更。
3.2 子模块数据操作权限
针对六大子模块（如跟进记录、决策链节点、法律问题记录）内部具体条目的增删改。 优先级逻辑：创建者优先 > 管理者优先 > 其他人只读。
| 操作功能 | 描述 | 数据创建者 | 管理员 / 订阅者 | 其他团队成员 |
|---|---|---|---|---|
| 编辑条目 | 修改自己或他人创建的子模块记录 | ✅ (仅限自己创建的) | ✅ (全量) | ❌ |
| 删除条目 | 删除子模块中的具体记录 | ✅ (仅限自己创建的) | ✅ (全量) | ❌ |
| 新建条目 | 在子模块中新增记录（如写一条跟进） | ✅ | ✅ | ✅ (需具备客户级读写权*) |
| 查看条目 | 浏览子模块内容 | ✅ | ✅ | ✅ |
*注：新建子模块条目通常要求用户对该客户拥有“服务团队”的读写权限。若仅为只读团队成员，通常也仅能查看子模块，无法新建记录（具体视系统配置而定，建议默认只读团队成员不可新建，以保持数据严谨性）。
场景举例：跟进记录 (Follow-up Records)
- 律师 A 创建了一条跟进记录：“今日与客户法务沟通案情”。
- 律师 A (创建者)：可以编辑修正错别字，也可以删除该记录。
- 合伙人 B (订阅者/管理员)：可以编辑补充批示，也可以删除不当记录。
- 律师 C (同团队其他成员)：只能查看，不可编辑或删除律师 A 的记录。
场景举例：决策链 (Decision Chain)
- 合伙人 B 添加了关键决策人“张总”。
- 合伙人 B (创建者/订阅者)：可随时调整张总的角色或移除。
- 助理 A (团队成员)：只能查看决策链图谱，不可篡改关键决策人信息，防止策略泄露或误操作。
4. 权限矩阵总览 (Permission Matrix Summary)
| 维度 | 功能点 | 订阅者/管理员 | 团队成员 (读写) | 团队成员 (只读) | 非团队成员 |
|---|---|---|---|---|---|
| 数据可见性 | 查看客户及子模块 | ✅ 全所可见 | ✅ 仅授权客户 | ✅ 仅授权客户 | ❌ 不可见 |
| 客户级操作 | 编辑客户基础信息 | ✅ | ✅ | ❌ | ❌ |
| 删除/归档客户 | ✅ | ✅ | ❌ | ❌ | |
| 新建联系人 | ✅ | ✅ | ❌ | ❌ | |
| 修改客户状态 | ✅ | ✅ | ❌ | ❌ | |
| 子模块操作 | 新建子模块记录 | ✅ | ✅ | ❌ (建议) | ❌ |
| 编辑子模块记录 | ✅ (全部) | ⚠️ (仅自己创建的) | ❌ | ❌ | |
| 删除子模块记录 | ✅ (全部) | ⚠️ (仅自己创建的) | ❌ | ❌ |
5. 特殊场景处理
5.1 利益冲突检索时的权限穿透
- 场景：风控合规官（通常为
管理员角色）需要进行全库利益冲突检索。 - 机制：即使普通律师将某客户标记为高度保密，
管理员和订阅者依然拥有**查看“过往法律问题”**的权限，以确保全所风控安全。这是律所 CRM 中“安全高于隐私”的特例。
5.2 人员离职与权限回收
- 自动回收：当用户账号被禁用，其作为“团队成员”的身份自动失效。
- 数据归属：
- 该用户创建的子模块数据（如跟进记录）不会被删除，保留在系统中。
管理员或新的读写成员可以继续查看和编辑这些历史数据，确保案件办理的连续性。
5.3 权限升级流程
- 若
只读成员需要编辑客户信息，必须由现有的读写成员或管理员进入“服务团队”设置，将其角色升级为读写。 - 严禁私自扩大权限，所有权限变更建议在“跟进记录”中留痕备注。
💡 最佳实践
- 最小化读写权：对于大型案件，建议仅主办合伙人和承办律师拥有
读写权限，助理和外围律师设为只读，防止误操作关键决策链信息。- 定期审查团队：每季度检查“服务团队”名单，及时移除已结案项目的外部人员或离职员工。
- 创建者责任制：鼓励律师对自己录入的“跟进记录”和“法律风险”负责，系统逻辑保障了只有创建者和管理员能修改，避免了责任推诿。
🚀 下一步
权限体系已明确，现在让我们开始实际操作。 请前往 第二章：客户管理 - 基础档案构建，学习如何以
读写权限创建一个标准的律所客户档案。