临抢修
blame | 历史 | 补丁 | 提交 | 提交对比 | ignore whitespace
zzw
昨天 943b68c17b27f3b0f9973533f832c48dd6afbb6f 
 HANDOFF.md


@@ -289,14 +289,14 @@




### 0.10 2026-09-28 专业配置与故障编号自动生成（本次会话，已实现并验证）




用户本次给出的 4 条新需求：① 系统管理增加“工程专业配置”（字段仅名称）；② 系统管理增加“T队专业配置”（字段名称、分类 A/B）；③ 故障编号不再手工输入，改为按 `潜1基-X号/A-YYMMDD-nnn` 自动生成；④ 派单号为 `故障编号/nn`，承修单位序号从 01 起。


用户本次给出的 4 条新需求：① 系统管理增加“工程专业配置”（字段仅名称）；② 系统管理增加“T队专业配置”（字段名称、分类 A/B）；③ 故障编号不再手工输入，改为按 `固定前缀-X号/A-YYMMDD-nnn` 自动生成；④ 派单号为 `故障编号/nn`，承修单位序号从 01 起。




已实现：


- “工程专业配置”：菜单 `/system/engineering-majors`，字段仅“名称”；表 `LX.T_ENGINEERING_MAJOR(ID, NAME, CREATE_TIME, UPDATE_TIME)`；接口 `/api/system/engineering-majors`（GET/POST/PUT/DELETE）。


- “T队专业配置”：菜单 `/system/team-majors`，字段“名称、分类（A/B）”；表 `LX.T_TEAM_MAJOR(ID, NAME, CATEGORY, CREATE_TIME, UPDATE_TIME)`；接口 `/api/system/team-majors`（GET/POST/PUT/DELETE）。


- 两处配置均校验名称非空与重名；T队专业分类只允许 A/B。启动时 `DataInitializer.ensureMajorConfigMenus` 幂等补菜单，`seedMajors` 预置演示数据：工程专业 动力/电气/液压/辅机；T队专业 动力=A、液压=A、电气=B、辅机=B（默认拆分，可在页面修改）。


- 故障编号自动生成：`BusinessService.generateFaultCode`，格式 `潜1基-X号/分类-YYMMDD-nnn`。


  - 前缀固定 `潜1基-`；X号取 3 位数字（`X01` → `001`）。


- 故障编号自动生成：`BusinessService.generateFaultCode`，格式 `固定前缀-X号/分类-YYMMDD-nnn`。


  - 前缀固定 `固定前缀-`；X号取 3 位数字（`X01` → `001`）。


  - 分类取“T队专业配置”的 A/B；未配置或分类非法时保存报错并提示先行维护。


  - YYMMDD 取上报日期；nnn 为“同一 X号 + 同一 T队专业 + 同一上报日期”的序号，从 001 起。


  - 新建自动生成；修改时强制沿用原编号（改 T队专业/日期也不重新生成）。


@@ -309,8 +309,8 @@


验证（2026-09-28）：


- 后端 `mvn -q -DskipTests package` 通过；前端 `vue-cli-service build` 通过（仅既有包体积提示）。


- 接口：工程专业、T队专业各返回 4 条；`/api/system/menu/nav` 系统管理下新增两项（排序 35/36）。


- 自动编号：`X02 + 动力专业(A) + 2026-09-28` → `潜1基-002/A-260928-001`、`潜1基-002/A-260928-002`；换 T队专业（电气 B）→ `潜1基-002/B-260928-001`；换上报日期 → `潜1基-001/A-260929-001`；修改故障改 T队专业后编号保持不变。


- 派单端到端：一条故障分配两个承修单位，生成 `潜1基-002/B-260928-001/01`、`.../02`。测试数据已从 `LX.T_FAULT`、`LX.T_WORK_ORDER` 清理。


- 自动编号：`X02 + 动力专业(A) + 2026-09-28` → `固定前缀-002/A-260928-001`、`固定前缀-002/A-260928-002`；换 T队专业（电气 B）→ `固定前缀-002/B-260928-001`；换上报日期 → `固定前缀-001/A-260929-001`；修改故障改 T队专业后编号保持不变。


- 派单端到端：一条故障分配两个承修单位，生成 `固定前缀-002/B-260928-001/01`、`.../02`。测试数据已从 `LX.T_FAULT`、`LX.T_WORK_ORDER` 清理。


- 浏览器：两个新配置页正常渲染；故障上报新增表单“故障编号”只读且占位“保存后自动生成”，T队专业/工程专业下拉为配置项；修复后控制台无新增报错。


- 历史演示故障仍使用 `GZ-2026-0xx` 旧编号（未迁移，避免影响已派工单引用）；新建故障一律使用新规则。


- 文档已同步：`requirement\决策表_待确认项.md`、`前44页需求梳理.md`、`工程状态机设计.md`、`界面还原.html`，以及首页公告“派单规则”文案。


@@ -646,7 +646,7 @@




**本次会话完成（细节见 0.10 / 0.11）**


- 决策表 B1–B4 按建议关闭并落地：系统管理新增“工程专业配置”（字段：名称）、“T队专业配置”（字段：名称、分类 A/B）。


- 故障编号改为自动生成：`潜1基-X号/A-YYMMDD-nnn`（X号 3 位数字，A＝T队专业 A/B，nnn 为同一 X号＋同一专业＋同一上报日期内从 001 递增）；派单号＝`故障编号/nn`（承修单位序号，从 01 起）。


- 故障编号改为自动生成：`固定前缀-X号/A-YYMMDD-nnn`（X号 3 位数字，A＝T队专业 A/B，nnn 为同一 X号＋同一专业＋同一上报日期内从 001 递增）；派单号＝`故障编号/nn`（承修单位序号，从 01 起）。


- 故障上报页：任务状态标签与任务状态下拉框拆成两行（标签换到下一行）。


- 完工信息上报页（AXU15）：修后质量情况独占整行；项目名称与验收方式同一行；故障说明、原因分析各独占整行；“处理解决情况”改为可多行的表格（序号／处理解决情况）；维修器材表列改为序号、名称、规格型号、技术参数、数量、计量单位、合格证明、出库单号、来源、备注。后端新增 `LX.T_COMPLETION_INFO.SOLUTIONS_JSON` 与 `MaterialItem.certificate`，并继续兼容原 `SOLUTION` 字段。


- 项目纳入公司 Git 仓库：`http://admin@61.183.254.94:3000/r/EmergencyRepair.git`，分支 `main`，首提交 `5305262`（103 个文件），随后 `0bacdcf` 补记远端信息。


@@ -697,3 +697,87 @@


2. `sensitive.js` 改动已获确认并随本次提交推送；`requirement\~$原始需求.docx` 是 Word 锁文件，不要提交。


3. 需求侧待确认项不变：决策表 B6–B10、AXU15 字段来源与可改性、完工验收各环节角色与打印输出、修后质量评级与 AXU14 T员评分字段的关系。


4. 后续改动完成后推送到公司 Git 仓库 `main` 分支。




## 17. 收尾快照（2026-10-04 周六，需求 11 / 12 / 17-19 联调收尾）




**本轮完成内容**


- 需求 11：完工情况处理将状态改为“完工”时，只更新派工单状态，不再跳转“完工信息填报”。完工处理与完工填报由不同用户分别操作。


- 需求 12：完工信息填报的派工单选择列表只展示“已在完工情况处理中确认完工、属于当前登录用户所属单位、且尚未填报”的派工单，并增加工程名称（项目名称）显示。


- 需求 17：角色管理的“用户设置”增加“全部 / 已设置”过滤切换。


- 需求 18：新增“组织机构”部门树表页面，菜单 `/system/organization`，页面 `OrganizationManage.vue`，数据来自 `CSICZB_ZB.SYS_DEPT`，后端接口 `/api/system/depts`。当前环境返回 34 个部门，支持名称、编码、负责人、部门类型筛选。


- 需求 19：承修单位改为读取 `SYS_DEPT.DEPT_TYPE='cj'` 的部门记录，部门 ID 作为承修单位 ID；承修单位接口保留 GET，页面改为只读。当前环境返回 7 个 cj 部门，XCB审核、派单均使用 cj 部门 ID/名称。




**主要文件**


- 后端：`emergency-repair-server/src/main/java/com/emergencyrepair/system/service/SystemService.java`、`emergency-repair-server/src/main/java/com/emergencyrepair/business/service/BusinessService.java`、`emergency-repair-server/src/main/java/com/emergencyrepair/bootstrap/DataInitializer.java`。


- 前端：`emergency-repair-web/src/views/system/OrganizationManage.vue`、`emergency-repair-web/src/views/system/ContractorManage.vue`、`emergency-repair-web/src/views/completion/CompletionReport.vue`、`emergency-repair-web/src/views/system/RoleManage.vue`、`emergency-repair-web/src/router/index.js`。




**验证结果**


- 后端 `mvn -B -DskipTests clean package` 通过；前端 `npm run build` 通过。


- 页面验证脚本完整通过：`node .codex-run/verify-items-11-12-17.js`、`node .codex-run/verify-items-18-19.js`；截图见 `.codex-run/organization-verified.png`、`.codex-run/contractor-readonly-verified.png`、`.codex-run/completion-report-verified.png`、`.codex-run/role-scope-verified.png`。


- 端到端联调使用临时故障 `固定前缀-088/A-261004-001`，跑通上报、XCB审核分配“厂家1/厂家2”、CMB/JCC三级审批、派单。最终故障保存 `contractorIds = 1303144990487465986,1303145150793764866`、`contractorNames = 厂家1、厂家2`，生成两张派工单，均保存 cj 部门 ID/名称。


- 完工填报可见性验证：`cjyh1-1` 仅看到厂家1派工单，`cjyh2-1` 仅看到厂家2派工单，`admin` 可看到两张。临时 `T_FAULT` / `T_WORK_ORDER` 测试数据已清理。




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


- 前端：`http://localhost:8082`；后端：`http://127.0.0.1:8091`；DM8：`127.0.0.1:5236`；headless Edge 调试实例端口 `9222`。


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




**接手注意事项**


- 非管理员用户的完工填报派工单单位匹配当前按 `DEPT_NAME`，不是按 `DEPT_ID`。本次验证通过；如存在同名部门，应改为按部门 ID 精确匹配。


- 历史演示派工单可能保留旧 `T_CONTRACTOR` 名称，非管理员 cj 用户可能看不到这些历史单；`admin` 不受单位过滤影响。


- `.codex-run`、Office 锁文件 `requirement\~$原始需求.docx` 和 `emergency-repair-web/public/新建 文本文档.txt` 属本地联调或临时文件，不应提交。


- 本轮代码已提交并推送公司 Git 仓库 `main` 分支，提交 `757dcb3`；交接文件回填提交记录。后续启动、构建和排错命令沿用第 16 节。




## 18. 收尾快照（2026-10-06 周一，需求 20 菜单权限管理收尾）




**本轮完成内容**


- 需求 20：菜单权限管理取消租户权限和角色权限的双重授权，改为单步设置角色权限。当前用户本身没有租户归属，因此不再设置租户权限。


- 权限树继续展示菜单节点和按钮节点，不按 `menuType` 过滤；切换角色后，已保存权限复选框正常反显。


- 菜单权限接口只保留 `roleId` / `roleMenuIds`，删除租户菜单授权及 `/api/system/tenants`。


- 修复雪花 ID 经浏览器 JSON 解析后精度丢失的问题：后端返回字符串 ID，前端选中态按字符串处理。




**主要文件**


- 后端：`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/SystemService.java`。


- 前端：`emergency-repair-web/src/views/system/MenuPermission.vue`。




**验证结果**


- 后端 `mvn -B -DskipTests compile` 通过；前端 `npm run build` 通过。


- 接口：`GET /api/system/menu-permissions?roleId=2106221661022490625` 返回字符串型 `roleMenuIds` 共 14 条。


- 浏览器：`node .codex-run/verify-menu-permission.js` 输出 `hasTenantPanel: false`、`buttonNodeCount: 76`、`checkedMatchesSaved: true`、`hasError: false`；截图 `.codex-run/menu-permission-verified.png`。


- 页面确认按钮节点保留，切换角色后权限勾选可正常反显。




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


- 前端 `http://localhost:8082`，后端 `http://127.0.0.1:8091`，DM8 `127.0.0.1:5236`，Edge CDP `9222`。


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


- 后端日志：`.codex-run/backend-20261006-menu-permission-fixed.out.log`、`.codex-run/backend-20261006-menu-permission-fixed.err.log`。




**接手注意**


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


- 本轮代码与交接记录一并提交并推送公司 Git 仓库 `main` 分支。




## 19. 收尾快照（2026-10-06 周一，需求 21-22 菜单权限入口与错误日志）




**本轮完成内容**


- 需求 21：移除独立“菜单权限管理”菜单，在角色管理操作列新增“权限设置”按钮，并复用菜单/按钮权限树弹窗；旧 `/system/menu-permissions` 路由和页面已删除。


- 需求 22：系统管理新增“系统配置 / 权限配置 / 日志管理”三个二级目录；组织机构、承修单位、产品结构树、设备基础库、工程专业、T队专业、三员控制归入系统配置，用户管理、角色管理、菜单管理归入权限配置，登录日志、操作日志、错误日志归入日志管理。


- 错误日志为新增功能：`GlobalExceptionHandler` 捕获未处理的非业务异常并异步写入 `LX.T_SYS_ERROR_LOG`；业务校验异常不记录。列表支持模块、异常类型、时间筛选，详情展示完整堆栈。


- 新库初始化和旧库迁移均会删除旧菜单并补齐二级目录的父子菜单关系；权限树继续保留菜单节点和按钮节点，角色切换后复选框可反显。




**主要文件**


- 后端：`emergency-repair-server/src/main/java/com/emergencyrepair/system/entity/SysErrorLog.java`、`.../mapper/SysErrorLogMapper.java`、`.../log/ErrorLogRecorder.java`、`.../common/GlobalExceptionHandler.java`、`.../bootstrap/DataInitializer.java`、`.../bootstrap/DatabaseBootstrap.java`、`.../system/controller/SystemController.java`、`.../system/service/SystemService.java`、`.../system/service/ButtonPermissionCatalog.java`。


- 前端：`emergency-repair-web/src/views/system/RoleManage.vue`、`RolePermissionDialog.vue`、`ErrorLogManage.vue`、`emergency-repair-web/src/router/index.js`、`MenuManage.vue`；`MenuPermission.vue` 已删除。




**验证结果**


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


- `node .codex-run/verify-req21-22.js` 通过：三个二级目录和错误日志菜单正常显示，旧菜单不存在，角色管理“权限设置”弹窗按钮节点数为 78 且反显正常。


- 人为访问非法错误日志详情 ID 后，记录自动落库并可在错误日志页面查看；验证用临时记录已从数据库清理。


- 截图：`.codex-run/role-permission-dialog-verified.png`、`.codex-run/error-log-verified.png`。




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


- 前端 `http://localhost:8082`；后端 `http://127.0.0.1:8091`；DM8 `127.0.0.1:5236`；Edge CDP `9222`。


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


- 后端日志：`.codex-run/backend-20261006-req21-22.out.log`、`.codex-run/backend-20261006-req21-22.err.log`。




**接手注意**


- 错误日志当前覆盖进入 Spring MVC 全局异常处理的异常；启动阶段异常、异步线程中未进入该处理器的异常暂不会自动落库。


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


- 本轮代码与交接记录一并提交并推送公司 Git 仓库 `main` 分支。