Majority of the missing methods belong to BPMS.

Mario, could you comment on the removal of QuartzHelper? 
https://github.com/droolsjbpm/droolsjbpm-knowledge/commit/52782d3e0eea40d3ce43003ab24e80aac82f15a8

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 )

Fixed. Commits: 

6.2.x: 
https://github.com/droolsjbpm/droolsjbpm-knowledge/commit/d2f50339
https://github.com/droolsjbpm/jbpm/commit/e099ce93
https://github.com/droolsjbpm/droolsjbpm-integration/commit/369a85f3

master:
https://github.com/droolsjbpm/droolsjbpm-knowledge/commit/285eef43
https://github.com/droolsjbpm/jbpm/commit/fda3e83d
https://github.com/droolsjbpm/droolsjbpm-integration/commit/27f6fd13

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

http://git.app.eng.bos.redhat.com/git/droolsjbpm/droolsjbpm-knowledge.git/tree/kie-api/src/main/java/org/kie/api/task/TaskService.java?id=sync-6.0.x-2014.09.05

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: 

6.2.x:
https://github.com/droolsjbpm/droolsjbpm-knowledge/commit/b548a64a9
https://github.com/droolsjbpm/droolsjbpm-integration/commit/3ff35517
https://github.com/droolsjbpm/jbpm/commit/718cef79

Yes, I think it's best if master doesn't diverge from 6.2.x (yet).

Cherry-picked to master: 

master: 
https://github.com/droolsjbpm/droolsjbpm-knowledge/commit/7084cdd8
https://github.com/droolsjbpm/droolsjbpm-integration/commit/674c5af4
https://github.com/droolsjbpm/jbpm/commit/40ce1823

Verified on 6.1.0.ER5.