How to prevent creator from completing task they are not responsible for - Windchill 10.2

[tgudobba]

In some of our workflows, the creator is completing tasks they shouldn't.

Is there a way to prevent the creator of the workflow from completing tasks that are assigned to someone else?

[MikeLockwood]

Terminology can get you tangled up on these things...

A user "creates" something like a Change Request, which is assigned a lifecycle (instance). The first state of the lifecycle is generally mapped to a workflow template, which becomes a workflow process instance, and starts delivering Tasks, etc.

So, a user doesn't create a workflow, but is assigned the "creator" role in that process. The Change request in this example is the PBO of the process.

All Tasks are configured in the workflow template to be delivered to someone - lots of options for who the someone is: a specific user (not good practice), the "creator" actor (sometimes good practice), a group, a role mapped to specific user(s) or a group, etc.

///
Separately, users can re-assign their tasks to others, but if the creator of the PBO is completing tasks that should be done by others, then likely re-assignment is not going on. Another complication is that calendar delegation (send all my stuff for these days to XYZ) could be going on.

////
Maybe provide some info on the current workflow template configuration for this?

///
Another thought - if you are talking about projectlink project document routing for approval, note that the OTB workflow template for this includes a Track task for the person who routes. This track task allows the person who does the routing (for approval) to skip all the approvers and set the document to Approved. Is this what you're referring to?

[DonSenchuk]

That should all be set up in your ACLs, use of roles in the workflow tasks and assigning the appropriate groups/participants to the Roles in your Context Team page.

[LewisLawrence]

The issue the original poster brings up is valid and not something you can easily solve using access control rules. The problem is that anyone who has permissions to complete a workflow tasks for a given primary business object (PBO)can complete any task in the process as long as they have read permissions to the PBO at the time.

A simple example would be a process with sequential Submit, Check and Promote tasks. Members of the Submitter, Checker and Promoter roles can physically complete any (or all three) of the tasks. But it is common business process to have an authority matrix where only certain users are checkers, or promoters and if you submit/create something then you should be neither. There is no easy out of the box way to enforce these business rules in the workflow during execution.

We were able to add this functionality by creating a workflow helper that is called from the transition tab of the workflow task. This looks at the primary business object for the process, then the context team for where it is stored and only allows the task to be completed if the user is in the appropriate role in the context team. We also use this to prevent the submitter from also being the checker or promoter.

Clearly another simpler approach would be to enforce this procedurally and have some accountability for anyone who promotes their own work. But in most organisations rules around the use of the system tend to be treated a bit like the speed limit is by drivers, it only strictly applies when someone of authority is watching….

In Reply to Don Senchuk:

That should all be set up in your ACLs, use of roles in the workflow tasks and assigning the appropriate groups/participants to the Roles in your Context Team page.

[tgudobba]

Thanks to all for the replies. Sorry for my terminology faux pas, I'm still kinda new to WC.

Our scenario is pretty much what Mike describes. An engineer/project manager/creator creates a new soft type document (work request). The first state is mapped to a workflow template, which becomes the instance, etc...

The workflow template is then delivered to a specific role in the project. This role is assigned to a user or group. This is where the "creator" is sometimes completing this task. The creator is not in the role, or group, but in most cases, is also the project manager. This is what we want to prevent.

From Lewis' response, it sounds like a customization may be required.

We are not using document routing.

[MikeLockwood]

A bit more info in attached on this.

[tgudobba]

Lewis,

We're still seeing this issue keep cropping up for us. You mentioned in your post;

"We were able to add this functionality by creating a workflow helper that is called from the transition tab of the workflow task. This looks at the primary business object for the process, then the context team for where it is stored and only allows the task to be completed if the user is in the appropriate role in the context team. We also use this to prevent the submitter from also being the checker or promoter."

Can you share the details of your workflow helper? I know you mentioned it wasn't a perfect solution, but we would like to try it. Thanks!

[atre.shreyas]

Tim,

Setup wokflow and team in such way that create will not be approver if that is not case have to write expression to remove create for approver. if you have set up participant activity in workflow where user is selecting approver then you can use below code (write code in complete transition of activity or call method from helper class.). Below is sample code i used in CR workow to avoide creator and QA approver same

// get members in approver role

ArrayList users = (ArrayList) members.get(role);

if (users.isEmpty()) {

// if no approver selected thorow error

throw new Exception("Select user for " + role.getDisplay());

}

// iterate the users in Approver role

for (int i = 0; i < users.size(); i++) {

wt.org.WTPrincipal ur = ((wt.org.WTPrincipalReference) users.get(i)).getPrincipal();

if (ur.getClass().isAssignableFrom(wt.org.WTUser.class)) {

wt.org.WTUser user = (wt.org.WTUser) ur;

// if user in role is same as create throw error

if ( user.getAuthenticationName().toString().equalsIgnoreCase(creator.getAuthenticationName().toString())) {

throw new Exception("Creator and " + role.getDisplay() + "is same ");

}

}

}

}

return true;

}

Hope this Helps !!!!

Thanks

Shreyas

[tgudobba]

Thank you Shreyas! This is exactly what we needed.