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

DialogFieldTagControl - don't add <None> for multiselects #19696

Merged
merged 2 commits into from
Jan 13, 2020
Merged

DialogFieldTagControl - don't add <None> for multiselects #19696

merged 2 commits into from
Jan 13, 2020

Conversation

himdel
Copy link
Contributor

@himdel himdel commented Jan 8, 2020

when selecting one option from a list, having <None> (or <Choose>) in the list makes sense
when selecting 0 or more options from a multiselect, neither <None> or <Choose> can be in the actual list of options.

This matches what #19148 did for DialogTagDropDownList,
(including introducing the multiselect? method).

(Previously, the options were added to tags in #14348)

Cc @eclarizio - can you review please?
Cc @skateman,
Fixes ManageIQ/manageiq-ui-classic#6393
and partly addresses the issue in ManageIQ/manageiq-ui-classic#6392

BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1834219

@miq-bot add_label bug, automate

when selecting one option from a list, having <None> (or <Choose>) in the list makes sense
when selecting 0 or more options from a multiselect, neither <None> or <Choose> can be in the actual list of options.

This matches what #19148 did for DialogTagDropDownList,
(including introducing the `multiselect?` method).

(Previously, the options were added to tags in #14348)
@miq-bot
Copy link
Member

miq-bot commented Jan 8, 2020

Checked commits https://github.com/himdel/manageiq/compare/cef975d90c1861c1ad9bade5a6261ac760e0e759~...20f9bed49ac65bc6558c9f07fe27fde3d1000a0f with ruby 2.5.5, rubocop 0.69.0, haml-lint 0.20.0, and yamllint 1.10.0
2 files checked, 0 offenses detected
Everything looks fine. 🍰

Copy link
Member

@eclarizio eclarizio left a comment

Choose a reason for hiding this comment

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

👍 LGTM

Edit: One comment

Comment on lines +40 to +42
def multiselect?
force_multi_value
end
Copy link
Member

@eclarizio eclarizio Jan 8, 2020

Choose a reason for hiding this comment

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

Should we add this method or just use force_multi_value on line 71? Or, if we do want multiselect?, should we just change it to an alias?

Just seems like we're making a method for the name, since it does nothing other than call the other method that already exists.

We could alternatively just call single_value? on line 71 and reverse the ternary. I think I like this idea the best.

Copy link
Contributor Author

@himdel himdel Jan 9, 2020

Choose a reason for hiding this comment

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

I'm adding it for consistency with dropdowns, which are already using the method.

But, I can change both :).

But, then it can't be single_value? which doesn't exist for dropdowns, and to me force_multi sounds misleading, we don't care about "forced" but about what we're actually using, that's why I introduced multiselect? in the first place.

(And in fact, with tagging, force_multi_value now gives the wrong value when the category doesn't allow multiselect, but the editor didn't know that, but I'm not sure what that change should affect yet.)

WDYT, anything we can use in both?

Copy link
Member

@eclarizio eclarizio Jan 9, 2020

Choose a reason for hiding this comment

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

Ah ok that makes sense, maybe we just do alias_method :multiselect?, :force_multi_value then?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

ah, next PR then :)

@bdunne bdunne merged commit 9ce9b3d into ManageIQ:master Jan 13, 2020
@bdunne bdunne self-assigned this Jan 13, 2020
@bdunne bdunne added this to the Sprint 128 Ending Jan 20, 2020 milestone Jan 13, 2020
@himdel himdel deleted the dialog-tag-multi branch January 14, 2020 12:46
@mzazrivec
Copy link
Contributor

We need to backport this to ivanchuk for https://bugzilla.redhat.com/show_bug.cgi?id=1834219

@miq-bot add_label ivanchuk/yes

ghost pushed a commit to fabiendupont/manageiq that referenced this pull request May 23, 2020
@ghost ghost mentioned this pull request May 23, 2020
simaishi pushed a commit that referenced this pull request Jun 18, 2020
DialogFieldTagControl - don't add <None> for multiselects

(cherry picked from commit 9ce9b3d)

https://bugzilla.redhat.com/show_bug.cgi?id=1834219
@simaishi
Copy link
Contributor

Ivanchuk backport details:

$ git log -1
commit 2bfe6d2aea2a2f2716e744ba847532a7261ee021
Author: Brandon Dunne <bdunne@redhat.com>
Date:   Mon Jan 13 14:24:08 2020 -0500

    Merge pull request #19696 from himdel/dialog-tag-multi

    DialogFieldTagControl - don't add <None> for multiselects

    (cherry picked from commit 9ce9b3df7565a7fe4ad64494e348841f4ada98e0)

    https://bugzilla.redhat.com/show_bug.cgi?id=1834219

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.

Dialog user's tag control with multiselect has selectable <None> value
6 participants