Red Hat Bugzilla – Bug 1311308
<Choose> Won't Display on Refresh of Dynamic Dropdown
Last modified: 2016-07-12 14:45:22 EDT
Description of problem: I have <Choose> set as a value if the hash is nil. <Choose> shows on initialization, but when it refreshes and redoes the ldapsearch, it goes to a blank value. The value <Choose> is in the hash in the logs when you log the inspect. I change the value to -Choose- and it is shows fine on the refresh without issues. I tried / \ REGEX escape values to no avail. It will escape and show the escape characters with the rest of the value. Version-Release number of selected component (if applicable): 5.5.2.4.20160127105142_395c086 How reproducible: Every time it refreshes after initialization. Steps to Reproduce: 1. Create a dynamic dropdown with automate code that has <Choose> as the nil value of a hash 2. Create a service dialog to use this dynamic dropdown and have it set to auto refresh 3. Try to create a service with this dialog and allow it to auto refresh Actual results: Initializes 1x fine, but subsequent auto refreshes change the displayed value to blank. Expected results: The dynamic dropdown shows <Choose> as the default value when sorted alphabetically in the hash. Additional info: self_service UI shows the value fine, but the old Service Catalog doesn't display correctly.
Dan, required is taken away when I select dynamic. I have dialog_field["required"] = "true" in the automate code. Do I have to set it ahead of time before I create the element like I do when it gives me the error of "cannot create without initial values" and then go back and make it dynamic?
Dan, I changed it from dynamic to traditional and saved it with the true value. Changed it back to dynamic with the same automate code underneath. No change since I toggle it between dynamic to traditional and it appears false underneath the dynamic every time I toggle it. It seems like more of a < > issue than anything since I can put gnandndindand between < > and it's a blank value.
Martin, This issue appears to be fixed in commit 30e5964f0f7a461aecee5f7e6a06e07466f5b7f5 on upstream master, i am not sure if all the changes in that commit are safe to be cherry-picked on to 5.5.z so sending this ticket your way to cherry-pick changes appropriately. Let me know if you have questions. Thanks, ~Harpreet
Fixed. Verified in 5.6.0.1-beta2.20160413141124_e25ac0e
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-2016:1348