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.
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?
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.
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. ---
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!
See https://bugzilla.redhat.com/show_bug.cgi?id=1262105#c4