审批与约束规则
菜单目录 /approval 下有两个页面，它们解决的是不同的问题，容易混淆：
| 页面 | 实体 | 解决什么 |
|---|---|---|
审批中心 /approval/review | SysReview + SysReviewLog | 通用的单据审批：某条业务数据要人来批一下 |
约束规则 /approval/constraint | SysConstraintRule + SysConstraintRuleItem | RBAC 约束引擎：授权本身合不合规 |
再加上第三套：工作流 处理多步骤、有分支、要等很久的流程。三者的选型见文末。
审批中心
SysReview 是一张通用审批单，特点是不绑定具体业务表——靠三个字段挂到任意业务对象上：
| 字段 | 说明 |
|---|---|
ReviewCode / ReviewTitle | 单号与标题 |
ReviewType | 业务类型（字符串），由接入方定义 |
EntityType / EntityId | 指向被审批的业务对象（多态关联） |
BusinessData | 提交时的业务数据快照（JSON） |
ReviewContent / ReviewDescription | 内容与说明 |
ReviewStatus | Pending / 已通过 / 已拒绝 等 |
ReviewResult | 审批结果 |
Priority | 优先级 |
SubmitUserId / SubmitTime | 提交人与时间 |
CurrentReviewUserId | 当前处理人 |
SysReviewLog（按月分表）记录每一步的操作留痕。
接入方式
业务写侧
│ 落业务表（状态=待审批）
│ 建 SysReview：EntityType="Contract", EntityId=合同Id, BusinessData=快照JSON
▼
审批人在审批中心处理 → 通过 / 拒绝 → 写 SysReviewLog
▼
业务侧据审批结果回写业务表状态BusinessData 快照的意义
审批发生在提交之后，中间业务数据可能已经被改。快照保证审批人看到的是提交那一刻的内容，也让事后追溯有据可查（「当时批的是什么」）。
代价是快照与当前数据可能不一致——通过后回写业务表时要考虑这一点，必要时做冲突检查。
与工作流的分工
审批中心是单步的：一个单子、一个（或一组）审批人、一次决定。
要多级审批、会签、条件分支、超时自动处理、并行分支汇合——用 工作流，它的 UserTask 活动天然支持或签/会签/依次审批与转办加签。
约束规则引擎
这套东西管的不是业务数据，而是权限本身：判断一次授权（或一次操作）是否违反组织的合规规则。
SysConstraintRule 的结构：
| 字段 | 说明 | 默认 |
|---|---|---|
RuleCode / RuleName | 规则编码与名称 | — |
ConstraintType | 约束类型（见下表） | SSD |
TargetType | 约束对象类型（角色 / 权限 / …） | Role |
Parameters | 规则参数（JSON），不同类型含义不同 | — |
ViolationAction | 违规时怎么处理（见下表） | Deny |
Priority | 优先级 | 0 |
EffectiveTime / ExpirationTime | 生效时间窗 | — |
Status | 启停 | Enabled |
SysConstraintRuleItem 是规则的目标项集合（如「这三个角色互斥」里的那三个角色）。
八类约束
| 类型 | 值 | 含义 | 典型场景 |
|---|---|---|---|
| SSD 静态职责分离 | 0 | 一个用户不能同时被授予这组角色 | 「制单员」与「审核员」不能是同一人 |
| DSD 动态职责分离 | 1 | 可以都有，但同一会话内不能同时激活 | 平时可切换身份，单次操作只能用一个 |
| 互斥约束 | 2 | 指定对象互相排斥 | 两个权限不能共存 |
| 基数约束 | 3 | 数量上限 | 「超级管理员最多 3 人」 |
| 先决条件 | 4 | 授予 A 前必须先有 B | 给「财务审批」前必须先有「财务查看」 |
| 时间约束 | 5 | 只在特定时间窗内有效 | 临时权限只在项目期内 |
| 位置约束 | 6 | 按 IP 限制 | 财务操作只能在办公网 |
| 自定义 | 99 | 扩展点 | — |
四种违规处理
| 动作 | 值 | 效果 |
|---|---|---|
Deny 拒绝 | 0 | 直接阻断，授权/操作失败 |
Warning 警告 | 1 | 放行但提示 |
Log 记录日志 | 2 | 静默放行，只留痕 |
RequireApproval 转审批 | 3 | 转成审批流程，批了才生效 |
上线新规则的姿势
直接上 Deny 风险很大——存量数据里往往已经有一批违规状态，一开就把人挡在外面。
推荐路径：先用 Log 跑一段时间，从日志里看有多少违规、都是谁；清理完存量后改成 Warning 观察；确认干净了再切 Deny。
违规检查发生在授权时，不是登录时
约束规则参与的是「能不能把这个角色/权限授给这个人」以及请求期的判定链。已经授出去的存量违规组合不会自动回收——要清理得跑一次巡检。
三套机制怎么选
| 你的需求 | 用哪套 |
|---|---|
| 一条业务数据要人批一下，一步搞定 | 审批中心 SysReview |
| 多级/会签/分支/超时/并行的长流程 | 工作流 |
| 「谁不能同时拥有哪些角色」这类合规规则 | 约束规则引擎 |
| 用户主动申请某个权限，管理员审批 | 权限申请（SysPermissionRequest，见 权限模型） |
它们可以组合：约束规则的 RequireApproval 就是把违规转成审批单；工作流的 UserTask 也可以承载复杂的权限审批流。