Relation picker (MultipleRecordPicker) removes a linked record instantly on uncheck — no confirmation, no undo

[massimilianoalu-art]

Bug Description

Unchecking an already-linked record in the relation picker (the checkbox/search dropdown used to edit a ONE_TO_MANY relation, e.g. a Company's "People" column, or a Person's/Course's relation to a custom join object) removes the association immediately, with no confirmation step and no undo. This is inconsistent with the confirmation modal already added for the sibling action — deleting a related record entirely from a record's detail-page relation list (#8818, merged Dec 2024) — which explicitly cited "safety... because this action can be disruptive" as the rationale.

Steps to reproduce:

1. Open any object's table view where a ONE_TO_MANY relation is shown as a column (e.g. Company -> People).
2. Click the relation cell to open the picker.
3. Uncheck an already-checked (linked) record.

The link is severed on click, no confirmation, no way to undo from the UI.

Why this matters:

• For a simple MANY_TO_ONE reverse relation (e.g. person.company), an accidental uncheck just nulls a foreign key — recoverable, but only if someone notices and remembers the original value.
• For a relation modeled as an explicit join object (e.g. a custom many-to-many via a join record that itself carries data, like a registration date), unchecking either side can orphan the join record's own fields with no natural way to reconstruct them — effectively silent, uncorrectable data loss.
• Both cases happen from a dense table/list view, where a stray click is easy and the consequence isn't visually obvious.

Environment: self-hosted, twentycrm/twenty:v2.32.0.

Expected behavior

Unchecking an already-linked record should prompt for confirmation before the association is actually removed, the same way #8818 gated the "delete related record" trash-icon action.

Technical inputs

MultipleRecordPicker/SingleRecordPicker (object-record module) appear to be the shared components behind this picker across several contexts (relation editing, filter drilldown, etc.), so a fix likely needs to scope the confirmation specifically to "removing an already-selected relation," not filter-picker usage.

[twenty-eng-sync[bot]]

Kind: Probably a feature request. The picker currently unlinks a selected relation immediately, while the report requests a new confirmation or undo safeguard.
Severity: UNDEFINED because this is a requested safety/UX capability rather than a malfunction of the documented picker behavior.
Root-cause hypothesis (medium confidence): packages/twenty-front/src/modules/object-record/record-picker/multiple-record-picker/components/MultipleRecordPickerMenuItems.tsx forwards every selection change directly to onChange; MultipleRecordPicker.tsx exposes no relation-removal context or confirmation stage.
The report includes clear reproduction steps and version information; only a screenshot or recording is absent.

[sonarly[bot]]

🟠 Sonarly Analysis — High Severity

Unconfirmed relation removal in MultipleRecordPicker

Unchecking a selected relation immediately persists a destructive unlink. For junction relations, the associated junction record and its stored fields are deleted without confirmation or undo.

Root Cause

The relation picker treats every checkbox change as an immediate persistence event instead of a draft change requiring confirmation.

MultipleRecordPickerMenuItemContent.handleSelectChange emits a RecordPickerPickableMorphItem as soon as the checkbox or keyboard selection changes, including isSelected: false when an existing relation is unchecked [ref:packages/twenty-front/src/modules/object-record/record-picker/multiple-record-picker/components/MultipleRecordPickerMenuItemContent.tsx:52-81]. MultipleRecordPickerMenuItems then updates picker state and immediately forwards that item to the parent through onChange [ref:packages/twenty-front/src/modules/object-record/record-picker/multiple-record-picker/components/MultipleRecordPickerMenuItems.tsx:50-105].

The picker’s onSubmit callback only closes or resets the picker; it is not a persistence boundary and there is no pending-change or confirmation state [ref:packages/twenty-front/src/modules/object-record/record-picker/multiple-record-picker/components/MultipleRecordPicker.tsx:27-95].

For ordinary one-to-many relations, RelationOneToManyFieldInput forwards the picker event directly to updateRelation [ref:packages/twenty-front/src/modules/object-record/record-field/ui/meta-types/input/components/RelationOneToManyFieldInput.tsx:315-333]. When isSelected is false, useUpdateRelationOneToManyFieldInput calls recordOneToManyFieldDetachTargetRecord [ref:packages/twenty-front/src/modules/object-record/record-field/ui/meta-types/input/hooks/useUpdateRelationOneToManyFieldInput.tsx:80-100]. That detach helper removes the target from the Apollo cache and persists a null foreign-key relation through updateOneRecord [ref:packages/twenty-front/src/modules/object-record/hooks/useRecordOneToManyFieldDetachTargetRecord.ts:60-91].

For explicit junction relations, the same picker callback reaches useUpdateJunctionRelationFromCell; its unchecked branch finds the junction record and calls deleteJunctionRecord before removing it from local state [ref:packages/twenty-front/src/modules/object-record/record-field/ui/hooks/useUpdateJunctionRelationFromCell.ts:108-157]. This deletes the junction record itself, including any fields stored on that record.

The existing ConfirmationModal is scoped to the separate detail-page Delete action, not to picker checkbox changes [ref:packages/twenty-front/src/modules/object-record/record-field-list/record-detail-section/relation/components/RecordDetailRelationRecordsListItem.tsx:192-198,280-292]. No confirmation, plan gate, permission gate, or intentional restriction exists in the shared picker path.

The triggering cause is the user interaction described in the report: an existing selected relation is unchecked. This deterministically invokes the destructive callback. The exact deployment, traffic pattern, first affected release, and data-change trigger are unknown because this issue has no observability data and the checked-out repository does not contain the reported v2.32.0 release metadata.

Blame commit: f0de6d31 by charlesBochet — Refactor MultipleObjectsPicker component (#10552)

Suggested Fix

Updated MultipleRecordPickerMenuItems so unselecting an existing relation opens a localized ConfirmationModal instead of immediately updating picker state and invoking the persistence callback. Confirming applies the removal and forwards the unchecked item to the existing relation update logic; cancelling leaves the selected state intact. The modal instance ID is scoped to the picker component instance so multiple pickers do not conflict.

---

Analyzed by Sonarly · View full analysis

[buildbynaeem]

Hi everyone! 👋 I've just opened a PR to address this here: #24665.

I implemented the suggested intercept step using the ConfirmationModal to prevent accidental unlinking. Let me know if you need any changes or adjustments during review!

[etiennejouan]

Hi @massimilianoalu-art not sure it's a bug, done on purpose. Record edition/update (unset a relation is record edition) does not have confirmation flow for other field types

[massimilianoalu-art]

Hi @etiennejouan,

thanks for looking at this, but I'd push back on "by design" here — the response conflates two very different categories of edit.

Why relation unlinking isn't like other field edits:

• Editing a text/number/date field changes a value in place, on one record. If it's a mistake, the fix is "type it back."
• Unchecking a relation is destructive to two records, not one, and depending on the relation type:
  • On a simple many-to-one, it nulls the foreign key with no trace of what it was.
  • On a relation backed by a join object (our case: a Registration linking Person↔Course), unchecking silently orphans a row that carries its own data (registration date, etc.) — gone in one click, in a dense table view, with zero visual distinction from any other checkbox interaction.

The actual inconsistency: PR #8818 already established that Twenty treats deleting a related record as dangerous enough to need a confirmation modal. Unlinking via the picker checkbox is the same category of action — severing a relationship that took deliberate effort to create — but currently gets less protection than deletion, not equal protection. The bug isn't "editing needs confirmation" as a blanket rule; it's that this one specific edit path has a materially higher blast radius than the field types it's being grouped with, and the UI gives it zero visual weight to match.

Why this isn't hypothetical for us: we ended up locking the entire object at the permission level (canUpdateObjectRecords: false) to stop this in our workspace, because field-level canUpdateFieldValue: false on the relation field doesn't block the picker either — so there's currently no scoped mitigation available short of removing update access to the whole object. That's a pretty blunt instrument for what should be a narrow, well-defined UX fix.

Could this be reopened as a feature request for a confirmation step (or an "are you sure" / undo toast) specifically on relation-picker uncheck, rather than closed outright? I see there is already a PR for that.

Thanks,
Max

[massimilianoalu-art]

@etiennejouan just to let you know that unfortunately, and I'm very sorry because I believe this project has a lot of potential, we had to switch platforms due to this issue, which I consider a showstopper. But I'd love to hear what the community thinks...

All the best,
Max