一般的RDAC权限系统设计,设计主体思路在于将功能权限授权于角色，再用用户去归属角色。因为一般角色是相对稳定的，而用户的变动可能会比较频繁（比如一个人换岗位，职务调整，人员入职，离职等）。这样，只要人员变动，只需要改变人员所属的角色就可以达到快速修正权限的目的。
活字格的权限系统大体上应该也是遵循这个原则。在活字格中，权限起作用的目标资源是"页面"（ps:暂时先不论数据的记录权限和字段权限，这个应该会新开个话题讨论）。在设计期配置"角色"对各个"页面"的访问权限，在系统上线后，通过改变具体人员用户所属的角色（一个用户可以有多个角色），最终达到用户权限的配置。（具体配置方式官方教程有详述，不再赘述）
有实施过企业erp系统对这套体系一般比较熟悉，其中角色的实际使用，经常是会和 职位/岗位/职能 这样的关键字挂钩。这里讨论一个场景:假设有个仓库管理功能，具体功能页面有（入库单列表，入库单编辑，出库单列表，出库单编辑，货车外派单列表，货车外派单编辑）。刚开始上线的时候，出入库和货车车辆的管理都是仓库部门负责的，所以这几个页面的权限都划给了"仓管员"这个角色。小张，小李这两个用户都是公司的仓管，所以他们都归属仓管员这个角色。过了一段时间，公司管理层决定调整公司岗位职能，将货车的管理归属行政部小王负责，如果这时候小王再去追加分配"仓管员"的职责就不合适了，因为小王只是负责货车管理的部分，而不需要做出入库管理。仓管小张小李的角色也迫切需要调整。这时候，只有进入设计器打开项目，新建个"车辆管理员"的角色，然后将货车外派单列表和货车外派单编辑页面的权限归属到该角色，再从原来仓管员角色下把这几个页面权限去除，接下来就是一个高风险的操作:发布到服务器。为啥说发布会是一个高风险的操作呢？在系统的开发期，发布到测试服务器是很简单而且很轻松的事情，爱怎么发布就怎么发布。但是，一旦正式上线了，任何发布就都变成了存在风险的举动。如果就一个开发人员，就一套源码还好，如果是团队开发，假想一个场景:假设这个发布动作是开发人员小马来完成，结果因为疏忽，忘记获取最新的源码，或者将自己开发到一半功能的源码给发布了，那就出大事儿了，如果影响太大，估计小马就要辞职去看看太大的世界了，说不定成立个阿里巴巴什么的也有可能……我们考察他发布这个版本的原因，竟然只是因为管理货车的岗位需要做个调整。当然，会有人说，作为团队开发，难道就没有开发规范和发布管理操作手册吗？这个当然需要，但是对系统原则而言，任何规范性的条文条例制度都是系统运维的最后一道防线，破防了就啥也没有了。如果可以从系统操作上避免，这个当然是第一选择。从上面这个场景案例，我们得知，在活字格，如果需要对已有的角色进行调整，就需要动用到开发权限（在设计期进行发布动作），而仅仅是在实施期的后台管理页面进行调整是做不到的。(这里还带来一个副作用:假设甲方公司是一家需要上线erp的制造业公司，委托乙方软件公司用活字格开发的系统，乙方并没有交付源码，这时候当甲方需要对管理职能进行调整的时候，还需要乙方介入才能完成权限的调整……当然，这是甲方的悲伤，却是乙方的幸福←_←)
鉴于以上，我考虑用如下这种方式进行权限操作，看是否能尽量规避这个问题，以及活字格是否有改善权限系统的空间提出个人的小建议，希望抛砖引玉，共同寻找一个权限配置的最佳实践。
目前我们的初步构想和做法是，将活字格现有的角色的概念进行改变，变成"最小功能操作集"的概念，即划分出一个操作需要涉及到的页面集合。例如上面的场景示例，先定义出[出入库操作]和[货车管理操作]这两个"角色"（实际上应该叫做最小操作集）（当然，也可以根据管理粒度需要在设计时分成入库操作，出库操作，货车管理操作这三个角色也行，至于这个粒度划分的依据，是以实际逻辑业务中的一个可能被分配的操作功能集合最小需要用到的页面集合）。[出入库操作]这个"角色"有出库单和入库单四个页面的访问权限，[货车管理操作]则拥有货车外派列表和编辑两个页面权限。发布系统后，仓管小张小李配置[出入库操作]和[货车管理操作]这两个"角色"。当管理层需要改变职能时，仅需在管理后台仓管人员的[货车管理操作]权限去除，加给行政小王即可。这样就达到了不需要发布而调整权限的目的（这时候乙方软件公司的脸色有些难看了O_o）。这里有人肯定会嗤之以鼻了:说了半天方案，怎么有种浓郁的马后炮的既视感？如果这么说，我一开始就建立"仓库管理员"和"货车管理员"这两个角色不就搞定了？需要在这里吧啦吧啦一堆概念然后证明1+1=2么？诚然，就这个例子是这样，但是如果将问题和场景放大至整个系统，就会发现，按传统的职能职务去划分角色，是很难准确判定这个角色粒度的。因为系统管理员们不会猜出未来公司管理的岗位变动和每个阶段的职能工作的划分，要能准确猜出就改行算命应该比做开发来的更赚钱……但是，划分最小操作功能集是比较容易的，即一个操作功能会涉及到哪几个页面集合才会完整，这个在需求定义和功能设计时就已经得到，并且一个还过得去的项目经理做出这个划分还是比较轻松的，毕竟不用特意去学《周易》什么的来推算未来的岗位变动。
好了，这种方式似乎是解决了上线后现有权限的调整问题，但是也同时带来了一个不方便，因为用户的角色权限被切换成了用户的功能操作权限，牺牲了原来的用户角色切换的方便性，实际使用时，会发现用户后面会挂上一堆的"角色"，这给维护带来了不小的挑战。另外对公共操作集的抽取和设置也是一个技术活，所以以下是基于以上方案的改善建议:
如果活字格能在后台管理再加上一层"岗位角色管理"（之所以这么命名是因为原来的角色管理被我替换成操作功能集管理了），可以在上线后在管理后台定义真正意义上的岗位角色，岗位角色持有操作功能集，用户还是挂在角色上，应该就能彻底解决这个问题了吧？
欢迎大家一起讨论！
|
陕公网安备：61019002000258 |
隐私政策 |
网站地图