Bug 1669533
| Summary: | Default Value for Dynamic Multi Select DropDown Behavior Inconsistent | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat CloudForms Management Engine | Reporter: | myoder | ||||||
| Component: | UI - OPS | Assignee: | Martin Hradil <mhradil> | ||||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Niyaz Akhtar Ansari <nansari> | ||||||
| Severity: | high | Docs Contact: | Red Hat CloudForms Documentation <cloudforms-docs> | ||||||
| Priority: | medium | ||||||||
| Version: | 5.9.5 | CC: | bmidwood, bwoolf, dmetzger, hkataria, lavenel, mkanoor, mpovolny, nansari, obarenbo, tfitzger | ||||||
| Target Milestone: | GA | Keywords: | Reopened, TestOnly, ZStream | ||||||
| Target Release: | 5.11.0 | ||||||||
| Hardware: | Unspecified | ||||||||
| OS: | Unspecified | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | 5.11.0.1 | Doc Type: | If docs needed, set a value | ||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | |||||||||
| : | 1686038 (view as bug list) | Environment: | |||||||
| Last Closed: | 2019-12-13 15:08:39 UTC | Type: | Bug | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | Bug | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | CFME Core | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Bug Depends On: | |||||||||
| Bug Blocks: | 1679295, 1686038 | ||||||||
| Attachments: |
|
||||||||
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
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
|
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.