权限管理平台的产品设计思路

15 评论 24110 浏览 173 收藏 16 分钟

后台的权限管理影响到业务的正常运转,笔者初接触权限管理,受实际工作情况启发,对权限管理平台进行了相应的设计。

权限管理模块是管理整个公司各个业务系统中最重要的一环,笔者之前尚未接触此模块,随着公司业务系统的繁多复杂,不可能在每个后台系统做重复的权限模块。

所以选择做一个独立的权限配置平台,即系统上的系统(此平台),此平台完成两个目标:管理公司组织架构;为整个公司的各业务系统来分配权限。

话不多说,直接上整体设计方案。

一、整体说明

统一权限配置平台(Unified Privilege Configuration Platform,简称upcp,以下简称此平台),权限配置是一个极其复杂的问题,也可简单表述为这样的逻辑表达式:判断“who对what(which)进行how的操作”的逻辑。

针对不同的业务子系统,现将目前的“xxx后台管理系统(后简称:后台管理系统)”命名为“xxx管理系统(后简称:业务系统)”,后续在各个业务板块管理的灵活性、完整性和易维护性之间,将销管系统(待开发)、指数分析系统(待开发)等都独立成单独的子系统,在这些因素权衡后,选择了此方案。

二、名词解释

为了对整个统一权限配置平台里面涉及到的一些名词术语有清晰的理解,现将一些关键元素做一些说明,如下:

  • 用户(员工):成功认证并登录系统的操作员(主体:who);
  • 权限:访问资源的许可(how);
  • 角色:权限的集合体;
  • 业务系统:每个业务板块独立的系统,如:业务系统;
  • 资源:各个业务系统中的菜单、子菜单、按钮、字段等(what)。

整个权限配置平台要素:用户、角色、权限、业务系统、资源。

用户与角色是多对多关系,角色与权限是多对多关系。

如图所示:

三、设计目标

此平台是对各个业务系统的所有功能和数据进行统一权限配置。

四、账号管理

此平台默认一个平台管理员角色,这个账号不可删除,但可以修改(由开发人员创建)。

复制一个平台管理员的账号(平台管理员2),此账号进行:

  • 组织架构的管理与维护(增删改查);
  • 员工信息的管理与维护(增删改查)。

平台管理员2在此平台创建该部门员工账号及分配权限。

普通员工不能登录此平台,只能登录对应的业务系统,维护对应的业务板块的权限。

五、整体规划地图

笔者将从以下四个模块讲起当时的设计思路:

1. 组织架构管理:

  • 建立部门;
  • 部门管理;
  • 组织架构树。

2. 员工管理

  • 员工分配部门;
  • 账号管理。

3. 业务系统管理

1)新增业务系统

2)资源管理

3)角色管理

  • 新增角色;
  • 分配权限;
  • 分配员工。

4. 操作日志管理

  • 操作日志
  • 登录日志
  • 异常日志

5. 大体思路

  1. 组织机构与员工关联;
  2. 新建业务系统管理,维护内部使用业务系统;
  3. 系统角色与业务系统关联;
  4. 角色权限与系统角色关联;
  5. 资源权限与角色权限关联,维护该角色对应的资源列表。

六、产品设计思路

1. 组织架构管理

组织架构管理是对整个集团公司的员工所属组织进行维护、更新的管理。

组织架构默认“xxx集团”,可编辑,不可删除,此版块由平台管理员2维护。

具体需求如下:

  • 对集团总员工有一个数量的统计,数据统计列表包括:组织架构层级、负责人、手机号码、人数、状态(正常/停用)、备注及操作。
  • 操作包括:新建下级部门、停用、查看、编辑和删除(最顶层“xxx集团”不可删除)。
  • 新建下级部门:默认当前添加时的组织机构为此时的上级部门,弹窗录入:上级部门、部门名称、负责人、手机号码、部门状态(正常或停用)、备注。
  • 停用部门:弹窗提示:“停用该部门如包含下级部门将一并停用,是否继续?”,一旦停用该部门后,部门下的员工账号不可登录任何业务系统,如有账号登录业务系统时,toast提示:“该账号被停用”。
  • 删除:当部门下有员工时,弹框提示:“部门或其下部门已有员工信息,请删除相关员工在来操作。”;当部门下无员工,只有部门时,弹框提示:“删除该部门且包含下级部门将一并删除,是否继续?”。

组织架构也可生成树形图形展示,便于实时对照架构的正确性。

2. 员工管理

员工管理中的员工是对各个业务系统的具体操作者,这些是一个一个的员工个体,员工按组织架构新建/导入在对应的组织上,一般是在机构对应的部门(一级部门–二级部门)下。

管理员工的前提是需要合理的组织架构,只有支持组织架构的灵活配置,才能进一步支持组织内人员的增删调整,以及禁止登录、重置密码和停用控制。

员工可以自己拥有权限信息,可以归属于0~n个角色。他的权限集是自身具有的权限、所属的各角色具有的权限,即:员工权限 = 所属角色权限合集+员工自身权限,它与权限、角色之间的关系都是n对n的关系。

具体需求如下:员工管理包括组织机构的展示、查询(员工姓名、状态、手机号码)、员工统计、新建员工、导入员工、分配部门、批量删除。

  • 员工统计列表:姓名、手机号码、所属部门、职位、状态、操作(查看、编辑、禁止登录/允许登录、重置密码、停用/恢复);
  • 新建员工:姓名、手机号码、性别、初始密码、所属公司、所属部门、职位、备注;
  • 员工批量删除:删除后,某角色下的有此员工信息也自动移除该角色;
  • 分配部门:弹窗显示已有的组织架构,勾选分配该员工到达的部门。

这里需要注意禁止登录和停用的区别:

  • 禁止登录:在登录系统时多次输入密码错误,系统会因为帐号安全问题暂时把禁用掉,或涉及到帐号被盗等场景需立马禁止,重置密码等操作。
  • 停用:员工离职,但是在职时所有的操作记录信息还存在,所以设置为停用。(可以跟人事系统打通,人事那边设置某员工离职后,所有系统账号自动设为停用)。

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

3. 业务系统管理

针对不同业务板块独立出来的系统进行管理,是比较粗颗粒度的一种管理方式,这种模式下一旦获得权限,即可对这个业务系统进行操作和全部数据的查看,这种权限开放给部门主管。

具体需求如下:由平台管理员2对各个业务系统进行统一管理,包括新增业务系统、批量删除,据列表统计业务系统的名称、排序、登录链接、编辑、资源管理和角色管理一系列的维护。

  • 数据统计列表:业务系统名称、链接、操作(编辑、资源管理、角色管理)。
  • 其中批量删除:如该业务系统下有关联的资源,toast提示:“该业务系统下关联资源,请删除相关资源后来操作。”;如该业务系统下无关联资源,弹框提示:“是否确定删除该业务系统?”。
  • 员工账号在登录业务系统时,判断员工是否属于该业务系统的某一角色,如果是,才能登录操作对应角色下的资源,否则toast提示“您未授权,无法登录”。

3.1 资源管理

此方案的资源指的各个业务系统下的菜单、子菜单、按钮、字段等。

具体需求如下:

  • 新增资源:平台管理员2可以对业务系统下的资源进行管理,新增资源时,弹窗录入:资源名称(可同时添加同类资源)、资源类型、备注;
  • 数据列表统计有:资源名称、资源类型、排序、编辑、添加下级资源;
  • 添加下级资源:弹窗录入:上级资源(默认当前资源为上级资源,可以修改)、资源名称、资源类型(菜单/子菜单/按钮/字段)、备注;
  • 批量删除:对话弹窗提示:“删除该该且包含下级资源将一并删除,是否继续?” 。

3.2 角色管理

角色往往是基于业务需求而预先在此平台中设定好的标签(目前默认设置已有的5个角色,详见《吃豆车生活管理系统角色权限表》),每个角色对应明确的业务系统权限,是一个集合的概念,是众多最小权限颗粒的组成。通过把权限给这个角色,再把角色给账号,从而实现账号的权限,因此它承担了一个桥梁的作用。

引入角色这个概念,可以帮助我们灵活的扩展,使一个账号可以具备多种角色。

具体需求如下:

  • 新建角色:角色名称,角色描述、复制角色(选择当前系统已有角色)、创建人、创建时间;
  • 数据统计列表包括:角色名称、角色描述、创建人、创建时间、修改时间、操作(编辑、删除、分配权限、重置权限、分配员工)
  • 角色的权限设置:对应跳转到权限分配界面,即资源(菜单/子菜单/按钮/字段),目前默认已知的5个角色权限;
  • 角色分配用户:添加员工,跳转到员工管理,勾选选择员工;移除员工,当前角色下的员工进行移除;
  • 删除:弹窗提示:“删除该角色后,员工会自动移除,是否继续?”。

4. 操作日志管理

操作日志管理用于管理此平台的操作日志,包括有登录日志、异常日志和操作日志。其中:

  • 登录日志是对用户登录操作的记录,记录有操作人员、登录终端型号、操作系统、IP、登录状态、操作内容和登录时间等。
  • 异常日志:帮助平台管理员检测企业内帐号异常登录记录,方便针对有安全隐患的帐号进行安全提升措施。例如:通知员工进行密码强度提升,跟踪检测异常次数较多的设备等,目前异常现象有:密码错误,通过手机号码密码方式登录时,超过3次尝试登录失败,则系统判定为异常登录,即帐号存在安全隐患。记录有操作人员、登录终端型号、操作系统、IP、登录时间和异常现象。
  • 操作日志是对此平台相应模块及其功能操作的记录,包括操作模块、操作结果、操作人员、IP、操作时间和操作内容等,其中操作内容记录的方式为“xx菜单-xx按钮”,如:员工管理-新增员工。

5. 个人资料

个人资料包括:姓名、手机号码、修改密码、所属公司、所属部门、职位、所属角色、备注、账号状态、创建人、创建时间、修改时间、上次登录时间、退出登录。

以上就是一只产品汪对“权限配置平台”的设计思路和对应的实现方法,欢迎和同行一起交流产品设计。

 

作者:蕃茄酱w,公众号:番茄酱w

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

题图来自 Unsplash,基于 CC0 协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
海报
评论
评论请登录
  1. 角色控制功能,架构控制数据查询范围。我是这么定位的。不过它的劣势是,如果要低层级架构人员配置高查询范围,只能调整人员的架构。

    回复
  2. 第四章账户管理中提到的平台管理员,如果存在多个管理员,他们之间的关系是怎样的,可以互相增删改查吗?

    来自广东 回复
  3. 唯一一篇理清了人、组织、角色、权限几方面之间关系的文章。这才是做权限的基石。

    来自浙江 回复
  4. 思路清晰

    回复
  5. 文中说是统一权限管理中心,不知道对多个平台的角色权限是如何规划的?

    来自浙江 回复
    1. 通过添加独立的业务系统,在针对每个业务系统进行资源管理(菜单、子菜单、按钮、字段)和角色管理,最后分配权限

      来自重庆 回复
  6. 权限系统的整体思路和框架没有什么问题,但是涉及数据权限的不知道作者是如何考虑的,不同的角色看到的数据权限范围是不同的,每个业务系统有自己的数据权限控制要求;如何进行统一管理?

    来自江苏 回复
    1. 数据我们实现的思路:把每个字段都作为资源来管理和控制,类似于按钮,做完后感觉还有其他实现办法,但目前没找到~~

      回复
    2. 不知道我说的对不对,我谈谈我对权限的看法,您上面说将每一个字段都作为资源管理和控制,会不会增加开发人员的开发量,因为真正的企业业务平台字段太多了,随随便便就有上千个字段,如果每个字段都要区分出来工作量太大了;我觉得是不是可以考虑将这些数据权限分配到角色中去,将角色与权限关联;举个列子,比如财务这个角色,那我用超级管理员设置出一个财务岗(此设置是一个权限),并且让这个财务岗仅能在后台系统里看到付款成功的订单、审核通过退款的订单等与财务相关的数据、和财务管理模块,(这个配置自然是可以随意配置的,不是前期配置死的)这样再创建财务角色的时候与其关联上,这样同一个订单管理模块不同的角色登录系统就区分了数据权限;其他角色登录自然也看不到财务管理模块的数据,不知道我这么说是不是解决了您上面说的数据权限的问题。总之我觉得将数据权限放到权限上是比较合理的,开发的工作量也比放到字段上要小,而且以后系统进行迭代,如果再增加字段怎么办?还要区分和控制,就比较麻烦了,直接上升到权限去控制数据,应该也会给后续节省资源吧。。。不知道我说的对不对,希望一起交流。

      来自北京 回复
    3. 其实我们也没有全部字段加权限的,只是一些涉及公司商业数据字段这么做的,你提的这个方法,之前我还有考虑,但根据开发实际评估后,没那么实现

      来自重庆 回复
    4. 角色是功能权限的集合,组织是数据权限的集合。同一个角色,在总公司和在分公司是不一样的,总公司可以看所有分公司的数据,但分公司只能看自己公司的数据。同一份数据,不同的角色所能做的操作是不同的,这个通过功能权限进行控制。具体到字段就是功能权限的细分,比如看ABC还是看AC。同时功能权限又有依赖关系,先有查看才能有增删改。

      来自上海 回复
    5. 你说的不错,数据权限指的不是对哪部分字段的操作权限,而是同一个字段下,不同的账号看到的数据是不同的

      来自广东 回复
    6. 具体到数据权限,可以通过客户维护划分数据权限,可以通过状态维护进行划分,或者通过组织树的结构维护进行划分。再细化下去,建立某一个模块下的数字权限,然后将这个权限配给某个角色。然后这个角色就被限制只能看所配的数字权限的数据

      来自广东 回复
    7. 说得对。数据权限的划分,实质上也算是功能权限的再细分,把同一功能权限从数据范围的角度进行细分,分为能查看不同范围数据权限。这个细分的方式可以通过状态维护,不同角色权限状态给予不同的数据权限范围;或者通过结构,划分子角色低级角色进行划分。
      最后请教下,你说的通过“客户维护”划分数据权限是指什么呢,我没有理解明白~

      来自浙江 回复
    8. 你好,前辈,可不可以请你把通过状态维护再讲解一下,我没有理解,非常感谢~

      来自广东 回复