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.

[joe_morton]

To me, this is the issue:

---

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:

We don't allow the Promotion Request to be edited while anything is in the locked state. Our workflow has a rework path, which changes the Promotion back to an editable state and unlocks everything in the promotion. Then the user can add items, and now set everything needed for promotion again. When the promotion goes forward, all the items are locked again for review.

There are other ways to manage it, like others are commenting, but to me, this is the easiest.

[N-Pyn]

So you lock the Promotion Request itself and not just the promotable objects? How is that done? Have you added some state-changing robot to the workflow or is there some OOTB solution for this?

[joe_morton]

We lock both. When the PRM is submitted:

• We use a robot in the workflow to change the state of the PRM itself to a state where it can't be edited. This is in the OOTB workflow: "Set State Under Review". You'd just have to make sure your ACLs do not allow editing the Promotion Request in that state.
• We use the OOTB expression "Lock Promotion Objects" to set the promotables to their lock state

The OOTB workflow has an "Unlock Targets" for a Rework also, they just don't change the state of the Promotion. You could either add the Set State, or else grant the person with the "Rework Promotion Request" task permissions to edit the Promotion Request as part of the task itself. 

End result is that you prevent people from editing the promotion while the items set for promotion are in the locked state.

[anursingh]

Hi @N-Pyn,

I wanted to see if you got the help you needed.

If so, please mark the appropriate reply as the Accepted Solution. It will help other members who may have the same question.
Of course, if you have more to share on your issue, please pursue the conversation. 

Thanks,
Anurag 

[N-Pyn]

We added the Promote transition from Pending Approval to Released, so the objects are not dropping out of Promotion Requests anymore when they are edited. But we still have the problem of some objects getting stuck to Pending Approval state when they are removed from Promotion Requests or if Promotion Requests are deleted.

There seems to be some kind of a bug in the process that should update the state of the promotion objects when they are not a part of a Promotion Request anymore.