审批流(二)

一.回顾

上篇说到了一个无法确定当前节点到底轮到谁的问题.

更加完整的数据库:

checkFlow:

baseProjecct:

上篇说到每个流程必定为一个发文所有,对应的就是baseProject的一行数据.

解释一下baseProject各列的含义:

checkState:当前审批到了哪个节点了,记录的是上一个完成的节点

delete:当前发文是否已经删除了

isDone:当前发文审批是不是通过了

有了baseProject的checkState,这样2个表结合起来查找,就能够找到现在应该轮到哪个节点来处理了//

二.具体的审批流怎么走

1.打草稿

2.发起审批

3.发起人:查看审批状态

审核人:查看需要自己审批的流程

4.查看已完结的审批(如果审批被完全打回了,则回到草稿状态,待发)

界面如下(泄漏一下某公司的部分OA界面应该没问题把...):

三.公文起草

增加一个project而已,具体的project有个叫做baseProjectId的外键,关系图:

这一步做了两件事:

1.往baseProject插入一条数据

2,往发文表插入一条数据,同时2个表相关联

此时baseProject字段的值:checkState=null

四.待发公文:

首先列出待发的公文,这里待发的公文有2:

1.从公文起草过来的刚起草的公文

2.审批不通过,被完全打回来的公文,这里后面再说

反正就是查找 baseProject中checkState=null的project,

所以说如果被完全打回来了,要记得把checkState设置为null,这个放后面说

发公文就是找到发文中对应的流程id,然后把一整套东西从flow拷贝到checkFlow中去(从模版复制到实际的项)

五.待办公文

这里的意思其实就是查看作为发起人,我发起的,正在审批中的发文

那么只要查看checkstate is not null 而且 isDone ! = 1的

六.已办公文

查找isDone=1的

七.待办发文

这个要求session中有个user,通过user我能够得到user的部门

checkFlow是通过部门来审批的,所以知道了部门我就能够知道哪些是轮到我该审批的项,把它们列出来.

这里的项包括:

1.正常流程往前走的

2.我同意了后,后面的人不同意,被打回来,要求我修改或者往回打的

3.我也往回打了以后,发文经修改后再次需要我审批的

列出了所有的需要处理的项,然后对当前节点进行修改.

最后需要通过baseProject的数据

如果我是第一个审批的人,我不同意了,那就要把checkState设置为null,这样发起人就能够在待发公文中看到

如果我是最后一个审批的人,我同意了,那就要把isDone设置为1

更多细节,后面再说