5.5 KiB
5.5 KiB
TODO: 成果归属部门设计评审
1. 文档目的
本文件用于说明当前系统“成果归属部门（assigned_departments）”的实现现状、已暴露的业务问题，以及推荐的改造方向，供管理层评审后再确定最终实施方案。
当前阶段仅做方案评审，不进行数据库结构变更。
2. 现有设计（当前线上逻辑）
2.1 数据结构
achievements.assigned_departments：TEXT[]，用于记录成果归属部门数组。achievements.contributors：JSONB，记录完成人列表（含name/phone/isMain/ranking/...）。- 统计与权限大量依赖
assigned_departments。
2.2 归属部门计算方式（新增/修改）
当前归属部门是这样算的：
- 先确定主要完成人（
isMain=true）。 - 用主要完成人手机号去
users反查其部门。 - 将查到的部门去重后写入
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 改为按以下顺序计算：
- 从
contributors中取所有完成人手机号； - 反查这些用户所属部门并去重；
- 排除无效值（空、null 等）；
- 读取
dict_leader_departments：- 默认将领导部门从归属集合剔除（防止“院领导部门吞噬”）；
- 如果剔除后为空：
- 回退到提交人部门；
- 若提交人部门也不可用：
- 回退为
['待定']。
- 回退为
说明：该方案不需要新增字段，直接替换归属计算逻辑即可。
4.3 同步改造点
- 新增成果时：使用新规则计算。
- 编辑成果时：使用同一套新规则重算。
- 封装公共函数
computeAssignedDepartments(...)，避免两处逻辑分叉。
4.4 历史数据处理（建议）
提供一次性回填脚本，重算历史成果 assigned_departments，否则新老口径并存会导致统计长期不一致。
建议执行流程：
- 开发机全量跑脚本；
- 抽样对比典型成果（院领导参与、多部门参与、单部门项目）；
- 生产低峰执行；
- 保留执行前快照，支持快速回滚。
5. 备选方案（供比较）
方案 B：保留“主完成人口径”，仅加领导部门排除
- 优点：改动最小。
- 缺点：多部门参与问题仍未解决，仍会有归属缺失。
- 结论：不推荐作为长期方案。
方案 C：双口径（归属部门 + 牵头部门）
- 优点：业务语义最清晰。
- 缺点：通常需要新增字段与更多改造（前后端、统计、权限口径梳理）。
- 结论：作为二期优化可评估；本期若要求“尽量不动数据库”，不优先。
6. 待管理决策项（请示时建议重点确认）
- 是否同意“归属部门 = 参与部门口径”？
- 是否同意默认剔除领导部门字典中的部门？
- 剔除后为空时，是否同意“提交人部门优先，最后回退待定”？
- 是否同意执行历史数据回填（推荐执行）？
- 统计报表是否继续沿用
assigned_departments（本期建议继续沿用）？
7. TODO 清单（待批准后执行）
- 确认最终业务口径（本文件第 6 节）
- 设计并评审
computeAssignedDepartments规则细节 - 修改新增成果归属计算逻辑
- 修改编辑成果归属重算逻辑
- 增加回填脚本（仅更新
assigned_departments） - 生成回填前后抽样对比报告
- 验证权限与统计页面关键场景
- 安排生产执行窗口与回滚预案
8. 风险与控制
-
风险：归属口径改变后，统计口径会发生可见变化。
-
控制：上线公告中明确“统计口径优化”；保留回填前快照用于追溯。
-
风险：部分历史成果完成人手机号与用户表不一致，可能回退到“待定”。
-
控制：先跑演练报告，输出异常清单再决定是否人工修正。