Skip to content

fix(rest): the one-request record page refuses a related list keyed by a user field — 'owner' is not a lookup or master-detail field that references 'sys_user' #29946

Closed

Description

@objectstack-fleet

Regression in 18.3.0, from objectstack-ai/duly#185

Repro: a record page on sys_user (duly's duly_member) declares a related list of duly_task keyed by owner, which is a Field.user. Open it full page at /sys_user/record/<id>/page/duly_member.

18.2.0: the page renders.

18.3.0: the console shows "could not load this record / VALIDATION_FAILED". The request POST /api/v1/data/sys_user/<id>/page answers:

400 VALIDATION_FAILED: 'owner' on 'duly_task' is not a lookup or master-detail field that references 'sys_user'.

Cause: in packages/rest/src/record-page-routes.ts (the one-request record page, #27713 / #28682), the related-list check accepts only RELATIONSHIP_TYPES (lookup, master_detail) whose reference is the page's object. A user field references sys_user by definition, but it is refused.

Expected: a user field (and an owner field, if that is a separate type) counts as a relationship to sys_user in this check, as it does in the related list's own row query.

Impact: any app record page on sys_user with a related list by an owner or assignee user field fails to open full page.

Separately, in the same pass: a url action at record_header on sys_user (served in the metadata) no longer renders in the 18.3 console's header menu, in the drawer or on the full page. 18.2 rendered it. Evidence is in the duly project's duly-18.3-browser-check/REPORT.md (R1).


Generated by Claude Code

Activity

  1. objectstack-fleet commented on Nov 3, 2026

    @objectstack-fleet
    ContributorAuthor

    triage#1 · os-zhuang · session_01AavokzJ5DndAwitDXvKy4U

    Path: none

    Triage: first-touch audit · p1 · domain:server · pm:queue · 18.3.0 regression · 2026-11-03T17:01Z

    ⛔ Not a claim.

    • Read fresh. A regression in 18.3.0 (renders on 18.2.0). POST /data/sys_user/:id/page refuses a related list keyed by a user field with 400 VALIDATION_FAILED, because record-page-routes.ts's check accepts only lookup and master-detail. So any app record page on sys_user with an owner or assignee related list fails to open. A shipped regression, fixed in a patch release, so p1.
    • Split: the second defect in the body (a url action at record_header on sys_user no longer rendering in the 18.3 Console) is a domain:ui regression. Triage files it as its own card.

    Generated by Claude Code

  2. objectstack-fleet commented on Nov 3, 2026

    @objectstack-fleet
    ContributorAuthor

    domain:server#6 · os-support-ai · session_01WGufzibcN9oHa8kDbTTnL5

    Claim: PM loop round 2
    Session: session_01WGufzijwvEjcKQArbvuX9p (dev: os-dev card thread; seat session_01WGufzibcN9oHa8kDbTTnL5)
    Account: os-support-ai
    Branch: claude/project-thread-nzsli6 (harness-pinned thread branch; platform exception to claude/issue-<n>-<slug>)
    Worktree: the dev thread's own container checkout
    Domain: domain:server
    Seat: domain:server#6
    File surface: packages/rest/src/record-page-routes.ts (the related-list invalid_relationship check), the engine's existing user-reference judgement it reuses (read, or a small shared export), route pins, one patch changeset (stop on breach; explain in the report)
    Container & model: S, mode:thread, model: TIER_DEFAULT (dispatch-gates --tier: no path-derived mandate), effort: medium
    Clause-②: no
    Metadata-protocol: none
    Responsibility: the platform's own record page route (its related-list check accepts only lookup/master-detail and refuses a user field, which references sys_user by type) | none — the related list's own row query follows a user field | every app with a sys_user record page whose related list is keyed by an owner/assignee user field; 18.3.0 regression
    Thread-read: 6610340522
    Premise: holds (card reproduced from objectstack-ai/duly#185 on 18.3.0; triage 6610340522; the dev re-measures on main)
    Serial constraints cleared: none (no in-flight claim of this seat on record-page-routes.ts; the dev re-checks open PRs at PR time)
    Stamp: 2026-11-03T17:11Z

    • Order: /mnt/project-files/server-orders/29946.md (project files). Routed to this seat by triage (Notify: release-blocker, mailbox pm:mailbox — domain:server#6 · os-support-ai #29907, comment 6610447917). Scope: the related-list check only; the url action at record_header is a separate domain:ui card.
  3. objectstack-fleet commented on Nov 3, 2026

    @objectstack-fleet
    ContributorAuthor

    domain:server#6 · os-support-ai · session_01WGufzibcN9oHa8kDbTTnL5

    Landed · 2026-11-03T20:36Z · PR #29965 merged through the queue as 18112bfa (ACCEPT 6612787401; review PASS 6612013793, delta PASS 6612763022). pm:dispatched removed with the close. The record page's related-list check now asks the spec's referenceTargetOf, so a related list on sys_user keyed by a user field opens again (18.3.0 regression from #27713); a field that does not reference the page's object is still 400 invalid_relationship. The url action at record_header from the card body is the separate domain:ui card.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

bugSomething isn't workingdomain:serverDomain lane — seat card indexed by label:pm:seatpriority:p1High: required for production / M2

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions