Unfortunately, no.  The creation of a list of values for a cascading list must be done manually.

Pickle Sphinx

Hi Surya – 

This is something that many people have wanted for a long time, but unfortunately there isn’t any way to enforce the presence of affected items through exit required fields.

One thing you can do – is create workflow criteria and/or status criteria to check for affected items before the workflow can be used or before the change can enter a particular status.  The major downside to this (compared to exit required fields) is that there won’t be any specific error message telling the user exactly what the issue is – so it becomes a training issue.

According to Oracle Support – this is caused by the use of old version jar file.  Apparently fixed in 9.3.3, but there is also a provided workaround:

Workaround:

1. Backup application.ear located under [Agile home]agileDomainapplications
2. Extract the application.ear
3. Remove the jar file : xmlparserv2-904.jar. The jar file is under  ‘applications/APP-INF/lib’
4. Compress the application.ear after removing the xmlparserv2-904.jar file
5. Restart the server and try the case again.

As far as an Out-of-the-Box solution goes – I think setting the criteria and training users is going to be your best bet.  Unfortunately – using Affected Item attributes (along with some other table attributes) in your exit required fields only seems to matter when there is an affected Item already present.  If there are no affected items (or no table rows present) those particular exit required fields are ignored.

In response to your original problem as to why you are getting the error when the affected item meets the status criteria – 

To troubleshoot – I would recommend enabling the two ‘read through’ fields on the ECO object itself to make sure that it is actually passing the values that your criteria expects.

Java Client > Admin > Data Settings > Classes > *Open ECO Subclass

*Select ‘User Interface Tabs’ Tab > *Open Affected Items > *Select ‘Attributes:Affected Items’ tab.
*Scroll down list to find and enable ‘Item Category’ and ‘Item Product Lines’ (set visible to ‘yes’)

Now go back the the ECO object that is getting the error and check these fields on the Affected Items tab of the ECO (rather than opening the item objects) to check the ‘Item Product Lines’ and ‘Item Category’ values.

It might even be the case that you need to have these fields visible on the change object for the criteria to work.  This shouldn’t be necessary, but I seem to remember encountering something similar several versions/years back and enabling the affected item read-through fields fixed my issue.  Might not be the same thing, but it won’t hurt anything to make sure…

Hi Surya – 
The Status Criteria Matching Type (SCMT) confused me for a long time as well. 

As Steve mentioned – this setting only matters at all if any of your status criteria (the criteria that you add to a specific workflow status) refers to something at the affected item level.  In other words if you only use generic status criteria, Like “All ECOs” or other status criteria that doesn’t drill down to the affected items level – it doesn’t matter what you set the SCMT to.

If /When any of your status criteria DOES refer to something at the Affected Items’ level (as your example criteria does) – then the SCMT setting does matter, but only for changes that contain multiple affected items.  If a change has only one affected item – the SCMT setting is more or less ignored.

SO – When a change contains more than one affected item AND the workflow it uses contains affected item based status criteria – the SCMT setting tells the workflow how to behave in relation to each affected item and the affected item based status criteria:

When set to ALL – it means that all of the affected items have to match at least one of a the affected item based status criteria. 

When set to SAME – it means that all of the affected items have to match the same affected item based status criteria.  

When set to SOME – it means that only one (or more) of the affected items has to match at least one of the affected item based status criteria.

Note – this is evaluated separately for each status that contains affected item based criteria upon attempted entry.

Java Client
System Settings > Product Portfolio Management > Schedule Status

Open the status that you mean to modify (Needs Attention, Off Track) and modify the “overdue value”

Just make sure that the overdue value for “Off Track” is greater than the value for “Needs Attention”

Solved!
It turns out that the problem came from the ifs user password not matching between the agile.properties and the server.conf files.  Since our Application and File Manager are on the same server – these passwords should match.  I’m not sure how they got out of sync, but hopefully this helps if someone ever encounters the same issue…

Hi Arif – 
This is in our Prod environment and the files are there.  I see the thumbnails, can view them in autoview, open in native app, and download a copy of the attachments – I just can’t copy them to a new revision or new item.  I have seen the issue that I think you are referring to (when we don’t copy the file manager data to a non-prod refresh), but I don’t think that is the issue here as, again, the files to appear to actually be there.  Maybe I misunderstood what you are saying though…

The action works fine if I choose to reference the existing files or continue without  the attachments.