+++ This bug was initially created as a clone of Bug #1262036 +++ Description of problem: If an user is used to authenticate against the "/query/task" endpoint and when querying for tasks using potentialOwner parameter, does not matter the value for the potential owner parameter, it returns all the task considering the authenticated user as the potential owner. Version-Release number of selected component (if applicable): n/a How reproducible: always Steps to Reproduce: 1. Create an user with roles admin, g1 and g2 2. Deploy process with human tasks with group g1 and g2 3. Use the query/task endpoint to query for tasks using potentialOwner with a random value: curl -X GET -u 'g1g2user:redhat2014!' http://localhost:8080/business-central/rest/query/task?potentialOwner=somerandomvalue Actual results: It returns all tasks where the user is potential owner: $ curl -X GET -u 'g1g2user:redhat2014!' http://localhost:8080/business-central/rest/query/task?potentialOwner=somerandomvalue <?xml version="1.0" encoding="UTF-8" standalone="yes"?><task-summary-list-response><task-summary><id>9</id><name>G2 HT</name><subject>G2 HT</subject><description></description><status>Ready</status><priority>0</priority><skipable>true</skipable><created-on>2015-09-10T13:07:36.050-03:00</created-on><activation-time>2015-09-10T13:07:36.050-03:00</activation-time><process-instance-id>16</process-instance-id><process-id>ht_tests.proc2_ht</process-id><process-session-id>16</process-session-id><deployment-id>example:ht_tests:1.0</deployment-id><quick-task-summary>false</quick-task-summary><parent-id>-1</parent-id></task-summary><task-summary><id>10</id><name>ht</name><subject>ht</subject><description></description><status>Ready</status><priority>0</priority><skipable>true</skipable><created-on>2015-09-10T13:07:40.217-03:00</created-on><activation-time>2015-09-10T13:07:40.217-03:00</activation-time><process-instance-id>17</process-instance-id><process-id>ht_tests.proc_ht</process-id><process-session-id>17</process-session-id><deployment-id>example:ht_tests:1.0</deployment-id><quick-task-summary>false</quick-task-summary><parent-id>-1</parent-id></task-summary></task-summary-list-response> Expected results: Only the tasks with potential owner equal the parameter should be returned. Additional info: This does not happen when we use other parameters such as processId. --- Additional comment from JBoss Product and Program Management on 2015-09-10 12:50:07 EDT --- Since this issue was entered in Red Hat Bugzilla, the release flag has been set to ? to ensure that it is properly evaluated for this release.
When the TaskSummary was first created by Mauricio, he added a "potentialOwners" field that he then used a second query to fill. Years later, I used the TaskSummary, unaware that he had used a hack (that we were also no longer using) to fill that field. The problem here is not that the wrong tasks are retrieved: the problem is that the field in the TaskSummary info returned to the client is not filled.
The bug has been set to CLOSED/WONTFIX because the problem is not that the query does not work, but that incomplete/incorrect results (namely an empty potentialOwners field) is being returned. However, adding the potential owners information to the result would make the operation at _least_ 2x as slow, because a second database query would have to be done in order to retrieve that information. The ideal situation would be to remove the potentialOwners field/element from the result, however this might break the API for users who are looking at the XML or JSON results, as opposed to serializing the result into a Java objects. As a result, we are doing the following: 1. adding @Deprecated and other comments to the code to show that the field is never stored. 2. Requesting that documentation be added that explains that the potentialOwners field will not be filled when a TaskSummary JAXB/JSON instance is returned from the REST API.
In 7.0, we will be removing the potentialOwners field.
Added a commit with @Deprecated: https://github.com/droolsjbpm/droolsjbpm-integration/commit/9f2c9078