Since BPM 8.5.5 the reassignment of tasks is governed by teams and the portal's reassign action; you control it in three places:
- Who may reassign: the task's team (participants) can reassign among themselves; team managers (the team's manager team, 8.5.5+) can reassign any task of the team; tw_admins can reassign everything. Restrict by giving the activity a team whose manager team is small (supervisors only) - regular members then only see claim / release.
- To whom: the reassign dialog offers the members of the task's team (team managers can pick any user on some releases); a team filter service on the team narrows the candidates dynamically (exclude the previous approver, only users with a skill) - this filter also applies to the reassign picker.
- Whether the portal shows the action at all: the Process Portal action menu is configurable per portal instance (on some releases the action can be disabled in the portal configuration section of 100Custom.xml); the safe and version-independent way is a custom dashboard that offers only the actions you want (question 47).
// team filter service (input team: Team, output team: Team): only members of the same region as the instance may get the task
var region = tw.local.region; // mapped from the BPD
var out = new tw.object.Team(); out.name = tw.local.team.name; out.members = new tw.object.listOf.String();
for (var i = 0; i < tw.local.team.members.listLength; i++) {
var u = tw.system.org.findUserByName(tw.local.team.members[i]);
if (u != null && u.attributes.get("region") == region) out.members.insertIntoList(out.members.listLength, u.name);
}
tw.local.filteredTeam = out;
// REST: reassign is PUT /rest/bpm/wle/v1/task/{id}?action=assign&toUser=jdoe - the same team rules apply to API callersAuditing: every reassignment is recorded on the task (Process Inspector, the task's history in the portal, the task resource of the REST API) - use the PDW task views for reporting who reassigned what.
References