SpringBoot+Flowable 审批「反悔」三态:发起人撤回、已办取回与驳回后重提如何用 viewType 门禁落地

SpringBoot+Flowable 审批「反悔」三态:发起人撤回、已办取回与驳回后重提如何用 viewType 门禁落地
SpringBootFlowable 审批「反悔」三态发起人撤回、已办取回与驳回后重提如何用 viewType 门禁落地演示地址http://ruoyioffice.com | 源码1·GitHubruoyi-office | 源码2·GitCoderuoyi-office | 源码3·Giteeruoyi-office | 微信17156169080备注「RuoYi Office」加签、转办改的是「谁来审」超时管的是「人不审怎么办」。还有一类高频却最容易做错的需求人要反悔——填错了要撤、批错了要取回、驳回了要改完再提。三件事听起来像一个「取消」落到 Flowable 上却是三条完全不同的状态路径。本文讲 RuoYi Office 如何把它们拆开并用移动端viewType把按钮露对。▲ 全景发起人撤回已办取回驳回后重提底部 viewType 门禁my / done / todo引言一个「撤回」按钮三种引擎语义产品经理常说「给我加个撤回。」研发需要反问三句谁在撤发起人还是已经点过通过的审批人撤到哪回到开始节点改单还是把下一节点的任务拉回来撤完什么态实例直接取消还是变成可编辑后再次提交混成一个 API轻则按钮乱闪重则历史任务、业务单据状态与消息通知全部对不上。RuoYi Office 明确拆成三态反悔态角色典型入口核心 API结果发起人撤回制单人我的 · 审批中PUT .../task/withdraw-to-start回到开始可改单重提已办取回刚办完的审批人已办GET .../get-withdraw-status→withdraw任务回到自己手里驳回后重提制单人我的 / 待办POST .../process-instance/resubmit变量更新 审批中再走一、发起人撤回withdraw-to-start1.1 业务语义流程还在跑RUNNING发起人发现金额/附件填错希望整单撤回到开始节点改完再往下推——不是直接delete掉实例。1.2 服务端校验链// BpmTaskServiceImpl#withdrawProcessToStart// 1. 流程实例存在且仍在运行// 2. 当前用户必须是 startUserId// 3. 流程定义 allowWithdrawTask 未关闭// 4. 子流程有 superExecutionId不允许撤// 5. 找到 StartEvent按「退回」逻辑撤到开始关键点权限只能撤自己的单。开关模型/定义级allowWithdrawTask财务类强管控流程可关掉。实现复用退回return到 StartEvent 的路径而不是另写一套「假取消」保证历史意见里留下「发起人撤回xxx」。控制器入口PutMapping(/withdraw-to-start)Operation(summary撤回流程到开始节点)publicCommonResultBooleanwithdrawProcessToStart(ValidRequestBodyBpmTaskWithdrawReqVOreqVO){taskService.withdrawProcessToStart(getLoginUserId(),reqVO.getProcessInstanceId(),reqVO.getReason());returnsuccess(true);}1.3 前端投影移动端viewType my status RUNNING→ 底栏「撤回」。成功后原地loadProcessInstance()状态进入可重提分支表单变可编辑。▲ 撤回完成后印章变为「已撤回」底栏切换为「提交」表单字段可改时间线会保留撤回意见多次撤回也能讲清故事▲ 进度区可见「发起人撤回123 / 234」与再次发起节点二、已办取回get-withdraw-status withdrawTask2.1 业务语义审批人刚点通过下一节点还没处理或规则允许希望把自己办过的那一笔取回来重审。这不是发起人撤回也不是管理员干预。2.2 先问能不能取再执行GetMapping(/get-withdraw-status)publicCommonResultBpmTaskRespVOgetWithdrawStatus(RequestParam(taskId)StringtaskId){// 查历史任务 → 流程实例 → 定义信息// 复用 buildWithdrawCheckData写入 withdrawable / withdrawDisableReason}VO 上暴露privateBooleanwithdrawable;privateStringwithdrawDisableReason;常见不可取回原因产品要能说清下一节点已办理 / 流程已结束定义关闭取回非本人历史任务会签/多实例规则不满足前端viewType done且带taskId时调用该接口仅当withdrawable true显示「取回」。2.3 执行取回PutMapping(/withdraw)publicCommonResultBooleanwithdrawTask(RequestParam(taskId)StringtaskId){taskService.withdrawTask(getLoginUserId(),taskId);returnsuccess(true);}移动端对应PUT /bpm/task/withdraw?taskId...。取回后该用户重新出现待办列表刷新靠bpm-list-refresh。与「退回给发起人」不同取回是审批人后悔自己的同意目标节点是自己刚完成的任务上下文。三、驳回 / 撤回 / 未提交后的重提resubmitProcessInstance3.1 何时出现「提交」而不是「通过」实例状态落在REJECT审批不通过WITHDRAW已撤回NOT_START未提交草稿态等且入口是my或todo时详情底栏显示「提交」。3.2 服务端改变量 把发起人任务审批掉publicvoidresubmitProcessInstance(LonguserId,BpmProcessInstanceResubmitReqVOreq){// 1. 实例存在// 2. 必须是发起人// 3. 找到发起人待办 findStartUserTask// 4. 更新 variables / 自选审批人// 5. updateProcessInstanceRunning// 6. approveTask(发起人任务, reason重新提交)}设计意图不新开一条实例避免业务单号、附件、关联单据分裂用「审批发起人节点」驱动引擎往下走和首次提交对称CUSTOM 单据可先走业务submitNORMAL 则带variables重提移动端if(formTypeCUSTOM){awaitformDetailRef.submit()}else{awaitresubmitProcessInstance({processInstanceId,variables:formDetailRef.getFormValues(),})}四、状态机总览给产品 / 测试的一张图发起 │ ▼ [审批中 RUNNING] / | \ 发起人撤回 正常通过/拒绝 审批人取回(已办) │ │ │ ▼ ▼ ▼ [已撤回] [通过/不通过] [该节点回到待办] \ │ \ 驳回后改单 \ │ └──► [可重提] ──resubmit──► [审批中]测试用例建议至少覆盖非发起人调withdraw-to-start→ 失败关闭allowWithdrawTask→ 按钮不出现或接口拒绝下一节点已审 →withdrawablefalse且文案可读非发起人 resubmit → 失败移动端copy入口 → 不出现撤回/取回/提交五、和 viewType 门禁如何咬合上一篇《移动审批详情》讲了同一页四入口反悔三态是门禁表的「右半边」viewTypeRUNNINGREJECT / WITHDRAW / NOT_START其它todo有 todoTask → 办理按钮否则可能撤回可重提只读或办理my撤回重提只读done——按 withdrawable 取回copy只读只读只读后端校验是安全底线viewType是体验底线——避免用户在错误入口看到「看起来能点、点了才报错」的按钮。六、和退回、取消、作废的边界动作谁发起引擎效果业务单据退回 return当前审批人回到指定历史节点通常保持原单待修改节点再办发起人撤回发起人回开始同单可编辑重提已办取回历史审批人任务回到自己下游未继续时才允许取消/作废发起人或管理员实例结束单据作废一般不重提同实例驳回 reject审批人实例不通过走重提或新开单产品策略把「取消」和「撤回」做成同一个按钮是历史债高发区。七、端到端体验建议发起一笔报销/请假审批中从「我的」点撤回看轨迹意见与印章。改金额后点提交观察是否不换单号、重新进入审批中。用审批人账号通过后立刻进「已办」看取回是否出现让下一节点先办完再看取回是否禁用。故意用非发起人调接口确认权限错误。对照流程定义开关验证关闭撤回后的产品文案。在线演示http://ruoyioffice.com源码仓库GitHub | GitCode | Gitee常见问题FAQ撤回后实例 ID 会变吗不变。重提也是同一processInstanceId靠发起人节点approveTask往下推业务businessKey保持连续。取回和退回可以互相替代吗不能。退回是当前办理人把流程打回历史节点取回是历史办理人在下游未推进时把自己的办理收回。角色、时机、校验都不同。为什么重提要「先改成审批中再 approve」引擎侧发起人节点仍是 UserTask业务状态要与 RUNNING 对齐消息、列表筛选、印章才会一致。只改业务表不推动任务待办会悬空。子流程为什么禁止发起人撤回父/子执行实例交织简单撤到主流程 StartEvent 易造成脏执行与重复通知。需要的话应做「父流程级撤销策略」而不是复用单实例撤回。和移动审批详情文什么关系那篇讲「壳」同一详情如何嵌单与露按钮本文讲「态」三种反悔 API 与门禁表。建议一起读。结语审批反悔不是一个按钮的文案问题而是三条受控的状态路径发起人撤回到开始、审批人有条件取回、驳回/撤回后同实例重提。RuoYi Office 用 Flowable 退回能力与任务校验把引擎做稳用viewType把门禁做对——产品可以说清测试可回归移动端与 PC 共用同一套/admin-api/bpm。你们公司现在是「只能管理员干预」还是已经对业务开放发起人撤回取回规则卡在哪条禁用原因欢迎评论区交流。想要体验 RuoYi Office 的强大功能在线演示http://ruoyioffice.com/web/账号 admin / admin123源码仓库GitHub | GitCode | Gitee技术咨询添加微信17156169080备注「RuoYi Office」⭐如果觉得不错请给个 Star 支持一下

最新新闻

日新闻

周新闻

月新闻