中后台产品经理基本都会碰见一个问题:权限!在产品设计过程中,或多或少都会涉及到这一点,其实,权限体系已经是一个比较成熟的体系,刚好公司的权限系统比较老旧,要求结合现有的业务,重新设计扩展性较强的权限系统,本人有幸主导整个项目,现在给大家分享一下,权限系统设计的雷区,希望能给大家一些好的建议。

一.什么是权限系统

什么是权限系统呢?权限系统就是不同部门,不同的人所拥有的权力是不一样的,例如运营部门同事与人事部门同事的权限是不一样,研发经理的权限与研发组员的也是不一样的,这些不一样都是取决于用户的角色的不同。我主要是借鉴RBAC(Role-Based Access Control)权限模型,再结合本公司当前的业务现状,推动整个项目。

权限主要分为两个大块:功能权限(界面权限、菜单权限、操作权限等)和数据权限。功能权限与数据权限分开配置,充分解耦。接下来,我将逐一讲解功能权限与数据权限将如何结合起来。

二.功能权限

RBAC模型最大的一个便利点就是:不直接将权限赋予在用户身上,而是通过角色的媒介过渡,先将权限赋予在角色上,再关联相应的用户,对应的用户就继承了角色的权限,对应关系如下图所示。

引入角色媒介的优点:

1.实现了用户与权限的解耦

2.提高了权限配置的效率,只需要建好对应的角色就行

三.数据权限

数据权限呢,指得是用户的数据读写权限,他可以查看哪些数据,可以处理哪些数据的权限。本次设计中的数据权限,我选择的是关联组织架构,根据用户所处的组织架构关系,赋予数据权限,如下图所示。

如图所示,公司组织架构一般都是树状组织架构,每个部门都是一个结点,每个结点上都绑定了不同的人。数据权限指得就是如何处理结点间数据共享的问题。结点间数据如何共享可以根据公司实际业务来设置相应的规则。我这次项目采用的结点数据规则如下:

1.父结点可以管理所有子结点的数据:用户1可以管理用户3.4.5.6.7.8.9的数据

2.结点里的用户只能管理自己的数据:用户7只能管理自己的数据

看到这里的同学,千万不要以为数据权限规则设置就万无一失了,还有一些特殊情况需要考虑。

1.同结点下的用户在实际工作中有上下级关系,数据权限如何切分?例如:用户3是用户4的上级,用户3可以看到用户4的数据,而用户4只能看自己的数据。

2.跨团队的数据权限,又要如何配置?例如:用户3想要查看中台组数据

很显然,这两种特殊情况,在之前创建的模型中是解决不了,因此,我在数据权限模块设计了两次数据规则,第一处就是全局数据规则,也就是组织架构对应数据规则;第二处是在用户选择角色的时候,可以配置个性化数据规则,如下图,这样就解决了上述两个问题。

另外,还有一个很重要的雷区需要特别小心,就是系统的删除功能,由于业务需要,我们需要删除部分角色或者部门,这时,我们的删除逻辑要怎么处理呢?大家可以想一想,假设我们需要删除的角色与部门下都已经关联了用户,此时要删除需要如何处理这批用户呢?让我来猜测一下,可能大家会说,先批量移除角色或者部门下的用户,然后才允许删除。这个逻辑也是可取的,是正确的,但是对删除这操作来讲,太麻烦了。有一个相对来说简单一点的处理方法:系统先设置一个未分配人员组,删除了某个角色或者部门过后,该角色或部门下关联的用户都进入未分配人员组,然后我们再对这些未分配的人员重新分配角色即可了,这个方案是不是要简单许多