Skip to content
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

Merged
merged 6 commits into from
Jun 8, 2018

Conversation

yrudman
Copy link
Contributor

@yrudman yrudman commented May 25, 2018

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 from settings_changes table, which effectively set that value to default (default value loaded from settings.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

@miq-bot miq-bot added the wip label May 25, 2018
@yrudman yrudman force-pushed the allow-delete-settings branch 9 times, most recently from 4a1c87a to 108c99c Compare June 1, 2018 13:23
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
@yrudman yrudman changed the title [WIP] Ability to reset settings to default value, delete newly added keys and set a value to nil Ability to reset settings to default value and delete newly added keys Jun 1, 2018
@miq-bot miq-bot removed the wip label Jun 1, 2018
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
Copy link
Member

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.

Copy link
Contributor Author

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 ...

_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")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Typo s/defaul/default/

end
private_class_method :process_magic_value

def self.walk_hash(hash, path = [], &block)
Copy link
Member

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

Copy link
Contributor Author

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
Copy link
Member

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

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}")
Copy link
Member

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>

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok

@miq-bot
Copy link
Member

miq-bot commented Jun 4, 2018

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
2 files checked, 0 offenses detected
Everything looks fine. 🏆

Copy link
Member

@gtanzillo gtanzillo left a 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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The definitions inside other definitions is weird, but...

private_class_method :process_magic_value

def self.walk_hash(hash, &block)
hash.each do |key, value|
Copy link
Member

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.

@Fryguy
Copy link
Member

Fryguy commented Jun 8, 2018

@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.

@Fryguy
Copy link
Member

Fryguy commented Jun 8, 2018

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

@Fryguy Fryguy merged commit 1bc038a into ManageIQ:master Jun 8, 2018
@Fryguy Fryguy added this to the Sprint 88 Ending Jun 18, 2018 milestone Jun 8, 2018
@Fryguy Fryguy added the core label Jun 8, 2018
@Fryguy
Copy link
Member

Fryguy commented Jun 8, 2018

@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 <<reset_all>> at each of the MiqServer, Zone, and MiqRegion levels? From the way you wrote the code, it literally removes everything from every region, which is just wrong. Were you trying to implement that at the zone and region it would delete all of the overrides from the children?

@yrudman
Copy link
Contributor Author

yrudman commented Jun 9, 2018

@Fryguy <<reset_all>>```` supposed to reset selected settings to values we supply (values from yml``` file).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants