Promotion Request: WTParts being automatically removed and getting stuck to lock state

[N-Pyn]

Hi, we are having a problem with our Promotion Request workflow.

Sometimes we come across a situation where at first only WTParts are added to a Promotion Request as Promotion Objects:

We use "Pending Approval" state to lock objects that are added to Promotion Requests so that they are not edited during the review process (because the promotion process seems to be unable to refresh the latest iteration automatically to the PR).

At this point the WTPart is moved to that state.

Then when the Promotion Request is later edited and the related CAD documents are added to Promotion Objects, the WTParts drop out of the Promotion Objects because they are in the "Pending Approval" state, which we are not allowing to be promoted:

Now at this point the WTPart gets stuck to "Pending Approval" state even though it is not in the Promotion Request anymore:

And someone with Admin or Product Manager access needs to now go and use Set State to change the state back to In Work so that the WTPart can be added back to the Promotion Request.

I know that we can get rid of this behavior by allowing Promote transition from Pending Approval state, but that would also enable people to accidentally add one object to multiple Promotion Requests. 

Is there any other solution for this problem? And why is the WTPart not reverting back to its original state when it drops out of the Promotion Request?

[DmitryC]

Are you using a temporary state for locking your WTParts or an actual lock?

You can easily lock promotion targets like this:

wt.maturity.PromotionNotice pn = (wt.maturity.PromotionNotice)primaryBusinessObject;
try
{
     wt.maturity.MaturityServerHelper.service.lockTargets( pn );
     result = "Accepted";
}

I have not tried it, but it might be possible to progressively lock additional targets as you add them to your promotion request.

You can then unlock targets to return them to the original state if needed:

wt.maturity.MaturityServerHelper.service.unlockTargets (pn);

If it's an actual state and not the lock transition, you will need to store the original state somewhere and return it manually later.

As for other solutions - you can create a tiny customization that would refresh your promotion request to use latest iterations when needed. Also, you can make a check to see if any iteration of a given revision (in promotion request) is a part of another active promotion request.

I doubt that there is a silver bullet for this issue.

Kind regards,

Dmitry

[N-Pyn]

We use the Pending Approval state as the lock state in the Lifecycle. And it is working otherwise okay, but we have this problem with WTParts dropping out of the promotion objects when the Promotion Request is edited.