We are working on a Windchill workflow project and found that when a task is submitted for review, the resulting objects associated to the task remain In Process and available for further edits. This behavior is different from Promotion Requests where the associated objects are also placed Under Review.
We prefer to use Tasks because of the traceability they provide and allowing association of unrelated objects. However, we would like functionaltiy similar to Promotion Requests once they are submitted. Can anyone provide suggestions how this might be accomplished?
Regards,
Jim
Jim,
By "Resulting Objects" I assume you a referring to the Primary Business Object attached to the workflow process itself, or are you referring to "Resulting Items" related to Change Notice Activities?
Either way, to prevent iterations/revisions during the course of workflow execution, you should first create ACL rules for the business object type dictating that during a specific lifecycle state, edits are not allowed.
Then, in your workflow, using a method robot, set the state of your object(s) programmatically to that lifecycle state. This will immediately prevent any edits until the objects advance to a new state that allows them.
If you would like any further explanations/examples email me and I'd be happy to help you out.
Thanks,
Jordan Reynolds
Hey Jordan
Do you have an example for the Expression Robot where you query these "resulting" objects ( both DOC and Part types) and then run through a loop and assign new LC state ?
THis is within the Change activity work flow. If you have would you please share
Thanks
Alex
public static void lockUnlockChangables ( WTChangeActivity2 activity, String targetState) throws WTException {
QueryResult resulting = ChangeHelper2.service.getChangeablesAfter(activity);
while (resulting.hasMoreElements()) {
LifeCycleManaged object = (LifeCycleManaged) resulting.nextElement();
LifeCycleHelper.service.setLifeCycleState(object, State.toState(targetState));
}
}}{}}}}}
We support a more direct method leveraging Review / Refine transitions which act similar to the Lock transitions in the Promotion Request process. You need to have States defined for your Review / Refine - examples below and I would use states that are unique to the needs of the process - not reuse states for other purposes. This will improve your control over access control during the process.
Review might be - Under Review
Refine might be - Rework
You can find more information here - this is supported in both Change Notice and Change Task starting at 9.1 (although 9.1 supports Change Notice only):
You can try to modify the setting of the lifecycle of the primary object, Maybe you have do some restrict or the default ACL does that.
You can add an intermediate state in the lifecycle and put a lock on that state. Add a policy that the object's in the intermediate state should be Read-only.
I'm not adding any benefit to the discussion but I second Sitanshu's idea.