Red Hat Bugzilla – Bug 1531677
Service Dialog Elements not sorting properly
Last modified: 2018-04-11 13:47:12 EDT
In ui-components 1.0.4: https://github.com/ManageIQ/manageiq-ui-classic/pull/3175
Created attachment 1396999 [details] image1_dropdown_issues There are main four locations were I tested dialog - A. Services > Catalog > 'Service Catalogs' accodion, order (run) your dialog B. From SSUI C. Automation > Automate > Customization > 'Service Dialogs' accordion (from Sample tab) D. New Dialog Editor (from Automation > Automate > Customization > 'Service Dialogs' accordion, edit this dialog) Location A and SSUI only 'runs' dialog, remaining cases only preview/demo dialog. Also note, SSUI have same use-case as OPS. *** Three main issues found (Check image1 and image2) - ------------------------------------------------- 1. For dropdown and radiobutton, when value==int, sortby==description, order==descending Expected result -> 1,2,3,9,10,11 | Appering -> 1,10,11,2,3,9 2. For dropdown and radiobutton, when value==int, sortby==description, order==acending Expected result -> 11,10,9,3,2,1 | Appering -> 9,3,2,11,10,1 3. Sorting behavior of Preview/Demo dialog (C and D locations) is not same as Running dialog (A and B locations) *** Suggestion - ------------ Current usecase of `Sort by` dropdown values are: 1. `Value` of `Sort by` option == `Keys` of `Entries` option 2. `Description` of `Sort by` option == `Values` of `Entries` option (Just read it > `Values` of `Sort by` are not `Values` of `Entries`, this are `Keys` of `Entries` and `Description` of `Sort by` are `Values` of `Entries`, confusing..) Expected -> `Sort by` and `Entries` dropdown should consist same values i.e. 1. Key and 2. Value. (Instead of Description-Value, Key-Value)
Created attachment 1397000 [details] image2_radiobutton_issues
Created attachment 1397001 [details] image3_none_thing _issue Need info - --------- A] Please confirm business logic for <none> thing here. (image3) 1. When sorting is ascending <none> is at top. 2. When sorting descending <none> is at bottom (?) First is obviously expected use case, but what should be business logic for A[2] here. Personally, <none> should always be at top regardless any order.. `Default option` of dropdown element is always placed on top and In Edit Field Details form, `Default value` option always set to `None` too (None by default). This logic also supports, <none> always be present at top regardless order. Please conform?
@Chris, about mentioned issue need to be fix. Thanks!
Ok, addressing Comment #3 https://bugzilla.redhat.com/show_bug.cgi?id=1531677#c3 There are a few things mistyped in that comment and I want to clarify what has been addressed and what still needs to be addressed. 1. For dropdown and radiobutton, when value==int, sortby==description, order==descending Expected result should be -> 11,10,9,3,2,1 (Please see my GH PR to view this sorting in SUI) 2. For dropdown and radiobutton, when value==int, sortby==description, order==acending Expected result should be -> 1,2,3,9,10,11 (Please see my GH PR to view this sorting in SUI) 3. I can confirm your observation of dropdowns not sorting in dialog demo screen. Please open up a BZ for Classic UI to address this issue. I also fixed that None show up at the top of a drop down no matter how it is sorted. Please reference https://github.com/ManageIQ/ui-components/pull/265 to view screenshots. I will post a follow up PR when this PR has been pushed, the version of UI-components has been bumped, and I have integrated this into service UI for validation.
Raised BZ1547231 for preview/running dialog issue in Classic UI. Thanks for corrections!
So for clarification on what follow up PR's are needed for this issue to be closed from the comment I made in https://bugzilla.redhat.com/show_bug.cgi?id=1531677#c8 . Below are the steps that exist. 1. https://github.com/ManageIQ/ui-components/pull/265 needs to be reviewed and merged 2. The PR needs to be backported to G release. 3. We need to push a new version of UI-components to NPM (will likely be version 1.0.16) 4. After the version bump occurs, we will create a PR in Service UI repo to use that new version of ui-components. 5. That PR will need to be backported and an appliance will need to be built and tested to validate issue is resolved.
Ok, GH PR https://github.com/ManageIQ/manageiq-ui-service/pull/1389 is the PR that bumps the version of ui-components with the fix for sorting drop downs in the SUI.
pr got merged, moving this to post
Created attachment 1408903 [details] Sorting in OPS UI Fixed in 5.9.1.0.20180314203929_67fd99d
Created attachment 1408904 [details] Sorting in Service UI
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. https://access.redhat.com/errata/RHBA-2018:0556