Bug 1576984 - [RFE] Advanced settings - ability to reset to default value, delete newly added keys
Summary: [RFE] Advanced settings - ability to reset to default value, delete newly add...
Alias: None
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Appliance
Version: 5.10.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: GA
: 5.10.0
Assignee: Yuri Rudman
QA Contact: Tasos Papaioannou
: 1358433 1358448 1444048 (view as bug list)
Depends On:
Blocks: 1353301 1358448 1592929
TreeView+ depends on / blocked
Reported: 2018-05-10 22:07 UTC by Gregg Tanzillo
Modified: 2021-06-10 16:08 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1592929 (view as bug list)
Last Closed: 2019-02-07 23:02:11 UTC
Category: ---
Cloudforms Team: ---
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2019:0212 0 None None None 2019-02-07 23:02:18 UTC

Description Gregg Tanzillo 2018-05-10 22:07:40 UTC
Description of problem:

Currently it is impossible to reset a setting that had been previously updated back to the original, default value.

Additionally, it is not possible to delete a setting that was added with new key and value.

Lastly, it is not possible to set a value of nil for any key

Additional info:

See related BZs


Comment 2 Gregg Tanzillo 2018-05-10 22:13:41 UTC
One idea to do this in a simple way with the current advanced settings UI would be to support "magic keywords" as values that could indicate how a setting should be saved.

For example-

A value of [default] would instruct the model to delete the existing "setting_changes" row for that key which would result in making the default values (from settings.yml) be the current value. If the key was not one of the out of the box settings it would result in deleting the key and value altogether.

A values of [nil] would force saving a literal nil as the value.

Comment 3 Dave Johnson 2018-05-10 22:43:38 UTC
Please assess the impact of this issue and update the severity accordingly.  Please refer to https://bugzilla.redhat.com/page.cgi?id=fields.html#bug_severity for a reminder on each severity's definition.

If it's something like a tracker bug where it doesn't matter, please set the severity to Low.

Comment 5 Yuri Rudman 2018-06-01 14:39:49 UTC
Above PR addressed deleting nodes and values.
Setting value to nil - I would suggest to track it separately

Comment 6 CFME Bot 2018-06-08 20:06:38 UTC
New commit detected on ManageIQ/manageiq/master:

commit 5d1861e6f0effd4ca05129b0acccda70a5dfa0f3
Author:     Yuri Rudman <yrudman@redhat.com>
AuthorDate: Fri Jun  1 10:16:01 2018 -0400
Commit:     Yuri Rudman <yrudman@redhat.com>
CommitDate: Fri Jun  1 10:16:01 2018 -0400

    add magic words <<reset>>, <<rest_all>>.
    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

 lib/vmdb/settings.rb | 39 +-
 1 file changed, 38 insertions(+), 1 deletion(-)

Comment 7 Jason Frey 2018-06-09 00:02:23 UTC
I don't understand the reset_all piece of this and I would like to get more clarity before moving this forward.

Comment 9 Jason Frey 2018-06-19 15:20:56 UTC
Updated the BZ title to reflect what is actually being changes.  Only the <<reset>> functionality will be implemented, which handles both the "inherit" from Zone or Region case, as well as the "delete" a newly added key case.

I will open a separate BZ for an <<enforce>> keyword which would be used to "push down" overrides to child resources.

Comment 10 CFME Bot 2018-06-26 13:51:41 UTC
New commit detected on ManageIQ/manageiq/master:

commit 72b7ec50997f210242fb583771b5e98066efb199
Author:     Jason Frey <jfrey@redhat.com>
AuthorDate: Tue Jun 19 10:44:21 2018 -0400
Commit:     Jason Frey <jfrey@redhat.com>
CommitDate: Tue Jun 19 10:44:21 2018 -0400

    Remove <<reset_all>> magic value from Settings

    The user expectations around <<reset_all>> are too complicated, and so
    this is being removed.  In doing so, the logic for <<reset>> has been
    greatly simplified.

    A different keyword is expected to implemented in a separate PR to deal
    with enforcing a setting at the Region or Zone level and pushing that
    value down to the child resources.  (This is not how <<reset_all>>
    presently works, but that is a feature we expect to need)


 lib/vmdb/settings.rb | 59 +-
 spec/lib/vmdb/settings_spec.rb | 127 +-
 2 files changed, 91 insertions(+), 95 deletions(-)

Comment 11 Jason Frey 2018-06-27 18:47:28 UTC
Opened https://github.com/ManageIQ/manageiq-ui-classic/pull/4224 to discuss presentation of the new <<reset>> keyword to the user.

Comment 12 CFME Bot 2018-07-02 06:03:11 UTC
New commit detected on ManageIQ/manageiq-ui-classic/master:

commit 3c5fe03a8cb291f6f9cb43ee2fbfba73b0299c3a
Author:     Jason Frey <fryguy9@gmail.com>
AuthorDate: Wed Jun 27 14:40:23 2018 -0400
Commit:     Jason Frey <fryguy9@gmail.com>
CommitDate: Wed Jun 27 14:40:23 2018 -0400

    Add guidance text for new <<reset>> magic word


 app/helpers/ops_helper.rb | 25 +-
 app/views/ops/_settings_advanced_tab.html.haml | 4 +
 2 files changed, 22 insertions(+), 7 deletions(-)

Comment 13 Tasos Papaioannou 2018-08-02 14:14:14 UTC
Verified on

Comment 14 Yuri Rudman 2018-08-06 19:24:34 UTC
*** Bug 1444048 has been marked as a duplicate of this bug. ***

Comment 15 Yuri Rudman 2018-08-06 19:26:40 UTC
*** Bug 1358448 has been marked as a duplicate of this bug. ***

Comment 16 Yuri Rudman 2018-08-06 19:31:59 UTC
*** Bug 1358433 has been marked as a duplicate of this bug. ***

Comment 17 errata-xmlrpc 2019-02-07 23:02:11 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.