New to 10.2: Promotion Request rights worse than previous versions?!!

[jwagh]

According to my research and the below SPRs, it appears that the rights for users to promote files are worse than previous versions of Windchill. Has anyone seen this? PTC does not want to fix it in 10.2.

1. Users can promote checked out objects
2. Promotion Requests with checked out objects will hand in the OPEN state and not change to UNDER REVIEW
3. Objects UNDER REVIEW can be checked out

SPRs:

https://support.ptc.com/appserver/cs/view/solution.jsp?n=CS158224&source=Case%20Viewer

https://support.ptc.com/appserver/cs/view/spr.jsp?n=2892612&source=Case%20Viewer

[MikeLockwood]

There is simple code on two conditionals in the two OTB Promotion Workflow templates (same for many releases) that confirms that a Promote LC transition exists, etc.  Seems that additional simple code could be added to confirm that all objects are not checked out.  If someone does a stellar job of creating this code and provides it to PTC they will add. 🙂 //// Permissions for checking out objects on a Promotion Request and have used the LOCK transition to go to UNDER REVIEW are a different matter.  If a system is properly configured, users will not have MODIFY permission at the UNDER REVIEW state.

[ChrisPLM]

Agreed with you Mike.  While I was reading, I thought  Checking Out ability for UNDER REVIEW is just an authorisation matter.

[ddemay]

As Mike pointed out, code, and also configuration of lifecycle.  I'll also add, promotion requests are heading the ways of dust in the wind.  Change notices with their recent functionality improvements are the future.  Personally, I like promotion requests, because it to me is not indicating a change, but a bump in the status, creating extra ECR's or ECN's are a killer waste of time and sap performance if too many exist concurrently.

[STEVEG]

I agree David.  We also still use promo req occasionally even though we have change management.

[MikeLockwood]

Promotion serves the purpose very nicely for certain cases to simply change state.  It has the same collection functionality as change and allows for all needed workflow variations.  But - Promotion Requests cannot be edited and do not allow attachment files. For this reason, we are forced to change objects a few places.  We'd be happy to use just Change Notice + Change Task with Change Request, but one cannot create a CN/CT without selecting the Assignee / Reviewer roles and this greatly confuses every new user.  They also don't "get" the concept of implementation plan.  Their goal is to request a change - which is clear on a Change Request. We'd be very happy if Promotion Requests allowed for Editing and Attachments.

[STEVEG]

I agree that it would be great if promotion requests were allowed to be edited.  But since it's not this is how we get around it.

Delete the promotion request and set the states by admin back to what they were.  Then recreate the PR.  Maybe a little bit much but we don't need to edit them very often at all.  Our promotion requests also typically do not have very many files.

I like using them so I can add some info in the Comments box as to why the PR was created just like a check in Comments box.  If someone sets the State manually there is no Comments box to explain the set state action.

[MikeLockwood]

If you use the Lock transition in parallel with the Promote transition, then the objects being promoted temporarily go to the designated lock state (at which they are not actually locked but at which you have to remove Modify permission).  If the promotion cannot be approved, users should vote Reject.  This automatically returns the objects being promoted to their original state and retains any comments in the rejected request. So - Admin does not have to set state or delete anything.