Skip to content

[Direction · v18] Per-user scope for view personal configuration (parked from #7494) #7611

Description

@os-zhuang

Direction card recording the parked half of the #7494 ruling (maintainer, 2026-08-11 — verbatim authorization in chat: 「接受你的全部建议,请更新 issue 的状态和标签」, accepting the four-lens decision-inbox review in full). Filed by the PM session under the maintainer-directed routing channel.

What is parked

A true per-user scope for view personal configuration (sort / hiddenFields / columnState / rowHeight as genuinely personal overlays), delivering the "Airtable-style per-view personal config" the console prose once promised.

Why parked, not queued (four-lens)

  • Business pull: none measured today. The harmful symptoms are closed by the NOW layer of updateViewConfig stores "per-view personal config" as ONE org-wide metadata item — sort/hiddenFields/columnState/rowHeight written by any user apply to every user of the view #7494 (permission gate on the org-wide overlay write; honest contract wording) and objectui#4227 (personalization rows distinguishable from saved views; system views not deletable via overlay).
  • Startup focus: this is a new platform capability surface — a new scope dimension in the view-overlay store, new read/write paths, migration for existing overlay rows. Capability expansion without real demand is exactly what the startup-focus principle defers.
  • Long-term: per-user scope remains the architecturally right end-state if demand appears; nothing in the NOW layer forecloses it.
  • AI-safety: the NOW layer already removes the namespace ambiguity that was the active mis-write trap.

Hold record

Refs

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions