一、项目背景
1.1 需求来源
前段时间，笔者所在公司收到了多个客户对后台权限和角色的需求。讨论发现，现有的产品后台架构并不能很好的满足用户需求，所以为了满足这些客户的需求并为之后可能存在的业务拓展打下基础，我们决定对现有产品的后台用户体系进行迭代。
1.2 需求的拆解
通过过滤需求，我们发现其实用户的需求主要是两类：
是要求我们的用户体系可以承载用户多级分销的业务模式并满足各级分销之间数据权限的要求；
是要求我们完善对用户权限的控制。
二、理论依据
涉及到后台用户管理系统，绕不开的概念就是权限，任何一个账号都会有自己的用例。但是多数情况下，我们对部分账号的用例会做一些限制，如果直接将这种限制加在账号上，就会产生二个问题：
每个账号都要配置很麻烦；
无法批量修改一类用户的权限。
所以角色的诞生就呼之欲出了，我们通过对权限集的抽象，创立了角色，通过修改角色，来达到控制拥有该角色的账号的权限修改的目的。
权限可以分为数据权限和功能权限两大类：
数据权限顾名思义，就是账号能查看多少数据，如何实现A部门与B部门之间相互不能查看业务数据，这个就涉及到数据权限；
功能权限按照范围以大致菜单权限和按钮权限，按照操作可以大致分为查看和编辑权限。
2.1 RBAC-0模型
2.1.1 简述
RBAC-0 模型的特点就是用户和角色是多对多的关系，同一个用户拥有多个角色的属性，我们通过组织这个概念来构建组织架构，从而实现对角色数据权限的分配。这样单个用户账号拥有的全部权限就是他所在组织的权限的累加。
2.1.2 举例
在RBAC-0模型中，A用户负责X组织的业务，B用户负责Y组织的财务工作。正常情况下，A和B自然不能查看对方的数据，但是如果有天，B由于业务需要需要协助处理X组织的财务，那我们就可以通过为B用户添加X组织的“财务”角色来实现这种需求。在业务结束后，也可以通过暂停/删除操作来管理B在X组织下的权限。
2.2 RBAC-1模型
基于RBAC-0模型，针对角色引人继承的概念，子角色可以对父角色的权限进行继承，但是子角色的权限一定小于父角色。
2.3 RBAC-2模型
相较RBAC-0系统，RBAC-2系统在用户与角色间和角色与角色之间加入了一些规则。
单个角色允许分配的用户数限制，例如一个公司不可能有多无限个“董事会”角色；
单个用户允许授予的角色数限制，例如单个用户不允许在一个公组织或多个组织担任无限多个职务；
角色与角色有层级关系，例如想新增一个部门经理，不能用一个部门职员的账号去创建吧？
角色与角色存在互斥关系，这个根据实际业务需要来做限制，例如销售不能兼任会计。
2.4 RBAC-3模型
RBAC-3模型也叫统一模型，它基于了RBAC-0，并包含了RBAC-1和RBAC-2模型的全部特点。
三、设计过程
3.1 新增账号的属性
新增账号是用户体系的最基本的功能，新增账号时需要获取账号的哪些参数决定了整个用户体系的数据维度。
这里不得不提的就是USER_ID，登录账号，昵称的概念。
USER_ID：对应的是账号在系统中唯一标识，可以不展示给用户,例如微信的open_id和union_id，一般在新增账号时由系统生成，且不可修改；
登陆账号：登录账号和USER_ID在有的系统并不一致，同一个USER_ID可能对应着多个登录账号，例如微信可以通过微信号，手机号，邮箱去登录，这里的不同登陆方式都对应这一个登陆账号，一般在新增账号时，由用户输入，且不可修改；
昵称：昵称是用户可以自由编辑操作的，由用户输入，且允许修改。
3.2 功能权限的处理方式
功能权限通过对角色的权限树进行修改来实现。在权限树种我们可以将页面权限，菜单权限和按钮权限罗列，通过筛选对应权限完成对角色功能权限的控制。
需要注意的一个问题是，权限控制的最小粒度。如果要实现每一个权限的控制，相当于每一个权限对应功能都需要做封装。大的页面和菜单权限是必备的，但是哪些按钮权限是可以封装在一起的，（比如“启用”和“暂停”一般都是成对出现的），这些是需要产品考虑的。
3.3 数据权限的处理方式
数据权限其实是角色权限的重要属性，但是由于数据范围太灵活，如果在角色加入“数据权限”tab，如果账号下的数据量较大，用户编辑数据权限的操作会很繁琐。因此，因此现在主流的后台设计都会使用“组织结构”来对应数据权限。
在系统中，我们使用了【新增组织】的方式，来处理数据权限。
3.4 对老用户的兼容
在做用户体系的重构时，老用户的账号兼容问题是产品必须考虑的部分。兼容问题也是从功能和数据两个维度去验证新的体系是否对老用户是否有影响。
四、总结
文章的内容主要是本次迭代中实际的使用场景，抱着他山之石可以攻玉的想法，参考了现有的资料，结合自己系统的实际情况，对用户体系设计做了一次小结。若有不足之处，还请大家多多沟通，共同进步。
网友评论