Files
twenty/packages
Abdul Rahman 5effee7754 Fix grouping a view that can no longer be changed or removed (#23619)
Fixes #23529


https://github.com/user-attachments/assets/2dbcf5ac-9b2e-4331-b7e8-703c8c5384b5



Grouping People by Company was a one-way door: once the view was
grouped, the grouping could neither be changed nor removed. Two
independent bugs on the same path caused it, and both had to be fixed.

## 1. The Group by entry was disabled, so the picker was unreachable

`ObjectOptionsDropdownRecordGroupsContent` disabled the `Group by` entry
whenever the object had a single groupable field. People exposes exactly
one (Company), so the entry was always disabled there.

That entry is the only way back to the field picker once a view is
grouped: `ObjectOptionsDropdownCustomView` sends `Group` to the picker
while the view is ungrouped, and to the group management screen once it
is grouped. With the entry disabled, the picker, and with it the `None`
option, became unreachable.

A table view can always drop its grouping through `None`, so the entry
now stays enabled there and is only disabled for layouts that require a
grouping.

## 2. The view groups created by the server were never synced back

The server deletes and recreates the view groups whenever
`mainGroupByFieldMetadataId` changes (`handleFlatViewUpdateSideEffect`),
and returns them in the `updateView` payload. `usePerformViewAPIUpdate`
only wrote the view itself back to the metadata store, so the
`viewGroups` entity kept the pre-change rows. The view create path
already syncs them; the update path did not.

On top of that, `useHandleRecordGroupField` overwrote the groups
returned by the mutation with client-generated ones whose ids matched no
persisted row, and `resetRecordGroupField` bailed out on
`viewGroups.length === 0`. Since a relation grouping legitimately starts
with no groups, clicking `None` was a no-op even when it could be
reached.

- sync the view groups returned by `updateView` into the metadata store
- use those groups instead of regenerating them client-side
- reset the grouping based on `mainGroupByFieldMetadataId`, and reload
the record index states so the table regroups and ungroups without a
refresh

## 3. Drive-by: No Value missing from the widget draft preview

`buildDraftViewGroupsForFieldMetadataItem` mirrors
`computeFlatViewGroupsOnViewCreate` so the page layout widget preview
matches what gets persisted, but it returned early for relation fields
and skipped the empty group. The server keeps creating it for nullable
fields, relations included, so the group appeared out of nowhere once
the widget was saved. It now skips only the option groups and keeps the
empty group.

## Not changed

Grouping by a relation shows no groups until you add them through `New
group`. That is intended, since a relation can have an unbounded number
of groups, and nothing here changes it.
2026-08-05 09:39:18 +00:00
..