Problem
removeDashboardPanel proves ownership before deleting anything and refuses
ownership-unproven when the tile's queryId names no query in
workspace.queries, or names one with more than one owner
(src/dashboard/application/dashboard-removal.ts:128-131). Both the Dashboards
tree and — since #537 — the tile header route their delete through it.
That is the correct fail-closed behaviour #494/#537 specify. The consequence is
that a tile whose query is missing (a dangling queryId) or shared by a
second tile now has no removal path from any surface:
How to reach it
A queries-only bundle import (#448) or a corrupt aggregate can produce a tile
pointing at an id no query carries. A legacy or hand-edited workspace can carry
two tiles referencing one query, which #427 forbids reaching but does not
retroactively repair.
Why it was deferred
#537's acceptance criteria require exactly this fail-closed behaviour, so the
alternative belongs in its own decision rather than smuggled into that change.
Options
- A separate, explicitly-labelled "Remove tile only" action, offered only
when removal is refused because the query is missing — a dangling reference has
no second resource to be atomic about. Would keep the remove-tile command,
which currently has no UI dispatcher left.
- Give
removeDashboardPanel an explicit tile-only arm for the missing-query
case, so one path still covers it.
- Accept it, and handle these workspaces through Import/Replace only.
Option 1 or 2 seems right for the missing-query case; a shared query arguably
should stay unremovable, since either tile still renders it.
Problem
removeDashboardPanelproves ownership before deleting anything and refusesownership-unprovenwhen the tile'squeryIdnames no query inworkspace.queries, or names one with more than one owner(
src/dashboard/application/dashboard-removal.ts:128-131). Both the Dashboardstree and — since #537 — the tile header route their delete through it.
That is the correct fail-closed behaviour #494/#537 specify. The consequence is
that a tile whose query is missing (a dangling
queryId) or shared by asecond tile now has no removal path from any surface:
⋯→ Remove tile row is disabled with the same reason;remove-tiledispatch, which removed such a tile without touchingqueries.How to reach it
A queries-only bundle import (#448) or a corrupt aggregate can produce a tile
pointing at an id no query carries. A legacy or hand-edited workspace can carry
two tiles referencing one query, which #427 forbids reaching but does not
retroactively repair.
Why it was deferred
#537's acceptance criteria require exactly this fail-closed behaviour, so the
alternative belongs in its own decision rather than smuggled into that change.
Options
when removal is refused because the query is missing — a dangling reference has
no second resource to be atomic about. Would keep the
remove-tilecommand,which currently has no UI dispatcher left.
removeDashboardPanelan explicit tile-only arm for the missing-querycase, so one path still covers it.
Option 1 or 2 seems right for the missing-query case; a shared query arguably
should stay unremovable, since either tile still renders it.