- 1、本文档共7页,可阅读全部内容。
- 2、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
- 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载。
- 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
- 5、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
- 6、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们。
- 7、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
- 8、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
4个步骤教你建立后台角色权限系统
4个步骤教你建立后台角色权限系统
角色权限系统设计可以更好的优化工作的流程步骤,本文分享角色权限系统设计的几个主要步骤。
公司的商户后台刚建立不久,之前仅能支持系统管理员和商户管理员两种角色使用,随着产品和业务线逐渐成熟,参与到整个产品中的人员越来越多了,涉及的部门和角色也由从前的一两种变成了多种,故由我主导了角色权限系统的重构升级。在此将工作心得记录下来,分享给需要用到的人。
先简单介绍下我司的后台产品功能,我司主要业务是向B端企业客户销售一些智能硬件,客户买到产品之后会将产品关联到自己的商户后台,硬件会上传一些核心数据到后台供商户管理查看,所以我们的后台核心功能是:设备管理、商户管理、用户管理、数据管理、产品销售管理。
角色权限系统
了解完我司后台的大概功能后,我们来聊下角色权限系统。
角色权限系统属于策略设计范畴,它的设计非常考验一个PM对业务的理解力以及对自己后台所有功能的熟悉程度。做角色权限系统之前一定要先深度了解业务流程以及后台的所有功能模块,在不了解的情况下,多向相关同事请教,避免角色权限系统设计过程中出差错和逻辑漏洞。由于角色权限系统属于功能底层系统,很多的业务功能、前端功能都深度依赖角色权限系统,所以尽量在第一次出产品方案时就尽可能的考虑全面,减少后续不必要的返工,如果前期产品方案不够缜密,后期改动成本会非常大。
目前市场主流的角色权限模型是RBAC权限模型,具体技术原理可以阅读下这个博客/lhyqzx/p/5962826.html,有人好奇为什么做角色权限系统设计还要了解技术架构呢?这个是为了让设计者能够设计出高效、安全、灵活且技术可实现的角色权限系统。
RBAC权限模型核心就是功能权限控制和角色产生关联,角色再和用户账号关联,即创建用户账号时选定一种角色,该角色里已经分配好了功能和权限。拿我们系统为例,由于有系统管理员和商户管理员的区别,即系统管理员可以查看所有的商户和设备数据,商户管理员逻辑上只允许查看自己商户下 的设备数据。所以我为了更灵活高效的去创建用户角色(比如:商务经理、商务专员、客服经理、客服专员等),我在用户角色之前又设置了角色类型,详见下图:
关于用户角色的创建权限上这里需要说明的是:如果贵司组织结构比较庞大,使用后台的角色人员涉及到各个职能部门,且不同职能部门又有不同的角色,那么创建、管理角色的权限应该下放到各个部门的leader,便于管理系统用户的效率。由于我司业务的特殊性,可以预估到会参与使用后台的角色大概十来种,所以我为了更加集中、高效、安全的管理用户角色,设定的只有超级管理员可以创建和修改角色。
角色权限系统设计流程
角色权限系统设计的大概流程如下:
一、工具准备
思维导图工具(mindmanager、Xmind都可,我用的Xmind)、word 、Axure.
二、给每个角色类型梳理功能架构图
功能架构图梳理是为了让设计者清晰理解后台所有的产品功能模块,以及各个产品功能之间层级关系,给每个角色类型都梳理一份功能架构图,可以让产品自身和开发以及项目成员都了解每个角色类型的区别。
比如:超级管理员这个角色类型,它应该可以管理后台的所有产品功能,并且拥有一些自己独有的功能权限;
比如:角色管理和账号管理功能我设定的只让超级管理员有权访问,其他角色类型全部访问不了,所以也不需要配置;
再比如:高级全局管理员应该有管理低级别角色类型的权限,而低级别角色类型不能管理高级别角色类型。
梳理功能架构图时可以根据一、二、三级这样的功能层次来画思维导图,有的后台系统可能非常庞大,那么是否需要把一级功能到一直到末级的所有功能包括界面按钮都全部罗列出来呢?这个需要看业务需求,看公司组织架构,多方面综合考虑再决定权限控制到哪一层,罗列到哪一级别的产品功能。通常情况下,权限控制到二/三层级基本能满足一个中小型公司的权限管理需求,再大型一点的公司,可以控制到更深层级的功能权限。
此外,我并不建议将权限控制到非常精细的级别,精细到可以控制前端页面上的每一个按钮,甚至每一个按钮的颜色以及交互效果,因为后台产品的核心是管理平台。管理无非增删改查四个操作,对于后台而言,管理的效率非常重要,如果权限控制的过于精细,在进行创建、修改角色时,效率会非常低。并且,如果不是系统的设计者理解起来会非常困难,对于页面上的一些关键按钮和操作可以加以控制。
注意事项:
层级划分清晰,不同级别的功能尽量用不同的字体区分开。
同类型的功能权限用不同的色块儿填充,一般来讲每种角色类型都至少会有两种类型的功能权限,(1)默认该角色类型拥有的功能权限,无须配置 (2)需要配置的功能权限。
之所以给不同角色类型的默认设定了一些功能权限,是为了创建角色
文档评论(0)