# 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. 风险与控制

- 风险：归属口径改变后，统计口径会发生可见变化。
- 控制：上线公告中明确“统计口径优化”；保留回填前快照用于追溯。

- 风险：部分历史成果完成人手机号与用户表不一致，可能回退到“待定”。
- 控制：先跑演练报告，输出异常清单再决定是否人工修正。

