关于角色数据权限相关问题，400奉上

[极客诗人]

在我们实际业务中，权限是尤为重要的一个环节。

目前权限的解决方案也是有很多。

但最近在实际业务开发中，就有些问题如下：

1.管理角色默认拥有所有数据


2.在某些数据的状态值(例如流程节点XXX的）为指定时，某些角色能看见数据进行操作，操作后数据不可见。

望指点讨论，400奉上

[极客诗人]

目前均是在代码中写死。 想将2更加灵活的处理，故此一贴，望赐教

[圣殿骑士18]

这不就是个数据过滤的问题吗，有难度？

[圣殿骑士18]

写死不写死，也就是把配置存起来的问题，也不难吧

[以专业开发人员为伍]

仅仅基于“数据层面”来设计权限，其实是最学究化、理想化的一种方式，这个前提是整个数据“读取”的 api 都被你自己编程控制情况下，例如你自己开发一个 SQLHelper且你自己解析、编译 sql 语句。 而基于工作流节点的权限管理，是基于“文档”的权限管理，是基于高一级别的“业务数据权限管理”。可见它不是基于 low 层面的通用数据库数据概念，而是基于业务领域分析来考虑。 进一步地可以看到，随着业务分析的深入，权限问题实际上在多“种”业务领域对象上都有涉及，而且其实是跟业务的“本质”相关的。例如工作流节点的权限，是在工作流图的设计器上进行配置，在工作流节点文档数据对象产生时指明了“发送人、接收人、抄送人”，这当然是与工作流协同、即时消息业务相关的。 可以说，认为“整个数据都能随便设置权限”其实是个幼稚的想法。更高级的想法反而是实际的——每一个业务服务模块的 API 各自判断的调用者是否有权限访问数据。先对业务领域进行详细设计，仅针对对某1、2种业务领域对象来适配权限系统，而不是以为纠结“所有数据”这种空洞的概念来适配权限概念。

[以专业开发人员为伍]

例如一个系统如果有工作流图设计器，则在设计器上对工作流节点配置“业务流程权限”，来说明节点数据的产生来源（并不是产生数据权限本身，而是配置数据权限的生成规则，例如配置某节点只能被传送给流程发起人、当前节点的接收人所在部门的某个岗位的人，等等）。假设系统中还有一些资产，那么你需要配置资产保管负责人、资产复核负责人。假设系统还有一些研发代码和研发问题，你需要配置研发工作组，问题接收人、评估参与人、任务分配者、最底层干活的人、测试人员、负责上线的人、测试人员，等等。 一个不大的业务系统中假设慢慢产生有500种数据库表，那么你可能需要在10种不同的数据库表中为每一“行”数据指定你说的所谓的“某些角色能看见数据进行操作”这类东西。也就是说真正的系统在高级别的业务对象上控制权限，而不是在低级别的“通用数据”上控制权限。有些人假设系统开发最高级的事情就是弄个后台数据库的查询客户端 Table 来“增删改查”数据，这是最学究、最简单化、最 low的想法，看上去高大上，其实这跟刚工作3个月的学生灭有区别，远远脱离了业务系统架构。真正的系统是用 API 将所有客户端与后台数据库想分离，客户端根本不可能用一个所谓的数据库表增删改查 Table 界面来随便乱改数据。真正的系统能把百十来个 业务API 给开放给各个客户端系统且提高整个系统使用效率、使用价值就不错了，需要在 API 接口上分别控制“权限”，还纠结低级地“随便去增删改查所有数据”？

[以专业开发人员为伍]

引用 1 楼 极客诗人 的回复:

目前均是在代码中写死。 想将2更加灵活的处理，故此一贴，望赐教

这其实是某种业务架构、业务 API 的具体设计抽象层次不够的问题。是业务流程了解不深入的问题，是对业务不熟悉的问题，而不适合纠结“通用数据库表增删改查”概念。

[cn2719691]

有几个方式吧，第一种简单点，用户表记录权限，然后程序根据权限开放按键或显示之类的 另外高级点的就是再写个菜单表，与权限对应，或者直接与用户对应，运行时查询菜单表分别显示菜单。