*** Description of problem:
There are changes in the kie-api which break backward functionality with 6.0.x version (and 5.3.x).
* Missing classes:
* Missing methods
org.kie.api.task.TaskService.getTasksAssignedAsPotentialOwner(java.lang.String,java.util.List,java.lang.String,int,int) on class org.kie.api.task.TaskService
org.kie.api.task.TaskService.getTasksByVariousFields(java.util.List,java.util.List,java.util.List,java.util.List,java.util.List,java.util.List,java.util.List,java.util.List,boolean) on class org.kie.api.task.TaskService
org.kie.api.task.TaskService.getTasksByVariousFields(java.util.Map,boolean) on class org.kie.api.task.TaskService
Majority of the missing methods belong to BPMS.
Mario, could you comment on the removal of QuartzHelper?
The getTaskByVariousFields(..) operations were incorrectly available in kie-api for 6.0.x, they were used by the REST service and should have been added to kie-internal.
The getTasksAssignedAsPotentialOwner with paging parameters was added based on a specific customer request for 6.0.1.GA, it was not applied to master at that point. For 6.1, new operations using QueryFilters are available in kie-internal TaskService.
I assume we could look at (re)adding the same operations in master for backwards compatibility if that is deemed critical, Marek, wdyt?
That QuartzHelper class has been incorrectly made available on kie-api and then removed, mainly because we want to keep the dependencies of our api to a minimal level and in particular we don't think it is necessary (or correct) that they depend on quartz.
I unable to assess how widely those methods are used (which would determine severity), but I would prefer to see them in the API for backward compatibility.
Marek, one thing to note about the methods is that the original API contained a mistake:
It's not possible to identify the user doing the operation with the the following methods:
- org.kie.api.task.TaskService.getTasksByVariousFields( java.util.List, java.util.List, java.util.List, java.util.List, java.util.List, java.util.List, java.util.List, java.util.List, boolean )
- org.kie.api.task.TaskService.getTasksByVariousFields( java.util.Map, boolean )
For that reason, both methods now have a String (userId) as the first argument and have the following signatures:
- org.kie.api.task.TaskService.getTasksByVariousFields( java.lang.String, java.util.List, java.util.List, java.util.List, java.util.List, java.util.List, java.util.List, java.util.List, java.util.List, boolean )
- org.kie.api.task.TaskService.getTasksByVariousFields( java.lang.String, java.util.Map, boolean )
The QuartzHelper class was not readded to the kie-api because it would add an unnecessary and incorrect dependency to the module, as explained above by Mario.
Marco, the signatures are not correct. Please see
which contains the old API to which the comparison was made.
Seems the userId parameter was not yet there for the two getTasksByVariousFields operations in 6.0.x. Is this required, or could we simply add another operation that would delegate to the second one where userId would be null?
Also the new getTasksAssignedAsPotentialOwner(..) should include a language parameter and the first getTasksByVariousFields operation is missing a language parameter as well.
The userId is required for the two getTasksByVariousFields operations in 6.0.x: not having them breaks the Task API because it allows ALL users to access tasks regardless of permissions. This then becomes a security bug.
I'll push a fix to do the following:
- add the String language parameter back to the following operation:
List<TaskSummary> getTasksAssignedAsPotentialOwner(String userId, List<String> groupIds, int firstResult, int maxResults);
- add the List<String> language parameter back to the following operation:
List<TaskSummary> getTasksByVariousFields( String userId, List<Long> workItemIds, List<Long> taskIds, List<Long> procInstids, List<String> busAdmins, List<String> potOwners, List<String> taskOwners, List<Status> status, boolean union);
Fixed (except for the userId issue, of course). Commits:
Yes, I think it's best if master doesn't diverge from 6.2.x (yet).
Cherry-picked to master:
Verified on 6.1.0.ER5.