# jeecgboot warmflow

**Repository Path**: nj_wangzhen/jeecgboot-warmflow

## Basic Information

- **Project Name**: jeecgboot warmflow
- **Description**: jeecgboot3.8.3 集成了 warmflow1.8.4 的一个版本 (主要是验证warmflow基本用法）
- **Primary Language**: Java
- **License**: Apache-2.0
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 1
- **Forks**: 1
- **Created**: 2025-12-24
- **Last Updated**: 2025-12-28

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

集成的版本 JeecgBoot 3.8.3 warmflow 1.8.4
视频教程（共8个视频） https://www.bilibili.com/video/BV1ibqaBVEga?t=471.0 


因为本人经常使用jeecgboot开源版开发一些小项目，有时需要使用到工作流的一些功能（使用场景比较简单）， 网上比较多的是jeecgboot集成flowable,activity之类的开源工作流，这类工作流比较笨重，大部分的功能使用不到 近来接触到warmflow工作流（因为rouyi框架集成了这个），这个流程引挚比较小巧（一共7、8张表），适用一些简单的流程场景 我个人比较偏爱jeecgboot的界面的商业风格， 所以我就参考rouyi框架的前后端源码（感谢rouyi开发团队的无私精神），为jeecgboot也集成了warmflow供喜爱jeecgboot框架的开发者参考（感谢jeecgboot开发团队提供的非常好用的开源框架）

**再次声明此项目只是我做研究使用的一个试验版本，功能比较简单且不会再更新，仅供爱好者参考 **


提供了一个示例的请假流程 (涉及的所有用户密码均为123456)

1、所有人都可以发起请假申请，申请完后可以修改、删除申请， 点提交按钮点即生成请假流程 （后台逻辑是发起流程调用instance.start，流程生成第一个申请待办，紧接着后台程序又调用task.pass方法将申请待办提交到组长角色审批环节） 2、在组长角色审批节点定义的办理人为 组长角色 （此角色中有两个用户 teamLeader, temLeader1 )， 这个待办会在这两个用户的 “我的待办”列表中出现，其中一个用户点击办理进入到处理页面后即给这个待办任务上锁 ，另一个用户的待办列表前这个任务的流程编号前出现一把小锁， 在任务处理页面， 用户可以有以下几种操作 1）点提交按钮， 根据审批意见（传递条件）生成下一个经理/董事长会签待办任务 2）点退回按钮， 根据节点定义的退回节点 重新生成 请假申请任务（此任务原来是谁发起的还由谁来处理）， 请假申请任务的发起人由待办处理任务时可以点终止按钮结束流程，或者修改 请假申请表单内容后再次点提交按钮 提交生成 组长角色审批环节 （因为在组长角色审批节点定义了预警期限和超期期限，所以当此环节被生成时 会根据当前创建任务时间， 是否是工作日， 是否是9:00到18:00, 是否是节假日， 预警期限（小时）， 超期期限（小时） 这些因素为任务活动更新预警时间和超期时间 ， 已超预警/超期时间还未处理的任务在待办列表中会用不同颜色作提醒）
3、 经理/董事长会签 环节 因为定义了协作方式是会签， 并且侯选人定义了经理和董事长(manager,chairman)两个人， 那这两个人必须全都处理完流程才会推进到下一个环节 （会签任务不受锁的影响）， 在会签环节只要有一个人审批为不同意 流程都会走审批拒绝分支 ， 此处的条件是counterPassRate投票率，投票率只有等于1于（说明两个人都同意）才会推进到人事归档环节， 投票率的变量是在任务传递时，使用流程实例标识和活动实例标识到流程审批表中去找审批记录 counterPassRate = 通过的总数/总的审批数, 拿到了就会将counterPassRate设置为流程变量 （只有会签环节才会这么做） 4、人事归档 （hr) ， 此处偷懒就直接用了个审批表单代替一下，没什么用处，提交即结束流程 ；

关于任务处理的表单的说明：

1、如果在任务节点上 “是否是审批表单”选否， 则处理任务界面出现的将是表单路径上配置的表单， 所有的非审批表单的任务表单都应该有一个processPass的回调函数， 在任务被提交时会调用这个回调函数让开发人员有机会在任务传递前处理业务数据，processPass返回true时，才会真正的去调用task.pass传递任务， 任务表单还会被透传流程实例标识，任务标识， 业务记录标识 这三个信息，开发人员需借助这些信息处理业务数据

2、如果在任务节点上 “是否是审批表单”选是， 则处理任务界面出现的将是一个通用的审批表单， 而表单路径上配置的表单 会做为 通用审批表单的第一个tab页中的上半部分的信息展示 ， 并且会被透传流程实例标识，任务标识， 业务记录标识， disabled="true" 这四个信息， 因为在通用审批表单中 业务信息应该是只读的， （为了复用业务表单和只读的业务表单所以多传了一个disabled属性，看着用）， 在本示例的 第一个流程环节就复用了请假申请表单的页面（并且在审批表单中显示为只读模式）

关于任务抄送的说明

如果在任务节点上定义了抄送者 （可以是用户，角色，部门）， 在任务finish的监听里发布了SendInSiteMessageEvent事件， 在监听此事件的方法中向抄送者发送了模板消息（这个自行按业务去实现，此处只做了个例子）

关于预警、超时的说明 如果在任务节点上定义了预警期限或超期期限， 在任务create的监听里发布了SetWarningOverTimeEvent事件，在监听此事件的方法中根据前面所列的影响因素，计算出预警时间和超期时间再更新到任务的相关字段里

重要说明：以下为对warmflow扩展的一些字段和表 ， 如果版本升级，务必考虑周全

flow_task 表中的lock_by,early_warning_time,overdue_time flow_approve 表 flow_instance_biz_ext 表 （这个表应该存一些关于业务记录的一些说明，可以在待办任务的业务描述中显示），在示例程序中没有使用，请自行按业务改造