审核
业务背景(领导现在想通过某套系统检索人才,那么就会很在意部分敏感信息比如技能等级、绩效、工作完成度、团队融洽度等等,而像这些信息的导入,不可能全部都让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
等有空再做点图来说明把,前端上主要是监听状态,数据字典转换等比较麻烦,后端也就是正常的增删更改,判空之类的操作,所以也还算简单的。