Bug 1262036 - Task query /query/task endpoint returns all the tasks for the authenticated user and ignores potentialOwner parameter
Task query /query/task endpoint returns all the tasks for the authenticated u...
Status: CLOSED WONTFIX
Product: JBoss BPMS Platform 6
Classification: JBoss
Component: Business Central (Show other bugs)
6.1.0
Unspecified Unspecified
urgent Severity unspecified
: ---
: ---
Assigned To: Marco Rietveld
Lukáš Petrovický
:
Depends On:
Blocks: 1262105
  Show dependency treegraph
 
Reported: 2015-09-10 12:43 EDT by William Antônio
Modified: 2016-09-20 01:06 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Known Issue
Doc Text:
Cause: The results of the REST /query/task or /task/query (operational synonyms) operations do not contain the potential owners information. Consequence: Even though the field (or XML/JSON element) is empty or null, this does not mean the task in question does not have potential owners. On the contrary, the problem is that the field has not being filled. The database query and server side logic are processing the query correctly: however, the results are lacking the potential owner information. Workaround (if any): Retrieve the enter Task instance in order to view the potential owners information via the ../rest/task/{taskId} operation.
Story Points: ---
Clone Of:
: 1262105 (view as bug list)
Environment:
Last Closed: 2015-09-29 10:54:27 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description William Antônio 2015-09-10 12:43:04 EDT
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.
Comment 2 Marco Rietveld 2015-09-23 12:03:46 EDT
William, 

The expected results for this operation: 

http://localhost:8080/business-central/rest/query/task?potentialOwner=john

when done by user mary

are the following: 

Tasks that 
1. have john as a potential owner
2. AND that mary is allowed to see

If john is a potential owner for tasks that mary is not permitted to see, then these tasks will not be returned by the above operation. 


Given the above, is there still a bug here?
Comment 4 Marco Rietveld 2015-09-24 03:46:26 EDT
William, 

Thanks, I'll write some tests to make sure that the potenialOwner parameter is not being ignored. If that is the case, I'll make sure to fix it. 

Configuring Mary to see tasks that she's not allowed to see (John's tasks that do not involve Mary) is not possible at the moment. However, implementing a "integration user" role that users can use in these cases is on the roadmap.
Comment 5 William Antônio 2015-09-25 01:42:14 EDT
Hello Marco,

This is the input from our customer:

---
The below query is returning bunch of tasks where as none of the tasks have xyz as potential owner. We think it's a bug.
---

Then I asked them if the behavior you mention is okay, and here is their response:

---
Yes. If Mary is the user and filters a search by groups, then the result set should only include tasks that match the group filter AND that she has access to view.
---
Comment 8 Marco Rietveld 2015-09-28 16:05:58 EDT
Ahh.. I believe this might unfortunately be very stupid problem: 

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 (AFAICT), not that the wrong tasks are retrieved: the problem is that the field in the TaskSummary info returned to the client is not filled!
Comment 9 Marco Rietveld 2015-09-29 10:54:27 EDT
See https://bugzilla.redhat.com/show_bug.cgi?id=1262105#c4

Note You need to log in before you can comment on or make changes to this bug.