先建部门、后任命管理员

[zhujue888]

当前系统逻辑：创建部门时，强制要求同步创建一个“部门管理员”账号，部门和管理员账号是绑在一起生成的。

按标准的 RBAC（基于角色的访问控制）模型给您梳理一套完整的设计思路，您可以拿去对照验收或提整改要求。

---

一、核心模型：四层结构

一个规范的权限体系应该是四个独立实体，两两解耦：

用户（账号） ——多对多——> 角色 ——多对多——> 权限
    │                                        
    └——归属——> 部门（组织架构）                 

• 用户：只管“这个人是谁”，姓名、手机号、状态、所属部门；
• 角色：管“这个人在系统里能干什么”，如超级管理员、公司级管理员、部门管理员、普通员工；
• 权限：具体到“能看哪个菜单、能用哪个按钮、能调哪个接口、能看哪些数据”；
• 部门：只管组织架构本身，不承载权限逻辑。

关键点：角色和权限多对多，用户和角色多对多。一个人可以既是部门 A 的管理员，又是公司级管理员；离职时只需停用账号或摘掉角色，其他都不用动。

---

二、四个模块分别怎么设计

1. 部门管理

• 树形结构，支持增删改查、上下级调整；
• “负责人”字段允许为空（未任命状态），仅作展示，不作为权限依据——权限由角色决定，不在部门表里写死；
• 删除部门时校验：下面还有没有子部门、还有没有在职人员，有则拦截。

2. 用户管理（人员账号）

• 创建账号时只填基本信息：姓名、手机号、所属部门、岗位，不强制选角色，默认“普通员工”；
• 账号列表提供“分配角色”操作，随时可任命、可变更、可回收；
• 账号状态：启用/停用，停用即失去所有登录和权限。

3. 角色管理（当前系统缺的这个模块）

• 预置四个基础角色：

角色 | 数据范围 | 典型权限 -- | -- | -- 超级管理员 | 全部 | 系统设置、角色管理、组织管理 公司级管理员 | 全公司 | 业务数据全览、人员管理、审批终审 部门管理员 | 本部门及下级部门 | 本部门人员管理、业务数据本部门范围 普通员工 | 仅本人 | 本人业务操作

• 支持自定义角色（比如“项目经理”“财务”），每个角色勾选对应的功能权限和数据范围；
• 部门管理员这类角色要支持绑定管理范围（哪个部门），这样同一个角色可以复用给不同部门的人。

4. 权限管理
分三个层面，缺一不可：

• 菜单/页面权限：决定登录后能看到哪些模块；
• 操作/按钮权限：决定页面上能点哪些按钮（如“删除”“导出”“审批”）；
• 数据权限：决定能看到哪些范围的数据——本人 / 本部门 / 本部门及以下 / 全部 / 自定义部门集合。这是“部门管理员只看本部门、公司管理员看全部”的实现基础。

---

三、权限与系统接口的对接方式

这部分是给开发方提要求用的：

1. 登录认证：用户登录后，后端签发令牌（JWT/Session），并在返回中带上该用户的角色编码和权限码列表；
2. 前端控制：根据权限码控制菜单显隐、按钮置灰（这只是体验层面的“藏起来”）；
3. 后端拦截（真正的安全防线）：每个接口标注所需权限，网关或中间件统一校验，无权限直接返回 403。前端藏了按钮但接口没拦截，等于没防；
4. 数据权限注入：查询类接口在 SQL 层自动拼接数据范围条件，比如部门管理员查列表时自动追加 WHERE dept_id IN (本部门及子部门)；
5. 权限缓存与即时生效：角色变更后要能刷新权限缓存（或重新登录生效），并在需求里明确“权限变更多久生效”，避免验收扯皮。

---

四、按这个模型走一遍您的业务流程

1. 建部门（不填管理员，随时可建）；
2. 招人 → 创建账号，归属该部门，默认普通员工；
3. 任命 → 在账号上授予“部门管理员”角色并绑定该部门，立即生效；
4. 升职 → 追加授予“公司级管理员”角色，一人多角色并存；
5. 调岗 → 变更所属部门 + 重新绑定管理范围，账号不用重建；
6. 离职 → 停用账号，所有角色自动失效，历史数据保留可追溯。