Note that this is as much a request for comments as it is a possible bug report.
I'm in the process of refactoring how TVs are rendered to the resource editing form and have come across a behavior that I wanted to confirm whether it is in fact a bug (or not): When updating a resource, any field (TVs and standard fields) that has its default value set in a form customization rule will always display that default value — even if a new value has been entered and saved.
Step to reproduce
Create a TV and a form customization (FC) rule applying to resource update that changes the TV's default value. Change a default value via this FC rule for a standard field as well.
Expected behavior
In update mode, the default value set in a the FC rule should only override other default values (in the case of those set in a TV's properties) and should only take precedence when there is no saved value in the database.
Related issue(s)/PR(s)
A future PR will address this issue if agreed it is not the desired behavior.
Environment
If I remember correctly, this behavior is long-standing and is present in 2.x and 3.x. I'm currently working in 3.0.0-alpha3.
Bug report
Summary
Note that this is as much a request for comments as it is a possible bug report.
I'm in the process of refactoring how TVs are rendered to the resource editing form and have come across a behavior that I wanted to confirm whether it is in fact a bug (or not): When updating a resource, any field (TVs and standard fields) that has its default value set in a form customization rule will always display that default value — even if a new value has been entered and saved.
Step to reproduce
Create a TV and a form customization (FC) rule applying to resource update that changes the TV's default value. Change a default value via this FC rule for a standard field as well.
Expected behavior
In update mode, the default value set in a the FC rule should only override other default values (in the case of those set in a TV's properties) and should only take precedence when there is no saved value in the database.
Related issue(s)/PR(s)
A future PR will address this issue if agreed it is not the desired behavior.
Environment
If I remember correctly, this behavior is long-standing and is present in 2.x and 3.x. I'm currently working in 3.0.0-alpha3.