Form section(s) missing from ATF Input variable form
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-30-2019 10:16 AM
We are bringing up ATF as part of our Madrid upgrade, so we have brought all of our PDIs to Madrid but our prod and sub prod instances are still on London. What we encountered was that two of our PDIs have the same problem with configuring test steps, and we don't know if the problem existed prior to Madrid or not, but it does NOT exist in our (London) test instance.
Briefly, when creating a new test step that uses an input variable, the form sections for Reference specification, Choice List Specification, Dependent Field, Calculated Value, and Default Value are missing from the Input Variable form. They exist in the Form layout...
But not on the form
This is true whether creating a new variable, or viewing/editing an existing one.
Our London instance shows the affected sections correctly. Both when examining an existing variable:
And when creating a new one:
The additional form sections are available as soon as the Reference type is selected. The UI Policy that appears to control this action (Show/Hide reference fields section) in my PDI is identical to the one in our Test instance, and at a glance the list of Client scripts and UI Policies do not appear to be different anywhere else. But we can reliably reproduce the same problem on two different Madrid instances -- at least one of which is patched to the latest level since it was only upgraded a few days ago.
Searching HI turned up KB Number: KB0639979 which offers a workaround involving searching for the Advanced view of either table (atf_input_variable or atf_output_variable) and deleting the two records from the list. Since both records are delivered read-only, it seems reasonable to assume that this was not intended to be used once the issue was fixed -- which happened in late Jakarta and Kingston releases. But if it was fixed, it's back and no amount of coercion seems to be able to correct it.
So I'm tapping out and hoping there is some wisdom from the SN Jedi Council to point us toward a solution.
- 1,989 Views
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-30-2019 12:03 PM
We are experiencing the same issue. Have you found a solution?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-04-2019 09:12 AM
Not really, no. Wish I had better news, but all we've found is what I mentioned above -- and if you're still encountering the same problem, then it doesn't sound like any of the patches since we upgraded have fixed it either.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
01-08-2020 04:56 AM
I managed to fix this in our instance. I noticed some very similar form sections that was recently updated under the table 'topic_variables' this might not be true in your case. What I did to find this information was to click the show versions UI link in the form layout configuration. If you find an update/version in the list click this and show related records. If the list is empty, doing an update to the section should spawn an update in the last.
In my case the related record showed a form section record with the topic variables table. To fix the issue in my case I copied the record, using the Copy UI Action, and changed the table to atf_input_variable. I then added a record to the form sections related list, putting atf_input_variable in the sys ui form field (make sure it's the advanced view record). Position should be the same as the positions in the records you've copied from.
The changes might not be visible until you've cleared the cache, using cache.do in the application navigator.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-28-2020 01:44 PM
So, I had this issue after our upgrade to Orlando this week, only we discovered it on the atf_output_variable form. I checked to make sure none of our 5 instances was actually working properly. No dice. I went to my personal developer instance, and looked at the Forms>atf_output_variable>advanced record.
- I exported all six form sections as .xml files (sys_ui_section) (make a dedicated folder to store these in - you'll be happy you did)
- For each form section, I exported all of the element files (sys_ui_element).
- I exported one type Reference record from my instance as an .xml file - save this file for the end of the process.
- Imported all of them except #3 to the 2 correct tables, sys_ui_section first and then sys_ui_element.
- Navigate to Forms>atf_output_variable>advanced - you have to manually add the form sections back in by searching for them. On the Form Sections, click "New", then use the search on the Sys UI Section field to find the sections you imported via xml earlier.
6. When you go to import the .xml for the output variable record in step 3 above, you will get an error about permission denied. Do it anyway, because for whatever reason, this is where the magic happens.
7. Navigate to atf_variable_output.do and confirm you can get your form to work.
Yes, this was manual and painful, but it worked for us. Feel free to ping me here or on LinkedIn.