Description of problem: There are 2 situations where populating a dynamic multi select with default values behaves odd. The first case seems like a legitimate bug, however the second case seems like a weird edge case, because I thought we only allow hash keys to be strings while in automate, not integers. [1] If the keys for the hash are bigger than 1 character, then the values load on init, but will not load when you manually refresh the dynamic dialog element. i.e. This works on init and on a refresh: {'A' => 'A', 'B' => 'B' ,'C' => 'C'} This loads correctly, but doesn't refresh correctly: {'AA' => 'A', 'BB' => 'B' ,'CC' => 'C'} [2] If the keys for the hash are a single integer value, the values will not load on init, but will load when you manually refresh the dynamic dialog element. Which seems odd for it to work only when refreshing. In my mind, this shouldn't work at all since the keys are an integer value, and I though we only allow strings. i.e. This doesn't load on init, but will on a refresh: {1 => 'A', 2 => 'B' ,3 => 'C'} Version-Release number of selected component (if applicable): CFME 5.9.5 (reported on this version) CFME 5.9.6 (tested on this version) How reproducible: always Steps to Reproduce: 1. 2. 3. Actual results: Dynamic multi select shows "Nothing Selected" after refreshing the dialog element. Expected results: Dynamic multi select should show the correct values when the element is refreshed. Additional info: I opened this under automate, but this may be a UI issue, not sure.
I added another case that looks buggy. #dialog_hash = {'A' => 'A', 'BB' => 'BB' ,'C' => 'C'} #works before but not on refresh, only has single char keys on refresh on init: a, bb, c after refresh: a, c
I re-created this issue on 5.9.8.0 appliance 10.8.198.8 Same behavior on latest 5.10 also.
Erik thinks this is a UI rendering issue. From Erik: "The automate methods are returning the right values and everything, they just aren't being selected by the UI"
Steps to reproduce: go to Automation > Automate > Explorer add a new method anywhere, type inline dialog_hash = {'A' => 'A', 'B' => 'B' ,'C' => 'C'} $evm.root['values'] = dialog_hash $evm.root['default_value'] = dialog_hash.keys exit MIQ_OK add a new instance in the same place, value = name of the new method go to Automation > Automate > Customization toolbar Configuration > Add a New Dialog add a dropdown, edit details tab Field Information enable Dynamic tab Options set entry point to the newly created instance enable Show Refresh Button enable Load values on init enable Multiselect go to Service > Catalogs > Catalog Items add a new catalog item, select the newly created Dialog, enable Display in Catalog, select a Catalog go to Service > Catalogs > Service Catalogs order the new catalog item
https://github.com/ManageIQ/ui-components/pull/365
New commit detected on ManageIQ/ui-components/master: https://github.com/ManageIQ/ui-components/commit/ddb9f6421a8a971dbfa6859201e6059fb80699c0 commit ddb9f6421a8a971dbfa6859201e6059fb80699c0 Author: Martin Hradil <mhradil> AuthorDate: Wed Feb 20 05:13:39 2019 -0500 Commit: Martin Hradil <mhradil> CommitDate: Wed Feb 20 05:13:39 2019 -0500 dialogField - move logic for setting default_value to one place instead of one service dealing with half of it, a controller $onInit method with other part of it, and an ng-init function which does not get called more than once dealing with multiselect default values Now, it all lives in `setDefaultValue`, called from `setupField`, in the `dialogData` service. Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1669533 src/dialog-user/components/dialog-user/dialogField.html | 1 - src/dialog-user/components/dialog-user/dialogField.ts | 29 - src/dialog-user/services/dialogData.ts | 35 +- 3 files changed, 20 insertions(+), 45 deletions(-)
Verified in Version 5.11.0.3.20190507174347_a77bd90
Created attachment 1568562 [details] datastore
Created attachment 1568563 [details] dialog