2026-08-17-water-supply-ui-completion.md 6.1 KB

Water Supply Frontend Completion Implementation Plan

For agentic workers: Execute this plan task-by-task in the current workspace. Steps use checkbox syntax and must be verified before completion.

Goal: Replace the blank water-supply home with a gas-style GIS dashboard, expose all requested water-supply modules through dynamic menus, and align monitoring/alarm interactions with the supplied alarm specification.

Architecture: Keep the existing Vue 3/RuoYi dynamic-route architecture. Add one reusable water dashboard component for both water home entries, extend existing water components rather than duplicating pages, and keep API contracts in src/api/pipeNetwork/waterSupply.js. Add a backend type constraint because frontend filtering cannot correct paginated mixed-device responses.

Tech Stack: Vue 3 <script setup>, Element Plus, ECharts, existing BMapGL/coordinate utilities, Axios request wrapper, Spring Boot/MyBatis service layer, SQL menu initialization.

Spec: .firecrawl/water-monitor-alarm.md and the user requirements in this task.

Global Constraints

  • Page names must remain aligned with the supplied water-supply menu names.
  • The four water modules remain dynamically authorized by backend /getRouters; frontend component existence alone is insufficient.
  • The home dashboard must show a GIS/map area with left and right data cards in the visual language of gas/ghome/gHome.vue.
  • Monitoring pages must show only the corresponding flow, pressure, or leakage sub-device data.
  • No credentials, tokens, map keys, or complete sensitive API responses may be written to memory or tracked files.
  • Preserve all unrelated existing worktree changes.

Task 1: Add the water-supply GIS dashboard

Files:

  • Create: src/views/subSystem/waterSupply/components/WaterSupplyHome.vue
  • Modify: src/views/subSystem/waterSupply/whome/wHome.vue
  • Modify: src/views/subSystem/waterSupply/index.vue
  • Test: tests/waterSupplyModel.test.mjs

  • [ ] Build the dashboard around getWaterFacilityOverview, getWaterFacilityFeatures, getDeviceGisAllPoints, getDeviceGisStatistics, getAlarmStats, and listRealtimeAlarms, with zero-value/empty-state fallbacks for failed APIs.

  • [ ] Reuse the gas dashboard visual hierarchy: title/time header, three-column body, dark blue map stage, left operational cards, right alarm/device cards, and responsive collapse below 1100px.

  • [ ] Render facility points and pipe lines from GeoJSON using the existing coordinate normalization helper, with facility legend, alarm-level legend, selected-point detail, and refresh action.

  • [ ] Make wHome.vue and index.vue thin wrappers around the component so either route renders the same non-empty page.

  • [ ] Add a model-level assertion for dashboard fallback/coordinate normalization and run the test.

Task 2: Align monitoring pages with device subtypes

Files:

  • Modify: src/views/subSystem/waterSupply/components/WaterMonitoringPage.vue
  • Modify: src/utils/waterSupplyModel.js
  • Modify: tests/waterSupplyModel.test.mjs
  • Modify: E:/pipe-ner-server/pipe-network-service/zksy-system/src/main/java/com/zksy/base/service/impl/MonitoringServiceImpl.java

  • [ ] Add a monitorType prop to the shared page and display 设备子类型 from equipmentTypeName.

  • [ ] Keep each page bound to its dedicated API and metric field: flow instantFlow, pressure pressureValue, leakage power.

  • [ ] In MonitoringServiceImpl, resolve matching equipment_type rows by type ID/name keywords and constrain the initial EquipmentBase query to those IDs before pagination; leave records empty when no matching subtype exists.

  • [ ] Preserve existing filters, trend calls, and export behavior; add a regression assertion for type-name normalization on the frontend model side.

Task 3: Complete monitoring-alarm interactions

Files:

  • Modify: src/views/subSystem/waterSupply/components/WaterAlarmPage.vue
  • Modify: src/api/pipeNetwork/waterSupply.js
  • Modify: src/utils/waterSupplyModel.js

  • [ ] Add a real-time exception card section from /waterSupply/alarm/realtime, including device, level, location, actual value, threshold, and time.

  • [ ] Add detail loading through /waterSupply/alarm/detail/{id}, one-click resolve, and a dispatch form bound to /waterSupply/alarm/dispatch.

  • [ ] Add audit action/result/opinion/attachment fields, audit history and full-flow timeline using /audit, /audit/list, and /flow/{id}; use the existing upload component only if its request contract is compatible.

  • [ ] Keep threshold CRUD and add clear classification/time-period labels; retain alarm map level coloring, search, and detail opening.

  • [ ] Ensure every operation is permission-safe and presents an empty/error state without breaking the page.

Task 4: Enable the complete dynamic menu tree

Files:

  • Create: E:/pipe-ner-server/pipe-network-service/sql/water_supply_menu.sql
  • Modify: src/views/subSystem/waterSupply/** only when a component path differs from the menu component value.

  • [ ] Add idempotent SQL for the water root, four module directories, 19 page menus, and the required list/export/handle/audit/dispatch button permissions.

  • [ ] Set requested menus visible='0' and status='0', use the exact Chinese names from the user list, and point components to existing semantic paths.

  • [ ] Verify menu parent lookup is by stable parent name/perms and does not duplicate rows on repeat execution.

Task 5: Verify and record

Files:

  • Modify: task_plan.md
  • Modify: findings.md
  • Modify: progress.md
  • Modify: memory/sessions/2026-08-17.md
  • Modify: memory/index.md and memory/long-term.md only if stable facts change

  • [ ] Run node tests/waterSupplyModel.test.mjs.

  • [ ] Parse all changed Vue SFCs with @vue/compiler-sfc and run the production build using the workspace Node runtime.

  • [ ] Start or reuse the frontend dev server and use the in-app browser to verify the water home renders a non-empty dashboard and the requested dynamic menu routes resolve after backend authorization.

  • [ ] Record errors, test results, changed files, and remaining backend/data limitations without secrets.