权限管理模块是管理整个公司各个业务系统中最重要的一环,笔者之前尚未接触此模块,随着公司业务系统的繁多复杂,不可能在每个后台系统做重复的权限模块。 所以选择做一个独立的权限配置平台,即系统上的系统(此平台),此平台完成两个目标:管理公司组织架构;为整个公司的各业务系统来分配权限。 话不多说,直接上整体设计方案。 一、整体说明统一权限配置平台(Unified Privilege Configuration Platform,简称upcp,以下简称此平台),权限配置是一个极其复杂的问题,也可简单表述为这样的逻辑表达式:判断“who对what(which)进行how的操作”的逻辑。 针对不同的业务子系统,现将目前的“xxx后台管理系统(后简称:后台管理系统)”命名为“xxx管理系统(后简称:业务系统)”,后续在各个业务板块管理的灵活性、完整性和易维护性之间,将销管系统(待开发)、指数分析系统(待开发)等都独立成单独的子系统,在这些因素权衡后,选择了此方案。 二、名词解释为了对整个统一权限配置平台里面涉及到的一些名词术语有清晰的理解,现将一些关键元素做一些说明,如下:
整个权限配置平台要素:用户、角色、权限、业务系统、资源。 用户与角色是多对多关系,角色与权限是多对多关系。 如图所示: 三、设计目标此平台是对各个业务系统的所有功能和数据进行统一权限配置。 四、账号管理此平台默认一个平台管理员角色,这个账号不可删除,但可以修改(由开发人员创建)。 复制一个平台管理员的账号(平台管理员2),此账号进行:
平台管理员2在此平台创建该部门员工账号及分配权限。 普通员工不能登录此平台,只能登录对应的业务系统,维护对应的业务板块的权限。 五、整体规划地图笔者将从以下四个模块讲起当时的设计思路: 1. 组织架构管理:
2. 员工管理
3. 业务系统管理1)新增业务系统 2)资源管理 3)角色管理
4. 操作日志管理
5. 大体思路
六、产品设计思路1. 组织架构管理组织架构管理是对整个集团公司的员工所属组织进行维护、更新的管理。 组织架构默认“xxx集团”,可编辑,不可删除,此版块由平台管理员2维护。 具体需求如下:
组织架构也可生成树形图形展示,便于实时对照架构的正确性。 2. 员工管理员工管理中的员工是对各个业务系统的具体操作者,这些是一个一个的员工个体,员工按组织架构新建/导入在对应的组织上,一般是在机构对应的部门(一级部门–二级部门)下。 管理员工的前提是需要合理的组织架构,只有支持组织架构的灵活配置,才能进一步支持组织内人员的增删调整,以及禁止登录、重置密码和停用控制。 员工可以自己拥有权限信息,可以归属于0~n个角色。他的权限集是自身具有的权限、所属的各角色具有的权限,即:员工权限 = 所属角色权限合集+员工自身权限,它与权限、角色之间的关系都是n对n的关系。 具体需求如下:员工管理包括组织机构的展示、查询(员工姓名、状态、手机号码)、员工统计、新建员工、导入员工、分配部门、批量删除。
这里需要注意禁止登录和停用的区别:
在用户状态上加状态控制,可用的用户就可以登录系统,禁止登录、停用的就无法登录。 3. 业务系统管理针对不同业务板块独立出来的系统进行管理,是比较粗颗粒度的一种管理方式,这种模式下一旦获得权限,即可对这个业务系统进行操作和全部数据的查看,这种权限开放给部门主管。 具体需求如下:由平台管理员2对各个业务系统进行统一管理,包括新增业务系统、批量删除,据列表统计业务系统的名称、排序、登录链接、编辑、资源管理和角色管理一系列的维护。
3.1 资源管理 此方案的资源指的各个业务系统下的菜单、子菜单、按钮、字段等。 具体需求如下:
3.2 角色管理 角色往往是基于业务需求而预先在此平台中设定好的标签(目前默认设置已有的5个角色,详见《吃豆车生活管理系统角色权限表》),每个角色对应明确的业务系统权限,是一个集合的概念,是众多最小权限颗粒的组成。通过把权限给这个角色,再把角色给账号,从而实现账号的权限,因此它承担了一个桥梁的作用。 引入角色这个概念,可以帮助我们灵活的扩展,使一个账号可以具备多种角色。 具体需求如下:
4. 操作日志管理操作日志管理用于管理此平台的操作日志,包括有登录日志、异常日志和操作日志。其中:
5. 个人资料个人资料包括:姓名、手机号码、修改密码、所属公司、所属部门、职位、所属角色、备注、账号状态、创建人、创建时间、修改时间、上次登录时间、退出登录。 以上就是一只产品汪对“权限配置平台”的设计思路和对应的实现方法,欢迎和同行一起交流产品设计。 本文由 @番茄 原创发布于人人都是产品经理 题图来自 Unsplash,基于 CC0 协议 |
|