- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎07-12-2016 08:52 AM
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).
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎07-20-2016 02:50 PM
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:
- Create an additional script for RITM/TASK to query the Variable Ownership [sc_item_option_mtom] table and populate the value onLoad
- 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!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎07-20-2016 02:50 PM
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:
- Create an additional script for RITM/TASK to query the Variable Ownership [sc_item_option_mtom] table and populate the value onLoad
- 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!

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎07-20-2016 02:52 PM
Well I'm glad you go to the bottom of it.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎12-27-2016 09:23 PM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎01-04-2017 01:30 PM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎11-06-2018 09:38 PM
Is this bug fixed now? Because It seems like it is still there.
If so can you mention sample script to have above solution.