Prefer :dialog_id to :new_dialog_name in config_info #14958
Conversation
|
@miq-bot add_label bug, services, providers/ansible_tower, fine/yes |
|
@bzwei unrecognized command 'review', ignoring... Accepted commands are: add_label, assign, close_issue, move_issue, remove_label, rm_label, set_milestone |
|
Checked commit bzwei@ee74ab4 with ruby 2.2.6, rubocop 0.47.1, and haml-lint 0.20.0 |
| @@ -225,19 +225,18 @@ | |||
| expect(service_template.resource_actions.first.dialog.id).to eq new_dialog_record.id | |||
| end | |||
|
|
|||
| it 'uses the existing dialog if :service_dialog_id is passed in' do | |||
| it 'uses the existing dialog if :dialog_id is passed in' do | |||
There was a problem hiding this comment.
@bzwei - It would also be good to cover the case where :new_dialog_name & :dialog_id were passed in.
There was a problem hiding this comment.
This is the case both options are present.
There was a problem hiding this comment.
Ahh - I see it now. catalog_item_options_three has it there. Then cool - Everything looks good.
Prefer :dialog_id to :new_dialog_name in config_info (cherry picked from commit ec26e2b) https://bugzilla.redhat.com/show_bug.cgi?id=1447427
|
Fine backport details: |
https://bugzilla.redhat.com/show_bug.cgi?id=1447110
When the request config_info contains both new_dialog_name and dialog_id, the update process will fail with error dialog already exists.
The cause is we will try to create a new service dialog even if the dialog_id is already given.
The fix is to use the given dialog_id and ignore the dialog name.
This problem was discovered while using rails console to test the update. OPS UI does not have the issue.
The fix is more preventive if the config_info comes from a REST API happens to contains both attributes.