产品经理在产品架构中的四种权限控制的方法!

产品经理在产品架构中的四种权限控制的方法!

不管是2C产品经理还是2B产品经理,都要将权限管理法则烂熟于心。只有熟悉权限管理法则,才能更好地理解自己产品的架构,做到每次产品迭代都心里有数。

产品经理在思考产品架构的过程中,必须要有业务流程的参与。通过业务流,常常会抽象出对产品有诉求的多个角色,再依据角色的特性去梳理使用场景并设计需求。

当角色之间的使用场景不冲突,不需要隔离时,我们会综合考虑这些角色的使用场景来设计解决方案。比如QQ音乐同时需要为听歌和听电台的用户提供所有的功能需求。

角色权限管理设计_角色权限图_角色权限设计5张表

当这些角色的使用场景完全不重叠、流程对立时,我们会设计完全独立的两套系统,如微店卖家端和买家端;

角色权限设计5张表_角色权限图_角色权限管理设计

除了上面两种情况,在toB产品中,基于产品流程和信息安全等多符合因素考虑, 各个角色的使用场景是部分通用,部分隔离的,这时候就需要引入“权限系统”了。

角色权限图_角色权限设计5张表_角色权限管理设计

涉及到权限的问题往往是都是复杂的问题,在系统权限控制方面,我们经常会参照现成的案例来设计自己的权限控制,以下就是John所总结最常见的四种权限控制的方法。

一、控制系统的帐号及登录

1. 帐号的定义

基本上所有的互联网产品,无论是移动端、PC端、C端或B端产品,登录都需要一个账号。只是对于C端的产品,都是用户自己注册即可。

而对于后台产品而言,是需要公司内部人员去创建账号的。而这个账号就是一把钥匙,我们通过控制账号所具备的权限,进而控制这个员工的所操作区域。

2. 帐号的层级:企业(管理员)帐号、普通帐号

公司的实际运营人,他应该掌握最核心、权限最大的企业帐号,所以也可以称为“管理员帐号”俗称admin账号,其他都为普通帐号。

在实际系统中的核心业务步骤如下:

(魅族的小伙伴可以说下,魅族论坛账号为“J.Wong”是不是admin的权限。哈哈哈哈)

在用户状态上加状态控制,可用的用户就可以登录系统,禁用、停用的就无法登录。

二、角色管理角色

往往是基于业务管理需求而预先在系统中设定好的固定标签,每个角色对应明确的系统权限,他是一个集合的概念,是众多最小权限颗粒的组成。我们通过把权限给这个角色,再把角色给账号,从而实现账号的权限,因此它承担了一个桥梁的作用。引入角色这个概念,可以帮助我们灵活的扩展,使一个账号可以具备多种角色。

其所拥有的系统权限一般不会随意更改材质材料,并且角色也不会随着用户的被添加和被移除而进行改变,相较于用户管理而言更加稳定。

角色权限设计5张表_角色权限管理设计_角色权限图

而引入“角色”概念后,用户与角色之间的关系链是怎么样的?这儿引用一个模型:RBAC模型(已经被大家写文章用坏了,可能有些小伙伴还是懵逼),John这边贴上百度百科解释下:

基于角色的权限访问控制(Role-Based Access Control)作为传统访问控制(自主访问,强制访问)的有前景的代替受到广泛的关注。在RBAC中角色权限设计5张表,权限与角色相关联,用户通过成为适当角色的成员而得到这些角色的权限。这就极大地简化了权限的管理。在一个组织中,角色是为了完成各种工作而创造,用户则依据它的责任和资格来被指派相应的角色,用户可以很容易地从一个角色被指派到另一个角色。角色可依新的需求和系统的合并而赋予新的权限,而权限也可根据需要而从某角色中回收。角色与角色的关系可以建立起来以囊括更广泛的客观情况。

简单点一句话说下:Who(权限的拥有者或主体)对What/Which(权限针对的对象或资源)进行How(权限针对的对象或资源)操作。

角色权限管理设计_角色权限图_角色权限设计5张表

上图示意为:用户与角色可为多对一或多对多的关系,当一个用户的角色为多对多时,当前用户的权限是多个角色的并集。

此时只需要为角色赋予权限,能够大大减轻管理负担,同时将用户与权限解耦,提供更大的灵活性。

由于随着公司扩大角色的增多,试想如果用户量上万,新增一个角色时,可能需要为大量用户都分配一遍新的角色,工程量仍然巨大,此时即可以引入用户组的概念:如果部分用户的使用场景是相对一致和基础的,我们可以把这些用户打包成一个组,基于这个组的对象进行角色和权限的赋予。

同理如果权限较多时也会存在一样的问题,处理方式是引入权限组的概念,将使用场景相对固定的一组功能或权限打包成组赋予角色。但是一般来讲一个系统中权限功能的体量是相对有限和可控的,所以实际应用中对权限组的使用较少。

角色权限图_角色权限管理设计_角色权限设计5张表

角色权限管理设计_角色权限图_角色权限设计5张表

角色权限设计5张表_角色权限图_角色权限管理设计

用一个页面例子来解释下:

角色权限管理设计_角色权限图_角色权限设计5张表

(用户组)

角色权限设计5张表_角色权限管理设计_角色权限图

(用户管理)

角色权限图_角色权限管理设计_角色权限设计5张表

(用户权限&权限组)

三、控制功能权限(案例)

功能权限定义:为可见、可以操作的功能范围。例如:某一部分目录,或者某个页面里的各种操作。

1. 目录管理模块

类型分为2种:目录、操作。

在目录上加权限控制,有权限的就可以访问对应模块。

在业务模块的功能按钮上加权限控制,最小粒度的控制用户行为。例如:上级有录入商品的权限角色权限设计5张表,就能看到商品录入的操作,点击录入就可以进行商品的录入操作;反之没有该权限的下级就无法进行商品录入的操作。

角色权限设计5张表_角色权限管理设计_角色权限图

(红色的代表目录,蓝色的代表操作)

2. 控制功能权限管理

底层目录管理配置一般为开发人员一早就配置好,现在由用户进行分配使用这些功能权限。

功能权限:以角色为基础,通过划分不同角色的不同功能权限,并将员工添加到对应的角色中,实现员工功能权限的区分和隔离,包括:

字段权限:在展示信息时加权限控制,保证敏感信息的安全性。可为角色配置对象字段的读写、只读或不可见。比如:为角色“服务人员”配置销售订单的【销售订单金额】字段不可见。

角色权限设计5张表_角色权限管理设计_角色权限图

(字段权限细节)

功能权限对于前端界面的影响点:

总结下:在权限管理中,需要遵循的一个重要的点:用户移动要匹配对应的操作。

四、配置权限注意点

产品设计支持后,配置权限需要注意以下几个要点:

1. 确定是否支持前端配置

如果角色和权限相对固定,则一般将角色与权限的关系可以写在后台,改动时需要后端变更且重新上线;这种情况适用于公司内部系统等只有一个使用主体的系统。

如果需要自定义角色、或者每个角色在不同使用者的场景下有不同的权限,则需要将角色的定义、角色与权限之间的配置体现在“前端用户配置页面”;这种情况适用于有频繁变动的自定义角色权限,和有租户体系的系统。

2. 以基本单元拆分硬件设备,以业务逻辑配置

一般可将每个对象的“增、删、改、查”各自作为一个基本的权限单元。打个比方,在“人员管理”中,查看人员列表、添加人员、删除人员、编辑人员信息最好拆分为4个权限单元。在技术和设计上,我们希望能尽量做到解耦和模块化。

但是在业务层面有些操作却是一体的。这些不能拆开的权限在“前端用户配置页面”中建议打包成一个整体提供配置。例如,如果我们确定在系统的现有和未来业务中,仅分为普通成员有“人员管理”的查看权限,管理员有操作权限,则可将“增、删、改”三个基本权限单位合并为“操作”权限进行配置。

3. 页面权限优先于操作和数据权限

必须配置了页面模块权限后,才能配置当前页面模块下具体的操作权限,以及页面模块的数据展示权限;

4. 查看权限优先于增删改权限

正常情况下,一定要先能查看某个模块或操作,其它的增删改操作才有意义。因此在设计时,应在获取查看权限前限制其它权限的配置;或者配置其它权限时默认赋予查看权限。

5. 角色与权限的多种关系

角色与权限的关系不仅是单纯“是/否关系”,还包括以某种限制进行操作,和以某种程度访问数据。例如在“人员管理”中:

6. 角色与权限的设计表达

在传达一个系统的权限设计规则时,设计师常常习惯用主观最直接的方式表达想法,如用“当……时,就……”的句式来表达。但一个平台中涉及的权限规则是非常多的,当通篇以这样的形式描述时,表达对象将很难理解。

正确的描述方式:更清晰的是基于开发的语言,和技术模型的结果进行表达:将各角色与权限单元绘制成网格,每个交叉点网格中描述该角色与权限的数据关系和限制。

五、后台产品逻辑自查表

后台产品逻辑遵循的就是八个字:“增(增加)”、“删(删除)”、“改(修改)”、“查(查询)”、“显(显示)”“算(算法)”、“传(传递)”和“异(异常)”。用一张表来整体看下自查表:

角色权限设计5张表_角色权限管理设计_角色权限图

后台权限不复杂,用户角色和权限一一对应匹配就好了。同样前端后台都不复杂,只要真实清楚的去了解业务就好了。

上一篇文章是一个视频,很多小伙伴都看了好几遍,是关于产品经理工作流程的全解释。可以看看:

(产品经理工作流十二步)

提前祝大家中秋节快乐……

点个“在看”吧。写文不易。

文章来源:https://www.sohu.com/a/340431910_695183