【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"
]
}
}
}
}