# TODO: 成果归属部门设计评审 ## 1. 文档目的 本文件用于说明当前系统“成果归属部门（`assigned_departments`）”的实现现状、已暴露的业务问题，以及推荐的改造方向，供管理层评审后再确定最终实施方案。 当前阶段仅做方案评审，不进行数据库结构变更。 --- ## 2. 现有设计（当前线上逻辑） ### 2.1 数据结构 - `achievements.assigned_departments`：`TEXT[]`，用于记录成果归属部门数组。 - `achievements.contributors`：`JSONB`，记录完成人列表（含 `name/phone/isMain/ranking/...`）。 - 统计与权限大量依赖 `assigned_departments`。 ### 2.2 归属部门计算方式（新增/修改） 当前归属部门是这样算的： 1. 先确定主要完成人（`isMain=true`）。 2. 用主要完成人手机号去 `users` 反查其部门。 3. 将查到的部门去重后写入 `assigned_departments`。 这意味着：**成果归属只看“主要完成人”，不看其他参与完成人**。 ### 2.3 “主要完成人”来源规则 - 论文：按角色自动推导（第一作者/通讯作者等）。 - 项目/成果转化：由前端勾选 `isMain`。 - 其他类型：按最小排名推导主要完成人。 ### 2.4 领导部门字典的当前用途 - `dict_leader_departments` 当前主要用于“签批院领导”用户搜索过滤（如技术报告签批）。 - 它不直接参与 `assigned_departments` 的计算。 ### 2.5 依赖场景 - 列表与可见范围过滤（如按部门可见）。 - 统计分析（按部门产出、趋势等）。 - 字典删除联动（部门删除时，成果归属中的对应部门会被替换为“待定”）。 --- ## 3. 已出现的业务问题 ### 问题 A：院领导主完成人导致归属失真 当业务上院领导必须/经常被标记为主要完成人时，归属部门会集中到“院领导部门”，导致： - 业务承接部门贡献被淹没； - 统计图偏向领导部门，失去决策价值； - 跨部门协同成果无法准确反映。 ### 问题 B：多部门参与信息丢失 一个成果可能有 3-4 个部门参与，但当前仅按主完成人计算，导致： - `assigned_departments` 不完整； - 基于部门的权限与统计存在系统性偏差。 ### 问题 C：语义混杂 当前“归属部门”既被当作统计口径，也隐含承载了“牵头责任”含义，但这两个概念在业务上并不等价。 --- ## 4. 推荐改造方案（不改库结构，优先） ## 4.1 目标 - 归属部门改为“参与部门口径”，提高统计与查询真实性。 - 保持当前表结构和现有 API 兼容，降低上线风险。 ## 4.2 核心规则（推荐） `assigned_departments` 改为按以下顺序计算： 1. 从 `contributors` 中取所有完成人手机号； 2. 反查这些用户所属部门并去重； 3. 排除无效值（空、null 等）； 4. 读取 `dict_leader_departments`： - 默认将领导部门从归属集合剔除（防止“院领导部门吞噬”）； 5. 如果剔除后为空： - 回退到提交人部门； 6. 若提交人部门也不可用： - 回退为 `['待定']`。 > 说明：该方案不需要新增字段，直接替换归属计算逻辑即可。 ## 4.3 同步改造点 - 新增成果时：使用新规则计算。 - 编辑成果时：使用同一套新规则重算。 - 封装公共函数 `computeAssignedDepartments(...)`，避免两处逻辑分叉。 ## 4.4 历史数据处理（建议） 提供一次性回填脚本，重算历史成果 `assigned_departments`，否则新老口径并存会导致统计长期不一致。 建议执行流程： 1. 开发机全量跑脚本； 2. 抽样对比典型成果（院领导参与、多部门参与、单部门项目）； 3. 生产低峰执行； 4. 保留执行前快照，支持快速回滚。 --- ## 5. 备选方案（供比较） ### 方案 B：保留“主完成人口径”，仅加领导部门排除 - 优点：改动最小。 - 缺点：多部门参与问题仍未解决，仍会有归属缺失。 - 结论：不推荐作为长期方案。 ### 方案 C：双口径（归属部门 + 牵头部门） - 优点：业务语义最清晰。 - 缺点：通常需要新增字段与更多改造（前后端、统计、权限口径梳理）。 - 结论：作为二期优化可评估；本期若要求“尽量不动数据库”，不优先。 --- ## 6. 待管理决策项（请示时建议重点确认） - 是否同意“归属部门 = 参与部门口径”？ - 是否同意默认剔除领导部门字典中的部门？ - 剔除后为空时，是否同意“提交人部门优先，最后回退待定”？ - 是否同意执行历史数据回填（推荐执行）？ - 统计报表是否继续沿用 `assigned_departments`（本期建议继续沿用）？ --- ## 7. TODO 清单（待批准后执行） - [ ] 确认最终业务口径（本文件第 6 节） - [ ] 设计并评审 `computeAssignedDepartments` 规则细节 - [ ] 修改新增成果归属计算逻辑 - [ ] 修改编辑成果归属重算逻辑 - [ ] 增加回填脚本（仅更新 `assigned_departments`） - [ ] 生成回填前后抽样对比报告 - [ ] 验证权限与统计页面关键场景 - [ ] 安排生产执行窗口与回滚预案 --- ## 8. 风险与控制 - 风险：归属口径改变后，统计口径会发生可见变化。 - 控制：上线公告中明确“统计口径优化”；保留回填前快照用于追溯。 - 风险：部分历史成果完成人手机号与用户表不一致，可能回退到“待定”。 - 控制：先跑演练报告，输出异常清单再决定是否人工修正。