权限体系：从菜单到数据行

平台的权限分三层把关——能进哪些页面、在每个页面上能做什么、能看到哪些数据行。本文讲这层机制怎么运转、为什么「界面隐藏 ≠ 无权限」。

本文解决什么问题：正式系统上线后，「谁能看到什么、能改什么」是最先被问到的安全话题。日常怎么配见用户、角色与菜单权限；这篇补上背后的机制——三层权限各拦什么、数据行级怎么生效、为什么界面藏起来不等于没有权限。

一句话机制

衍数的权限把「一个人能碰系统到什么程度」拆成三件递进的事：

三层是叠加关系：进不了菜单，后面两层谈不上；进了菜单但没勾「删除」，删不动；能删，也只能删自己权限范围内的行。

界面上最常见的权限表现是「按钮不显示/不可点」——这层是体验层。如果只靠它，绕过界面直接调请求仍可能越权。

衍数把权限做成前端显示 + 后端拦截两层：

结论：界面隐藏只是「让不该看见的人不被打扰」，不是安全本身；安全由后端的第二次校验兜底。

能进某个页面之后，「能看到哪些数据行」由角色的数据范围决定，通常四档：

例如「仓库」角色配成「仅本部门」，那么即便它拥有库存列表的菜单与查看权限，打开列表时看到的基本上只是自己仓库那部分——同一个页面，不同角色打开是不同的可见范围。

很多系统要做到「部门只看本部门数据」，需要在每张业务表上手工加一个部门字段、再写过滤逻辑。衍数的动态模型在发布时自动记录每一行由谁、在哪个部门创建（作为不可见的框架信息随数据保存），数据范围过滤直接基于它执行：

提醒：行级过滤仅在模型开启数据权限时生效——个别模型（如公开字典）明确不需要按人隔离时，可以不开启。开启与否由模型配置决定，不是所有表一刀切。

AI 数字员工（如自动生成报表、代查数据）不是凌驾于权限之上运行，而是作为一位「使用者」被同一套角色/数据范围约束：它只能读它被授权范围内的数据、只能执行它被允许的动作，越权请求同样被拒绝。也就是说，您给员工配的权限口径，与给人配的权限共用同一套规则——AI 不会成为绕过权限的后门。

把菜单藏起来，是不是就等于没权限了？ 不等于。菜单隐藏是体验层的处理；是否真正有权，以后端的动作校验为准。所以配置时请把两者都配好：界面按角色显示、后端按角色拦截。

数据范围能细到「某几个指定部门」吗？ 内置的四档覆盖了最常见的诉求（全部/本部门及子部门/本部门/仅本人）。需要更细粒度的按指定范围授权时，属于进阶定制，请在实施阶段与交付方确认。

改了角色权限，要多久生效？ 角色与数据范围在平台内有统一缓存与刷新机制，权限变更后会随之生效；涉及登录会话的变更建议重新登录后确认。具体生效节奏以实际部署环境为准。