Renaming Options in List Type Custom Field Removes Existing Article Assignments

[keep]

Steps to reproduce the issue

• Create a custom field of type "List"
• Add some options to this list field (e.g., option name 'joomla').
• Assign this list field with the selected option to an article, saving it so it stores in #__fields_values.
• Edit the custom field, rename the existing option (e.g., change 'joomla' to 'Joomla!'), and save the changes.

Expected result

The renamed option ('Joomla!') should update for all articles that were previously assigned the original option ('joomla') in #__fields_values.

Actual result

The rename action updates the field itself, but the original assignment in #__fields_values is removed, causing the field to lose its value in the article.

Additional comments

Option modification could be quite common, for instance, when fixing typos, updating names after marriage, or making other adjustments. This issue could impact data consistency, as existing assignments of the modified field value are lost from #__fields_values, which can lead to unintended data removal in articles that depend on these custom fields.

[brianteeman]

This issue could impact data consistency, as existing assignments of the modified field value are lost from #__fields_values, which can lead to unintended data removal in articles that depend on these custom fields.

That is exactly why it works the way that it does. Imagine completing a form that has a field "no you cannot have my money" and someone changes the field to "yes I owe you a million"

[keep]

I can understand that, but what if we encounter this scenario:

A news page has multiple editors, and the articles can have several list-type attributes, such as contributors, sources, illustrators, supporters, etc. These are stored as field values.

An editor adds a new value to the "illustrator" field: Jonh Doe, and assigns it to many articles. A few days later, another editor notices the typo—it should be John Doe, not Jonh Doe. What options does he have? Should he add a new option, check all articles (we have over 5,200) to find those with "Jonh Doe" and change it? I think the editor would prefer to simply correct the existing one.

Currently, if he changes the field option, it causes data loss without any notification.

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/44411.}

[brianteeman]

If you can think of a way to address both scenarios then a solution might be able to be provided. Currently I cant think of one

[Sabine-2023]

So here we are to continue discussing this issue, formerly known as #48283
As I wrote lately:

"Hi there, and thank you for your feedback. Brian, you have a point when you say "it wouldnt make sense to keep something checked as red if the value has been changed to blue." But would it make sense if the name has been changed to green when the value is still red? This is possible now. And, moreover, it's possible to save the custom field without adding a value at all because "value" isn't mandatory.
I added a radio field with the same issues.
When you left the values empty and go to the article, the field displays only one option, in this case the last of three options."

This is messy, isn't it?

Maybe I'm wrong but as far as I understand the "value" should be "checked" or "not checked" and is added in the article.
And what sense does it make when the value in the custom field configuration can be left empty?

[Sabine-2023]

Suggestions
Change the wording:
instead of "Name" "Option Text - displayed in your item"
instead of "Value" "Unique field name for internal use, must not be empty, not changeable after saving"
Is it possible to make the value field mandatory?

[Sabine-2023]

If my suggestions are ok so far, I would write a PR for the wording.