第十章. 系统管理（四）：部门管理（数据权限的核心基石）

本章学习路径

我们将聚焦于部门管理的“增、删、改”及其背后的“安全约束”，最后升华理解其“抽象应用”：

10.1. 部门字段解析与“单一根节点”

在第八章，我们实战了五种“数据权限”，其中“本部门数据”和“本部门及以下数据”是最核心的两种。这两种权限都依赖于一个共同的基础设施——部门管理。

现在，我们就来深入了解这个为“数据权限”提供支撑的基石。

我们点击 系统管理 -> 部门管理。

10.1.1. 树状结构与“单一根节点”的最佳实践

首先映入眼帘的，是一个和“菜单管理”非常相似的树状结构。

我们可以看到 叉叉叉科技 作为最顶层的节点，下面有 深圳总公司、长沙分公司 等，而 深圳总公司 下又有 研发部门、测试部门。

这种层级结构，正是 RVP 实现“本部门及以下”数据权限的关键。

在实际业务中，我们 强烈建议 只保留一个根节点（例如 叉叉叉科技 代表我们的总公司）。如果存在多个并列的根节点，会给后续的数据权限控制带来不必要的麻烦。

10.1.2. 选填字段的业务价值：“类别编码”与“负责人”

我们点击任意一个部门（如 叉叉叉科技）右侧的“修改”按钮，来看看它的配置。

除了“部门名称”、“上级部门”、“显示排序”这些基础项外，我们重点关注几个 非必填 的字段：

• 类别编码：
  • 这是什么？这是一个我们可以自定义的分类标识，甚至可以是重复的。
  • 它有什么用？目前系统没有使用它。但如果我们的业务需要（比如，我们想标记所有“研发”相关的部门，无论它们在哪个城市），我们就可以给它们设置相同的“类别编码”，以便在业务逻辑中灵活控制。
• 负责人：
  • 这里可以关联一个系统内的用户，作为该部门的负责人。
  • 它有什么用？同样，这取决于业务设计。如果我们有一个 OA（办公自动化）流程，需要“部门负责人”审批，那么这个字段就派上了用场。

核心思想：RVP 提供了这些 选填 字段，并不是要求我们必须使用，而是为我们未来的业务扩展预留了“钩子”。如果我们的业务暂时用不上，完全可以忽略它们，这不会影响部门管理的核心功能。

10.2. [重点] 部门的增删改与安全约束

部门管理的核心操作是增删改，但 RVP 在这里设置了非常重要的“安全约束”，这也是新手最容易踩坑的地方。

10.2.1. 新增部门与层级归属

新增部门有两种方式：

1. 方式一（标准）：点击顶部的“新增”按钮，此时“上级部门”需要我们 手动选择。比如，我们选择 叉叉叉科技，然后创建一个新的 广州分公司。
2. 方式二（快捷）：在列表中找到 广州分公司，点击其 右侧 的 +（新增）按钮。此时，系统会非常智能地 自动帮我们选定“上级部门”为 广州分公司，我们直接填写新部门名称（如 研发部门）即可。

10.2.2. [重点] 约束（一）：存在下级部门不允许删除

我们刚刚在 广州分公司 下创建了 研发部门。现在，我们尝试一个危险操作：直接删除 广州分公司。

• 操作：点击 广州分公司 右侧的“删除”。
• 结果：系统弹出错误提示：“存在下级部门，不允许删除”。

这是 RVP 的第一道安全锁。它防止我们因为误操作，而导致 研发部门 及其所有子部门（可能还有很多层）瞬间成为“孤儿”数据。

10.2.3. [重点] 约束（二）：已分配用户不允许禁用或删除

好，既然不能删除父级，那我们去删除子级的 研发部门（广州）总可以了吧？它下面可没有子部门了。

我们先去“用户管理”给这个新部门分配一个用户。

• 操作（准备）：进入“用户管理”，找到 admin（或任何用户），点击“修改”，将其“归属部门”修改为我们刚创建的 广州分公司 -> 研发部门。
• 操作（验证）：回到“部门管理”，点击 研发部门（广州）右侧的“删除”。
• 结果：系统再次弹出错误提示：“该部门存在已分配用户，不允许删除”。
• 操作（再试）：那我不删除，我“停用”总行了吧？点击“修改”，将“部门状态”改为 停用。
• 结果：系统依然提示：“该部门已存在已分配用户，不能禁用”。

这是 RVP 的第二道安全锁。它防止我们正在使用中的部门（有用户在里面）被突然停用或删除，导致数据权限计算出错。

10.2.4. [实战] 正确的部门下线流程

通过上面的实战，我们知道了“不能做什么”。那么，如果我就是想下线 广州分公司 及其所有子部门，正确的流程应该是什么？

文稿中的演示流程非常清晰，我们必须“反向操作”：

1. 解除用户：
   • 回到“用户管理”。
   • 找到隶属于 研发部门（广州）的那个 admin 用户。
   • 将其“归属部门”修改为其他任意部门（例如改回 叉叉叉科技）。
   • 确保 研发部门（广州）及其子部门下 已没有任何用户。
2. 停用/删除子部门：
   • 回到“部门管理”。
   • 此时，我们再去点击 研发部门（广州）的“停用”或“删除”，操作成功。
3. 删除父部门：
   • 当 广州分公司 下所有的子部门（如 研发部门）都被清空后。
   • 我们再去点击 广州分公司 的“删除”，操作成功。

10.2.5. 联动验证：部门变更与用户管理界面的同步

当我们成功“停用”或“删除”一个部门后（如 研发部门），这个变更是 立即生效 的。

此时我们回到“用户管理”界面，点击左侧部门树的“刷新”按钮，会发现 广州分公司 下的 研发部门 已经 立刻消失 了。这证明了 RVP 各个模块之间的“联动性”。

10.3. [核心] 部门的“抽象”应用：不止于“部门”

学到这里，你可能会想：“部门管理，不就是给公司维护组织架构吗？”

如果只停留在这个层面，就大大低估了 RVP 这套设计的精妙之处。“部门管理”的真正威力在于——抽象。

“部门”二字只是一个 标签，它的 本质 是一个可以无限层级、用于实现数据隔离的“树状结构”

我们可以利用这个“树”，搭建出任何我们想要的层级关系。

10.3.1. 场景推演（一）：学校、年级与班级

假设我们要做一个“学校管理系统”。

• 叉叉叉科技（根节点）-> 可以改名为 某某中学。
• 深圳总公司（一级部门）-> 可以改名为 一年级。
• 研发部门（二级部门）-> 可以改名为 一年级一班。
• 测试部门（二级部门）-> 可以改名为 一年级二班。

看，我们用“部门树”完美地搭建了“学校-年级-班级”的组织架构。

数据权限如何应用？

• Prorise 用户是 一年级一班 的 学生 -> 分配“仅本人数据权限”的角色（只能看自己的成绩）。
• admin 用户是 一年级一班 的 班主任 -> 分配“本部门数据权限”的角色（可以看 一年级一班 所有学生的数据）。
• root 用户是 年级主任 -> 分配“本部门及以下数据权限”的角色（可以看 一年级 所有的班级数据）。

10.3.2. 场景推演（二）：宿舍、楼栋与房间

同理，假设我们要做一个“宿舍管理系统”：

• 叉叉叉科技（根节点）-> 某某大学
• 深圳总公司（一级部门）-> A 栋
• 研发部门（二级部门）-> 1 楼
• 测试部门（二级部门）-> 101 房间

通过这种方式，我们可以灵活地控制宿管、楼长、学生所能看到的数据范围。

10.3.3. 核心思维：用“部门树”实现灵活的数据权限隔离

RVP 的“部门管理”为我们提供了一个极其灵活的、用于实现数据权限控制的“架子”。

凡是涉及数据权限控制的场景，我们都可以思考是否能用“部门树”来实现。

这套设计（部门树 + 角色数据权限）是 RVP 框架的精髓之一，它使我们能够用一套固定的框架，去灵活适配千变万化的业务开发场景。

10.4 第十章总结

本章我们深入学习了“部门管理”，它不仅是组织架构的载体，更是 RVP 数据权限体系的基石。

• 核心配置：我们了解了“单一根节点”的最佳实践，以及“类别编码”、“负责人”等字段作为“业务钩子”的选填价值。
• 安全约束：我们实战了部门的两个核心“安全锁”：
  1. 存在下级部门，不允许删除父级。
  2. 已分配用户，不允许删除或禁用该部门。
• 正确流程：我们必须遵循“先解绑用户 -> 再删子部门 -> 最后删父部门”的逆向流程来下线部门。
• 抽象思维：我们深刻理解到“部门”只是一个标签，其 本质是一个数据隔离的“树”。我们可以用它来模拟“公司”，也可以模拟“学校（年级/班级）”或“宿舍（楼栋/房间）”，以实现灵活的数据权限控制。