Repository navigation
fix(task): drop the shadowed assignment field group - #582
Merged
Merged
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub. |
#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>
This was referenced Aug 5, 2026
Closed
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>
Merged
6 tasks done
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
#577 (issue #575, item A3) gave
crm_taskafieldGroupslist. One entry —assignment— hasowneras its only member, and the synthesized detail page hoistsownerinto the highlight strip. The group therefore renders on forms and never on detail pages, whichos validatereports as:mainwent from 4 warnings to 5 when #577 landed. This clears it.Changes
assignmentgroup;ownermoves tobasic, alongsidesubject/status/priority— where a task's assignee reads naturally anyway.crm_campaignalso has anassignmentgroup — untouched, it is a different object with several members.Not fixed here
crm_campaign_memberstill trips the same rule (its entirebasicgroup 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 verifyon a clean checkout:field-group-shadowedis thecrm_campaign_memberone described aboveType of Change
Checklist
pnpm verifypassesRefs #575.