#19978: View manifest sync: `shouldHideEmptyGroups` and `anyFieldFilterValue` are not propagated from `ViewManifest`

Context

This issue is a follow-up to #19946, where five view fields (mainGroupByFieldMetadataUniversalIdentifier, kanbanAggregateOperation, kanbanAggregateOperationFieldMetadataUniversalIdentifier, calendarLayout, calendarFieldMetadataUniversalIdentifier) were being hardcoded to null inside fromViewManifestToUniversalFlatView and added to ViewManifest.

While fixing that, a review question surfaced: are there more missing fields? After auditing every view-related manifest → universal-flat-entity converter, the answer is yes for the top-level View converter, no for the six sub-entity converters.

Gaps found on the View converter

Audit scope: compare ViewManifest (packages/twenty-shared/src/application/viewManifestType.ts) against ViewEntity (packages/twenty-server/src/engine/metadata-modules/view/entities/view.entity.ts) and CreateViewInput (packages/twenty-server/src/engine/metadata-modules/view/dtos/inputs/create-view.input.ts).

Two fields are present on the entity and accepted by the GraphQL input DTO, but are hardcoded to a default inside fromViewManifestToUniversalFlatView and are not declared on the ViewManifest type — so SDK consumers cannot set them via an app manifest:

These are the same category of bug as the five fields fixed in #19946 — the converter silently drops a user-provided value.

Impact

• An app manifest that declares a Kanban/table view with shouldHideEmptyGroups: true will be installed with shouldHideEmptyGroups: false (no error, silent data loss).
• An app manifest that declares a view with an anyFieldFilterValue cannot persist that value at all.
• Lower severity than #19946 (no check-constraint / validation failure), but still a silent discrepancy between what the SDK author writes and what lands in the workspace.

Proposed fix

1. Add the two fields to ViewManifest in packages/twenty-shared/src/application/viewManifestType.ts:

   shouldHideEmptyGroups?: boolean;
   anyFieldFilterValue?: string | null;
   

2. Update fromViewManifestToUniversalFlatView to read from the manifest with the same ?? default pattern used by the five fields in #19946:

   shouldHideEmptyGroups: viewManifest.shouldHideEmptyGroups ?? false,
   anyFieldFilterValue: viewManifest.anyFieldFilterValue ?? null,
   

3. Extend from-view-manifest-to-universal-flat-view.util.spec.ts with preservation + default cases for both, mirroring the Kanban/Calendar tests added in #19946.

Audit of the sibling converters (no gaps found)

For completeness, the following converters were also audited. Each one already propagates every field declared on its respective manifest type to the universal-flat type:

• from-view-field-manifest-to-universal-flat-view-field.util.ts — complete.
• from-view-filter-manifest-to-universal-flat-view-filter.util.ts — complete.
• from-view-filter-group-manifest-to-universal-flat-view-filter-group.util.ts — complete.
• from-view-group-manifest-to-universal-flat-view-group.util.ts — complete.
• from-view-sort-manifest-to-universal-flat-view-sort.util.ts — complete.
• from-view-field-group-manifest-to-universal-flat-view-field-group.util.ts — complete.

So the remediation can be scoped strictly to the top-level View converter and type.

References

• PR #19946 — fixed the Kanban/Calendar hardcoded-null gap.
• File: packages/twenty-server/src/engine/core-modules/application/application-manifest/converters/from-view-manifest-to-universal-flat-view.util.ts
• File: packages/twenty-shared/src/application/viewManifestType.ts