dohertj2/ScadaBridge
1
0
Fork 0
Code Issues 2 Pull Requests Actions Packages Projects Releases Wiki Activity

Topology page: renaming an area does not persist (QA, area 'row1') #38

New Issue
Closed
opened 2026-10-22 13:42:29 -04:00 by dohertj2 · 1 comment
dohertj2 commented 2026-10-22 13:42:29 -04:00
Owner
Copy Link
Copy Source

Summary

On QA (wonder-app-vq03.zmr.zimmer.com:8085), renaming the area row1 from the Central UI Topology page (Deployment → Topology) never took effect — the area kept its old name.

Environment

  • QA central pair wonder-app-vq03/vq04, build b3021e7c (deployed 2026-09-28)
  • Site: QA Site (site-a, site id 2), area id 1 (row1)

Steps

  1. Open Deployment → Topology on QA.
  2. Rename area row1 to Aisle001 in the tree.
  3. The rename does not persist — the area still shows row1.

Workaround / current state

Renamed via the CLI on 2026-10-22, which worked immediately:

scadabridge site area update --id 1 --name Aisle001

Area 1 is now Aisle001 on QA.

Possibly related

On current main (52a1e1b6), the Playwright suite Deployment.TopologyAreaTests fails against the docker rig, including RenameArea_EnterCommits_PersistsNewName and RenameArea_Escape_RevertsToOriginalLabel; that is under investigation as part of the 2026-10-21 review remediation. QA runs the older b3021e7c build, so the QA symptom predates that work — root cause not yet determined for either.

## Summary On QA (`wonder-app-vq03.zmr.zimmer.com:8085`), renaming the area **`row1`** from the Central UI **Topology** page (Deployment → Topology) never took effect — the area kept its old name. ## Environment - QA central pair wonder-app-vq03/vq04, build `b3021e7c` (deployed 2026-09-28) - Site: `QA Site` (`site-a`, site id 2), area id 1 (`row1`) ## Steps 1. Open Deployment → Topology on QA. 2. Rename area `row1` to `Aisle001` in the tree. 3. The rename does not persist — the area still shows `row1`. ## Workaround / current state Renamed via the CLI on 2026-10-22, which worked immediately: ``` scadabridge site area update --id 1 --name Aisle001 ``` Area 1 is now `Aisle001` on QA. ## Possibly related On current `main` (52a1e1b6), the Playwright suite `Deployment.TopologyAreaTests` fails against the docker rig, including `RenameArea_EnterCommits_PersistsNewName` and `RenameArea_Escape_RevertsToOriginalLabel`; that is under investigation as part of the 2026-10-21 review remediation. QA runs the older `b3021e7c` build, so the QA symptom predates that work — root cause not yet determined for either.
dohertj2 commented 2026-10-22 14:58:16 -04:00
Author
Owner
Copy Link
Copy Source

Fixed on main (560adefb, local — not yet pushed). Root cause: the inline rename input bound with the default onchange trigger; the browser fires change only after the Enter keydown (or on blur, which cancels by design), so CommitRename always saw the original name and silently no-oped. UI rename has never persisted since the page was written, which is why QA (b3021e7c) showed it. Now binds @bind:event="oninput"; bUnit regression InlineRename_TypeThenEnter_PersistsNewName + Playwright RenameArea_EnterCommits_PersistsNewName (now types + Enter like an operator) pass against the rebuilt docker rig. QA/prod keep the bug until their next deploy.

Fixed on main (560adefb, local — not yet pushed). Root cause: the inline rename input bound with the default onchange trigger; the browser fires change only after the Enter keydown (or on blur, which cancels by design), so CommitRename always saw the original name and silently no-oped. UI rename has never persisted since the page was written, which is why QA (b3021e7c) showed it. Now binds @bind:event="oninput"; bUnit regression InlineRename_TypeThenEnter_PersistsNewName + Playwright RenameArea_EnterCommits_PersistsNewName (now types + Enter like an operator) pass against the rebuilt docker rig. QA/prod keep the bug until their next deploy.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
dohertj2 (dohertj2)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: dohertj2/ScadaBridge#38
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?