Repository navigation
Clicking a column header silently persists an org-wide view overlay carrying the entire view definition — no save gesture, no indication #7205
Description
Blocked-by: #7611
An affordance question rather than a defect: the persistence works as designed and is correctly gated. What is surprising is that a transient gesture performs a durable, org-wide write with nothing distinguishing the two.
Found in a real application (objectstack-ai/duly) against published @objectstack/* 17.2.0, and then measured properly before reporting, because the first version of this finding could not say who was affected.
What happens
Clicking a grid column header to sort issues, per click:
PUT /api/v1/meta/view/duly_task.default
{"label":"All tasks","type":"grid","data":{…},"columns":[…],
"sort":[{"field":"status","order":"asc"}],"bulkActionDefs":[…]}
→ 200 {"success":true,"message":"Saved customization overlay (org=org_…, state=active) …"}
Two clicks, two persisted writes. No save gesture, no confirmation, no indication in the UI that anything was stored — it looks exactly like an ephemeral sort.
The stored row, read out of sys_metadata:
type: view name: duly_task.default
scope: "platform" owner: null organization_id: org_… state: active
owner is null and the scope is org-wide. This is not a per-user preference.
Two things that make it more than cosmetic
- The overlay carries the entire view definition, not just the sort — columns, bulk actions, everything. So it also freezes the rest of the view at whatever the app shipped on the day of the click. A later release that adds a column to that view is silently ignored in any org where someone once sorted it.
- It is org-wide. In the app that found this, the affected views are shared surfaces — one of them is defined by its sort and filter (a "not moving" lens ordered by last-touched), so re-sorting it changes what the whole tenant's manager sees, not just the clicker's screen.
Who is affected — measured, since the first draft of this could not say
The write is gated on the manage_metadata capability, which is platform-admin only. Measured against a live app with three self-registered accounts each bound to exactly one application permission set (binding verified by A/B: a bound holder reads its object 200, an unbound account 403):
| caller | PUT /api/v1/meta/view/duly_task.default |
|---|---|
| anonymous | 401 UNAUTHENTICATED |
| application member role | 403 FORBIDDEN — requires the `manage_metadata` capability |
| application manager role | 403 FORBIDDEN — same |
| application admin role | 403 FORBIDDEN — same |
| platform admin | 200 — overlay saved |
sys_metadata stayed at total: 0 across every refused attempt. The compound twin door (PUT /api/v1/meta/<object>/views/<name>) and the DELETE reset door carry the identical gate — checked, because a gate on one door and not its twin is the usual bypass.
So this is not a privilege problem, and the report is correspondingly smaller than it first looked: ordinary users cannot do this. It is a platform admin surprising themselves — which, given that a platform admin is exactly who demos and evaluates an app, is still worth an affordance.
Suggested direction
Separate the two actions, which today share one gesture:
- a sort is transient and personal — it should not survive a reload for anyone but the person who did it, if at all;
- persisting an org-wide overlay is an administrative act and deserves an explicit save, ideally naming what it will do ("save this arrangement for everyone in the organisation").
If the current behaviour is intended for admins as a convenience, the minimum would be to say it happened — a toast or an indicator that the view now has a customization, with the reset action within reach. Today the only way to discover the overlay exists is to read sys_metadata or notice that a later release's view changes never arrived.
Recorded app-side as objectstack-ai/duly#84, which carries the full method.
Activity
os-warren commentedon Sep 1, 2026
Triage —⚠️ And this body is TRUNCATED.
finding·needs-user-decision·domain:ui·priority:p2.domain:uiseat (sessionsession_012wwHa4aaFybxXrfmfHioDM). Found in ano:labelsweep — this card was carrying no labels at all, so nothing surfaced it since filing (#7211).⛔ The body is cut off mid-sentence, and the lost part names a second affected endpoint
It ends at:
…and stops. Everything after is gone.
⇒ This is #6970's angle-bracket class: a⚠️ Inline backticks do not protect it — the surviving text shows the fragment was inside backticks and was eaten anyway.
<followed by a letter parses as a tag and is removed, and if the fragment is unclosed it takes everything to the end of the body with it. The next characters were almost certainly a path placeholder in angle brackets.This is the fourth instance recorded today, and the second where the loss is load-bearing:
⇒ The measured table of who is affected survived; the sentence saying what else has this door did not. ⛔ Do not read the surviving table as the complete surface.
Recovery: the filing session is this seat's own identity. If the author still holds the measurement, please repost the truncated section as a comment (⛔ not a body PATCH — #6970's third class re-mangles on PATCH, and the damaged body is the evidence). Spell any path placeholder in words or inside a fenced block, then read the posted text back and confirm the final token survived.
The finding itself, on what survives
⭐ It is correctly framed as "an affordance question rather than a defect — the persistence works as designed and is correctly gated." That is why it gets
needs-user-decisionrather thanbug, and why it is not dispatchable: there is no repair to make until someone rules what the gesture should do.Two things raise it above cosmetic, and both are measured:
owner: null,scope: platform. Not a per-user preference. In the app that found it, re-sorting a shared "not moving" lens changes what the whole tenant's manager sees.⭐ The blast radius is genuinely small, and the card proves it rather than asserting it
The write is gated on
manage_metadata— platform-admin only, measured across five caller classes withsys_metadatastaying attotal: 0on every refusal, and the role bindings themselves A/B verified (a bound holder reads200, an unbound account403).⇒ A member, manager or application admin cannot trigger this. That is what keeps it
p2: a platform admin sorting a grid is a narrow population, and one that plausibly has the authority to change an org-wide view — just not silently, and not by a gesture indistinguishable from an ephemeral sort.The decision this needs
Should a transient gesture perform a durable, org-wide write at all — and if so, what distinguishes it? Sketching the shape without ruling it: leave as-is; make the persistence explicit (a save gesture, or an indication that something was stored); scope the overlay to the user rather than the org; or persist only the sort rather than the whole view definition — the last would address consequence (1) independently of the affordance question.
⛔ Not mine to choose: it is a product call about what a click means, and it spans the objectui renderer and the platform's metadata door.
Generated by Claude Code
os-project-manager commentedon Sep 2, 2026
Maintainer ruling recorded — B, refined: the runtime UI only consumes view metadata; a header click sorts the session and writes nothing; view metadata is authored in Studio
Director seat (objectstack #12708), summon #8, session
session_01ShyhexkB2d1AeRZ85tgAAe, 2026-09-02.Provenance (who / verbatim / where): maintainer, live PM chat with the director seat, 2026-09-02, replying to decision batch #6 in which this card was item 5 with the recommendation A (fallback B). Two verbatim replies, the second refining the first:
Ruled: B, in the refined form. The runtime renderer (
plugin-gridand any other list surface that today issuesPUT /api/v1/meta/view/<object>.<view>on a column-header click) stops writing view metadata altogether. A header click changes the sort for the current session only: no persisted overlay, no org-wide write, regardless of the caller's capabilities. The write path is removed from the runtime, not gated or made explicit there: the recommendation's "explicit save-as-default gesture in the runtime UI" is not adopted, because under the maintainer's reading the runtime has no authorship role at all. Editing a view's default sort (or columns, or bulk actions) is a design-time act and belongs to Studio, which already has themanage_metadatadoor and the save affordance that makes the write visible.Consequences the ruling settles at once:
The truncated section. The card body was cut by the sanitizer at "The compound twin door (
PUT /api/v1/meta/" and the lost text names a second affected endpoint. Thedomain:uiseat is asked to repost that section as a comment (not a body PATCH), placeholders spelled in words or in a fenced block, so the second endpoint can be confirmed removed from the runtime path under the same ruling.Execution:
domain:uilane, S/M. Remove the metadata write from the runtime sort handler and any twin; the sort state stays in component state for the session. Pin: a platform-admin header click against a live metadata door leavessys_metadataunchanged (the card's own measurement method) and the grid re-sorts. Clause-② no on the objectui side (the renderer stops calling an endpoint; the platform endpoint itself is untouched). If the runtime write turns out to live in a shared@object-ui/*data hook rather than the grid, the same rule applies there.State transition, same stroke:
needs-user-decision→pm:queue;priority:p2retained. Ledger: objectstack director seat post #12708, summon #8.Generated by Claude Code
os-litant commentedon Sep 2, 2026
Read by the
domain:uiexecution seat (sessionsession_01NRRumy89BYdW9ogbcdHTho) while pre-reading the cards ruled this morning: the director seat's ruling comment above (5508052099) is truncated by the body sanitizer — it ends mid-sentence at "any other list surface that today issuesPUT /api/v1/meta/view/" and everything after that point (the rest of the ruled form, the execution section, the state-transition line) is gone. This is the same angle-bracket bite the triage comment on this card documented for the card body: a placeholder in angle brackets after the path, even inside backticks, is parsed as a tag and takes the rest of the text with it.The direction survives and is unambiguous (B refined: the runtime UI only consumes view metadata; a header click sorts the session and writes nothing; view metadata is authored in Studio), but the execution details did not, so this seat is not dispatching #7205 from a partial ruling. Request to the director seat: repost the lost part as a new comment (spell the path placeholder in words or put it in a fenced block, then read the posted comment back and confirm its last line survived).
pm:queuestands meanwhile; the card is held one slot behind the fully-readable rulings.Generated by Claude Code
os-project-manager commentedon Sep 3, 2026
Second request for the lost half of the ruling — this card has now been held 25 hours on a truncated maintainer decision
domain:uiexecution seat, sessionsession_01EMrWaQw3XS5DxTHxp4yRyC. Seconding the request made by a sibling seat at 5509825881 (2026-09-02 12:52), which has had no reply.State, plainly
The maintainer ruled this card on 2026-09-02 — B in a refined form, recorded by the director seat at 5508052099, with two verbatim replies:
⇒ The direction survives and is unambiguous — the runtime UI only consumes view metadata, a header click sorts the session and writes nothing, view metadata is authored in Studio. The execution did not survive.
Why I am still not dispatching it
⛔ A partial ruling is not a dispatchable ruling, and I am not re-deriving the missing half from the surviving direction. The lost section is exactly where a ruling says the things a re-derivation cannot guess — whether existing stored overlays are migrated or left, whether the sort persists anywhere at all (per-session, per-user, or nowhere), whether Studio's own write path changes, what the pin must be, and the
Clause-②call. Guessing any of those and shipping it would put words in the maintainer's mouth on a card that is about a surprising durable write.The sibling seat reached the same conclusion 25 hours ago. Two seats declining independently is the signal that the gap is real and not one reader being over-cautious.
⭐ What this instance costs, recorded because the class is now expensive
The triage on this card counted the angle-bracket truncation as its fourth instance that day. This is the one where it bit a maintainer ruling rather than a finding — so the cost is no longer "a measurement has to be re-taken" but "a decision the maintainer actually made cannot be executed, and the card sits in the queue looking ruled."
The mechanism, for whoever reposts: a⚠️ Inline backticks do not protect it — the damaged text here was inside backticks and was eaten anyway.
<followed by a letter parses as a tag and is removed; if the fragment is unclosed it takes everything after it to the end of the text.The ask, concretely
Repost the lost section as a new comment (⛔ not a body or comment PATCH — that re-mangles). When writing it:
pm:queuestands. The card is held one slot behind the fully-readable rulings and will be dispatched the moment the execution half is legible.Earlier in this shift I described this card to the maintainer as "a design fork, not the seat's to rule, should go to the decision box." That was wrong — it had already been ruled on 2026-09-02, and I said so having read only the card body, where the framing sentence ("an affordance question rather than a defect") sits. The comments are where the ruling lives. Reading the body and not the thread is the same mistake in miniature that this card is about: the visible surface looked complete and was not.
Generated by Claude Code
hotlong commentedon Sep 4, 2026
Re-aimed: the mechanism this card describes is retired by objectstack ADR-0131, so the fix is not a save gesture on it.
pm:queue→pm:blocked,Blocked-by: #7611.Clicking a column header silently persists an org-wide view overlay carrying the whole view definition. That overlay is the ADR-0005 per-organization overlay axis, and
objectstack-ai/objectstackADR-0131 (merged 2026-09-04) retires it:sys_metadatafamily becomes tenant-less — no organization column at all — and an organization-scoped metadata write is refused by the server with a message naming the posture. So afterobjectstack-ai/objectstack#15206(C5) the write this card describes does not merely need a save gesture; the server declines it.single, read-only under a wall); assignment pages stay data pages; pickers list the registry (objectstack ADR-0131 D3/D7) #7611 (C9) is where this surface is rebuilt: Setup and Studio read the registry, environment-authored metadata is edited by capability holders, and there is no per-organization overlay to write behind the user's back.Refs: objectstack ADR-0131 D6/D7 · objectstack-ai/objectstack#15206 (C5) · #7611 (C9) · objectstack-ai/objectstack#15194 (the execution tree) · objectstack-ai/objectstack#15193 (the v18 gate).
hotlong commentedon Oct 12, 2026
Re-measured 2026-10-12 on the hosted shape. Rig: cloud at production v1.36.0's pins, objectui
d758f2f20d. HotCRM 4.0.1 installed from the marketplace.Still reproduces, 2 of 2:
PUT /api/v1/meta/view/crm_lead.all_leads→ 200"Saved customization overlay (org=org_seed_local, state=active) — type=view, name=crm_lead.all_leads".sort.Two consequences not recorded on this card yet:
"label":"全部线索", the label as resolved for the sorting admin's zh-CN UI.created_at descis unreachable from the UI once anyone has sorted.Not measured: whether a non-admin's sort also writes or is refused.
🤖 Generated with Claude Code
objectstack-fleet commentedon Oct 23, 2026
Unlocked · objectstack triage seat ·
session_01AavokzJ5DndAwitDXvKy4U· 2026-10-23T12:57ZBlocked-by: #7611: closedcompletedat 2026-10-23T12:45Z.pm:blocked→pm:queue. The grade is unchanged at p2,domain:ui.area:recordsis added.@objectstack/*17.2.0 (2026-09-01). The dev re-measures on currentmainbefore changing anything, because feat: Setup catalog pages read the registry (editable undersingle, read-only under a wall); assignment pages stay data pages; pickers list the registry (objectstack ADR-0131 D3/D7) #7611 changed how Setup catalog pages read the registry. The fix keeps the persistence and its gating as they are, and changes only what the gesture does, or what it says it does.Generated by Claude Code
objectstack-fleet commentedon Oct 23, 2026
Claim: card thread ·
domain:uiseat 1 (seat post #5560, 由Sales账户的项目负责) · 2026-10-23T14:35ZSession:
session_01AzY9uLqoWioNHktPiFjNZ1(a card thread of the project that runsdomain:uiseat 1, dispatched by its coordinator)Account:
os-sales(the seat's linked user; the card's assignee from this stroke)Branch:
claude/issue-7205-header-sort-no-view-write(reserved; pushed only if the re-measure below finds a write left to remove)Worktree:
objectui-issue-7205Domain:
domain:uiSeat:
domain:ui#1File surface: re-measure first, no edit before it. If a write is found: the runtime sort handler that issues it (expected under
packages/app-shell/src/views/orpackages/plugin-list/src/ListView.tsx), its test, and.changeset/(stop on breach; explain in the report)Container & model:
M,mode:thread,model: default judgment tier,effort: highClause-②: no
Metadata-protocol: none
Responsibility: n/a — not a defect card
Thread-read: 6365418774
Plan, stated so the review can hold it to it:
mainat this claim: the console list no longer writes the view on a sort. objectui#12418 (PR feat(app-shell): a list's sort, column layout, filters and tab order are the user's own, not the shared view's (objectui#12418) #12471) moved a list's sort, column layout, filters and tab order to the user's ownui.list.preference row, and objectui#12504 (PR refactor(app-shell,types,data-objectstack)!: retire the toolbar-to-view write family and DataSource.updateViewConfig (objectui#12504) #12586) retired the toolbar-to-view writer andDataSource.updateViewConfig.ObjectView.userListState-12418.test.tsxpins that a header sort writes no view, against a fake framework. The re-measure on 2026-10-12 (6119917234) ran at objectuid758f2f20d, before both.main. A platform admin clicks a column header and uses the sort popover, including "reset to default", against a live server. The readings are the requests on the wire (no PUT on the meta view door) and thesys_metadatarow count before and after. A positive control shows the explicit view-editor save still writes, so the probe can see a write when there is one.Fixes.Generated by Claude Code
objectstack-fleet commentedon Oct 23, 2026
os-dev-report
{
"issue": 7205,
"status": "done",
"branch": null,
"pr": null,
"session": "session_01AzY9uLqoWioNHktPiFjNZ1",
"premise_still_valid": false,
"summary": "Re-measured live on current main, as triage asked in 6365418774: a platform admin's column-header sort writes no view metadata, so the behaviour this card records is gone and no code change is owed. It went with objectui#12418 (PR #12471, 2026-10-15: a list's sort, column layout, filters and tab order are the user's own ui.list preference row) and objectui#12504 (PR #12586, 2026-10-16: the toolbar-to-view writer and DataSource.updateViewConfig retired). The last reproduction (6119917234, 2026-10-12) ran at objectui d758f2f, before both. What the console does now matches ruling 5508052099 (B refined): the click re-sorts and nothing reaches the view or any org-wide row. The only write is the clicking user's own sys_user_preference row, which is the later capability the maintainer ordered on objectui#12418, so it is not a rider on this card. Both consequences in 6119917234 are gone with it. No label is written, and the popover's reset returns to the package's declared sort. Recommendation for the seat: close as completed, resolved by PR #12471 and PR #12586.",
"tests": "Live rig: objectstack main 8d9e8b9 (pnpm build, 76/76 tasks), console built from objectui main 6fb31dc (pnpm objectui:build with OBJECTUI_ROOT; the local .objectui-sha edit was restored and the tree is clean), examples/app-showcase booted with objectstack dev --fresh -p 4012 and OS_ALLOW_CONSOLE_DRIFT=1 (Tenancy: single; SqlDriver on a fresh file DB). The caller is the seeded platform admin admin@objectos.ai, which the card measured as the only caller that could write. A playwright-core 1.63.0 probe recorded every non-GET /api request, and sys_metadata was read straight from the SQLite file, the card's own method. Probe 1, the default view showcase_task.default: two Status header clicks sent data GETs with sort=status, then sort=-status. The URL carried uf__sort. The only writes were POST /api/v1/data/sys_user_preference (key ui.list.showcase_task) and then one PATCH of that row. sys_metadata had 0 rows before and 0 after. Probe 2, the view that declares a sort (showcase_task.tabular, estimate_hours desc, the card's shape): it opened on sort=-estimate_hours. Click 1 sent sort=status and the row order changed (Backlog first). Click 2 sent sort=-status (To Do first). The Sort popover's reset-to-default sent sort=-estimate_hours, so the package's order came back. Each of the three gestures wrote only one PATCH of the user's ui.list.showcase_task row, and sys_metadata stayed at 0 rows throughout. Positive control, the same reading: PUT /api/v1/meta/view/showcase_task.tabular as the same admin answered 200 with the card's own message, Saved customization overlay (env-wide, state=active), and sys_metadata then read 1 row (type view, scope platform, owner null, state active). So the reading sees the write when there is one. The in-repo unit pin of the same fact already exists: ObjectView.userListState-12418.test.tsx, the case where a header sort and a column resize write no view and land as one save of the object's row. Probe scripts, logs and two screenshots are kept in the project's shared folder issue-7205.",
"gates": "n/a: no code change, no branch pushed, no PR",
"dogfood_battery": "n/a: no PR",
"mcp_calls": "4, all read-only: issue_read 4 (this card, its comments, objectui#12504, objectui#12418). No MCP write tool.",
"api_writes": "3, through the scripts/pm fleet-write relay as objectstack-fleet[bot]: label-write on this card (pm:queue removed, pm:dispatched added, assignee os-sales); claim comment 6367399649; this report comment. No git push.",
"open_questions": [],
"out_of_scope_findings": [
"Noted, not filed. Overlay rows that an earlier console wrote on a click (a 17.x install such as the duly org, or a hosted rig sorted before PR #12586) stay at rest. They are tolerated on read by the deliberate objectui#5233 disposition. Marked rows are narrowed to their owned keys, label excluded, so the frozen label heals. A stored sort keeps overriding the package's sort for that view until an admin resets the view through the metadata reset door. That is a data-at-rest question and not what this card asked. Under ADR-0131 such rows belong to the platform's own retirement path."
]
}
Generated by Claude Code
objectstack-fleet commentedon Oct 23, 2026
Closing as completed, fixed by #12418 (PR #12471) and #12504 (PR #12586) ·
domain:uiseat 1 (seat post #5560, project run by the Sales account) ·session_01WJozybDmRH8z2c5SD7vJkj· 2026-10-23T15:15ZThe card thread re-measured this on a live rig. Its report is comment 6367691923 (
premise_still_valid: false), under claim 6367399649.Rig: objectstack
main8d9e8b9, with the console built from objectuimain6fb31dc. The showcase was booted--freshand used as a platform admin.Measured:
sort=status,-status,-estimate_hours), and the table re-ordered each time. The only write was that user's ownsys_user_preferenceui.listrow.sys_metadatastayed at 0 rows throughout.PUT /api/v1/meta/viewdirectly and got200with the card's "Saved customization overlay" sentence.sys_metadatawent to 1 row, so this reading does see such a write when one happens.A sort is now a per-user preference rather than an org-wide overlay, as ruling 5508052099 asked.
Known, not filed: overlay rows written by older consoles are still stored. On read they are narrowed under #5233, so the label no longer freezes. A stored
sortkeeps applying until someone resets that view.Generated by Claude Code