【Saas】【OA】基本管理设计：权限管理/角色管理/组织管理/成员管理
前言
第一次接触 Saas(Service as a soft)，用此博客记录本人从 0-1 摸索企业管理（OA）平台的设计思路及中途所遇见的坑，共勉。
背景
设计一个 OA 管理平台，此篇重点讲述通用的基本管理功能：
- 权限管理
- 角色管理
- 组织管理
- 成员管理
权限管理
框架初构
在设计权限管理时，目前尝试到最好的方式是将操作权限（即按钮的可见可点击）和数据权限拆分开，以灵活适配各种用户场景。其中，划分的权限颗粒度越细，权限配置的场景可越灵活。
-
操作权限: 即管理平台的页面操作按钮，涉及页面控件的封装，采用可见即可操作原则。
- 是否所有的操作按钮都需要权限控制？
- 除开基本的增删查改，还有哪些基本的常用控件需要控制权限？
-
数据权限: 同样的表单，不同部门看到的数据需要区分，部门管理人可见数据及非部门管理人可见数据也需要做区分。
- 数据分配仅由权限管理分配？
- 当涉及上层可见直系下级的权限，应该做在逻辑上 or 权限管理中？
- 数据往往可分类为：个人数据/部门数据/全部数据
- 数据也可按照相关方分类：个人数据/相关方数据/全部数据
-
权限继承: 上级可继承（拥有）下级所拥有的权限
- 涉及权限继承，会加大设计难度，需谨慎。
- 往往在新建用户时分配足够多的权限，则无需考虑继承子成员权限的问题
权限控制图
权限管理设计
1. 明确权限管理范围
权限管理贯通了整个管理平台的功能及数据，在设计前需要明确：
- 当前的管理平台有哪些模块？
- 模块里哪些操作是需要分配权限？哪些操作无需分配权限？
- 模块里数据是否需要分配权限？数据分类是按照组织维度（个人数据/部门数据/全部数据）/相关方纬度（个人数据/相关方数据/全部数据）或其他纬度？
- 是否会有后期动态新增的权限？
- 若提供自定义表单功能，是否需要热更新表单的操作权限及数据权限
2. 权限控制设计
采用树结构列举所有的权限，以下为示例：
点击查看JSON
{
"module_a": {
"operate_approval": {
"create": "新增权限",
"read": "读取权限",
"update": "编辑权限",
"delete": "删除权限",
"other": "其他操作权限"
},
"data_approval": {
"all": "此模块全部数据可见",
"none": "此模块全部数据不可见",
"department": "部门全部数据可见",
"user": "仅个人数据可见"
}
},
"module_b": {
"operate_approval": {
"create": "新增权限",
"read": "读取权限",
"update": "编辑权限",
"delete": "删除权限",
"other": "其他操作权限"
},
"data_approval": {
"all": "此模块全部数据可见",
"none": "此模块全部数据不可见",
"relation": "此数据相关人可见",
"user": "仅个人数据可见"
}
}
}
角色管理
什么是角色
角色即多个权限的合集，不同的角色拥有不同的权限集。
角色将决定成员在该项目中的功能权限，即该成员可否使用某项功能。一般在项目中有预置的系统角色，已预置好相应的权限。
如何管理角色
- 支持增删查改即可
由于角色的权限配置对于普通用户来说存在一定的理解成本，故一般会预设系统角色，而不对用户开放增删改的功能
基本预置角色
-
超级管理员admin
- 拥有所有权限，且不可删除不可更改权限
-
普通管理员
- 根据业务场景适配
-
普通成员
- 根据业务场景适配
预置角色示例
字段意义见权限管理
点击查看JSON
{
"超级管理员": "拥有所有权限",
"普通管理员": {
"module_a": {
"operate_approval": {
"create": true,
"read": true,
"update": true,
"delete": false,
"other": true
},
"data_approval": {
"all": false,
"none": false,
"department": true,
"user": false
}
},
"module_b": {
"operate_approval": {
"create": false,
"read": true,
"update": true,
"delete": false,
"other": false
},
"data_approval": {
"all": false,
"none": false,
"relation": true,
"user": false
}
}
}
}
组织管理
用于管理企业的组织架构，将用户划分至不同的部门或部门下的用户组
框架初构
- 采用树结构设计组织架构
- 根节点往往为组织名（公司名）
- 第二层节点往往为部门名
- 再往下可支持自定义用户组
- 不建议无限增加组织树深度
组织结构json示例图：
点击查看JSON
{
"组织名": {
"部门": {
"财务部": {
"用户组-1": {},
"用户组-2": {}
},
"行政部": {}
}
}
}
增删查改组织节点
- 新增组织节点：建议限制组织树的深度，即尽量减少子部门的层级
- 删除组织节点：
- 组织节点会与成员挂勾，需考虑当组织节点被删除后，所在节点下的成员应如何处理
- 更改组织节点：
- （同删除节点，需考虑相关的成员处理）
- 查询组织节点：
- 按照初构的组织树结构进行查询即可
成员管理
明确成员的基本要素
- 用户id：用户的唯一标识，不可重复
- 用户名：用户的直观展示信息
- 用户密码：后台维护，不展示出来
- 用户角色：给用户分配的权限，可见角色管理
- 用户所在组织架构：需全路径展示，避免混淆
- 关键人物标志：区别是否为当前组织节点下的leader
成员管理可提供的相关功能
- 增删查改成员
- 导出成员列表
- 重置密码
- 绑定与解绑手机号/微信号...
成员与组织架构
- 成员可挂在任意组织节点下，并因此形成上下级部门关系
点击查看JSON
{
"xxx公司": {
"用户列表": [
"用户A",
"用户B",
"用户C"
],
"部门": {
"财务部": {
"用户列表": [
"用户F",
"用户G"
],
"用户组-1": {
"用户列表": [
"用户D",
"用户E",
"用户F"
]
}
},
"行政部": {
"用户列表": [
"用户H",
"用户I"
]
}
}
}
}
