-
Notifications
You must be signed in to change notification settings - Fork 141
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
Added logic to support both string and symbol access to keys in dialog hash under options #572
Conversation
ad3c892
to
b550694
Compare
Checked commit gtanzillo@b550694 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.
Looks good to me. The only possible downside is that HWIA #keys method or #each will walk the keys with the key name as a string and that is different than what we had prior to this PR.
It feels like this is the safest change we can make and is isolated to dialogs.
Added logic to support both string and symbol access to keys in dialog hash under options (cherry picked from commit 023da5f) Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1696362
Hammer backport details:
|
Added logic to support both string and symbol access to keys in dialog hash under options (cherry picked from commit 023da5f) Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1696363
Gaprindashvili backport details:
|
This addresses an issue that was introduced in #312. That change resulted in symbolizing the keys in the
dialog
hash underoptions
when a service is ordered with an API request.This change enables accessing keys in the dialog hash both as strings and symbols
/cc @tinaafitz, @lfu, @jrafanie
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1694716