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):
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
Initializes 1x fine, but subsequent auto refreshes change the displayed value to blank.
The dynamic dropdown shows <Choose> as the default value when sorted alphabetically in the hash.
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.
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.
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.