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

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

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

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

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

一、整体说明

统一权限配置平台（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. 个人资料

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

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

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

题图来自 Unsplash，基于 CC0 协议

作者暂无likerid, 赞赏暂由本网站代持，当作者有likerid后会全部转账给作者（我们会尽力而为）。


Support author:
Author's Filecoin address:
Or you can use Likecoin to support author: