SpringBoot3+Vue3+Flowable 发起权限：谁可以发起、菜单关联流程和兜底权限码怎么配

SpringBoot3+Vue3+Flowable 发起权限：谁可以发起、菜单关联流程和兜底权限码怎么配

🌐 文档地址：https://ruoyioffice.com
📦 源码1·GitHub：https://github.com/yuqing2026/ruoyi-office
📦 源码2·GitCode：https://gitcode.com/zhouzhongyan/ruoyi-office
📦 源码3·Gitee：https://gitee.com/yqzy1688/ruoyi-office
💬 微信：17156169080（备注「RuoYi Office」）

用车单只想让行政发、请假单全员能发，最常见的错法是再做一套「流程角色」，和菜单 RBAC 各管各的。RuoYi Office 把发起权收到菜单「关联流程」：大厅只列出当前人有权限的定义；模型上的「谁可以发起」只收窄到人/部门；「发起所需权限」是没有菜单入口时的兜底。配置体检把未绑菜单、孤儿权限码列出来。本文按能点的页面讲怎么配。

▲ 左是发起大厅和工作台卡片，中是模型「谁可以发起 / 发起所需权限」，右是菜单关联流程 Key；底下三条是孤儿码、组织收窄、required 开关

引言：发起权难在「两套名单」

把「能进菜单」和「能发这个流程」配成两张表，上线后一定打架：

一句话：功能权限以菜单为唯一配置源；组织范围只做收窄。 模型上的权限码是兜底，不是主路径。

下面按能点的四处讲：发起大厅、流程模型基本信息、菜单「关联流程」、系统管理里的配置体检。

一、先给出可直接抽取的定义

1.1 什么是发起权限

发起权限，是「当前登录人能不能创建该流程定义的实例」。 它在两处生效：发起列表（大厅/工作台卡片）和真正的发起接口。只滤列表、不滤接口，等于没配。

RuoYi Office 的判定入口是 canUserStartProcessDefinition：先过功能权限，再过组织范围。功能权限关了（bpm.start-permission.enabled=false）时，行为回到「已发布且可见即可发」，组织范围仍然生效。

1.2 菜单反查和兜底权限码

菜单反查：用流程定义 Key 去菜单表找 processDefinitionKey 命中的菜单，取出这些菜单上的 permission，当前用户命中任意一个即可发。 改菜单立刻生效，不必重新发布流程。

兜底权限码：模型字段「发起所需权限」，例如 oa:car-apply-bill:create。 只有反查不到任何菜单权限时才读它。帮助文案写得很直白：流程表单请在表单设计配菜单并发布同步；业务表单在菜单管理给创建按钮填「关联流程」；仅无菜单入口时才在这里填。

兜底码必须真实存在于菜单。写一个菜单里没有的字符串，任何角色都命中不了，等于除超管外全员拒绝。配置体检会把这种情况标成严重。

1.3 谁可以发起

谁可以发起是组织范围，不是第二套功能权限。 三个选项：

名单为空表示不收窄。有人员名单时不再看部门名单。多组织开启后，指定部门用的是会话当前 deptId，不是用户档案主档——切到长沙就不能再发「仅深圳研发可发」的单。

它和候选人策略、发起人节点三策略不是一回事。后者管审批节点谁来批；本篇只管能不能把单开出来。

二、发起大厅：列表已经按权限裁过

路径：/bpm/start-process。标题就是「发起流程」。卡片只出现当前账号能发的定义，不是「库里所有已发布模型」。

▲ 能看见的卡片，点进去才应能提交；看不见的不要靠改 URL 绕过，接口会再判一次

工作台应用中心的「发起流程」走进的是同一套大厅。不要把大厅页当成流程表单的父菜单——设计器会拦：父菜单不能选「发起流程」大厅页，请挂到「自定义申请」等业务目录。大厅是目录，不是某张单的创建按钮。

流程表单发布时可以自动生成菜单。生成后仍要把该菜单授给角色，否则大厅和侧栏都不会出现。业务单据（用车、用印）则是在已有「创建」按钮上填关联流程 Key。

三、流程模型：基本信息里的两行配置

路径：/bpm/manager/model，卡片墙按分类摆，点「修改」进入四步向导，第一步就是基本信息。改发起权不必先打开 BPMN 画布。

滑到表单下半段能看到两行：

▲ 兜底权限码一般留空；人员/部门选择器只在对应类型下出现

保存并发布后，这两项写入流程定义 Info 表。只保存不发布，大厅仍按旧版本判权。复制模型会带上范围，但权限码若是孤儿码，复制后体检照样报。

管理员名单 managerUserIds 管谁能改这个模型，不管谁能发起。不要把「流程管理员」和「可发起人」配成同一组人——实施会改模型，员工只发单。

基本信息这一步还有「是否可见」。不可见的定义不会进大厅，和发起权限是与关系：可见且有权才能出现卡片。测试中的模型可以先关可见，配完权限再打开，避免员工在大厅里点到半成品。

四步向导的后三步（表单设计、流程设计、更多设置）不参与 canUserStartProcessDefinition。字段权限、候选人、超时策略都在后面配，不要跑到那些页去找「谁可以发起」。

四、菜单：关联流程才是主配置源

路径：/system/menu。在创建按钮或菜单上点「编辑」（不是列表顶上的「修改流程」页签）。类型选按钮或菜单后，表单下半会出现「关联流程」：下拉选已发布定义的 Key，可多选（tags），也可手输历史别名。保存成逗号分隔，供发起权限反查。

弹窗右侧有一块「影响面」，配的时候盯着它改，比改完再去大厅试更快：

目录节点几乎一定显示「未关联流程 Key」——这是正常的，不要给目录填 Key。只有真正的创建按钮，影响面才会变成按本菜单 permission 判权。

帮助语义：

• 填了 Key：发起校验按本菜单的 permission 判权
• 没填：不会按本菜单控权
• 可见端包含 App，但既没移动路径也没关联流程：App 工作台不会出现入口，配置体检标黄

列表「入口影响」列会给绑了流程的行打紫色「流程」标签，方便扫一眼哪些按钮已经纳入发起权。改完点工具栏「清理菜单缓存」，再用一个没有该按钮权限的账号刷新大厅，卡片应消失。

同一 Key 可以挂在多个菜单（PC 创建、App 创建）。反查时这些权限任一满足即可，不是必须同时有。不要把同一 Key 挂到十个互不相关的按钮上，体检会提示保留唯一发起入口。

改菜单立即生效，因为反查走菜单缓存。不必为了「收紧谁能发用车」去改 BPMN、不必重新部署流程。这是和「把权限码写死在模型里」最大的产品差异。

字段只在菜单类型为「菜单」或「按钮」时出现。目录节点没有「关联流程」，也不该把 Key 写在目录上——反查会把目录的 permission（常常为空）也算进去，体检会出现「同一 Key 挂了多个入口」。

4.1 流程表单和业务表单怎么配

两类表单进同一套判定，配法不同：

不要把业务表单的创建按钮删掉，只靠发起大厅。侧栏没有入口，实施会以为「菜单没配」，其实大厅还能发——两边必须同一套权限。

发布流程表单时，设计器会拦：父菜单不能选「发起流程」大厅页。正确挂法是挂到「OA / 自定义申请」这类业务目录。大厅是挑单目录，不是某张单的父级。

4.2 同一 Key 挂多个菜单

PC 创建按钮、App 创建按钮、工作台快捷入口，可以挂同一个 Key。反查取出这些菜单的 permission，hasAnyPermissions 任一满足即可。不要理解成「必须同时拥有三个码」。

反过来，不要把同一个 Key 挂到十个互不相关的按钮上。配置体检会提示「流程被多个菜单关联」。保留一个真正的发起入口，其余入口用路由跳转，不要再写一遍 Key。

菜单表单里这一项是可多选的流程定义下拉，保存成逗号分隔的 Key，供发起权限反查：

{
fieldName: 'processDefinitionKey',
label: '关联流程',
component: 'ApiSelect',
componentProps: {
api: getSimpleProcessDefinitionList,
labelField: 'name',
valueField: 'key',
mode: 'tags',
allowClear: true,
showSearch: true,
placeholder: '下拉选择或回车输入流程 Key',
},
help: '可多选；支持手输历史别名 Key。保存为逗号分隔，用于流程中心发起权限反查',
}

只在类型为按钮或菜单时显示。目录节点看不到这一项，也不要靠改库把 Key 写到目录行上。

五、配置体检：未绑、孤儿码、死链

路径：/system/permission-audit。页顶 Alert 汇总严重/提示条数；表格可按全部 / 严重 / 提示筛选。行内「去修复」跳菜单或模型。

▲ 清零严重项之前，不要把 required 打开；打开后未绑流程含超管也发不了

体检主要看三类：

未绑在 required=false（默认）时是提示：当前所有人都可以发。required=true 时变严重：任何人（含超管）都无法发起。升级过渡务必保持默认，把未绑清零后再收紧。

测试表单、无入口遗留流可以忽略。不要为了「体检全绿」把演示用的测试流程全禁掉。

六、两道部署开关

写成配置项，不要和租户开关搞混：

组织范围不受 enabled 影响：关掉功能权限过滤后，指定人员/部门仍然生效。这是有意的——客户可以先关菜单反查做兼容，但「只有行政能发用车」这种范围仍要管。

工作台也能看到发起入口。权限裁剪后卡片变少，不是首页坏了。

▲ 发起是权限裁过的卡片；铃铛是站内信/IM 未读，下一篇专门讲，不要和发起大厅混

七、后端判定顺序

public boolean canUserStartProcessDefinition(
BpmProcessDefinitionInfoDO def, Long userId) {
if (def == null) {
return false;
}
if (isStartPermissionEnabled() && !checkStartPermission(def, userId)) {
return false;
}
if (CollUtil.isNotEmpty(def.getStartUserIds())) {
return def.getStartUserIds().contains(userId);
}
if (CollUtil.isNotEmpty(def.getStartDeptIds())) {
AdminUserRespDTO user = adminUserApi.getUser(userId).getCheckedData();
Long deptId = user != null ? user.getDeptId() : null;
if (Objects.equals(userId, SecurityFrameworkUtils.getLoginUserId())
&& SecurityFrameworkUtils.getLoginUserDeptId() != null) {
deptId = SecurityFrameworkUtils.getLoginUserDeptId();
}
return deptId != null && def.getStartDeptIds().contains(deptId);
}
return true;
}

要点：人员名单优先于部门名单；当前请求若已 overlay 会话部门，指定部门用会话值。功能权限失败直接 false，不会再看组织范围——没有创建按钮的人，即使在指定部门里也发不了。

功能权限内部再分三步：

List<String> permissions = menuApi
.getPermissionListByProcessDefinitionKey(key).getCheckedData();
if (CollUtil.isNotEmpty(permissions)) {
return permissionApi.hasAnyPermissions(userId,
permissions.toArray(new String[0])).getCheckedData();
}
String permission = processDefinition.getStartPermission();
if (StrUtil.isBlank(permission)) {
return handleUnboundProcess(processDefinition, "未关联菜单且未配置兜底");
}
if (CollUtil.isEmpty(menuApi.getMenuIdListByPermission(permission)
.getCheckedData())) {
return handleUnboundProcess(processDefinition, "兜底码不在菜单中");
}
return permissionApi.hasAnyPermissions(userId, permission).getCheckedData();

handleUnboundProcess 在 required=false 时打 warn 后返回 true，保证存量；required=true 返回 false。孤儿码先按「不在菜单中」走进未管控分支，体检则单独标严重，避免实施以为「码写了就生效」。

流程 Key 解析优先走引擎 ProcessDefinition.getKey()。历史上有的部署把定义 ID 写成纯 UUID，截取冒号前一段会得到整段 UUID，菜单 FIND_IN_SET 命中失败。不要自己 id.split(":")[0] 当 Key 去配菜单。

前端基本信息里，权限码是自动完成，选项来自全量菜单的 permission 去重，聚焦输入框才去拉，避免一进页就打菜单列表。占位写得很清楚：一般留空。

<Form.Item label="发起所需权限" name="startPermission">
<AutoComplete
v–model:value="modelData.startPermission"
:options="permissionOptions"
placeholder="如 oa:car-apply-bill:create；一般留空"
allow–clear
@focus="ensurePermissionOptions"
/>
</Form.Item>

「谁可以发起」切到指定人员时出现头像选择器，切到指定部门时出现部门树。切回全员会清空已选名单，保存前看一眼，避免「界面显示全员、库里还留着旧 userId」。

7.1 大厅为什么已经是裁过的

发起大厅和工作台「发起流程」卡片，走的不是「查出所有已发布定义再在浏览器里藏」。后端在组装列表时对每条定义调用同一套 canUserStartProcessDefinition。所以：

• 角色被收回创建权限后，刷新大厅，卡片应立刻消失
• 指定人员改成别人并发布后，自己的大厅不再出现该卡片
• 只保存不发布，大厅仍按上一版 Info 判

可见性 visible=false 的定义不会进大厅，这是另一条过滤，和发起权限是与关系：不可见的流程，有权限也看不到。

八、数据落在哪

不要为发起权再新建「流程角色表」。角色已经通过菜单 permission 作用到人。再加一张表，配置体检无法闭环。

Info 表和菜单表的职责可以记成一张对照：

「要不要发布」这一列最容易漏：改组织范围却只点了保存，大厅还按上一版 Info 放行，实施会以为指定人员没生效。

九、和相邻能力划界

把「销售不能发用车」配成数据权限「本部门」，是错的：新建时还没有部门行可过滤。应去掉销售角色上的用车创建权限，或把用车发起范围指定到行政部。

9.1 四类常见错配

App 工作台还有一条独立规则：菜单声明了 App 可见，但既没填移动路径、也没关联流程，体检标黄，App 不会出现制单入口。PC 大厅不受这条影响。配移动端时三条一起看：可见端、移动路径、关联流程。

缓存键按流程 Key 存权限列表。改菜单「关联流程」或 permission 后应失效；页面上有「清理菜单缓存」。改完角色授权，用户要重新拉菜单（退出或刷新），否则侧栏还显示旧按钮，大厅已经按新权限裁了，两边看起来不一致。

十、设计对照

十一、技术亮点

十二、FAQ

Q1：模型里填了发起所需权限，菜单也关联了，以谁为准？
菜单反查优先。只要反查到任意权限码，模型兜底字段被忽略。

Q2：超管是不是永远能发？
功能权限上超管通常命中所有 permission。但 required=true 且流程完全未绑时，判定走「未管控禁止」，超管也发不了。先体检清零再开 required。

Q3：指定部门后，兼职人员切到该部门能不能发？
能。判定用当前会话部门。没切过去时，即使档案挂过这个部门也不算。

Q4：大厅看得见，提交报没权限？
列表和接口应用同一套 canUserStartProcessDefinition。若仍发生，多半是发布后权限变了、或打开的是旧页签里的已选定义。刷新大厅再发。

Q5：流程表单发布同步的菜单要不要再填关联流程？
同步时应已带上 Key。到菜单里核对一眼即可，不必在模型兜底再写一遍同一个码。

Q6：enabled=false 后指定人员还管不管用？
管。enabled 只关菜单/兜底功能权限，组织范围仍过滤。

Q7：复制模型会不会把发起范围带过去？
会带上人员/部门名单和兜底码。若原模型是孤儿码，复制后体检照样报。复制后先清兜底，再给新 Key 配自己的菜单。

Q8：流程管理员能发单吗？
managerUserIds 管谁能改这个模型，不管谁能发起。实施账号和员工账号应分开：实施改模型，员工只发单。

Q9：和「用户多组织」是什么关系？
指定部门用的是当前会话部门。多组织关掉时，会话部门就是档案主档；打开后，顶栏切到长沙，用车若指定「仅深圳研发」，大厅卡片应消失。不要在发起权限里再存一份「兼职部门名单」。

Q10：配置体检 300 多条提示要不要当天清零？
不必。提示里大量是测试表单未绑、App 可见但没移动路径。先滤「严重」：孤儿码、菜单 Key 未发布、required 打开后的未绑。提示可以列入迭代，不要当成发布门禁。

十三、快速体验

在线演示：https://ruoyioffice.com/web/（账号 admin / admin123）

建议路径：

常见验收失败（对照上面 1～6）：

• 第 1 步卡片很多、第 3 步创建按钮没 Key：大厅可能靠 required=false 放行，上线一收紧就全没了
• 第 2 步改了指定人员但第 1 步没变：只点了保存，没发布
• 第 4 步严重项里有「用车申请单创建」指向未发布 Key：菜单 Key 和模型标识不一致，先对一下 oa_car_apply_bill

实施清单：

升级当天建议按这个顺序动刀：先跑配置体检，把「菜单指向的流程未发布」和孤儿码修掉；未绑项先挂上真实创建按钮；组织范围（指定人员/部门）最后收。不要一上来把 bpm.start-permission.required 打开——那会让还没来得及绑菜单的存量流程全员（含超管）发不了。

SIMPLE 和 BPMN 两种画布共用 Info 表里的这两行配置。换设计器类型不会丢掉「谁可以发起」。可见性、管理员名单、允许撤销是旁边的字段，保存时一起提交，但判定发起时不会读它们。

源码仓库：GitHub：https://github.com/yuqing2026/ruoyi-office ｜ GitCode：https://gitcode.com/zhouzhongyan/ruoyi-office ｜ Gitee：https://gitee.com/yqzy1688/ruoyi-office

结语

发起权不该成为「流程模块自己的 RBAC」。菜单关联流程 Key，角色勾按钮，大厅和接口共用一次判定；谁可以发起只回答「这些人/这些部门」；兜底权限码留给没有菜单的特例，并且必须能在菜单里找到。配置体检把未绑和孤儿码摊在一张表上，升级才敢把 required 打开。

同一套「菜单为源、范围为收窄」还可以用在移动端制单入口：App 可见 + 移动路径 + 关联流程，缺一不可，体检同样会标黄。

配置体检页顶的 Alert 会直接写出 start-permission.required 打开后的后果。把它当成上线检查清单，而不是出了 P0 再翻日志。大厅、模型、菜单、体检这四页走完，发起权就不再是「流程模块自己的第二套 RBAC」。

菜单编辑弹窗右侧有一块「影响面」：会告诉你这条菜单会不会进 PC 侧栏、会不会按本菜单控发起权、App 工作台缺不缺移动路径。目录节点几乎一定显示「未关联流程 Key，不会按本菜单控权」——这是正常的，不要给目录填 Key。只有真正的创建按钮或菜单，影响面才会变成「按本菜单 permission 判权」。配完保存后，到发起大厅用一个没有该按钮权限的账号验证卡片消失，比只看体检绿勾更准。

实施排期上，把「绑菜单」和「收组织范围」拆成两次发布：第一次只让大厅和侧栏对齐；第二次再指定人员或部门。两次都走配置体检，比一次改三处更容易回滚。

💡 想要体验 RuoYi Office 的强大功能？

🌐 在线演示：https://ruoyioffice.com/web/（账号 admin / admin123）

📦 源码仓库：GitHub：https://github.com/yuqing2026/ruoyi-office ｜ GitCode：https://gitcode.com/zhouzhongyan/ruoyi-office ｜ Gitee：https://gitee.com/yqzy1688/ruoyi-office

💬 技术咨询：添加微信 17156169080，备注「RuoYi Office」

⭐ 如果觉得不错，请给个 Star 支持一下！