city-life-line/memory/sessions/2026-09-29.md

2026-09-29 预警流程联调

• 目标：在已登录的本地页面实际验证草稿、发布、接收、处置、核查、退回及解除流程。
• 实测两条 TEST- 预警：一条走发布到解除；另一条走核查退回、再次处置到解除。预警状态和处置轨迹均按预期显示。
• 首次发布因开发库缺少 early_warning.reviewer、warning_todo.action_type 失败；执行后端仓库的幂等迁移 migration_warning_workflow_fields_kingbase.sql 后成功。
• 修复待办查询：同一用户同一预警的多条已办任务只展示最新一条；修复详情对下划线字段的处置类型、说明、人员和时间展示。页面复测两条预警各显示一行，完整处置轨迹可见。
• 验证：npm run build:stage 成功；mvn -pl zksy-system -am '-Dtest=EarlyWarningWorkflowTest' '-Dsurefire.failIfNoSpecifiedTests=false' test 成功（3 项）；前后端 git diff --check 无错误。
• 两条测试预警及关联待办、处置、归档记录已从开发库精确清理，回查计数为 0；页面重载后我的已办为 0。未测试不同登录用户分别担任处置人和核查人的权限分支。

督办、批示、升级联调

• “预警处置”作为升级、督办、批示的统一入口；“待办预警”仅保留接收、开始处置、提交处置、核查解除/退回等个人工作流动作，避免重复入口。
• 调整 LwarningDisp.vue：使用 alert_type/alert_level 字典和统一状态文案；草稿、已解除不显示操作，一级预警不显示升级，核查解除/退回仅 HANDLED 且当前用户为核查人；日期和处置轨迹兼容下划线字段。
• 调整 LTobeHandled.vue：移除升级、督办、批示重复弹窗和按钮，保留个人工作流操作；状态、日期和详情轨迹统一显示。
• 使用测试预警 YJ20260929102646138AB5C16 实测：三级升级到二级成功；督办记录成功；领导批示记录成功；详情轨迹显示升级、督办、批示。一级预警和草稿按钮显隐符合规则。
• 督办通知、批示短信当前后端只保存记录，未接入真实外发渠道；页面已改为“通知方式（记录）/通知内容（记录）”，测试未填写真实号码。
• 测试预警及其 warning_todo、warning_disposal、warning_supervision、归档、附件、报警关联已从开发库精确清理，回查计数均为 0。
• npm run build:stage 成功；git diff --check 无错误。不同登录用户的权限分支和真实短信外发仍未验证。

督办通知方式与附件调整

• 督办弹框通知方式收敛为“短信”和“系统通知”，移除通知字段中的“（记录）”文案；附件地址改为单文件上传控件，限制 20 MB，并随 multipart 请求提交。
• 短信复用现有 SmsTemplate.sendBatchSms，系统通知复用 warning_todo 的 NOTICE 类型；短信在事务提交后发送，失败写入 warning_supervision.notification_status/notification_error，前端提示“已保存但短信发送失败”，避免用户重复提交。
• 前端增加通知内容 180 字提交前校验，上传按钮改用 Element Plus Upload 图标。
• 新增 WarningSupervisionNotifierTest，并扩展 EarlyWarningWorkflowTest 覆盖非法通知方式、指定用户系统通知和短信失败；mvn -pl zksy-system -am '-Dtest=EarlyWarningWorkflowTest,WarningSupervisionNotifierTest' '-Dsurefire.failIfNoSpecifiedTests=false' test 通过（6 项）。
• npm run build:stage 通过，前后端 git diff --check 通过；未在本轮真实页面提交短信督办，需先部署 migration_warning_supervision_notification_kingbase.sql 并在 Nacos 配置已审核的 aliyun.sms.supervision-template-code（模板变量 warningName、content）。

督办人员选择与行业处置分析修复

• 督办人员继续使用全部启用用户下拉，显示姓名、账号及部门，支持按三者搜索；弹框明确说明所选人员即短信/系统通知接收人，当前仍无默认接收人。补齐 SysUserMapper.selectAllEnabledUser 的部门关联；接口路径和权限机制不变。部门展示需运行后端加载本次 Mapper 改动。
• 原行业处置分析菜单已有正确的组件路径，但对应 Vue 页面缺失。本次新增 lstatistics/industryAnalysis/index.vue，复用现有四个 /warning/industryAnalysis/* 接口，提供行业/日期汇总、状态及时效图、明细状态筛选和分页；API 封装位于 src/api/warning/statistics.js，旧组件名兼容位于 src/router/alarmMenuView.js。
• 统一已发布/已处置的阶段说明，合并历史“已解除”状态选项，格式化日期；平均时长只统计有效处置时间样本，补齐分页错误和空结果展示，修复处置页空字符串标签类型造成的 Vue 警告。
• Kingbase 只读核对：行业分析菜单 2233 的父菜单、path、component、route_name、perms、visible/status 和角色关联均已存在，不需要写入菜单或修改表结构。
• 已在用户登录后的本地页面实测行业分析加载、排水筛选、已解除空结果、重置、人员账号搜索、两种通知选项及未填必填项校验；行业分析真实统计为两条已发布预警，其中一条已完成处置；刷新后未出现新增控制台警告。没有新增测试业务数据或发出实际通知。
• 验证：npm run build:stage 通过；mvn -o -pl zksy-admin -am -DskipTests compile 通过；前后端 git diff --check 通过。真实短信外发、部门展示在后端重启后的页面联调、不同角色权限分支未验证。可重复的统计测试数据沿用后端 sql/warning_statistics_test_data_kingbase.sql，本轮未执行写入。

处置记录展示附件

• 预警处置、待办、发布详情和预警查询详情/流程接入共享 components/WarningAttachments.vue。按 disposalId/disposal_id 精确匹配附件，显示文件名、大小和上传时间；无关联或关联记录已缺失的附件放入“其他预警附件”，不按时间猜测归属。
• 复用已有 /warning/attachments/{attachmentId}/preview 和 /download 鉴权接口，不直接拼接 MinIO 地址；图片可在弹框预览，PDF 提供浏览器预览及下载提示，其余文档下载。包含加载中、读取失败、JSON 错误响应校验和对象 URL 释放。
• 本轮仅修改前端，无后端业务接口、数据库结构或菜单变更。后端原有附件列表已含关联编号。
• tests/warningAttachments.test.mjs 提供内存 TEST 夹具，4 项通过：不同记录隔离、无编号及孤立附件、图片/PDF/文档分类、零字节大小。
• 浏览器实测：新增 TEST-ATTACH-20260929- 草稿并通过真实上传保存 PNG/PDF；对该测试草稿在开发库事务插入两条 TEST 处置记录并分别关联两份附件，仅用于读取展示测试，不推进流程、不发通知。处置页、发布详情和查询轨迹显示各自附件；未关联附件兜底展示也通过，PNG 预览解码为 240×120。
• 当前内置浏览器的 PDF 预览空白，下载点击未捕获下载事件；已保留提示及下载按钮，普通浏览器 PDF 显示与文件落盘仍待核验，不声明下载端到端通过。待办页已接入同一组件并经构建检查，未新增真实待办验证。
• 通过应用删除测试草稿（调用既有附件和对象存储清理）；数据库回查测试预警、处置、附件均为 0，页面也无测试记录。本地临时素材及 SQL 清理，内存测试夹具保留供重跑。
• 最终 npm run build:stage 和 git diff --check 通过；本轮未变更后端，未重复 Maven 构建。

预警清单重构与发布处置关联

• 目标：完成事项组合查询、维护和状态管理、原因库、自动编码及按编码详情，并接入发布和处置。用户确认允许不关联事项直接发布，不设强制关联门槛。
• 清单使用与预警发布一致的 alert_type/alert_level，行业独立；类型、级别、编码作为稳定标识，选择类型级别后自动预览，保存时事务锁生成编码。禁用可恢复，作废不可恢复或修改。
• 发布可选同类型同级别的启用事项，后端重新校验并读取配置，发布固定配置副本。总处置时限从发布起算，接收/处置/核查分别从发布/接收/提交结果起算，退回重新计算处置环节时限；时长解释采用已告知用户的建议，超时仅提示，不自动改变状态。
• 处置原因按当前预警类型级别筛选、多选，后端校验并保存原因 ID 和内容副本，历史详情显示已选原因。清单修改、禁用或作废不改变已发布预警的配置和流程。
• 采集共享模块增加可选 source_warning_code 精确映射，编码和等级唯一匹配启用事项时关联草稿；无匹配、多匹配、读取失败仍保留未关联草稿，已发布事件不被采集覆盖。
• 前端主要文件：warningList 五个页面和 shared.js；lifeCompany/lAlertInformation/LRelease.vue、WarningWorkflowActions.vue、components/WarningItemSummary.vue、components/WarningDisposalReasons.vue，以及待办、处置、查询详情与 api/pipeNetwork/earlyWarning.js。保留上一轮附件和行业分析改动。
• 后端复用原 item/reason/save/update/publish/process 接口；编码预览用类型和级别，预警新增 itemId，处置新增 reasonIds。新增 WarningCatalogRules、WarningItemBindingService，扩展原清单、原因和预警服务及 Mapper；采集端新增 WarningItemBindingMapper。
• 开发库已执行 migration_warning_catalog_binding_kingbase.sql，增加来源编码、事项关联和配置副本、总/当前环节截止、原因 ID/副本及索引，无业务数据回填。清单菜单2195～2206、组件、权限和角色授权只读核对通过，无菜单写入。
• 用户重启主业务服务后，真实页面通过事项新增/修改/启停/作废、编码预览、原因新增、组合筛选、分页、按编码详情，以及关联草稿→发布→接收→开始处置→多选原因→提交核查→解除归档。事项24小时改48小时后历史预警仍为24小时，作废事项不阻断原预警解除；不关联事项发布成功且无截止时间。
• 联调修复 MyBatis 防更新插件拒绝 LOCK TABLE（改用项目已有事务 advisory lock）、动态路由 name 不匹配（改核对后的完整 path）、缓存页编码参数变化不刷新、时间展示和状态操作错误提示。
• 验证：最终 npm run build:stage 通过；主服务 mvn -o -pl zksy-admin -am -DskipTests compile 通过；管理端 WarningCatalogBindingTest/EarlyWarningWorkflowTest/WarningSupervisionNotifierTest 共11项通过；采集 WarningItemAutoBindingTest 共3项通过；前后端 git diff --check 无错误。
• 可重复夹具 warning_catalog_binding_test_data_kingbase.sql 覆盖6类型、3等级、3状态及分页，重复执行不增记录。清理脚本已精确删除本轮2预警、13事项、1原因、3待办、6处置、1归档；回查预警、事项、原因、待办、处置均为0，未留下业务测试数据。
• 未验证：其他角色权限组合、真实设备采集自动匹配、并发压测；未发送真实短信或他人通知。采集端自动匹配需重新打包并重启引用新版共享模块的采集服务。完整命令、迁移和联调结果见后端 docs/warning-catalog-binding-2026-09-29.md。未提交或推送代码。

预警等级下拉统一一至四级

• 用户要求清单等级与系统预警一致，支持一至四级。根因是开发库 alert_level 仅有一至三级，并非页面或 Java 限制四级。
• 经系统字典管理页面查询后，使用原新增接口补入“绿色预警（四级）”，值4、排序4、正常状态，接口同步刷新字典缓存。回查共4条；保留一至三级原标签，未改业务记录和菜单。
• 真实页面核对事项查询、事项编码和预警发布下拉均显示1～4级；水质异常+四级的编码预览成功生成 WI-2-L4-202609290001，后端校验通过。没有创建测试业务数据或外发通知，无需清理。
• 业务前后端代码无变更；新增后端 sql/migration_alert_level_four_kingbase.sql 供其他环境补齐缺失字典，当前环境通过应用接口完成，独立迁移脚本未执行。部署脚本后需刷新字典缓存。
• npm run build:stage、mvn -o -pl zksy-admin -am -DskipTests compile 均通过。前端构建因沙箱限制 esbuild 首次失败，按已授权构建权限重跑成功。本地服务无需重启，页面刷新生效。

事项、预警与原因库关系说明

• 向用户解释：事项提供可选处置规则，预警是实际事件，原因库按类型和等级提供可多选参考原因。
• 用户追问原因库无匹配项如何处置。核对 WarningWorkflowActions.vue、WarningProcessDTO 和 EarlyWarningServiceImpl.submitWarningProcess：原因选择为可选，无选项时隐藏下拉；处置结果必填，空原因列表允许提交核查。原因查询失败同样允许直接填写处置结果。
• 手填原因保存在本次处置说明，不自动加入原因库；可以后续由维护人员整理常见原因供复用。本轮仅代码只读核对和说明，无业务代码、接口、数据库或菜单变更，无新增测试数据，未重复构建。