【Saas】【OA】基本管理设计：权限管理/角色管理/组织管理/成员管理

前言

第一次接触 Saas(Service as a soft)，用此博客记录本人从 0-1 摸索企业管理（OA）平台的设计思路及中途所遇见的坑，共勉。

背景

设计一个 OA 管理平台，此篇重点讲述通用的基本管理功能：

• 权限管理
• 角色管理
• 组织管理
• 成员管理

权限管理

框架初构

在设计权限管理时，目前尝试到最好的方式是将操作权限（即按钮的可见可点击）和数据权限拆分开，以灵活适配各种用户场景。其中，划分的权限颗粒度越细，权限配置的场景可越灵活。

1. 操作权限: 即管理平台的页面操作按钮，涉及页面控件的封装，采用可见即可操作原则。

   • 是否所有的操作按钮都需要权限控制？
   • 除开基本的增删查改，还有哪些基本的常用控件需要控制权限？

2. 数据权限: 同样的表单，不同部门看到的数据需要区分，部门管理人可见数据及非部门管理人可见数据也需要做区分。

   • 数据分配仅由权限管理分配？
   • 当涉及上层可见直系下级的权限，应该做在逻辑上 or 权限管理中？
   • 数据往往可分类为：个人数据/部门数据/全部数据
   • 数据也可按照相关方分类：个人数据/相关方数据/全部数据

3. 权限继承: 上级可继承（拥有）下级所拥有的权限

   • 涉及权限继承，会加大设计难度，需谨慎。
   • 往往在新建用户时分配足够多的权限，则无需考虑继承子成员权限的问题

权限控制图

权限管理设计

1. 明确权限管理范围

权限管理贯通了整个管理平台的功能及数据，在设计前需要明确：

1. 当前的管理平台有哪些模块？
2. 模块里哪些操作是需要分配权限？哪些操作无需分配权限？
3. 模块里数据是否需要分配权限？数据分类是按照组织维度（个人数据/部门数据/全部数据）/相关方纬度（个人数据/相关方数据/全部数据）或其他纬度？
4. 是否会有后期动态新增的权限？
   • 若提供自定义表单功能，是否需要热更新表单的操作权限及数据权限

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

成员管理可提供的相关功能

1. 增删查改成员
2. 导出成员列表
3. 重置密码
4. 绑定与解绑手机号/微信号...

成员与组织架构

• 成员可挂在任意组织节点下，并因此形成上下级部门关系
  

点击查看JSON

{
    "xxx公司": {
        "用户列表": [
            "用户A",
            "用户B",
            "用户C"
        ],
        "部门": {
            "财务部": {
                "用户列表": [
                    "用户F",
                    "用户G"
                ],
                "用户组-1": {
                    "用户列表": [
                        "用户D",
                        "用户E",
                        "用户F"
                    ]
                }
            },
            "行政部": {
                "用户列表": [
                    "用户H",
                    "用户I"
                ]
            }
        }
    }
}