Our users seem have the ability to create promotion notices with non-latest versions of objects in the promotable objects list. Brushing aside the reasons why anybody would be promoting non-latest (in our case this is user error), I'm wondering why this is possible and how to stop it. The promotion notice fires a workflow which aims to change state, but of course set state is only possible on the latest iteration. This conflict of interest creates a severe entry in the WfPropagationQueue resulting from the hung workflow process. Have we managed to break something here, or this a hole the OOTB config? Either way does anybody now how to put a lid on this? All I can think of is to put an expression in the WF that checks for non-latest version promotables. If this is the solution I have no ideas what that expression would be.
There is a helper provided since 9.1 m050 that can refresh the iterations of items on the promotion request. I will send an example when I am back at my computer.
This is from Jeff originally. If you use the two lines of code beforehand…it will automatically gather the latest iteration. Thanks again Mr. Zemsky.
The following is what you need to add to your code. Add this before the actual promote step of the workflow or potentially during the review – see attached image for an example workflow concept
[cid:image001.png@01CBEA06.94400CC0]
Add the following code to the expression robot to call the update method :
com.ptc.windchill.enterprise.maturity.PromotionNoticeWorkflowHelper helper = new com.ptc.windchill.enterprise.maturity.PromotionNoticeWorkflowHelper((wt.maturity.PromotionNotice)primaryBusinessObject, false);
helper.updateWithLatestIterations();
Note : Replace 'false' with 'true' to test the scenario where you need to update only the promotion targets in the baseline and seeds. 'false' would imply update ALL - i.e update with latest iterations for promotion targets, baselineables in the baseline and the promotion seeds.
