4个步骤教你:如何建立后台通用权限管理系统?
由于本人的工作方向偏向于后台,同时也是技术出身转岗产品经理,在设计后台时常会查阅后台的相关资料,但是网上关于这方面的分享也比较少,于是利用空闲时间,把所经历的三家公司所设计过的后台系统进行整理、总结,输出一套通用的完整解决方案。系统的跟大家一起来探讨、分享,希望对大家有所裨益。
由于不同的后台管理系统需求多样化,此处所分享的是通用型,对于大多数的后台管理系统逻辑都已足够使用,主要应用于WEB应用程序,如:网站管理后台、CMS、CRM、OA等等。
当然,您也可以对他进一步深度设计,以做出更强的系统。
涉及到权限的问题往往是都是复杂的问题,在系统权限控制方面,我们经常会参照现成的案例来设计自己的权限控制,以下就是我所总结最常见的四种权限控制的方法。(附上高保真原型链接+整体结构图:见最底部)
一、控制系统的帐号及登录
1. 登录首先要有帐号,帐号的定义
基本上所有的互联网产品,无论是移动端、PC端、C端或B端产品,登陆都需要一个账号。只是对于C端的产品,都是用户自己注册即可。
而对于后台产品而言,是需要公司内部人员去创建账号的。而这个账号就是一把钥匙,我们通过控制账号所具备的权限,进而控制这个员工的所操作范围。
2. 帐号的两个层级:企业(管理员)帐号、普通帐号
公司的实际运营人,他应该掌握最核心、权限最大的企业帐号,所以也可以称为“管理员帐号”,其他都为普通帐号。
在实际系统中的核心业务步骤如下:
- 企业购买系统时,创建一个企业帐号,这个企业帐号绑定的手机号码为公司实际运营人的手机号码。该手机号码必要时可以解绑修改(例公司运营人变更),但是企业帐号不可删除、离职。
- 在部署培训阶段,可指导企业账号持有人创建一个或多个普通账号(可是给其帐号授权管理员角色),该账号一般授权给行政总监或人力资源总监,后续配置即由管理员账号进行。
这里需要注意的是2者区别:
- 帐号禁用:在登录系统时多次输入密码错误,系统会因为帐号安全问题暂时把禁用掉。或涉及到帐号被盗等场景需立马禁用,修改密码等操作。
- 帐号停用:员工离职,但是在职时所有的操作记录信息还存在,所以设置为停用。(ps:可以跟人事系统打通,人事那边设置某员工离职后,所有系统账号自动设为停用。)
在用户状态上加状态控制,可用的用户就可以登录系统,禁用、停用的就无法登录。
二、角色管理
角色往往是基于业务管理需求而预先在系统中设定好的固定标签,每个角色对应明确的系统权限,他是一个集合的概念,是众多最小权限颗粒的组成。我们通过把权限给这个角色,再把角色给账号,从而实现账号的权限,因此它承担了一个桥梁的作用。引入角色这个概念,可以帮助我们灵活的扩展,使一个账号可以具备多种角色。
其所拥有的系统权限一般不会随意更改,并且角色也不会随着用户的被添加和被移除而进行改变,相较于用户管理而言更加稳定。
由于随着公司扩大角色的增多,而不好进行管理,比如:hr这个角色,如果集团有分公司可以给与分类,比如:上海分公司:人力总监;北京分公司:人力总监。
这个角色所赋予的数据权限会不一样,对于中小型公司,可以对角色进行一个精细的分类管理起来比较方便。
三、控制功能权限
功能权限定义:为可见、可以操作的功能范围。例如:某一部分菜单,或者某个页面里的各种操作。
1. 菜单管理模块
类型分为3种:目录、菜单、按钮。
- 在目录、菜单上加权限控制,有权限的就可以访问对应模块,没有的连菜单名都看不到。
- 在业务模块的功能按钮上加权限控制,最小粒度的控制用户行为,譬如:老板娘有录入商品的权限,就能看到商品录入的按钮,点击录入就可以进行商品的录入操作;反之没有该权限的店员就无法进行商品录入的操作。
2. 控制功能权限管理
底层菜单管理配置一般为开发人员一早就配置好,现在由用户进行分配使用这些功能权限。
功能权限:以角色为基础,通过划分不同角色的不同功能权限,并将员工添加到对应的角色中,实现员工功能权限的区分和隔离,包括:
- 对象级功能:比如功能的入口是否可见,如角色为“蓝鲸观察者”,对象“人员管理”的“查看列表”权限点取消,则此角色下员工不可见人员管理的功能入口。
- 操作点权限:比如新建、编辑等业务操作;
- 字段权限:在展示信息时加权限控制,保证敏感信息的安全性。可为角色配置对象字段的读写、只读或不可见。比如:为角色“服务人员”配置销售订单的【销售订单金额】字段不可见。
控制了员工对字段的可见性,可编辑性,比如:不想要电销人员看到客户的电话号码,不需要服务人员看到客户销售订单中销售订单金额,则可以把相应字段隐藏。
- 【读写】权限:员工将具备该字段的最大权限,【新建】【编辑】时可编辑,列表和详情页可见该字段。
- 【只读】权限:员工在【新建】【编辑】时不可编辑,列表和详情页可见该字段。
- 【不可见】权限:员工在【新建】【编辑】【列表】【详情】界面对该字段(或该字段值)不可见。
功能权限对于前端界面的影响点:
- 如果员工没有某对象“查看列表”的权限,则该对象的功能入口会被隐藏。
- 如果员工没有某对象的操作点权限,则在对象页面上隐藏相应操作按钮。
- 如果员工没有某对象的指定字段的可见权限,则在对象页面上隐藏相应字段。
3. 控制字段权限用户操作界面
控制字段权限需要有一个页面配置页面来做支撑,此界面由开发人员进行控制操作。
点击某一个页面进行配置,可以进行添加,或从数据库快速生成属于这个页面的字段。在从这个页面的字段中选择哪些字段是提供给用户进行设置字段权限,因此有了上上图。以及字段的显示名称,是否必填字段都是控制提供给用户进行设置字段权限界面。
4. 控制数据权限
数据权限定义:数据权限管理主要控制某条数据记录对用户是否可见,结合功能权限可以更灵活的配置业务过程中每一位员工的功能操作权限及数据可见范围,全面保障企业数据的安全性。
类似矩阵列表中,功能权限决定用户可见哪些列,比如客户对象中可见姓名、电话、邮箱等字段。数据权限决定用户可见哪几条数据,比如:“王先生”、“李先生”等。
数据权限分两个层次来控制数据:
- 基础数据权限:即根据数据的负责人来决定。
- 数据共享:根据基础数据权限中的数据记录所属将其共享给其它用户查看或编辑。
基础数据权限:
- 私有:对象中所有数据遵循相关团队成员(包括负责人)及其上级对数据可见,且对这条数据具备同样的权限【只读、可编辑】,上级部门的部门负责人可以看到下级部门的所有数据。
- 公开只读:对象中所有数据对全公司公开,单条数据的负责人及其上级、以及相关团队具备编辑权限的成员可以编辑该数据。
- 公开读写:对象中所有数据对全公司公开,全员可编辑。
备注:此处的“上级”是指用户的汇报对象,在用户管理界面可进行编辑汇报对象。
系统初始化一开始默认设置好(默认设置的应该是根据客户公司实际运营情况),用户再根据公司的发展而进行改变默认设置,也可进行恢复默认设置,因为默认设置是涵盖了客户公司90%的场景。
数据权限共享:
数据共享规则是将某个部门/员工(数据来源)的某个对象(比如客户)的全部负责的数据共享给某个部门、人员或者用户组(共享范围)。配置数据共享规则后,被共享方对共享方所负责的所有数据可见,并具备共享权限对应的操作权限。
业务配置说明:
- 数据来源于:即需要共享的数据,选择员工即指该员工负责的记录数据,选择部门即指该部门下员工负责的记录数据。
- 共享的数据:选择需共享的对象,比如:将员工A负责的客户数据共享给员工B。
- 数据共享到:被共享方,可选择员工、部门或用户组,被选择的员工、部门或用户组成员将可以看到共享的数据。
- 共享后的权限:配置被共享方可对数据查看或是可编辑的权限,如果配置为“读写”权限后,被共享方对共享数据的权限可类比于负责人的权限。
业务场景举例:销售一部想让财务部张三看到该部门的所有销售订单数据,并且让张三可编辑。
(1)共享规则配置
- 【数据来源】是“销售一部”;
- 【共享数据】是“销售订单”
- 【共享范围】是“张三”;
- 【共享权限】是“读写”。
(2) 配置完成后
配置完成后,张三在【销售订单】对象,【共享给我的】场景下,可以看到销售一部的所有员工负责的销售订。
附上高保真原型链接+整体结构图:
《蓝鲸后台权限管理系统》高保真原型链接:http://www.wulihub.com.cn/go/4Jrn8J/start.html#g=1&p=登录页面&c=1
总结
后台权限管理系统并不是越复杂越好,只有贴合客户实际需求并具备最大弹性的权限系统,并有效控制开发成本的设计就是合理的设计。
以上根据自己的设计经验总结给出的一套方案,小小产品一枚,有不足之处,欢迎各路大神拍砖指教~
本文由 @ 董小姐 原创发布于人人都是产品经理。未经许可,禁止转载
题图来自Unsplash,基于CC0协议
原型链接可以再发一下吗?看不了了呢
请问一下,如果我可能所属多个部门的情况下,如何将确定自己发布的数据是属于哪个部门呢
请问您这边所属多个部门的业务场景是?
所属多个部门的情况,从人事的角度一般为借调 或 兼职。
1、借调:例如,张三从A部门借调到B部门,那么在借调期间,该员工属于B部门,所产生的业务数据,如薪资、绩效等都归属B部门。有B部门权限的管理员才能看到这些业务数据,A部门的管理员的权限只能在员工档案看到此张三档案数据,无法看到张三产生的B部门的业务数据。
借调期结束后,张三所属部门变回A部门后,这时再产生的业务数据归属A部门。
2、兼职:例如,张三本部门为产品部老大,兼职测试部老大。实际所属部门不变,那么产生的相关业务数据一般归属产品部,只不过在审批流、考评上,系统按照关系找产品部、测试部的领导时均可找到张三。
还有一种情况,由于该员工所属多个部门,所以在创建业务数据时,应该下拉选择所属部门,让数据有个归属部门。
ps:所属部门数据来源为员工所属部门和兼职部门的数据,不过主要结合实际系统业务设计。
希望对您有帮助!
你好,理解下来角色授权那边的字段权限资源是通过页面管理这个模块功能来实现的,但是页面和菜单的关联是如何实现的呢,是通过页面管理中的那个主键吗?
请问菜单管理中的连接目标是干什么的,在设计中是必须的吗
请问可以分享一下框架图的原型文件吗
挺不错哦(这不是机器回复)
分享内容很详实,谢谢楼主。
你好,查看原型链接需要登录?
不需要,直接点击登录即可进入
请问下组织架构管理采用树状结构的形式展现好实现吗?会不会被前端砍啊
数量比较庞大的组织确实不适合用这个组件,确实会被前端砍
反手就是一个订阅加个赞
谢谢支持哦!
你好,有框架图的原型文件可以分享么?
具体可以直接在文章中预览哦
有问题想讨论下:1)共享功能中,如果被共享人没有被共享模块的菜单和功能权限,这种情况是怎么处理的?2)当前登录人可以查看的数据范围是按什么维度来控制的呀?3)因为有主部门和附属部门,新建数据的时候,怎么来判断该数据是属于主部门还附属部门?
1、跟共享人有没有权限没关系,例如员工没有请假单模块权限,但是hr有啊,可以帮他录入。
数据共享规则是将某个部门/员工(数据来源)的某个对象(比如请假单)的全部单据的数据共享给某个部门、人员或者用户组(共享范围)。
2、当前登陆人可以查看的数据范围在数据共享那边去决定
3、新建数据,怎么判断该数据属于主部门还是复数部门什么意思
楼主的第一个问题的意思我明白:
还是这个业务场景举例:销售一部想让财务部张三看到该部门的所有销售订单数据,并且让张三可编辑。
被共享人张三被共享了销售订单的数据权限,但是按照业务理解,财务人员张三理应是没有订单模块的权限啊,比如订单的列表查看,订单详情等等。但这个时候共享了订单数据给张三却没有该订单模块的菜单及功能权限。出现矛盾….
你好,需要有菜单权限,分配的数据权限才会发生作用哦,如果没分配菜单权限为啥要共享数据呢,数据权限在功能权限的基础上成立,目前前端页面是没有这个判断的,但是程序逻辑里边要有这层的判断。如果没有菜单权限,数据权限有没有分配都是一样的。
这是我的想法,欢迎交流!
3)是否可默认为主部门,可以修改;或者在上层已经存在部门间数据隔离,数据归属可以继承
功能是挺全的,就是感觉操作太复杂了 ➡
涉及到底层的权限分配是会比较复杂,只要理清逻辑业务,大家可把这个作为参考自行根据实际情况优化哦~
这种设置方法的话,如果一个字段权限设置了读写,但对应操作权限没有选,或者反过来的时候,系统逻辑如何判断呢?
只有进行勾选了查看列表,才显示设置字段权限按钮
你好高保真原型图链接打开怎么是登录页面的啊?
不好意思看懂了
你好,加我一下,1903841331微信
你好有框架图的原图吗?
有的,可加我微信:13544773417
你也太好了吧 😐