-
Notifications
You must be signed in to change notification settings - Fork 897
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
Ability to reset settings to default value and delete newly added keys #17482
Conversation
f24c42b
to
8a3fc77
Compare
4a1c87a
to
108c99c
Compare
If <<reset>> word passed as value for node or leaf than that node or leaf deleted for selected resource. If <<reset_all> passed that leaf/node deleted for all resorces. Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1576984
108c99c
to
5d1861e
Compare
lib/vmdb/settings.rb
Outdated
hash.each do |key, value| | ||
key_path = path.dup << key | ||
yield key, value, key_path, hash | ||
walk_hash(value, key_path, &block) if value&.class == hash.class |
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.
Won't hash.class
just always be Hash
? Also do we want to recurse into something like an array of hashes? I think this would fail in that case.
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.
@carbonin it is always Hash
, will change.
Array of Hashes would be OK, I am adding another rspec test for it ...
lib/vmdb/settings.rb
Outdated
_log.info("removing custom settings #{delta[:key]} on #{resource.class} id:#{resource.id}") | ||
resource.settings_changes.where("key LIKE ?", "#{delta[:key]}%").destroy_all | ||
when DELETE_ALL_COMMAND | ||
_log.info("resetting #{delta[:key]} to defaul for all resorces") |
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.
Typo s/defaul/default/
lib/vmdb/settings.rb
Outdated
end | ||
private_class_method :process_magic_value | ||
|
||
def self.walk_hash(hash, path = [], &block) |
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'm not sure I understand why we are keeping track of this path
parameter here.
We are yielding it and passing it along into the next level of recursion, but don't use it in the block in .remove_magic_values
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.
you are right, we do not need it here if we are ignoring Arrays
I was thinking to process Arrays too (as in SettingsWalker
from were this method was copied), but could not find example in our settings.yml
and decided not top do so.
Removing it ...
@Fryguy should we accommodate resetting nested Hash as an element of Array in Settings
?
@@ -21,6 +22,11 @@ def initialize(errors) | |||
PASSWORD_FIELDS = Vmdb::SettingsWalker::PASSWORD_FIELDS | |||
DUMP_LOG_FILE = Rails.root.join("log/last_settings.txt").freeze | |||
|
|||
# RESET_COMMAND remove record for selected key and specific resource | |||
# RESET_ALL_COMMAND remove all records for selected key and all resources |
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 these should match the name of the constant, right? DELETE_COMMAND
and DELETE_ALL_COMMAND
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.
👍
lib/vmdb/settings.rb
Outdated
return false unless MAGIC_VALUES.include?(delta[:value]) | ||
case delta[:value] | ||
when DELETE_COMMAND | ||
_log.info("removing custom settings #{delta[:key]} on #{resource.class} id:#{resource.id}") |
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 should read resetting ...
to be consistent with <reset_all>
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.
ok
Checked commits yrudman/manageiq@9888390~...c68a4fe with ruby 2.3.3, rubocop 0.52.1, haml-lint 0.20.0, and yamllint 1.10.0 |
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.
LGTM 👍
# RESET_COMMAND remove record for selected key and specific resource | ||
# RESET_ALL_COMMAND remove all records for selected key and all resources | ||
MAGIC_VALUES = [RESET_COMMAND = "<<reset>>".freeze, | ||
RESET_ALL_COMMAND = "<<reset_all>>".freeze].freeze |
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.
private_class_method :process_magic_value | ||
|
||
def self.walk_hash(hash, &block) | ||
hash.each do |key, value| |
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.
Prefer using the existing walk method, which already handles this. Even so, I don't think Iike this manual thing at all, A reset is really just taking the parent's value at that level and replacing it. Then, let the differ handle the rest.
@yrudman Sorry it took me a while to review this, but the general approach is wrong, IMO. Resetting to default is equivalent to settings the values specifically to the parent value. We already have logic for walking a hash and we have logic for dealing with applying changes when the user re-specifies the default. So, I think that it should be implement as a walk to find magic values, and then just replacing that section with the parent's corresponding values. |
I am going to merge this for now, to get the feature moving, but I'll make a follow up PR to clean up the approach |
@yrudman I started writing the fixup PR for this, and it's pretty straight forward, but the reset_all doesn't work as I expected. What are you expecting it to do when someone sends |
@Fryguy |
Current implementation of
Settings
does not allow to reset value to default or delete new entries.Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1576984
This PR introduced "magic" words:
<<reset>>
- if this word set as value than key/value deleted fromsettings_changes
table, which effectively set that value to default (default value loaded fromsettings.yaml
.To reset all subtrees down from some node: delete all subtree in UI editor and make that node a leaf with value
<<reset>>>
<<reset_all>>>
- works the same as<<reset>>
but on ALL resources@miq-bot add-label bug