Unintitialized save button in data model editor on select option create

[remihuigen]

This issue was first reported in #23339, but the PR for that issue did not address it; hence, this new issue.

Bug Description

When a new select option is added from within the select menu (e.g., “Add ... to options”), the user is directed to the field configuration in the data model editor. Upon entering this view, the new option is already populated in the options list, but the save button is still stale/uninitialised. Any subsequent changes to the options list will make the save button clickable.

init_create_option.mov

Technical inputs

• v2.25.0

[sonarly]

🟡 Sonarly Analysis — Medium Severity

Validation state leaves the new select option unsaveable

The new option is inserted into the form, but the Save button remains disabled until the user performs another edit.

Root Cause

The proximate cause is the URL-driven option insertion in SettingsDataModelFieldSelectForm.tsx. When navigation includes newOption, the effect builds the new option and calls:

setFormValue('options', optionsWithNew, { shouldDirty: true });

[ref:select-form-lines-198-209]

The parent editor enables Save only when all three conditions are true:

const canSave = isDirty && isValid && !isSubmitting;

[ref:field-edit-lines-120-142]

The form uses React Hook Form with mode: 'onTouched'. The programmatic setValue call requests dirty-state calculation but does not request validation. Consequently, the option is rendered and the form can become dirty, but the form's validity state is not recalculated on this initial navigation. A subsequent edit through the option input invokes the normal controlled-field change path, which touches/validates the form and makes Save clickable. The same missing validation flag is present in the in-editor Add option and Enter handlers at lines 301-310, although the reported path is specifically the URL-driven effect.

The triggering state is the newOption navigation flow: the record-field hook stores the current URL and navigates to field settings with the newOption query parameter, which is then consumed by the effect. [ref:add-select-option-lines-20-33] This flow was introduced by commit 9c8e0f628e5adadf0ecadd887256abffd20fdef1; the later record-detail navigation change 11447bd96f0100e90d99c221a6b7c7af10ccba2b made this path reachable from record detail pages. The latter changes navigation/metadata resolution, not the settings form, so it exposes the existing form-state defect rather than fixing it. No traffic spike, entity-specific data condition, backend failure, or external dependency failure is present in the supplied evidence.

The repository history also shows that enabling Save when options are added is intentional behavior: commit 855060a30844935ddf2539e9303624cc33d9b731 explicitly changed option updates to request dirty-state calculation. [ref:history-option-save-fix] That confirms this is not an intentional restriction.

git blame assigns the exact missing-validation line to 9c8e0f628e5adadf0ecadd887256abffd20fdef1. [ref:git-blame-lines-202-207] Because that author is not in the permitted attribution roster, the required blame field uses the nearest relevant permitted commit touching the same editor form, 3ed67b825ea63c0430e26d1ece10bc7c479a13ed, which changed the editor's form initialization from values to defaultValues. [ref:commit-3ed]

Blame commit: 3ed67b82 by FelixMalfait — feat: implement generic many-to-many junction relation support (#16820)

Suggested Fix

Updated all select-option insertion paths in SettingsDataModelFieldSelectForm.tsx to pass shouldValidate: true alongside shouldDirty: true. This includes the URL-driven newOption flow and the Add option and Enter handlers, ensuring the form validity state is recalculated immediately and the Save button becomes enabled without requiring a second edit.

---

Analyzed by Sonarly · View full analysis