产品经理要做的操作权限/数据权限设计

产品经理在工作中还需要知道一个：用户权限设计能力。权限设计理念贯穿于后台产品、以及用户前端产品。

权限能力包括两类：数据权限、系统操作权限

有的人会好奇，为什么前端产品会有有权限管理的要求？接下来我将以角色、权限、以及RABC权限设计方法来概述权限设计、数据权限设计2个操作。

了解权限系统前，首先要定义角色，角色的分类如下

最高权限角色

超级管理员，这个角色一般为平台创建者。可以拥有最高权限，可分配所有的系统权限到其他用户，一般是把最高权限设计还会映射一个超级管理员作为副管理，方便删除、编辑人员

副管理员角色

副超级管理员，仅次于最高权限，可以分配自己权限下的以外权限。显然在他之上就是超级管理员权限

部分权限所有者角色

是指的是在副管理员下，有子权限的用户。比如在副管理员分层下的权限

特约用户角色

只是定向权限开通，同事这样的用户有大量的。比如PMTalk产品经理社区的签约作者

付费用户角色

付费用户权限在针对产品生命周期早期是与免费直接区分，随着付费用户精细化运营打造用户分层，比如QQ会员的超级会员、普通会员等

角色之间的关系如下，可以看见在超级管理员角色下以树状结构分布到子角色。

▲  角色之间关系 

基于角色权限控制的RABC权限思想

依次为理论的角色设计模型关系图

▲  RABC角色权限 

上图是基于用户的会话集合归位角色再分配权限。角色有操作和控制对象的权利，在基础上将用户权限系统氛围：用户管理、角色管理、权限管理。

实际上用户管理在系统早期是可以满足权限使用，但随着系统用户、公司扩张逐渐增多，可能用户会有因为部门的职责区别，造成了部门下的同用户权限是一样的。

因此产品经理务必要在用户管理上增加部门管理对角色区分。

▲  部门管理 

将部门架构的编辑、添加、管理都以系统化的方式管理。

看到部门之间的流转关系，还可以知道部门下有什么基础权限。比如运营部门肯定会涉及到公众号管理、客服号管理，所以在以下部门的员工都要求设置。

同个部门中存在多个角色，比如上有运营总监、副总监、组长、用户，因此权限要给到每个部门负责人进行编辑、删除、添加。

让权限管理者降低了日常运营权限工作量，将权限分配能力分配给了其他成员。

▲  网上来自部门角色权限管理的配置图 

用户管理，给与用户授权角色

最普遍的做法是设计用户名单列表，针对用户信息进行编辑。

用户管理列表如上，可以操作用户属于封禁状态与否、查看用户先有状态。

每个角色下的权限设置，可以编辑权限、和删除权限。以及批量同意权限

设置好角色后，还可以在角色下查看已经开通的用户名单，对用户名单进行管理。

用户名单进行删除、添加。同时当前页面需要下可以展示多少用户、是否需要分页也要注意明确。

2.添加/创建用户

为系统添加新的管理人员，增加权限。增加手机号、邮箱、用户名称，如果企业使用了OA系统，可以和OA系统进行关联。

比如现在的企业微信、钉钉都是支持开放接口，快速同步员工信息。

3.创建添加账户管理流程

系统建设好后，接下来就是规范运营了。以账户开通来说要建立账户开通权限流程规范，比如下图是某个公司开通运营系统管理员权限的流程

▲  系统权限创建流程

上图“选择字段”可以理解为权限下的子权限。若系统不复杂可以不用在早起权限设计上增加子权限颗粒度。

我们需要先设置角色，给新账号关联对应的角色，如果账号有特殊权限或者相关字段的权限，再单独设置相关字段。

最后基于RABC角色权限系统设置，产品经理可以借鉴的一个思考脑图案例

完成权限设计后，要搭建权限表单。快速罗列各个角色下的权限通道

▲  图片来自网络 

数据权限的设计

操作权限是比较容易做的，但数据权限则比较难了。甚至许多互联网公司都没有考虑数据权限，只要达到不同人员使用的功能不同即可。

数据权限可以控制组织、可以控制数据域（比如，10个门店，有的人能看到1个门店的数据，有的人能看到10个门店的数据）

做个比喻，功能权限就像是容器，觉得了你有什么功能，数据权限就像水，决定了你容器内放的是什么。功能权限和数据权限是相互独立的。

数据权限是指对系统用户进行数据资源的可见性、以及控制性。直白说：“复合条件的用户才能查看和操作对应数据的权限”

比如公司老板需要看到公司的营收、利润、用户增长数据

公司运营总监需要看到互联网产品业务营收

公司公司销售要看实物销售产品的以后

在数据权限设计下，要定义清楚规则元

名词定义：规则元。在本文是指单个独立的数据规则定义，不同用户对规则元可设置具体的规则过滤值，该值用作数据查询时的筛选条件。

规则元配置：规则元名称的配置。一个表中哪些字段可以进行规则设置，以及规则元名称如何与表字段关联。