This bug was initially created as a clone of Bug #1103970 but the main issue of BZ1103970 is just related to BPMS 6.0.x and not to BPMS 6.1.x. This BZ is cloned to focus on the Marco's comment below for BPMS 6.1.x. --- Additional comment from Marco Rietveld on 2014-09-29 23:10:24 EDT --- Here are the current issues: 1. The "getTasksAssignedAsPotentialOwnerByStatusByGroup" method is a InternalTaskService method, not a TaskService method. The Remote Java API (kie-remote-client) supplies a TaskService implementation, *not* a InternalTaskService method. (In short, at the moment, there's no way to call this method.) 2. On the other hand, the method is paged and, as you mention, it's the only method where the user can submit a list of group ids as a parameter to retrieve tasks. I'm currently leaning towards promoting/refactoring the "getTasksAssignedAsPotentialOwnerByStatusByGroup" method from the InternalTaskService interface to the TaskService implementation. One other possibility is to provide access to the new query functionality that's been added to the InternalTaskService in the Remote Java API. This functionality supports the new REST query operations.
+1 for promoting getTasksAssignedAsPotentialOwnerByStatusByGroup :)
Toshiya, this bug is for BPMS 6.1, right?
Yes. This BZ is for BPMS 6.1.0. And BZ1103970 is for BPMS 6.0.x. Thank you for changing the version field.
This has been fixed in community (the operation has been readded to the TaskService interface) as part of the work for BZ 1120213. Please see that bug for more info.
Failed in BPMS 6.1.0.ER3 Let's sum it up: - getTasksAssignedAsPotentialOwner(String userId, List<String> groupIds, int firstResult, int maxResults) - is deprecated - paging is now possible through the new query API: https://github.com/mrietveld/droolsjbpm-integration/wiki/jBPM-Rest-Query-API However, I do not see there any parameter to set groupIds, so we could have a replacement for the getTasksAssignedAsPotentialOwner(String userId, List<String> groupIds, int firstResult, int maxResults) and make other operations with groupIds.
Operations with groupIds are indeed deprecated, as we've been recommending the use of the UserGroupCallback for a long time already (that is responsible for providing the roles for the user). As a result, we are not planning to reintroduce more operations related to groupIds. Introducing support for filtering of the results based on provided groupId(s) would be a good enhancement, especially if the amount of results is large so that paging is necessary, which makes client-side filtering based on groupId(s) difficult. Note that this should only be used to do _additional_ filtering of the results, it would not allow you to avoid the UserGroupCallback and provide roles that otherwise wouldn't already be available by UserGroupCallback. Will look into this as a future feature request.
Created a jira here: https://issues.jboss.org/browse/JBPM-4873