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

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

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

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

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

最高权限角色

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

副管理员角色

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

部分权限所有者角色

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

特约用户角色

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

付费用户角色

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

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

▲  角色之间关系 

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

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

▲  RABC角色权限 

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

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

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

▲  部门管理 

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

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

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

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

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

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

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

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

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

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

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

2.添加/创建用户

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

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

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

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

▲  系统权限创建流程

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

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

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

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

▲  图片来自网络 

数据权限的设计

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

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

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

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

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

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

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

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

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

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

你可能感兴趣的:(产品经理要做的操作权限/数据权限设计)