热搜:
编辑导语:权限管理是所有后台系统的都会涉及的一个重要组成部分,在管理后台中对于权限的标准需要准确地把握,并且根据各种需求进行设计,达到最终目的;本文作者分享了关于权限系统的设计,我们一起来了解一下。

写在前面,为什么要写权限系统的设计呢?

因为每一个项目,有管理后台,90%会有权限管理。在我自己历史以往的项目,其实对于权限始终是一个相对表面的认知。直到我去年研究了钉钉的管理系统、以及今年做了产品重构,让我对权限有了一个深度的认知。

一、权限是什么

我对于权限的理解,一开始是一个账号,管理着后台的某些模块;这个时候,权限很简单,他是一个账号列表,可以编辑账号信息以及设置账号查看菜单,即账号yimi可以管理订单列表。

后面接了一些门店端的项目,在区分菜单查看上,也加上了数据区分,即账号yimi可以管理**门店的订单列表数据;上面这两项,我觉得可以基本可以支持中小型的项目是足够使用的。

然后更深一个层级的,当你接了一个大型的项目,你的后台管理员是一个集团的人,或者是上百人,这个时候一个账号区分是远远不能满足的;也延伸了在做CRM系统的时候研究了钉钉的逻辑,权限不仅仅是开通一个账号(仅有账号+密码)这么简单,权限是对于不同部门的人的管理。那么这个时候会将账号跟菜单权限独立开来。

账号即部门下面的某个成员,可通过手机号作为唯一标识。菜单权限按照不同角色去区分,财务有拥有什么菜单、采购拥有哪几个菜单。

听到这里,权限就涉及了:部门、成员、角色、菜单。那我会觉得,权限可复杂可简化,其实无非是人管事。那么不同的权限设计会有什么区别呢?

二、最小权限设计

最小的权限设计,如下图所示,有登录账号、密码、以及菜单勾选。其实还有个XS版本的,即仅有账号,无菜单权限分隔。

最小权限设计-图示1

那什么情况会使用这种最小的权限设计,我个人的理解是小型的项目,或者说客户内部运营结构相对简单;这个时候需要注意几点,第一个拥有整个菜单即拥有菜单所有操作,第二点是没有数据隔离,即每个拥有菜单权限的管理员查看内容一致。

对于需求梳理如下所示:

三、中型项目权限设计

中型大小的项目,类似于多门店、或者是负责角色不同,同个模块需要查看不同数据、进行不同的操作。如下图所示:

中型项目权限设计-编辑管理员-图示2

中型项目权限设计-编辑角色-图示3

相对于最小权限设计,你可以理解为菜单+账号的拆分,并且在菜单的基础上,扩展了操作权限;也通过角色的区分,扩展了数据权限,此时的权限=菜单权限+操作权限+数据权限。

相对于上一个会复杂很多,为什么我前面会说建议按照产品体系,再去做这一套中型的权限系统?

一方面,众所周知是由于开发工作量以及难度,对应报价会高;另一方面是,这个的复杂度也提高了他使用难度,如果是没有这种业务情况需求(类似于多门店、或者是负责角色不同),就不建议用了。

最后也是最重要一个方面,针对不可持续性产品的说明:不断向软件增加功能,是不可持续的。增加复杂性意味着遗留代码越来越沉重,导致产品维护成本越来越高,而且也越来越难以灵活应对市场变化;这个道理我想不仅仅适用于用户前端,对管理后台也同样适用。

对应的需求梳理如下:

四、大型项目权限设计

大型项目的权限,最大的一个变化,是有部门组织架构,不同部门的人使用系统,即将管理员管理拆解为部门管理+成员管理,但是又不仅仅于此。

在一个接入审批的系统、或者CRM中,往往数据是相对独立的,可以按照部门组织架构数,去区分数据的权限。如下图所示:

大型项目权限设计-部门组织架构-图示4

如果说,中型项目的数据权限是按照门店或者区域划分,那么部门树则是数据权限的另一个维度。按照创建者所在部门,将这条数据归属于某个成员某个部门(此处还要考虑成员存在多部门的情况),同个部门间数据独立,而主管可以查看所有人的数据。

则这个数据划分,并不适用于后台管理的所有列表,例如用户列表、订单列表此类数据来源并非后台的,或者是一些文案管理的列表,并没有必要做数据的区分;所以在开发的时候,还需要在每个列表列出说明,是否使用;这个逻辑实现的确是相对比较复杂的,整个权限系统可以相当于一个小型项目了,这个需求我大概写了一下功能点,有需要的小伙伴可以再问我要。

五、总结

权限还是一个可简单可复杂的系统模块,但是还是要按照需求,进行设计。

熟悉产品体系跟需求后,提出的方案才能更贴合、更有说服力,才能真正解决问题;所以也建议,对权限系统感兴趣的话,有空的时候多研究一下钉钉、飞书这类型的软件,虽然并不能完全复用,大厂的解决方案,每个模块甚至于每个文案内容,都凝聚着一整个技术团队的心血,还是很值得我们学习的。