Hello Everybody,
Yesterday I applied a fix to the configuration editor that on the surface looks harmless
but changes across the board the way default values are applied to fields on unset
updates.
The original behaviour was very confusing and unintuitive. Here is the behaviour and what
was confusing to me:
1) On initial configuration editor load
a) if a field was unset, then the default value was loaded the form field but the actual
field was disabled.
The problem: the field was disabled and unset checked, however there is a value in thr
form field that cannot edited or cleared. This can give the wrong impression that unset
fields automatically get the default value when saved. If a user really gets confused
about that value being there but greyed out then there is no way for a user clear that
value without changing the value of unset twice, see 3) and 4) below.
2) When the user changes the unset state from true to false for the first time:
a) the form field was enabled for editing
b) since the default value was already there from the initial load, that default value
would still be selected
c) the form could not be saved because the changed event was not fired by the code
The problem: the default value is there (and selected for properties with options) but the
user will need to update the field before the configuration can be saved. As an example,
for fields with options, the user will have to select another value and then reselect the
default value before they can save the configuration with the default value for property
with options. This is all because internally the code does not fire the event that the
form changed.
3) When the user changed the unset state from false to true:
a) the value of the field was cleared
b) the field was disabled
No problem! This is the only case where the behaviour is intuitive.
4) When the user changed the unset state from true to false for third, fourth, fifth, ...
time on the same field:
a) the form field was enabled for editing
b) the form field would be empty or no value selected for fields with options, since the
value was cleared in 3)
c) the user would need to read the field description and type or select the default
value, if the default value is even mentioned in the field description.
The problem: This contradicts 2) where the default value was in the field. So, the user
will see the default value for the first time but not for subsequent times. If the default
value is set for the field but not in the description, the user will have absolutely no
way to find that out after the initial unset change since the default value is not
displayed in the UI.
To fix this, I changed the way default values are applied to properties to give a natural
user experience. As you can see even explaining this new behaviour is more concise. Here
is how this works after the update:
1) On load, if the field is unset then disable field and set value to null.
2) On load, if the field is set then enable field and load saved value.
3) On unset change from true to false, enable field and load default value if not null.
Enable save button.
4) On unset change from false to true, disable field and set value to null. Enable save
button.
All this work was triggered by BZ 851186 which was reported against the AS7 plugin.
However this problem was applicable to every single screen with a configuration editor. As
you can see from the bug description, the original behaviour was very confusing even to
the reporter. Here is the BZ for reference:
https://bugzilla.redhat.com/show_bug.cgi?id=851186
Any thoughts? Is the new behaviour intuitive enough?
Thank you,
Stefan Negrea
Software Engineer