Description of problem: When I have declared (or dynamically created) human task in an ad-hoc process/case assigned to group "customRole", none user (added to the role "customRole") does not have permissions to execute operation 'Claim', 'Start', 'Complete' on the human task. For adding user to the role "customRole", I use the following operation from CaseMgmtService: caseMgmtService.addUserToRole(caseId, "customRole", "john"); Creating human task dynamically assigned to "customRole": caseMgmtService.createDynamicHumanTask(pid, "Custom Role Task", null, "customRole", null, null); Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
This is actually expected behavior, because case roles are specific to one case instance, where task roles are globally defined. So you cannot use addUserToRole(..) to add users to a task role. So if you want to assign a task to a case role, you have to resolve the case role first: - dynamically you would first resolve which user has a certain role (using the case mgmt api) and pass that (the actual user id) as potential owner - when you have a task defined in the process, a similar approach would also first resolve the case role and pass the actual user ids on task creation Does that make sense?
Yes, it works this way around by setting potential owner but it is not something that I would expect to do "manually" when we have case roles and I believe neither other users will. This solution forces us to choose a direct person to the task. When we do not care and we only need anybody capable with the specific case role, we are not able to define it due to ignoring the case roles in tasks. Next example in a scenario where we have case role "responsible" and only one person can be assigned to this role, we need to do all the suggested work just to assign a task to the responsible person. So, the solutions for this example are: 1) according to roleInstance(s) of "responsible" case role, "manually" assign the potential owner - additional work - for assignment we may use business rules but generally this is overkill for basic scenarios like this - duplicates information about roles since we need to set case data for "responsiblePerson" to be assigned to the task's potential owner as #{responsiblePerson} 2) use a process variable for responsiblePerson and use it as potentialOwner - avoiding case roles and case management features 3) enable human tasks to use case roles when available - person is kept only in RoleInstance - it's enough to set groupId "responsible" and add the user into the role through addUserToRole()
Ivo, There's possibly a difference between how it works underneath and how something is presented to the user. For example, I can see how a UI (for example one to dynamically add user tasks to a case) could offer the user the option to create a task for a specific case role. In the backend, the role instance could then be replaced by the actual user having that role. Technically, I don't think it's feasible to use case roles in the task itself (as potential group owner), but we have to assign it to specific users. Otherwise, there's no efficient way to get that task in the task list of affected users. - whenever a user is opening his task list, we first determine which groups he is part of - we retrieve all the tasks where this user is potential owner, and also all tasks for the groups he is part of - if we would use a case role in there, it would not be possible to resolve this once, but this case role could be different for each case instance - the only way seems to be to iterate all cases to resolve this information somehow, which wouldn't be performant I believe the concept of case roles can be made very useful, especially if the UI can hide some of the complexities. And we could make enhancements to for example the user task in the future to make it easier to assign a task to a role (to avoid too much mapping work). This is actually similar to how BugZilla seems to work: when you for example set a needinfo flag, you are able to choose from common roles like 'reporter', but this role is then replaced by the actual role owner.
Alright, I see your point, Kris. Especially, listing the tasks for a user was convincing from the technical POV. Therefore, let's leave it as it is and I will try to make some abstraction in the tests that use case roles as task groups. When we have tests as examples how to use case roles and some documentation in developer guide, it should help developers to get use to this concept. Thank you for elaboration, I believe it will be helpful in the further UI work in case management.