Select Box value not showing on RITM/TASK

Mike McCall
Giga Guru

I currently have a select box variable with no actual "choices" defined. On the catalog item (submission) form, a catalog client script dynamically adds options when the page loads. Once the form is submitted, the database stores the selected text value, even though that value doesn't map to a real "choice."

As of Fuji Patch 11, I could open RITM or TASK records and see the text value showing on the form. When we upgraded to Helsinki Patch 1, those two form views stopped showing the text value; they now just default to "-- None --."

What's especially interesting is that I can preview RITM or TASK records and see the text value properly showing in the variable field. Actually opening the form view must be rendering the drop-down (while the preview just shows read-only text).

1 ACCEPTED SOLUTION

It is a bug! (PRB679673, to be exact)



Sure enough, a drop-down variable value stored in the database just won't render on RITMs/TASKs when the drop-down list is generated on-the-fly (and not using regularly defined question choices).



I'm told a fix is coming in Istanbul, and there are at least two potential workarounds for now:


  1. Create an additional script for RITM/TASK to query the Variable Ownership [sc_item_option_mtom] table and populate the value onLoad
  2. Make the variable read-only after submission (e.g., using Read Roles)


Obviously, #2 involves committing to values that can't change after submission, but I got that commitment from my stakeholder, so we're taking the easy way out!


View solution in original post

9 REPLIES 9

It is a bug! (PRB679673, to be exact)



Sure enough, a drop-down variable value stored in the database just won't render on RITMs/TASKs when the drop-down list is generated on-the-fly (and not using regularly defined question choices).



I'm told a fix is coming in Istanbul, and there are at least two potential workarounds for now:


  1. Create an additional script for RITM/TASK to query the Variable Ownership [sc_item_option_mtom] table and populate the value onLoad
  2. Make the variable read-only after submission (e.g., using Read Roles)


Obviously, #2 involves committing to values that can't change after submission, but I got that commitment from my stakeholder, so we're taking the easy way out!


Well I'm glad you go to the bottom of it.


Hello,



I have the same problem now and i wanted to go with the second option, so i created a client script and made the variable read only but still i see the wrong value in it, it is defaulting to the first value. could you help me here.


Hmm, I'm not sure what wouldn't be working about the client script, Sowmya.



I only personally tried using a Write Role of "admin" to make our variables read-only, and that displayed perfectly (unless you were an admin, hah). For better or worse, I can't recreate the issue anymore because it appears to have been fixed by Helsinki Patch 5.



I'd recommend seeing if Write Roles work--maybe a catalog client script won't?--or just moving to Helsinki Patch 5, if you can.


Is this bug fixed now? Because It seems like it is still there. 
If so can you mention sample script to have above solution.