审核
业务背景（领导现在想通过某套系统检索人才，那么就会很在意部分敏感信息比如技能等级、绩效、工作完成度、团队融洽度等等，而像这些信息的导入，不可能全部都让HR或者部门领导来操作，工作量大且效率低下，就还是需要本人来填写这些信息，像刚刚提的敏感信息就可能需要涉及到审核的过程）
交代完业务背景就开始进入正题，大概审核流程会分为什么，应该如何进行设计。
审核流程设计
确定审核逻辑流程
- 审核人 审核人是否涉及多层审批，如果是，那就需要设计一个工作流进度表控制审核流程
- 审核项 那些信息是需要审核的，审核时是提交整个表单，还是仅针对某项进行审核
- 审核展示 确定展示权限，谁可以看到审核，谁只能看到请求页面【部门领导、普通员工、老板】
由于此处只涉及一层审核，所以在权限上仅限定了领导层用于展示部门所有人审核。审核项由于是单项的，所以仅做了单项的审核表单，如果是单页面内【比如绩效、工作年限都需要审核】那可以加一张审核表单项表用于存储审核信息，在审核表中关联审核表单项的id主键，可以用“15, 16”来存储，后期做逗号分隔即可。
数据库表设计
根据刚才说的逻辑流程，这次设计中没有外加设计一张工作流程表以及审核表单项表，这里仅做了单审核表，实现整个审核流程【展示、审批、请求等】如果对审核有更高的需求，可考虑设计更多内容，比如角色权限表，审核流程定义表【存储些审批模板】
审核表:
| 字段名 | 字段解释 | 补充说明 |
|---|---|---|
| id | 自增主键 | 若并发困难，考虑分段自增id，并做缓存处理 |
| applicantId | 申请人id | 尽量与数据库字段一致，避免做多余的数据类型转换 |
| accessorId | 审核人id | 同上 |
| auditFormId | 审核项表单id | 这里是审核项内容的存储【拓展表】，也可以直接合并进来，如果审核流程不复杂的话 |
| auditStatus | 审核当前状态 | 可做数据字典 |
| startTime | 开始时间 | 同下 |
| endTime | 结束时间 | 这个时间也可以放在工作流程表中 |
审核表单项表
| 字段名 | 字段解释 | 补充说明 |
|---|---|---|
| id | 自增主键 | 表单项id |
| itemId | 审核项的id | 【比如是对绩效表id=43的工作年限进行审核，这里就存储43，以便审核通过时对其进行修改】 |
| oldValue | 旧值 | 发起审核前值为xxx |
| newValue | 新值 | 请求审核修改为的值为 |
| itemDBName | 审核项数据库字段名 | 因为审核通过后，需要修改指定项为新值，就需要知道该项的名字，当然这里也可以是实体项的名字，在接口进行处理也可以 |
| itemUpdateUrl | 审核项修改接口URL | 可以修改该项的接口URL |
再提供一些相关表的设计思路
工作流驱动表
| 字段名 | 字段解释 | 补充说明 |
|---|---|---|
| id | 自增主键 | 主键 |
| flowId | 流程id | 用于表示当前流程审核结点为【比如到HR审核了】 |
| flowPersonId | 当前审核人id |
还有就像流程定义表、流程历史表等等
后端接口编写
增删更改就没什么好说的了
前端页面设计
发起审核弹窗页面
当然如果不希望与表单页面耦合度高，可以抽象出到我的请求页面，设计一张审核项表以及流程表，定义好审核项数据库字段名，修改接口URL，在我的请求页面发起审核也可以，这样子不会影响到编辑表单页面。
但是当然绑定编辑页面，就可以让用户使用起来更方便，也能知道修改某些敏感信息需要发起审核，也可以减少要操作的内容。
主要开发点
- 监听敏感信息 当敏感信息触发时，将编辑按钮换为发起审核按钮，并以消息box形式进行提醒该项需要审核。
- 发起审核后 点击按钮后，应该让编辑页面的敏感信息栏禁止操作了，且是为原本值，只有当审核结束后才可以继续操作。
- 新增表单 若为新增表单，那么就没有旧值，这里最好给用户默认一个旧值，防止一些空异常出现，且也要防止用户发起审核后，直接关闭了新增页面，导致审核通过时修改的是空的数据。所以这里最好是发起审核后，保存外面的表单，防止对空数据进行操作。
- 审核人 编写当前用户审核人列表接口
我的审核页面
- 审核通过 修改审核状态+调用接口更改审核项值为新值
- 审核不通过 修改审核状态
我的请求页面
- 查看审核状态
- 若不通过给一个再次发起审核的机会
查看部门请求页面
- 查看部门申请状况
TODO
等有空再做点图来说明把，前端上主要是监听状态，数据字典转换等比较麻烦，后端也就是正常的增删更改，判空之类的操作，所以也还算简单的。
