Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1262036

Summary: Task query /query/task endpoint returns all the tasks for the authenticated user and ignores potentialOwner parameter
Product: [Retired] JBoss BPMS Platform 6 Reporter: William Antônio <wsiqueir>
Component: Business CentralAssignee: Marco Rietveld <mrietvel>
Status: CLOSED WONTFIX QA Contact: Lukáš Petrovický <lpetrovi>
Severity: unspecified Docs Contact:
Priority: urgent    
Version: 6.1.0CC: kverlaen, smcgowan
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
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 14:54:27 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1262105    

Description William Antônio 2015-09-10 16:43:04 UTC
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 16:03:46 UTC
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 07:46:26 UTC
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 05:42:14 UTC
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 20:05:58 UTC
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 14:54:27 UTC
See https://bugzilla.redhat.com/show_bug.cgi?id=1262105#c4