第 1 章｜角色与权限

Mica 的权限模型由三层组成：角色（Role） 决定基础能力范围，字段级权限（Field-level） 决定同一条记录中每个角色看到哪些字段，行级权限（Row-level） 决定一个用户能看到哪些公司 / 部门的数据。本章聚焦前两层，以及在多公司场景下的行级表现。

1. 五种角色

Mica 的角色枚举由后端统一维护，系统内一个用户同一时刻在同一公司下仅持有一个角色。

角色码（English）	中文名	主要职责
admin	管理员	全量权限；负责系统配置（公司、部门、用户、审批阈值、AI 路由）与数据维护
it_buyer	IT 采购员	发起采购申请、跟踪订单进度、登记到货收货
dept_manager	部门负责人	审批本部门提交的 PR（小额通道）
finance_auditor	财务审核	登记付款、登记发票、财务视图只读查看 PR/PO
procurement_mgr	采购经理	大额 PR 审批；采购全局视图，统一看板

1.1 管理员（admin）

系统最高权限。通常由 1–2 名核心运维 / IT 负责人持有。职责：

• 维护公司主体、部门、用户、供应商、物料主数据
• 配置审批金额阈值（决定 PR 走"部门负责人"还是"采购经理"通道）
• 配置 AI 模型路由与特性开关
• 应急排查：查看审计日志、冻结用户、重置账号状态

1.2 IT 采购员（it_buyer）

采购主线的发起人。职责：

• 创建与维护采购申请（PR），必要时反复修改后提交
• 跟踪 PR 审批状态，被退回时修订重新提交
• 将已批准的 PR 转为采购订单（PO）
• 登记到货信息（收货 / 多批次 shipment）、序列号（如硬件资产）
• 对接供应商日常沟通

1.3 部门负责人（dept_manager）

对本部门提交的 PR 进行小额审批。职责：

• 审批 / 退回 / 驳回本部门 PR（仅金额在阈值以下的 PR 走该角色）
• 查看本部门的采购执行情况（PR / PO / 收货进度）
• 不参与付款与发票登记

1.4 财务审核（finance_auditor）

财务侧的执行与留痕角色。职责：

• 登记付款记录（payment_record），维护付款计划与多期付款
• 登记发票（invoice），执行发票与 PO / 收货的三单匹配
• 只读查看 PR / PO 的财务相关字段
• 不发起采购、不审批业务 PR

1.5 采购经理（procurement_mgr）

全局视图 + 大额审批。职责：

• 审批金额超过部门阈值的 PR（大额通道）
• 查看所有公司主体、所有部门的 PR / PO / 合同（按其所属公司范围）
• 供应商策略、集中采购、价格异常复核

2. 权限矩阵

下表用"✓ / ✗ / 条件"描述五角色对核心动作的可用性。"条件"指该动作存在但有附加限制（金额、所属公司、所属部门等）。

动作	admin	it_buyer	dept_manager	finance_auditor	procurement_mgr
创建 PR	✓	✓	✗	✗	✓
提交 PR（发起审批）	✓	✓	✗	✗	✓
审批 PR	✓	✗	本部门 & 金额 ≤ 阈值	✗	金额 > 阈值
PR 转 PO	✓	✓	✗	✗	✓
登记交货 / 收货	✓	✓	✗	✗	✓
登记付款	✓	✗	✗	✓	✗
确认付款	✓	✗	✗	✓	✗
登记发票	✓	✗	✗	✓	✗
查看全部数据（跨部门 / 跨公司）	✓	仅本人相关	仅本部门	财务视图只读	全采购视图
配置系统（公司 / 部门 / 用户 / 阈值 / AI）	✓	✗	✗	✗	✗

审批阈值由管理员在系统配置中维护，默认将 PR 按金额路由到部门负责人或采购经理。当前版本仅支持单级审批，尚无多级串签与审批委托能力，这些能力在规划中。

3. 字段级权限

字段级权限由后端统一控制。含义是：同一条记录的同一份 JSON，对不同角色剪出不同的可见字段集合——角色看不到的字段不会出现在响应里。

几个关键举例（以当前实现为准）：

• 采购订单（purchase_order）：admin / procurement_mgr / finance_auditor 可见全部字段；it_buyer 和 dept_manager 看不到一部分财务/来源元数据。
• it_buyer 可见 source_type / source_ref，但看不到 amount_paid / amount_invoiced（财务进度字段）。
• dept_manager 看不到 source_type / source_ref / created_by_id / amount_paid / amount_invoiced，仅保留订单核心与收货进度。
• 付款记录（payment_record）：admin / finance_auditor / procurement_mgr 看全部；it_buyer 看不到 payment_method / transaction_ref / notes 等敏感执行细节；dept_manager 只保留最核心的金额与状态字段。
• 发票（invoice）：finance_auditor 看全部；it_buyer / dept_manager 只读到基本抬头与金额，看不到税号、税额、匹配标记等内部字段。
• 采购申请（purchase_requisition）：几乎所有角色都可见全部字段——PR 作为业务发起源头，透明度优先。

这意味着：同一条 PO 给 it_buyer 看，和给 finance_auditor 看，JSON 结构会不一样。前端需要按服务器返回的实际字段渲染，不要假设字段一定存在（服务器还会下发 FieldManifest 告诉前端哪些字段该显示）。

4. 跨公司 / 多公司角色

当一个用户在多个公司主体都有角色（例如集团内轮岗的采购经理）时：

• 默认视图：登录后自动合并所有授权公司的数据，呈现一份汇总列表。
• 公司筛选器：顶部导航提供"公司筛选器"下拉，切到单一公司主体视图。筛选器与列表、看板、报表联动。
• 角色合并规则：若用户在 A 公司是 dept_manager、在 B 公司是 it_buyer，则对 A 公司的数据行使"部门负责人"能力，对 B 公司的数据行使"IT 采购员"能力，两者不互相溢出。
• 审批归属：审批任务严格按审批单所属公司分派，不会把 A 公司的 PR 发给 B 公司的部门负责人审批。

（截图待补）

5. 职责分离建议

一些组合在技术上可以赋予，但出于内控与风控考虑强烈不建议：

• 同一人既是 finance_auditor 又是 it_buyer：会出现"自己发起采购、自己登记付款"的情况，既当裁判又当运动员。应拆给两个人。
• 同一人既是 dept_manager 又是 procurement_mgr：会出现"自己审自己的 PR"的上下文（本人发起的 PR 仍需走审批）。建议由不同自然人持有。
• admin 尽量只授予 1–2 人：admin 可绕过所有字段级限制，是审计关注的重点账号。不要把 admin 作为"省事"的日常角色使用；日常业务请另开一个低权角色账号。

当组织不得不让一人身兼多职时，至少应确保：

1. 关键动作（付款确认、审批）都在审计日志中留痕；
2. 定期（例如每月）由第三方角色抽查审计日志；
3. 尽快招聘或协调岗位拆分，把风险恢复到结构性安全的状态。

---

版本 v0.5.0 · 维护人 helixzz