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

70 评论 87966 浏览 746 收藏 7 分钟

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

一、系统概述

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

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

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

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

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

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

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

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

二、实例设计

1、账号管理

添加/编辑账号:

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

2、角色管理

添加/编辑角色:

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

三、经验之谈

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

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

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

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

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

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

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

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

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

 

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

题图来自unsplash,基于CC0协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 一个账号可以绑定多个角色 /如果有些角色权限是互斥或者一样的,那该账号的用户看的东西是求同存异吗 🙄

    来自浙江 回复
    1. 个人理解角色中有权限是互斥的,那么就应该在账号分配的时候设计不能选择互斥角色

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

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

      来自上海 回复
    2. 针对这个问题,你应该有相应的解决办法了吧。我办法是在添加用户的时候给用户进行分类,例如:总经理、主管、员工等。对应的账户可见范围根据类型去进行限制加载。不知道你有没有更好的实现方案,欢迎一起探讨。

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

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

    来自日本 回复
    1. 还有这私活吗,来,聊聊。

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

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

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

      来自上海 回复
  7. 😳 受用

    来自广东 回复
  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. 简单点的,账号-角色-权限,如果权限比较多就账号-角色-权限组-权限 🙄 我现在俩个系统就是这样弄的

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

      来自上海 回复
  18. 很不错,受教了 😳

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

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

      来自北京 回复
  20. 很好 先收藏

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

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

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

    回复
    1. 一起学习进步

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

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

      来自上海 回复
  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. 谢谢你的回复~~ 😆
      第三点我还不是很明白,对数据权限的理解我还不是很透彻 你会不会有什么指教给到我呢?

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

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

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

      来自山东 回复
    7. 明白了 非常谢谢 😎

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

    来自上海 回复
    1. 谢谢鼓励

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

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

      来自上海 回复