Uploaded image for project: 'Service Packs and Hot Fixes'
  1. Service Packs and Hot Fixes
  2. MNT-21309

ACS - Update REST Api documentation for workflow /tasks endpoint

    Details

    • Type: Documentation
    • Status: Open
    • Resolution: Unresolved
    • Affects Version/s: 5.2, 6.0, 6.1, 6.2
    • Fix Version/s: 6.N
    • Component/s: ACS REST API
    • Labels:
    • Bug Priority:
      Category 4
    • ACT Numbers:

      01002304

      Description

      Description

      • Update the description of the workflow endpoint "/tasks" to specify that by default the response JSON lists only the tasks where the user is assigned but not where is a candidate.
        To return all the tasks where the user is a candidate it's required to add the "where" clause with the "candidateUser" parameter on the request URL.

      Supporting evidence

      Steps to reproduce

      • Create two users, in this example "user1" and "user2"
      • As the "admin" user create a private site and make "user1" site manager
      • Login as "user2" and request to join the newly created site
      • A new task has been created, with the request from "user2" to join the site
      • Both "admin" and "user1" are able to see and claim the task since they are both site managers
      • Using the REST api endpoint, make a request at the following URL:
        <ALFRESCO_URL>/api/-default-/public/workflow/versions/1/tasks

      Expected Behaviour

      • Logged as the "admin" user, the JSON response list the task created by "user2" to join the site (since "admin" is site manager)
      • Logged as the "user1" user, the JSON response list the task created by "user2" to join the site (since "user1" is site manager)

      Observed Behaviour

      • Logged as the "admin" user, the JSON response list the task created by "user2" to join the site (since "admin" is site manager)
      • Logged as the "user1" user, the JSON response does NOT list the task created by "user2" to join the site (apparently wrong, since "user1" is site manager)

      The only way to reliably get all the tasks where a user is a candidate is to specify the following "where" parameter on the request URL:

      where=(candidateUser={userName})
      

      This is not considered a bug, but it's important to update the current documentation on the API since it now states:
      "Tasks are returned for which the authenticated user is the assignee or a candidate" 

      which is correct but it's important to specify that the "where" parameter is required in order to list the tasks where the user is a candidate.

        Attachments

          Structure

            Activity

              People

              • Assignee:
                Unassigned
                Reporter:
                dmondardo Damiano Mondardo
              • Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                • Created:
                  Updated:

                  Structure Helper Panel