Set fields created in the future as "visible" doesn't work

[Bonapara]

Bug Description

Newly created fields are not added to the fields widget, regardless of the "Set fields created in the future as visible" setting

Source Discord thread: https://discord.com/channels/1130383047699738754/1507963594137145386

[Bonapara]

@Weiko do you think you can have a look?

[sonarly]

🟡 Sonarly Analysis — Medium Severity

Fields widget defaults hide custom object fields

Custom object record pages can show only system fields by default, making user-defined fields appear missing. Users can recover manually via layout edit, but default UX is misleading.

Root Cause

The failure is in the custom object record-page scaffolding path on the server:

1. New custom object Fields widget is created without newFieldDefaultVisibility

• In compute-flat-default-record-page-layout-to-create.util.ts, the FIELDS widget configuration sets only:
  • configurationType: FIELDS
  • viewId / viewUniversalIdentifier
    and does not set newFieldDefaultVisibility.
• But auto-addition of future fields depends on this flag being defined:
  • compute-flat-view-fields-from-fields-widgets.util.ts filters matching widgets with:
    isDefined(widget.configuration.newFieldDefaultVisibility).
  • If undefined, newly created fields are never auto-inserted into the FIELDS_WIDGET view.
• Result: users add fields later, but they do not appear in the Fields widget by default.

2. Initial record-page fields for custom objects exclude key fields

• During custom object creation (object-metadata.service.ts), record-page view fields are generated via computeFlatViewFieldsToCreate(..., excludeLabelIdentifier: true).
• In compute-flat-view-fields-to-create.util.ts, this creation also excludes RELATION and MORPH_RELATION.
• Combined effect:
  • label field is removed from initial FIELDS_WIDGET view,
  • relation fields are not created in that view,
  • if no other scalar custom fields are pre-seeded, what remains visible are mostly system fields (e.g., created/updated by/at), matching the reported “only 4 system fields”.

Why it failed now:

• The rollout that made record-page layout behavior broadly active in this codepath (feature-flag removal for record-page layout) exposed this default configuration/data-shape to all relevant workspaces in current releases.
• Once users create/select custom objects under this path, they hit the missing default visibility behavior immediately; this is a state/configuration trigger (layout/view-field initialization), not a transient runtime error.

This is not “working as designed” from product intent:

• Standard-app FIELDS widget scaffolding explicitly sets newFieldDefaultVisibility: true, indicating intended default behavior differs from this custom-object path.

Blame commit: 04eb9135 by charlesBochet — chore(page-layout): remove IS_RECORD_PAGE_LAYOUT_* feature flags (#20556)

Suggested Fix

Implemented a focused backend fix so new custom object record pages no longer default to a misleading “system fields only” state.

1. Fixed custom record-page FIELDS widget defaults:

• Updated computeFlatDefaultRecordPageLayoutToCreate to set newFieldDefaultVisibility: true on both:
  • configuration (flat/runtime config with viewId)
  • universalConfiguration (universal config with viewUniversalIdentifier)
    This aligns custom-object scaffolding with the standard-app FIELDS widget behavior and unblocks automatic insertion of newly created fields into record-page fields views.

2. Fixed initial record-page field seeding for custom object creation:

• Updated ObjectMetadataService.createOneObject to stop passing excludeLabelIdentifier: true when computing record-page view fields.
  This ensures the label field is included in the initial fields widget view instead of being hidden by default.

3. Added regression coverage:

• Added a new unit test validating that the generated record-page FIELDS widget includes newFieldDefaultVisibility: true in both flat and universal configurations.

I also checked recent commits in the last 30 days on affected files (git log --all --oneline --since='30 days ago' -- ...) and did not find an existing commit that already implemented this exact fix path.

---

Analyzed by Sonarly · View full analysis