第十一章. 系统管理（五）：新版岗位管理（部门下的精细化职责）

本章学习路径

我们将从“为什么改版”出发，深入理解新版岗位的核心价值：

11.1. [核心] 从“用户标签”到“部门下属”：5.x 岗位设计的演进

在学习本章前，我们必须先思考一个问题：在 RVP 中，我们已经有了“部门”（第十章）和“角色”（第八章），“部门”管组织，“角色”管权限，为什么还要多此一举，再来一个“岗位管理”？

这是一个非常好的问题，而 RVP 5.x 的答案，与 4.x RVP 4.x 截然不同。

11.1.1. 回顾 4.x：岗位的“尴尬”定位

在 RVP 4.x 的老版本中，“岗位”是一个非常尴尬的存在。它与“部门”没有任何关系。

这意味着，“研发部” 的 “项目经理” 和 “市场部” 的 “项目经理”，在 4.x 系统中很可能指向的是 同一个 岗位。这显然是不合理的，“研发项目经理” 和 “市场项目经理” 的职责、考核、工作流完全不同。

在 4.x 中，岗位更像是一个全局的、扁平化的“用户标签”，它的业务价值非常有限，导致很多开发者在二次开发中宁愿直接“阉割”掉这个模块。

11.1.2. 剖析 5.x：岗位与部门强绑定的动机

RVP 5.x 彻底“重构”了岗位管理，解决了这个核心痛点。

新版设计的核心思想：岗位（Post）只有在部门（Dept）的上下文中才有意义。

“研发部” 下的 “项目经理” 和 “市场部” 下的 “项目经理”，现在是 两个完全独立 的实体。

这才是真实世界中企业运作的方式。一个岗位（职责）必然是归属于某个部门（组织）的。

11.1.3. 新的筛选逻辑：左侧部门树的联动

理解了“岗位必须归属部门”这个核心思想，我们再来看“岗位管理”的界面，就豁然开朗了。

我们点击 系统管理 -> 岗位管理。

• 左侧的部门树：这在 4.x 中是没有的。它现在是 必须的，用来“筛选”——你必须先告诉系统：“我想看哪个部门下的岗位？”
• 联动筛选：
  • 当我们点击 深圳总公司，右侧列表会显示隶属于 深圳总公司 及其 子部门（如 研发部门）的所有岗位。
  • 这证明了筛选是 自上而下 穿透的。

这个 UI 上的巨大变化，就是为了“强迫”我们接受 5.x 的新设计：先确定部门，再谈岗位。

11.2. 岗位与部门的“强绑定”实操

这个“强绑定”的设计，不仅体现在查询时，更“强制”地体现在创建和分配时。

11.2.1. 岗位创建：必须先归属于部门

我们点击“新增”岗位：

• 上级部门：这是 必填项。你无法创建一个“无根之萍”的岗位。你必须先指定这个岗位“长”在哪个部门下。

11.2.2. 用户分配：必须先选部门，再选该部门下的岗位

这个“强绑定”逻辑在“用户管理”模块中体现得淋漓尽致，也是 新手最容易踩坑 的地方。

我们来做一个实战演练：

1. 场景：我们有一个岗位 普通员工，它归属于 叉叉叉科技（根部门）。
2. 操作：我们进入“用户管理”，修改 Prorise 用户。
3. 踩坑：Prorise 的“归属部门”假设是 深圳总公司。此时，我们去点击“岗位”下拉框。
4. 现象：下拉框是空的！ “普通员工” 岗位去哪了？
5. 解谜：系统此时的逻辑是：“你为 Prorise 选择的部门是 深圳总公司，我（系统）只会为你加载 深圳总公司 下的岗位。普通员工 是 叉叉叉科技 的，所以你当然选不到。”
6. 正确操作：
   • 第一步：在“归属部门”字段，将 Prorise 的部门修改为 叉叉叉科技。
   • 第二步：此时，再去点击“岗位”下拉框。
   • 现象：普通员工 岗位出现了！

11.2.3. 联动逻辑的意义：确保职责归属清晰

这个“先选部门、再选岗位”的联动下拉框设计，不是 Bug，而是一个至关重要的特性。

它在数据层面上，100% 保证了“用户”、“部门”、“岗位”三者之间绑定的 一致性 和 强关联。它杜绝了“研发部”的员工被误分配一个“市场部”岗位的可能性。

11.3. 岗位的核心字段与安全约束

11.3.1. [重点] 岗位编码的业务价值

我们打开一个岗位的“修改”界面，会看到“岗位名称”和“岗位编码”。

对于二次开发者来说，我们必须建立一个铁律：在我们的业务代码中，永远只使用“岗位编码”，绝不使用“岗位名称”。

• 岗位名称（如 董事长）：是给人看的，非常容易变化（今天叫“董事长”，明天可能改叫“老板”）。
• 岗位编码（如 ceo）：是给程序看的，它必须是 唯一且稳定 的。

在我们的业务逻辑中（例如 if/else 判断、权限校验），必须依赖 ceo 这个“岗位编码”来进行，这样无论“岗位名称”怎么改，我们的程序都不会出错。

11.3.2. 选填项：“类别编码”的业务钩子

和“部门管理”一样，岗位也提供了一个选填的“类别编码”。它的作用也完全一致：为未来的业务扩展预留“钩子”。

例如，我们可以给所有“技术”相关的岗位（无论在哪个部门）都打上 TECH 的类别编码，方便我们后续做“技术类”岗位的统一统计或培训。

11.3.3. 安全约束：已分配用户禁止停用/删除

这个约束和“角色”、“部门”完全一致，是 RVP 的标准安全设计。

1. 场景：Prorise 用户已被分配了 普通员工 岗位。
2. 操作：我们回到“岗位管理”，尝试“停用”或“删除” 普通员工 岗位。
3. 结果：系统 阻止 了该操作，提示“已分配用户，不能禁用/删除”。

正确流程：必须先去“用户管理”，将所有使用该岗位的用户（如 Prorise）的岗位 替换 成其他岗位，才能回来停用或删除。

11.3.4. [注意] 岗位分配的“替换”逻辑（无法清空）

在实操 11.3.3 的“解除绑定”时，我们会发现 RVP 5.x 在这里有一个非常“独特”的设计：

• 操作：我们去修改 Prorise 用户，想“清空”他的岗位，点击岗位字段的 x 叉号，然后保存。
• 现象：保存失败！ 或者再次打开，发现岗位 依然还在。

结论：在 RVP 5.x 中，用户的岗位 只允许“替换”，不允许“清空”（至少在默认的前端交互上是如此）。

你不能把 Prorise 的岗位从“普通员工”变成“无”，你只能把他从“普通员工”替换 为“项目经理”。

11.4. [重点] 岗位的二次开发应用：从“职责划分”到“工作流”

理解了新版岗位的“强绑定”特性，我们终于可以回答那个终极问题：它在二次开发中到底有什么用？

11.4.1. 应用场景（一）：更精细的职责划分

这是最基础的应用。

• 场景：研发部门 下有 50 人。
• 老办法：我们只能用“角色”来区分，比如“前端角色”、“后端角色”。
• 新办法（更优）：现在我们可以用“岗位”。在 研发部门 下创建 后端工程师、前端工程师、UI 设计师、测试工程师 四个岗位。
  • “角色”（如 研发角色）统一负责 权限（能看哪些菜单、哪些数据）。
  • “岗位”（如 后端工程师）负责 职责（在业务逻辑中，你是谁）。

这种 “角色管权限，岗位管职责” 的分离设计，使得系统扩展性大大增强。

11.4.2. 应用场景（二）：[核心] 作为工作流的审批节点

这是 5.x 新版岗位设计 最有价值 的应用场景，也是它与“工作流”模块的完美结合点。

• 场景：Prorise（研发部 - 后端工程师）提交了一个“请假申请”。

• 审批流：流程规定，申请需要“所属部门的项目经理”审批。

• RVP 4.x (老版) 怎么做？

  • 无法实现。系统不知道谁是 Prorise 的“项目经理”。

• RVP 5.x (新版) 怎么做？

  • 工作流引擎 会自动执行以下逻辑：
  1. 获取 Prorise 的 dept_id（研发部）。
  2. 在“岗位表”中，查找 dept_id 为“研发部”且 post_code 为“manager”的岗位 ID。
  3. 在“用户表”中，查找所有拥有该“岗位 ID”的用户。
  4. 将审批任务推送给这个（或这些）用户。

看到了吗？正是因为 5.x 实现了岗位与部门的“强绑定”，才使得这种动态的、按组织架构查找审批人的“工作流”应用得以实现。

11.5 十一章总结

本章我们深入剖析了 RVP 5.x “脱胎换骨”的岗位管理。

• 核心变化：从 4.x 的“全局标签”，进化为 5.x “强绑定部门”的精细化职责。这个变化是实现复杂业务（如工作流）的基础。
• 强绑定实操：我们必须遵循“先选部门，再选岗位”的核心联动逻辑，这保证了数据的一致性。
• 开发抓手：在二次开发中，我们必须 永远依赖“岗位编码”（Post Code） 而 非“岗位名称”来编写业务逻辑。
• 核心价值：“角色管权限，岗位管职责”。岗位的终极价值在于配合工作流，实现“按组织架构（部门）和职责（岗位）查找审批人”的动态流程。

知识盲点自查表

不看笔记，尝试回答以下问题，检验你是否真正掌握了新版岗位管理：

1. （简答）RVP 5.x 的岗位管理相对 4.x 最大的区别是什么？这个区别解决了什么核心问题？
2. （场景）我在“用户管理”中，为 Prorise（归属 研发部）分配岗位，但在“岗位”下拉框里找不到 市场经理（归属 市场部）这个岗位。这是 Bug 吗？为什么？
3. （判断）我的代码里，可以用 if (postName == "CEO") 来判断用户职责。（对/错？为什么？）
4. （核心）请简述“岗位管理”是如何支持“工作流”实现动态审批的。