Problem/Motivation

Follow up from #3095257: Option for _none is removed once a field has a value and can cause accidental data corruption,

In fact, the best action would be to show a message that the previously selected value is no longer available.

Moving to follow up as that's a nice to have but shouldn't block the parent

Steps to reproduce

TODO

Proposed resolution

TBD

Remaining tasks

TBD

User interface changes

TBD

Introduced terminology

TBD

API changes

TBD

Data model changes

TBD

Release notes snippet

Comments

smustgrave created an issue.

alexpott’s picture

alexpott
he/they
Primary language English
Location 🇪🇺🌍
commented

I dispute that this is the best action. The real problem is the other end of this - it's allowing an entity reference to be deleted when it is the only value set in a required field. At that point you make an entity invalid. It is broken until you edit it and set a value. Unfortunately solving this in core in a performant way will be nigh on impossible. The entity usage model offers some help here - but it's not a complete fix.

smustgrave’s picture

smustgrave commented

Think it's a blocker for #3095257: Option for _none is removed once a field has a value and can cause accidental data corruption ?

Can't think of a complete solution but the scenario where all values may be deleted may be low?

mstrelan’s picture

mstrelan commented

If it makes a difference, it's not necessarily only deletions. It can be caused by a change of access, such as a node being unpublished or a user account being blocked. The latter was the cause of the original issue - we had users assigned to nodes in a user reference field, and when a user left the org and was blocked the node was then assigned to some other user in the list the next time the node was saved.

alexpott’s picture

alexpott
he/they
Primary language English
Location 🇪🇺🌍
commented

I don't think this is a blocker. I'm just not sure a message is particularly worthwhile given the old value is either inaccessible or deleted. Hmmm.... actually as I write that I think the access situation does deserve a message but the deletion does not. Because with the deletion the old value is no longer possible but with access it is a different issue and changing the value possibly is not what you should be doing.