第 1 章｜角色与权限¶
Mica 的权限模型由三层组成：角色（Role） 决定基础能力范围，字段级权限（Field-level） 决定同一条记录中每个角色看到哪些字段，行级权限（Row-level） 决定一个用户能看到哪些公司 / 部门的数据。本章聚焦前两层，以及在多公司场景下的行级表现。
1. 六种角色¶
Mica 的角色枚举由后端统一维护，系统内一个用户同一时刻在同一公司下仅持有一个角色。
| 角色码（English） | 中文名 | 主要职责 |
|---|---|---|
admin |
管理员 | 全量权限；负责系统配置（公司、部门、用户、审批阈值、AI 路由）与数据维护 |
it_buyer |
IT 采购员 | 发起采购申请、跟踪订单进度、登记到货收货；可见全量业务数据 |
dept_manager |
部门负责人 | 审批本部门提交的 PR（小额通道）；仅可见本部门相关数据 |
finance_auditor |
财务审核 | 登记付款、登记发票；可见全量业务数据（财务视图） |
procurement_mgr |
采购经理 | 大额 PR 审批；采购全局视图，统一看板 |
requester |
需求方 | 提交本人 PR；仅可见自己提交的 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 / 合同（按其所属公司范围）
- 供应商策略、集中采购、价格异常复核
1.6 需求方（requester）¶
最小权限角色，由业务部门员工持有。职责：
- 仅可提交本人的采购需求
- 仅可查看自己提交过的 PR 及其下游订单、合同、付款、到货记录
- 看不到他人的 PR，看不到询价（RFQ）和发票模块
2. 权限矩阵¶
下表用"✓ / ✗ / 条件"描述六角色对核心动作的可用性。"条件"指该动作存在但有附加限制（金额、所属公司、所属部门等）。
| 动作 | admin | it_buyer | dept_manager | finance_auditor | procurement_mgr | requester |
|---|---|---|---|---|---|---|
| 创建 PR | ✓ | ✓ | ✗ | ✗ | ✓ | ✓ |
| 提交 PR（发起审批） | ✓ | ✓ | ✗ | ✗ | ✓ | ✓ |
| 审批 PR | ✓ | ✗ | 本部门 & 金额 ≤ 阈值 | ✗ | 金额 > 阈值 | ✗ |
| PR 转 PO | ✓ | ✓ | ✗ | ✗ | ✓ | ✗ |
| 登记交货 / 收货 | ✓ | ✓ | ✗ | ✗ | ✓ | ✗ |
| 登记付款 | ✓ | ✗ | ✗ | ✓ | ✗ | ✗ |
| 确认付款 | ✓ | ✗ | ✗ | ✓ | ✗ | ✗ |
| 登记发票 | ✓ | ✗ | ✗ | ✓ | ✗ | ✗ |
| 查看 PR | 全部 | 全部 | 本部门 | 全部（只读） | 全部 | 仅自己 |
| 查看 PO / 合同 / 到货 / 付款 | 全部 | 全部 | 本部门 PR 关联 | 全部（只读） | 全部 | 仅自己 PR 关联 |
| 查看 RFQ（询价） | ✓ | ✓ | ✗ | ✓ | ✓ | ✗ |
| 查看发票 | ✓ | ✓ | ✗ | ✓ | ✓ | ✗ |
| 配置系统（公司 / 部门 / 用户 / 阈值 / AI） | ✓ | ✗ | ✗ | ✗ | ✗ | ✗ |
审批阈值由管理员在系统配置中维护，默认将 PR 按金额路由到部门负责人或采购经理。当前版本仅支持单级审批，尚无多级串签与审批委托能力，这些能力在规划中。
2.1 行级权限速查¶
自 v1.21.0 起，行级权限严格按下列规则收敛（详见 decision 0020）：
- admin / it_buyer / finance_auditor / procurement_mgr → 看全部业务数据（无行级过滤）
- dept_manager → 仅看
pr.department_id == 我的部门的 PR，及其下游 PO / 合同 / 到货 / 付款 / 发票 / 交货计划 - requester → 仅看
pr.requester_id == 我的 PR，及其下游记录 - RFQ 模块对
dept_manager和requester完全隐藏
下游记录（PO / Contract / Shipment 等）通过 entity.po_id → PO.pr_id → 可见 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作为"省事"的日常角色使用；日常业务请另开一个低权角色账号。
当组织不得不让一人身兼多职时，至少应确保：
- 关键动作（付款确认、审批）都在审计日志中留痕；
- 定期（例如每月）由第三方角色抽查审计日志；
- 尽快招聘或协调岗位拆分，把风险恢复到结构性安全的状态。
版本 v1.21.0 · 维护人 helixzz