Skip to content

fix: keep a persisted field's code stable when its name is renamed [3.x] - #201

Merged
ManukMinasyan merged 1 commit into
3.xfrom
fix/field-code-stable-on-rename
Aug 13, 2026
Merged

fix: keep a persisted field's code stable when its name is renamed [3.x]#201
ManukMinasyan merged 1 commit into
3.xfrom
fix/field-code-stable-on-rename

Conversation

@ManukMinasyan

Copy link
Copy Markdown
Collaborator

Problem

The name input on FieldForm derives code from name whenever the current code still matches the slug of the previous name:

if (($get('code') ?? '') !== Str::of($old)->slug('_')->toString()) {
    return;
}

$set('code', Str::of($state)->slug('_')->toString());

That heuristic is correct while a field is being created — it stops overwriting a code the user typed by hand. On a persisted field it is wrong: the code is an identity, not a label. Stored values, report columns and visibility conditions all key on it, and a field cloned onto a new form version deliberately shares its code with the original.

So renaming a field silently rewrote its code and severed it from its own data: the existing values kept the old code, and reporting then offered two unrelated columns where the user expected one renamed column.

Fix

Only derive the code while the field is being created, detected by the absence of a bound record.

This is correctly scoped across all four FieldForm::schema() consumers:

Consumer Binds a record? Behaviour
ManageCustomFieldSection::createField no derivation still runs
ManageFieldsTable create action no derivation still runs
ManageCustomField::editAction yes derivation suppressed
ManageFieldsTable::editField yes derivation suppressed

duplicateAction does not use this form — it is confirmation-only and already generates its own unique code via generateUniqueCode(), so it is unaffected.

Verification

New regression test in CustomFieldsFieldManagementTest, verified red against the previous implementation (it failed on the code assertion) and green with the fix.

  • Full package suite: 786 passed, 3 todos, 0 failures
  • PHPStan: no errors
  • Rector + Pint: clean

Downstream

This is the blocker for Padmission/journey#3427, where renaming a field on a new Flex Fund form version broke code continuity with v1 and hid the field from Custom Reports. Journey will need a version bump once this is released.

The name input derived `code` from `name` whenever the current code still
matched the slug of the previous name. That heuristic is right while a field
is being created, but on a persisted field the code is an identity rather
than a label: stored values, report columns and visibility conditions all key
on it, and a field cloned onto a new form version shares its code with the
original.

Renaming such a field therefore rewrote the code and silently severed it from
its own data — the values kept the old code, and reporting saw two unrelated
columns where the user expected one renamed column.

Only derive the code while the field is being created. Both create actions
bind no record so they are unaffected; both edit actions bind one, which is
what now suppresses the rewrite. The duplicate action does not use this form
and already generates its own unique code.
Copilot AI lite review requested due to automatic review settings August 13, 2026 11:52

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

@ManukMinasyan
ManukMinasyan merged commit a7f5855 into 3.x Aug 13, 2026
4 checks passed
@ManukMinasyan
ManukMinasyan deleted the fix/field-code-stable-on-rename branch August 13, 2026 14:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants