Skip to content

fix(task): drop the shadowed assignment field group - #582

Merged
os-zhuang merged 1 commit into
mainfrom
fix/task-shadowed-field-group
Aug 1, 2026
Merged

os-zhuang merged 1 commit into
mainfrom
fix/task-shadowed-field-group

Conversation

@yinlianghui

Copy link
Copy Markdown
Collaborator

Description

#577 (issue #575, item A3) gave crm_task a fieldGroups list. One entry — assignment — has owner as its only member, and the synthesized detail page hoists owner into the highlight strip. The group therefore renders on forms and never on detail pages, which os validate reports as:

⚠ object "crm_task": every field in group "assignment" (owner) is hoisted into the
  detail highlight strip (or is the record title) — the group renders on forms but
  never on detail pages
  rule: field-group-shadowed  at objects[14].fieldGroups

main went from 4 warnings to 5 when #577 landed. This clears it.

Changes

  • Removed the assignment group; owner moves to basic, alongside subject / status / priority — where a task's assignee reads naturally anyway.
  • Left a comment recording why the group is absent, so the next person adding groups to this object doesn't reintroduce it.

crm_campaign also has an assignment group — untouched, it is a different object with several members.

Not fixed here

crm_campaign_member still trips the same rule (its entire basic group is hoisted). That one is pre-existing, predates #577, and has a different shape — the object also has no name/title field, so it needs its own think rather than being swept into this PR.

Verification

pnpm verify on a clean checkout:

  • exit code 0, 0 errors
  • warnings 5 → 4; the remaining field-group-shadowed is the crm_campaign_member one described above
  • 630 passed | 2 skipped (33 files) — unchanged

Type of Change

  • Bug fix (non-breaking change which fixes an issue)

Checklist

  • pnpm verify passes
  • Changeset added

Refs #575.

@vercel

vercel Bot commented Aug 1, 2026

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment
Project Deployment Actions Updated (UTC)
hotcrm Ignored Ignored Aug 1, 2026 1:03am

Request Review

#577 gave crm_task a fieldGroups list (#575 A3). One entry, `assignment`, has
`owner` as its only member — and the synthesized detail page hoists `owner`
into the highlight strip, so the group renders on forms and never on detail
pages. validate flagged it as `field-group-shadowed`, taking main from 4
warnings to 5.

`owner` moves into `basic` alongside subject/status/priority, which is where a
task's assignee reads naturally anyway, and the one-field group is gone.

The same warning still stands for crm_campaign_member — pre-existing, whole
`basic` group hoisted, and a different shape (that object also has no
name/title field). Left alone here.

verify: exit 0, 630 passed | 2 skipped, 5 warnings → 4.

Refs #575.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@github-actions github-actions Bot added the metadata Declarative metadata — schema, security posture, UI surfaces label Aug 1, 2026
@os-zhuang
os-zhuang merged commit 7709114 into main Aug 1, 2026
10 checks passed
yinlianghui added a commit to yinlianghui/hotcrm that referenced this pull request Aug 10, 2026
…jectstack-ai#715) (objectstack-ai#1007)

Every field in `crm_campaign_member`'s `basic` group was hoisted out of the
detail body: `member_number` is the record title, and `crm_campaign` /
`crm_lead` / `crm_contact` are the first three highlightFields. A detail page
drops the title and the leading four strip entries from the body, so the group
kept its heading on forms and rendered nowhere on detail pages — `os lint`
reported it as `field-group-shadowed`, the one such warning on main.

Fixed on the GROUP side, not the strip, and that side is forced rather than
chosen: `highlightFields` is also what curates the members panel on a campaign's
detail page (a related list falls back to the child's highlightFields minus the
lookup it is scoped by, and this object ships no view at all). Dropping the two
party lookups from the strip would have left that panel showing Status /
Response Date and no person — the degradation objectstack-ai#944 measured and
test/view-references.test.ts pins.

So `added_date` moves from `response` to `basic`, which is where it reads
anyway: it stamps when the MEMBERSHIP was created, not how the person responded.
Response Tracking keeps the lifecycle (First Opened, First Clicked, Response
Date, Has Responded). Same resolution as crm_task's shadowed `assignment` group
(objectstack-ai#582): move the field to the group it belongs to, leave the strip alone.

Guarded in test/field-groups-coverage.test.ts, which already replicates the
other two `validateSemanticRoles` rules for the same reason: `os lint` exits 0
on warnings, so nothing in `pnpm verify` fails when this one comes back.
Reverting `added_date` to `response` turns the new check red with the platform
rule's own field list.

verify: exit 0 — validate ✓, typecheck ✓, lint 13 → 12 warnings
(field-group-shadowed gone), hygiene ✓, build ✓, 1823 passed | 1 skipped.

Co-authored-by: Claude <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

metadata Declarative metadata — schema, security posture, UI surfaces

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants