临抢修
blame | 历史 | 补丁 | 提交 | 提交对比 | ignore whitespace
zzw
13 小时以前 c12046de999994bbb4a2be2986e8c3a9555c240c 
 HANDOFF.md


@@ -827,6 +827,33 @@


- 不要提交 `.codex-run`、Office 锁文件或 `emergency-repair-web/public/新建 文本文档.txt`。


- 本轮代码、需求文件和交接记录一并提交并推送公司 Git 仓库 `main` 分支。




## 27. 收尾快照（2026-10-07 周三，CMB 审批后 JCC 助理列表未刷新）




**问题与根因**


- `rk_CMB领导审批` 通过后进入 `rk_JCC助理审批`，页面可能不显示已进入 `CMB_APPROVED` 状态的数据。


- CMB、JCC 助理、JCC 处长三个审批路由共用 `SimpleApproval.vue`，并共用同一个 keep-alive 缓存名 `SimpleApproval`。路由切换时组件实例被复用，但原代码只在 `created()` 查询一次，未在 `stage` 变化时重新加载。




**修复内容**


- 监听 `stage`，审批环节切换时清空旧关键词、选中项和列表，并按新状态立即查询。


- 增加 `activated()` 刷新逻辑：缓存页签再次激活时重新加载当前审批环节数据。




**主要文件**


- `emergency-repair-web/src/views/fault/SimpleApproval.vue`




**验证结果**


- 前端 `npm run build` 通过，仅有既有包体积告警。


- 真实接口数据验证：`XCB_REVIEWED` 为 `0` 条，`CMB_APPROVED` 为 `3` 条。


- 浏览器联调 `node .codex-run/verify-cmb-jcc-refresh.js` 返回 `pass: true`：直接进入 CMB 显示 `0` 条；切到 JCC 助理后重新查询并显示 `3` 条；从其他页签返回 JCC 助理后仍重新查询并显示 `3` 条。


- 截图：`.codex-run/cmb-jcc-refresh-verified.png`。




**当前运行状态（2026-10-07）**


- 前端 PID `57312`，监听 `http://localhost:8082`；后端 PID `56124`，监听 `http://127.0.0.1:8091`；DM8 `127.0.0.1:5236`；Edge CDP `9222`。


- 登录 `admin / admin123`；后端日志：`.codex-run/backend-20261007-req28-30-final.out.log`、`.codex-run/backend-20261007-req28-30-final.err.log`。




**接手注意**


- `.codex-run`、Office 锁文件及 `emergency-repair-web/public/新建 文本文档.txt` 仍为本地临时文件，不应提交。


- `emergency-repair-web/public/sensitive-words.json` 是用户既有未提交修改，本轮不纳入提交。




## 21. 收尾快照（2026-10-06 周一，需求 21 权限设置范围切换）




**本轮完成内容**


@@ -921,3 +948,75 @@


- 后端 `mvn -B -DskipTests compile`、`mvn -B -DskipTests package` 通过。


- 将数据库菜单 `id=2101493905517301763`、`url=/system/product-tree` 的名称改为“产品结构树”后，使用新 jar 重启后端，接口再次查询仍为“产品结构树”。


- 新后端 PID `151580`，监听 `8091`；日志：`.codex-run/backend-20261006-menu-name.out.log`、`.codex-run/backend-20261006-menu-name.err.log`。




## 25. 收尾快照（2026-10-07 周三，清空故障及完工业务数据）




**本次操作**


- 清空 `LX.T_FAULT`、`LX.T_WORK_ORDER`、`LX.T_COMPLETION_INFO`、`LX.T_ACCEPTANCE` 四张业务表。


- 清空前数量：故障 `23`、派工单 `8`、完工信息 `6`、验收 `6`；清空后均为 `0`。


- 同步关闭启动演示业务数据回填：新增配置 `app.seed-demo-data=false`，避免 `T_FAULT` 为空时后端重启又自动生成 16 条演示故障及完工数据。




**主要文件**


- `emergency-repair-server/src/main/java/com/emergencyrepair/bootstrap/DataInitializer.java`


- `emergency-repair-server/src/main/resources/application.yml`




**验证结果**


- 后端 `mvn -B -DskipTests clean package` 通过。


- 使用新 jar 重启后再次查询，四张业务表仍均为 `0` 行；登录接口 `200`，前端首页 `200`。


- 当前后端 PID `21528`，监听 `8091`；日志：`.codex-run/backend-20261007-cleared.out.log`、`.codex-run/backend-20261007-cleared.err.log`。


- 如需重新灌入演示业务数据，将 `app.seed-demo-data` 临时设为 `true` 后重启。




## 26. 收尾快照（2026-10-07 周三，需求 28-30 扩展属性与新增故障默认值）




**需求口径**


- 需求 30 编号已确认；新增故障里的“责任”就是“负责人”。


- 部门扩展属性“负责rk_T”的值就是 `rk_X号`，值必须是产品结构树 `side` 类型节点，单选。


- 新增故障的 `rk_X号` 默认值只取登录用户所属部门的扩展属性；即使用户扩展属性也设置了“负责rk_T”，仍以部门设置为准。


- “rk_TD专业”与现有“rk_T队专业”是同一字段，代码字段为 `teamMajor`，当前界面暂时沿用“rk_T队专业”。


- 外部 `CSICZB_ZB.SYS_DEPT`、`CSICZB_ZB.SYS_USER` 由其他系统维护，本项目只读；扩展属性保存到本地新表。




**本轮完成内容**


- `DatabaseBootstrap` 自动创建 `LX.T_SYS_DEPT_EXT`（`DEPT_ID`、`RESPONSIBLE_X_NO` 及审计字段）和 `LX.T_SYS_USER_EXT`（`USER_ID`、`ENGINEERING_MAJOR`、`TEAM_MAJOR`、`RESPONSIBLE_X_NO` 及审计字段）。


- 组织机构页面增加“扩展属性”按钮和弹窗，可设置部门“负责rk_T”；列表显示已设置值。


- 用户管理列表展开显示工程专业、rk_T队专业、负责rk_T三列，未设置时显示“未设置”；表格最后增加固定“操作”列，提供“编辑属性”按钮打开设置弹窗。


- 新增故障弹窗默认带出：上报单位为当前登录人的单位、负责人为当前登录人、`rk_X号`为当前部门扩展属性、工程专业和 rk_T队专业为当前用户扩展属性。


- 用户扩展属性为空时，工程专业和 rk_T队专业不再默认选择配置列表第一项。




**接口与权限**


- `GET/PUT /api/system/depts/{deptId}/ext`：查询和保存部门扩展属性。


- `GET/PUT /api/system/users/{userId}/ext`：查询和保存用户扩展属性。


- `/api/auth/login`、`/api/auth/me` 返回 `userId`、`deptId`、`engineeringMajor`、`teamMajor`、`deptResponsibleXNo`、`responsibleXNo`。


- 按钮权限新增 `system:organization:ext`（扩展属性设置）、`system:users:ext`（扩展属性设置）。




**主要变更文件**


- `emergency-repair-server/src/main/java/com/emergencyrepair/auth/AuthController.java`


- `emergency-repair-server/src/main/java/com/emergencyrepair/bootstrap/DatabaseBootstrap.java`


- `emergency-repair-server/src/main/java/com/emergencyrepair/business/dto/Requests.java`


- `emergency-repair-server/src/main/java/com/emergencyrepair/system/controller/SystemController.java`


- `emergency-repair-server/src/main/java/com/emergencyrepair/system/service/ButtonPermissionCatalog.java`


- `emergency-repair-server/src/main/java/com/emergencyrepair/system/service/SystemService.java`


- `emergency-repair-web/src/views/Login.vue`


- `emergency-repair-web/src/views/fault/FaultReport.vue`


- `emergency-repair-web/src/views/system/OrganizationManage.vue`


- `emergency-repair-web/src/views/system/UserManage.vue`


- `requirement/改进20261003.txt`（补充需求 28-30）




**验证结果**


- 后端 `mvn -B -DskipTests clean package` 通过；前端 `npm run build` 通过，仅有既有包体积告警。


- `node .codex-run/verify-req28-30.js` 返回 `pass: true`。


- 部门 `1390477009348739073 / sy区域` 设置 `rk_X号=201`，用户 `123 / yszl` 设置工程专业 `动力专业`、rk_T队专业 `液压专业`、负责 `202`。


- 新增故障实际默认值为：上报单位 `sy区域`、负责人 `助理用户（演示）`、`rk_X号=201`、rk_T队专业 `液压专业`、工程专业 `动力专业`。


- 用户管理页面实测表头顺序为工程专业、rk_T队专业、负责rk_T、状态、操作，行内扩展值正常，操作列每行显示“编辑属性”；截图：`.codex-run/req29-user-ext.png`。


- 截图：`.codex-run/req28-org-ext.png`、`.codex-run/req29-user-ext.png`、`.codex-run/req30-fault-defaults.png`。


- 验证后已清除临时部门、用户扩展属性，查询确认 `configured=false` 且字段为空。




**当前运行状态（2026-10-07）**


- 后端 PID `56124`，监听 `http://127.0.0.1:8091`；前端 PID `57312`，监听 `http://localhost:8082`。


- 为 UI 验证启动的 headless Edge PID `95756`，CDP 端口 `9222`；配置目录 `.codex-run/edge-profile-req28-30`。


- 后端日志：`.codex-run/backend-20261007-req28-30-final.out.log`、`.codex-run/backend-20261007-req28-30-final.err.log`。


- 登录 `admin / admin123`；数据库 `SYSDBA/SYSDBA`，业务 schema `LX`。




**接手注意**


- 开发环境敏感词配置会把 `rk_T` 显示为“梯”，因此页面截图中可能显示“负责梯”；代码和后端字段仍是 `rk_T`。


- 不要提交 `.codex-run`、Office 锁文件或 `emergency-repair-web/public/新建 文本文档.txt`。


- 本轮代码、需求文件和交接记录一并提交并推送公司 Git 仓库 `main` 分支。