同一个任务链接，User A 点开就能完成，User B 直接访问却被服务端拒绝，返回 403 。这不是界面藏了按钮，是引擎在每一次 HTTP 调用上做了角色与动作的交集校验。 Oumma 的流程天然是多角色的：收银员复核、经理审批、操作员发起。权限模型被拆成一条三环链，每一环都缺一不可。 身份提供方（Keycloak）说明你在哪些组里，比如 Operateur、cashier、management。用户令牌是角色的唯一来源，应用和引擎都不信任客户端自报的身份。 流程设计说明每一步归哪个角色所有，以及该角色能执行哪些动作：完成、评论、附件、查看。这些配置在设计师的「角色与权限」标签页里。 引擎在每一个动作上强制执行两者的交集——任务完成、评论、附件，甚至读取卷宗，全部在服务端、每一次 HTTP 调用上校验。 规则很直接：设计里没有的角色，没有访问权；设计里有但你的令牌里没有，同样没有访问权；两者都有，才拿到设计授予的那组动作。 角色怎么建，动作怎么配 在流程的「角色与权限」标签页里，角色按角色 id（也就是 Keycloak 的组名）添加，配一个显示名，再标记启动角色——即哪个角色可以发起新卷宗。也可以直接在对话里说「给质量团队加一个主管角色」，助手会替你调用 add_role，你确认后它落进待发布版本。 每个步骤随后引用其中一个角色，可以在画布的步骤面板里用步骤名旁的角色下拉框设置，也可以在这个标签页里设置。 对步骤上的每个角色，设计师配置一组动作。这些不是界面上的建议，引擎的 RoleActionChecker 会在完成任务接口、每一次评论增删改查调用、以及附件增删改查调用时被查询。校验不通过的请求拿到 403 和一条明确的提示，并像其他拒绝一样被记录。 从设计同步到身份 过去的做法是手工的：每次设计变更后跑一遍 add-roles-to-.sh 脚本，然后祈祷组名对得上。Oumma 用一个同步动作替代了它——设计师里的角色列表被推送到 Keycloak 成为组，缺的创建，成员关系按配置的用户对齐。在角色标签页点一下，组织的身份模型和流程模型就不会漂移。 这在实操中很关键：一个新入职的收银员被加进 cashier 组，登录后就能看到自己的复核任务，流程不需要重新部署——成员关系在登录时从令牌里读取。 同一任务，两个用户的对照 场景是这样的：流程「订单处理」的 manual_review 步骤分配给角色 cashier，动作为查看、完成、评论。User A（custrel_1001）在 CustRelations/cashier 组里，User B 不在。 User A 打开「我的任务」，看到这一步，用自己的表单完成它，流程进入下一步。User B 直接访问同一个任务 URL，引擎的 RoleActionChecker 拿他令牌里的组去比对步骤的角色与动作，返回 403——你的角色不允许该动作。 没有界面花招：接口本身拒绝，所以这个拒绝对任何客户端都成立，手机应用、curl、AI 助手都一样。同样的检查也守着评论和附件接口——User B 连在自己打不开的任务上留一句话都做不到。 AI 也走同一扇门 流程助手（AI Assist）以你的身份、用你的令牌行动。如果你的角色在某一步缺少完成权限，助手的 complete_task 工具调用会拿到同样的 403，它会如实告诉你，而不是想办法绕过去。基于角色的访问控制不是界面主题，它是安全模型，每一个行动者——人、设计师、助手——都走同一扇门。 这套设计换来几件事：单一事实来源，令牌组乘以设计动作，没有重复的 ACL 需要同步；服务端、动作级的强制执行，每一次增删改查都被检查、记录，界面与助手表现一致；身份从设计同步，角色的事实来源是设计师而不是 shell 脚本；安全入职，新人拿到正好属于他所在组的那些步骤，从他加入组的那一刻起。 特别