-
-
Notifications
You must be signed in to change notification settings - Fork 658
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FeatureFlag: fix changing from default value and value of default #14133
Conversation
See test results for failed build of commit 77b915a162 |
See test results for failed build of commit b2f3ec5b6c |
See test results for failed build of commit a91446c26a |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this looks good, However, could you add unit tests?
In particular, given PR #14183, it would be good to confirm this behavior for other data types.
6ef7a57
to
154a90a
Compare
if self._isSection(val) or self._isSection(curVal): | ||
# If value is a section, continue to update | ||
pass | ||
elif str(val) == str(curVal): | ||
# Check str comparison as this is what is written to the config. | ||
# If the value is unchanged, do not update | ||
# or mark the profile as dirty. | ||
return |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note: this section is the only intended change of behaviour
Fixes #14760 Fixup of #14133 Summary of the issue: When saving a config spec, validation would be skipped if the string value of the data is unchanged. This caused various issues including config values not being correctly converted to numbers from strings when validating. This caused config profiles to fail to load or save correctly. Description of user facing changes Fix up of various bugs related to user config Description of development approach Perform special handling that was introduced in #14133 for feature flags only
) Fixes #17157 Fixup of #14133 Partially reverts #15074 Summary of the issue: When saving configuration profiles, unchanged values are yet saved to a profile. Description of user facing changes Configuration profiles should become less polluted after this change. Description of development approach Restored the behavior of #14133, mostly reverting #15074. There was namely a False assumption in #15074. @seanbudd wrote: This caused various issues including config values not being correctly converted to numbers from strings when validating. In fact, the validation was not the problem here. Instead, when __getitem__ was called with checkValidity set to False, the unvalidated value was yet saved in the cache. Therefore subsequent calls of __getitem__ would always return the unvalidated cached value that would always be of the string type.
Link to issue number:
None
Summary of the issue:
Feature flags use a default option that results in a default value.
For example, for a boolean feature flag could have three options:
Default (Enabled), Enabled, Disabled
.When comparing feature flags
__eq__
is overridden such thatDefault (Enabled) == Enabled
.NVDA checks if a value has changed before marking a profile as dirty so that it is written to disk when saving the configuration.
Due to
__eq__
being overridden, NVDA does not write changes to disk if you change from the default value to the value of default.STR:
Default (Enabled)
toEnabled
Default (Enabled)
Description of user facing changes
NVDA correctly updates feature flags when changing from the default value to the value of default.
Description of development approach
When checking if a config setting has changed, compare non-sections as strings, as this is how they are written to the config profile.
Testing strategy:
Manually test STR
Unit testing has been added for
AggregatedSection
Known issues with pull request:
AggregatedSection
should be moved in a separate PR to the new module.Change log entries:
Bug fixes:
Code Review Checklist: