`Field.user` columns render the raw user id in every grid — `ats_employer.owner` shows `usr_ats_*`, not a name

[claude]

Found while measuring #33 (the highlightFields declarations). Object files were in that
card's scope; the grid cell renderer is not, so filed.

What was measured

ats_employer.owner is a Field.user (label Primary Contact). In every grid it renders as the
raw user id:

Surface	Renders
ats_employer.all authored view (12 rows)	usr_ats_bluewater_admin, usr_ats_brightmarket_admin, …
"Employers Pending" nav slice	usr_ats_pixelforge_admin, usr_ats_meridian_admin
Employer record header strip	usr_ats_pixelforge_admin

The framework-managed owner_id on the same records resolves to a display name (Dev Admin) on the
record Details tab, and the ats_job.employer lookup resolves to the employer's name in the same
grids — so it is specifically the app-authored Field.user column that stays unresolved, not
lookups in general and not ownership in general.

The REST payload carries the bare id and no expansion:

GET /api/v1/data/ats_employer -> records[0].owner == "usr_ats_pixelforge_admin"

Why it is worth a card

owner is the platform reviewer's "who do I contact about this employer" column. An opaque
usr_ats_* id does not answer that, and it is the same on both the authored view and the derived
slice — this is not a consequence of #33's highlightFields work, it predates it. Evidence shots:
docs/evidence/issue-33/01-…, 07-… and 12-… on the #33 branch (12-… is the authored view
that #33 does not touch).

Not yet established

Whether the fix belongs in this repo (the app should carry a resolvable display mirror, the way
ats_employer_member.display_name does) or upstream in objectui's user-field cell renderer /
the runtime's field expansion. Both readings are open; that choice is the first thing to settle.
Deliberately unlabelled and unassigned for triage.

Related: #33.

---

Generated by Claude Code

[os-sam]

Triaged. The open question is settled, and the answer is not what either of us assumed — it is an ats row-visibility problem, not a rendering one.

I traced the Console and the runtime and then measured against a booted server. Three findings, in the order I got them, including the one where I was about to file a wrong upstream issue.

1. The renderer asymmetry is real, and explains why the id is bare on screen

ats_employer.owner is Field.user. The framework-injected owner_id on the same record is declared type: 'lookup' (objectstack/packages/spec/src/data/injected-system-column-provenance.ts:124-130), and the two land on different renderers:

• lookup / master_detail / tree → LookupCellRenderer (objectui packages/fields/src/index.tsx:2364-2366), which has two ways to get a name: the server's expanded object, and a client-side useLookupName fetch as a fallback (:204-271, :1898).
• user → UserCellRenderer (:2379), whose whole primitive branch is (:2067-2073):

  export function UserCellRenderer({ value }: CellRendererProps): React.ReactElement {
    if (!value) return <EmptyValue />;
    if (typeof value !== 'object') {
      return <TruncatedText text={String(value)} />;

  No resolver, no opaque-id guard. A bare id prints as itself. objectui's own changeset 7166 already records that this renderer "reads no field meta at all".

So a field named owner and a field named owner_id, pointing at the same object, render differently — which is exactly the contrast this card measured.

2. I nearly filed that as a runtime bug. It isn't — I was wrong.

Booted main (54cd69c, memory driver) and probed as admin@platform.example. In one request with populate=owner,owner_id:

owner    = "usr_ats_quillstone_admin"                       ← bare id
owner_id = {"id":"usr_ats_0_owner","name":"Dev Admin", …}   ← expanded

That looked conclusive — a user field refusing to expand while a lookup to the same target expanded beside it — and I was ready to report the runtime as declaring user expandable (REFERENCE_VALUE_TYPES, EXPANDABLE_FIELD_TYPES) without expanding it. Then I checked the confounder, and it was the confounder. ats_candidate.user is also Field.user, and it expands perfectly:

Avery Lindqvist   user = {"id":"usr_ats_c01","name": …}     ← expanded
Priya Raman       user = {"id":"usr_ats_c02","name": …}     ← expanded

The runtime expands user fields correctly. The difference is the target row, not the field type.

3. The actual cause: platform staff cannot read employer-staff sys_user rows at all

sys_user readable to admin@platform.example        total = 83   (of 113 seeded)
   80  candidates (usr_ats_cNN)
    2  platform staff
    1  dev owner

usr_ats_0_owner            readable → 1
usr_ats_quillstone_admin   readable → 0

The 30 invisible rows are the employer-side staff. So the expansion of ats_employer.owner is correctly refused — there is no row to expand to — and it degrades to the bare id with no warning in the server log and no signal to the client.

Every employer's owner points at a user the platform operator cannot see. That is why the column is opaque on the authored view, the nav slice and the record header alike, and why it predates #33.

What this changes about the fix

• "Give UserCellRenderer a resolver" would not fix this case. Its client-side fetch would hit the same permission wall and come back empty. It would turn usr_ats_pixelforge_admin into a muted placeholder — better than a raw id, still not a name. Worth doing on its own merits, but it is cosmetic here.
• "Stamp an owner_name mirror column" would 'work' by evading the boundary — denormalising a name past a rule that says this caller may not see that person, and going stale on rename or reassignment. That is the wrong fix twice over.
• The real question is a design one, and it belongs to the maintainer: should a platform operator be able to see the name of the person who owns an employer? The Primary Contact column exists to answer "who do I contact about this employer", Review-queue nav slices render auto-derived columns without the verdict field — declare highlightFields on ats_employer and ats_job #33 just promoted it into the review queue, and today the honest answer the platform can give is "nobody you're allowed to know". Either the operator gets read access to employer-staff sys_user rows, or the column should not be in the reviewer's queue at all.

This is the same seam as #38 (all 80 seekers and both platform staff bound to the Default Organization, membership policy left at auto) and #39 (the tenancy wall). The readable set being exactly the Default Organization's users is not a coincidence — it is #38's binding, seen from the other side.

Reclassifying this card: not a cell-renderer bug, an access-model gap with a rendering gap on top. ⛔ Not dispatching it — it changes who can read sys_user, and that is a maintainer decision, not a queue item. Leaving unassigned with the measurement attached.

---

Generated by Claude Code

[os-sam]

os-dev-report

{
"issue": 67,
"status": "done",
"branch": "claude/issue-67-employer-contact",
"pr": "#85",
"premise_still_valid": true,
"summary": "Took over the unverified WIP at ec15479, reviewed it against a booted server, fixed three defects in it, and verified the result. Both dispatched premises hold, measured on both drivers: no platform persona reads an employer-staff sys_user row (1 of 113 each -- self only, tighter than the 83 the triage measured on 54cd69c, so the runtime's refusal to expand ats_employer.owner is correct), and both platform personas read all 30 ats_employer_member rows with names, so the mirror restates a fact that audience already holds. Defects fixed in the WIP: (1) the new column was readable to job seekers -- FLS here is a deny-list, a seeker reads the 9 verified employers and is 403 on ats_employer_member, so the WIP disclosed 12 contact names to 80 seeker accounts; sealed in JobSeekerSet like verification_note. (2) input.owner ?? prev.owner treated an explicit owner:null as absent, leaving the removed contact's name in the column (measured on the WIP); now reads previous only when the payload omits owner, and clears the mirror when the pointer is cleared. (3) the e-mail fallback lookup was dead code on a false premise -- the engine refuses a Field.user value that is not an existing sys_user id (reference_not_found, measured on an e-mail and a bogus id) and the seeder resolves its externalId before hooks run; removed, one lookup by id. CONFLICT TO FLAG: the only comment on this card argues against the mirror approach and explicitly declines to dispatch, saying the decision belongs to the maintainer. I proceeded because the dispatch relayed an off-card decision and because the measurement refutes that comment's first objection, but no on-card record of that decision exists -- the PR body opens with this so the merge decision is made on the evidence.",
"tests": "pnpm validate exit 0; pnpm lint exit 0 (514 keys both sides, en verbatim, zh-CN present); pnpm typecheck exit 0 -- exit codes captured before any pipe, re-run on the final tree. Runtime, memory + sqlite drivers, after [Seeder] Seed loading complete {inserted:818, errored:0}, every count asserted with hasMore==false and records.length==total: 12 of 12 owner_name values cross-validated against ats_employer_member.display_name (a different column, different handler, different row, seeded independently) on BOTH the name and the pointer -- never against the column itself. Browser (real Chromium, admin@platform.example): pending queue 2 records and the authored ats_employer.all 12 records, both with zero usr_ats_* strings on screen; shots in docs/evidence/issue-67/. #43 regression: PATCH {} / PATCH {city} / PATCH {verification_note} each moved 0 of 12 stamps; PATCH {owner_name} was re-derived; PATCH {owner:another} moved exactly 1; PATCH {owner:null} emptied the mirror; second boot of ONE persistent sqlite file ([Seeder] inserted:0 updated:7 skipped:811 errored:0, the claimSeedOwnership boot) reproduced 12 of 12 (name, owner, owner_name) triples identical to boot 1 with 12 distinct values, so no single SET clause was broadcast. Seal verified per persona: platform admin/ops and both employer personas read owner_name, job seeker reads 0 of 9. Seed shape unchanged: 818 rows, funnel 88/46/28/14/9, employers 12, members 30, candidates 80, on both drivers and both boots. No ablation was run: this change adds a stamp and a seal rather than a gate, and each claim is carried by a direct before/after measurement instead.",
"mcp_calls": "9 -- issue_read get, issue_read get_comments, 3 issue_write (findings), create_pull_request, 2 update_pull_request (sanitizer repair), this comment. All issue/label/duplicate READS went through the unauthenticated REST channel plus local grep; MCP was used only for writes.",
"open_questions": [
{
"question": "The maintainer decision this card was dispatched on is not recorded on the card, and the card's only comment argues the opposite. Should that decision be written onto #67 before the PR merges?",
"options": [
"A. Maintainer posts the decision on #67 (or edits the triage comment) so the record matches what shipped, then merges.",
"B. Merge as is -- the PR body carries the conflict and the measurement that resolves it.",
"C. Treat the triage comment as still binding and close the PR unmerged."
],
"recommendation": "A. The measurement disposes of the comment's disclosure objection for the platform audience, and the PR bounds the audience it did NOT dispose of, so C would discard a verified fix. But B leaves the repository's own record contradicting its code, and this card's whole history is a chain of people re-deriving the access model from scratch -- one paragraph on the card is cheaper than the next re-derivation."
},
{
"question": "The mirror fixes one column. #82 measures that every Field.user column now renders a bare id to a platform persona, including ats_candidate.user which the triage measured expanding correctly on 54cd69c. Mirroring is not available there (no second column already tells a platform reviewer those names), so this is the access-model question the triage raised, now with numbers.",
"options": [
"A. Let a platform persona resolve the users it governs (a scoped sys_user read, not a general widening).",
"B. Leave the ids and mirror per column where an audience already holds the fact -- the shape of this PR.",
"C. Do nothing until a user-facing surface complains."
],
"recommendation": "A, scoped, as the eventual answer: B does not reach ats_interview.interviewers or ats_candidate.user, and the readable set going 83 -> 1 without an issue attached is the kind of drift that gets re-discovered rather than decided. But A changes who reads sys_user, which is exactly the maintainer decision the triage refused to take for a queue item -- so #82 should be triaged, not dispatched."
}
],
"out_of_scope_findings": [
"filed as #82: every Field.user column reads as a bare id to a platform persona -- the readable sys_user set is now the caller's own row (1 of 113, was 83 at 54cd69c); ats_candidate.user, ats_interview.interviewers, ats_offer.approved_by, ats_report.reporter and ats_employer_member.user all measured unresolved; cause not traced, interval named (#38 / #79)",
"filed as #83: a platform administrator cannot create an ats_employer -- HTTP 500 ERR_SYSTEM_WRITE_ORGANIZATION_REQUIRED regardless of payload, while PlatformAdminSet declares allowCreate; the persona holds no organization membership, and the precondition surfaces as Internal server error",
"filed as #84 (finding): the record header strip truncates the last highlightFields value to Zoe Ha... at 5+ items -- second sighting, docs/evidence/issue-33 recorded the first as Pendi... / Full-ti...; shell-side layout, no app metadata controls it",
"not filed, reported here: GitHub's body sanitizer destroyed the third image embed on both of the first two writes of the PR description (once dropping the ! and injecting backtick junk into the URL, once wrapping the URL in double backticks so the img rendered with no src), and it strips a trailing attribution footer block from an edited PR body -- PR 85 now carries two inline images and two plain links, verified against body_html, and the commits carry the Claude-Session trailers"
]
}

---

Generated by Claude Code

[os-sam]

裁决记录(2026-09-08)—— 补上这条,因为上一条评论说的是相反的话

上一条评论(我写的)的结论是「⛔ 不派发,这改的是谁能读 sys_user,属于维护者决定」。维护者已经就此做了决定,方向和那条评论的分析一致,但结论不同 —— 决定是「按最小投影做,现在就做」。 决定发生在对话里,没有落到卡上,PR #85 的作者发现了这个矛盾并在报告里点了出来。他是对的:仓库的记录不该和仓库的代码互相打架。

决定的内容

1. ⛔ 不放开 sys_user 通读。上一条评论的这一半原样成立,而且现在更硬:实测平台管理员可读的 sys_user 从 83 行掉到 1 行(只剩自己),所以 ats_employer.owner 的 expand 被拒绝是正确行为,不是渲染缺陷。
2. ✅ 在雇主记录上做最小联系人投影,沿用这个仓库自己已有的模式(ats_employer_member.display_name 是先例)。
3. 正当性的全部依据是:同一批姓名,平台受众已经通过 ats_employer_member 持有(30 行全可读,两个驱动都验过)。所以镜像投影的是该受众已经拿到的事实,不是新的信息披露 —— 这也是为什么只投影姓名:工作邮箱和电话今天不对平台受众开放,把它们复制过来就会是"披着渲染修复外衣的新披露"。

上一条评论里被推翻的部分

它说「给 UserCellRenderer 加解析器也修不了,因为客户端取数会撞同一堵墙」—— 这一半仍然对。但它由此得出「所以这是访问模型问题,不该当队列项做」,这一步跳过了第三条路:信息已经在另一个对象上,只需要把两条路对齐,不需要动任何授权。#85 走的就是第三条路,src/security/permission-sets.ts 里只增加了一处封禁(对求职者遮蔽),没有放开任何东西。

仍然是维护者的、没有被这张卡解决的

ats_candidate.user、ats_interview.interviewers、ats_offer.approved_by 这些 Field.user 列同样渲染成裸 id,而它们没有一个"该受众已经持有"的第二列可以镜像 —— 镜像这条路到不了那里。那才是上一条评论说的访问模型问题,现在带着数字记在 #82。⛔ #82 该被三方裁决,不该被派发。

---

Generated by Claude Code