后台系统:账号权限系统设计

不懂技术怎么做产品?15天在线学习,补齐产品经理必备技术知识,再也不被开发忽悠。了解一下>

文章对账号权限系统设计展开分析,希望能够给你带来些启发。

一、系统概述

一个账号权限管理系统,主要包括三个元素:账号、角色、权限。我们所要管理的,也就是账号、角色和权限之间的关系。

账号:基本上所有的应用,无论是移动端,PC端,C端或B端产品,登陆都需要一个账号。只是对于C端的产品,都是用户自己注册即可。而对于后台产品而言,是需要公司内部人员去创建账号的。

角色:所谓角色,就是用来控制各个账号的操作范围的,可以理解为权限组。因为一个系统中权限太多,我们不可能每创建一个账号,就去挨个设置一遍权限,因此可以根据不同的部门、职级、工作内容等来对权限进行分组,制定成不同的角色,这样,在创建账号时,就可以直接赋予账号不同的角色,从而把角色拥有的权限给到这个账号。

权限:包括数据权限、操作权限和页面权限。

一、数据权限:即账号可以看到的数据范围,比如一个旅游行业的公司管理者能看到公司的所有数据,而亚太部的人只能看到亚太部门产生的数据。在设计过程中,数据权限控制的难易程度与业务和公司部门设置的复杂程度有关。

二、页面权限&操作权限:页面权限即账号可以看到的页面内容,操作权限即用户可以进行操作的内容,如增删改等。在产品设计的过程中,可以将操作权限和页面权限结合起来做到一个集合中,创建角色时将权限赋予给角色即可。

系统的主要流程为:将权限设置成不同的集合,即角色,再将角色绑定到账号上,那么这个账号就拥有了这些角色的权限集合。一个账号可以绑定多个角色,一个角色又拥有多个权限。

如上图所示:用户A拥有了角色1和角色2两个角色,从而拥有了“增加、删除、审核”的权限。

二、实例设计

1、账号管理

添加/编辑账号:

在创建账号时,一般都需要填写基本信息和设置角色。基本信息主要包括姓名,部门,账号备注等等,不同企业需求不同。
此外,为了控制数据权限,还可能会有账号等级的选择、账号关联、上下级关系绑定等操作。具体流程视设计情况而定。

2、角色管理

添加/编辑角色:

需要说明的是,角色不能随意删除或禁用,需要判定该角色有没有被哪个账号绑定,若该角色正在被使用,则不允许删除并给出相应的提示。

三、经验之谈

1、事先可以对账号进行一个等级划分(根据实际业务制定划分规则),然后可以根据等级来判定数据权限。如等级为公司高级管理者,则可以看到所有的数据,而等级为分公司管理员,则根据分公司的ID或者名称去获取对应的数据等。不过这个只能做一个比较粗略的控制,仅一个等级来控制数据权限是远远不够的;

2、考虑是否需要提供账号与账号之间做数据关联的入口。当然,这是属于比较特殊的情况,当设计的控制数据权限的规则都不能满足的时候,是否需要为特例提供操作入口;

3、考虑是否需要提供一个账号和数据之间直接做绑定的入口?如:等级为分公司管理员,由于业务需求,需要看到另外一个分公司的某条数据,该如何实现。当然,这里只是举了一个很简单的例子,实际实现时会有很多更细节和深入的问题;

4、若大部分账号在权限上都存在差异,那是否每个账号都需要有一个设置详细权限的地方,而仅把角色当做一个快捷选择的方式。(若不是必需,最好不要采取该种方式,这样会破坏权限的规范性,不利于维护和管理);

5、创建角色(权限组)之前,需要明确各个部门之间的业务范围及权限(包括页面权限和操作权限),并将这些人就行划分;当然,随着公司的业务和后台系统功能的改变,各个角色的权限是需要不断完善和调整的;

6、在一些系统流程中,还需要为权限设置互斥关系,这样的话,拥有互斥权限的两个角色就不能同时绑定给同一个账号了。是否需要这一步操作,需要根据业务情况而定;

7、对于一些基础的账号,在创建账号时,是否需要直接根据账号等级绑定默认角色(即给以默认权限)。

暂时想到的就是这些,后面想到了会再继续补充。

小小产品一枚,文章纯属工作中个人经验总结,欢迎大神拍砖指教。

 

本文由 @姜荨 原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自unsplash,基于CC0协议

给作者打赏,鼓励TA抓紧创作!
6人打赏
评论
欢迎留言讨论~!
  1. 一个账号可以绑定多个角色 /如果有些角色权限是互斥或者一样的,那该账号的用户看的东西是求同存异吗 :roll:

    回复
  2. 其实我还是想问一下,同一个页面不同的角色进来看到的数据都是不一样的(不是字段不同是可产看的数据范围不同),如果要做成可配置化,应该怎么去做呢?有没有哪位大佬可以解答一下呢,感谢!

    回复
    1. 对于字段的数据范围进行配置

      回复
  3. 原来产品并没有做账号角色权限的划分,后期想补上,请教下老数据该怎么处理呢?有什么好的思路吗?

    回复
  4. 大佬,我有个后台设计私活,有兴趣聊聊吗

    回复
  5. 深有同感,有些点我遇到过,有些点给了我扩展,超棒啊

    回复
  6. 超级棒啊,最近刚刚接触后台,很有用的,想请教您一个细节,那个创建员工信息时,是把角色设置和基本信息分开录入,如果我只填写了员工信息,没有选择角色就点击了保存,页面回到列表页还是继续请求选择角色?两个板块的信息是统一保存还是单独保存,可不可以把选择角色和基本信息放在一个板块里呀?

    回复
    1. 如果一个用户只有一个角色,且后续不会变化,可以添加用户信息的时候一起设定;但很多情况下,员工可能同时有多个角色,且可能会需要修改调整。所以,建议分成两步,添加用户信息一步,为用户维护用户角色是另外一步。

      回复
  7. :oops: 受用

    回复
  8. 账号权限设定好之后,后期增加功能的时候,是分角色增加功能吗?比如A角色增加abc功能,B角色增加cd功能??

    回复
  9. 请问下第2点角色管理中的例子中,给角色添加权限,这里是不是只有页面权限和数据权限,而没体现操作权限呢?操作权限是不是页面上的操作按钮?

    回复
    1. 权限配置应该还有一个单独的页面,分 页面 功能 以及 数据,对下边的子选项进行勾选。组合起来塑造一个角色

      回复
  10. 您好!希望加您微信多多交流

    回复
  11. 您好!希望加您微信多多交流

    回复
  12. 请问数据权限后台怎么控制的

    回复
  13. 这是Axure原型么?

    回复
    1. 对,是用axure画的

      回复
  14. 账号、角色、权限用三个维度来定义用户登陆后台所拥有的权限。在真正操作时,是否会过于复杂。因为你要时时刻刻记住或记录,对应的用户所拥有的的角色与权限分别是什么。直接在用户开通账号选择权限不好吗?这样直接开权限即可,不会出现权限互斥的问题。而且增加用户新权限时,直接选择对应权限即可。不用在去找文档选择对应角色或新增对应的角色。

    回复
    1. 一般情况下,一个系统的权限会很多,一个账号甚至可以登录多个系统,如果每次创建账户的时候再一个个去勾选,其实是很不现实的。不过,如果权限比较少的情况下,你想要这样设计也是可以的,没有对错的问题。

      回复
    2. 极端一点的例子,你可以想象一下 如果今天新增初级用户为5万,两种方案:
      1. 把初级用户这个角色直接assign给所有新增用户
      2. 手动给每个用户去选择权限

      我们肯定会选择方案1呀,节省了太多时间和精力,

      回复
    3. 这就是C与B的区别,B你不能先考虑操作是否复杂,而应该先考虑是否兼容多种场景,易于维护。

      回复
    4. 经验之谈哈哈哈

      回复
    5. 看来这句是你的口头禅了~

      回复
  15. 一个账号对应多个角色,当该用户登录系统时,A是一次性看到多个角色下的全部权限,B是通过切换角色的方式查看不同角色的不同权限。大家更多是采用哪种方案?

    回复
    1. 肯定是A啊,B的意义何在?考虑什么限制吗?

      回复
    2. 一般来说都会先考虑A吧。

      回复
    3. 我感觉要看这多个角色的数据权限范围是否一致,如果一致那A是没问题,如果不一致那应该是B。比如一个人即是部门A的负责人,又是分管财务的分管领导,作为部门负责人,他有部门所有事物的权限,可以访问部门财务、认识、业务等数据,但是作为分管财务的饭馆领导,那他能看整个单位的财务信息,但不能查看其它部门的人事、业务信息,如果合起来,就会是所有部门的所有财务、人事、业务都能拿看了。

      回复
    4. 评论没有编辑功能?发现错别字都不能修改了。

      回复
  16. 为部门角色规划权限的事情,产品还是少/不去掺和,由运营人员去和对应的业务部去对接。个中缘由,一想就通。

    回复
    1. 经验之谈

      回复
  17. 很不错,我现在的系统都是这样设计的,基本上现在的后台系统账号权限设计都大同小异

    回复
    1. 是啊,最基本的元素都是那几个

      回复
    2. 简单点的,账号-角色-权限,如果权限比较多就账号-角色-权限组-权限 :roll: 我现在俩个系统就是这样弄的

      回复
    3. 恩呢都差不多,我现在也是账号——角色——权限:oops:

      回复
  18. 很不错,受教了 :oops:

    回复
  19. 个人感觉,一个账户只有一个角色,一个角色可以有多个权限,而且还要考虑原始角色设计,即有一个角色拥有所有的权限,随着系统功能的增加,权限自动增加,由它赋予其他角色新的权限或者建立角色

    回复
    1. 一个账户拥有多个角色,是为了角色的权限统一化,如果一个账户只允许有一个角色的话,根据公司人员和业务需求不同,势必会出现一大堆不标准化的“角色”,到后期对角色的管控是有很大风险的 :oops:

      回复
  20. 很好 先收藏

    回复
  21. 基础很牢,不知道,再往点的问题,如,,复杂的部门权限如何划分,这种,你是怎么解决的

    回复
    1. 后面会再继续整理完善的 :oops:

      回复
  22. 正准备写这个需求,涉及到总公司分公司几十个用户,8个角色,受教了。

    回复
    1. 一起学习进步

      回复
  23. 梳理的很全面了!创建账号时选择角色应该属必填项,如果过于复杂的业务其实并不适合

    回复
    1. 嗯嗯。现在是基于工作中涉及到的项目整理的,后面会继续思考学习,谢谢提示 :oops:

      回复
  24. RBAC

    回复
  25. 考虑是否需要提供账号与账号之间做数据关联的入口。当然,这是属于比较特殊的情况,当设计的控制数据权限的规则都不能满足的时候,是否需要为特例提供操作入口;
    请教下 这句话 不是很理解 账号和账号之间怎么做数据关联呢?是针对哪种用户。

    回复
    1. 其实我也不知道这样表述正不正确。这句话想表达的意思是:比如某个部门所有人的默认权限是自己只能看到自己创建的数据,A只能看到他自己创建的,B也只能看到他自己创建的,若A也想要看到B的数据,那是不是可以把两个账号做关联从而实现数据共享呢。

      回复
    2. 这个地方的业务特点可能不应该属于权限系统的范畴了吧,是否考虑可以通过业务操作来实现呢

      回复
    3. 有时候要根据实际情况做调整 这些也不是绝对的

      回复
    4. 千人千面

      回复
  26. 很棒!!!

    回复
  27. 想要转发在我们公司内部平台分享可以吗

    回复
  28. 我司的产品是从两个层面去阐述的
    1.业务层面:用户,岗位,部门
    2.系统层面:数据权限,功能权限
    用户即是账号,被赋予了岗位和部门
    岗位则是功能权限的集合,按照需求给岗位设置相对应的功能权限
    部门则是数据权限的集合,按照需求给部门设置相对应的数据权限

    简单来说,岗位和部门结合为用户;数据权限和功能权限结合为账号权限

    回复
    1. 最近正好也在做这一块,我的想法跟你的设计类似。想就此咨询一下:
      1.你的意思是绕开了角色这一概念吗?
      2.我也觉得这样更符合公司组织架构或者更好理解,公司组织中,不同的岗位就拥有不同的权限,也就是说岗位就是系统上说的角色,然后把权限赋给岗位,岗位赋给用户 是这样吗?
      3.部门就是数据权限的集合:那如果要给部门中的不同岗位赋予不同的数据权限要怎么办呢?

      回复
    2. 不好意思,下午才看到你的信息
      1.角色即是岗位,概念一样,称呼不同而已。
      2.你的理解是正确的
      3.在系统层面,部门和岗位是独立而平行的,也就是说,你可以任意组合部门和岗位之间的关系

      回复
    3. 谢谢你的回复~~ :lol:
      第三点我还不是很明白,对数据权限的理解我还不是很透彻 你会不会有什么指教给到我呢?

      回复
    4. 同一BU的设计和运营能看的数据肯定不完全相同,所以不用太死板地认为部门就决定数据权限。不过可取之处就是,角色可以从部门*岗位*职级3个小维度来做控制,决定到底哪些权限挂在下面。

      回复
    5. 那数据权限还是需要通过配置的方式来设置吗?还是数据权限是通过什么方式来控制的呢?

      回复
    6. 如果具体场景,需要为同一个部门的不同人划分数据权限的话,也可以做一个页面来配置,只要确保数据集合能够区分到一定的粒度。但是通常来说,通过部门(更应该说是组织架构,重点是节点间的关系)已经划分了数据权限了,举个OA的例子——工作日志,比如顶级部门A,子部门A1,子部门A2,那么A1可以看到A1部门下所有人的工作日志,A2可以看到A2部门下所有人的工作日志,A就可以看到A1,A2下的工作日志,这是不需要单独配置的,组织架构已经确立了这种关系了,当然这里还会考虑限制数据可见的层级数的问题,根据具体需求来判断了。

      回复
    7. 明白了 非常谢谢 :cool:

      回复
  29. 写得已经很全面了,本质是RBAC模型的实践,经验之谈的部分很不错,很多复杂的业务逻辑都考虑到了,很棒

    回复
    1. 谢谢鼓励

      回复
  30. 非常感谢!正在准备案例,希望转岗成功

    回复
    1. 加油,共同交流进步

      回复