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

GET /nodes/{nodeid} with 'association' include not returning association data


    • Type: Service Pack Request
    • Status: Closed
    • Resolution: Not a bug
    • Affects Version/s: 5.2.5
    • Fix Version/s: None
    • Component/s: ACS REST API
    • Environment:
    • Bug Priority:
      Category 2
    • ACT Numbers:


    • Sprint:
      Repo 74
    • Story Points:
    • Epic Link:


      Problem Description:
      The 'GET /nodes/{nodeid}' REST API has an include option for returning 'association' information.


      However, this only returns the OOTB primary cm:contains association:

              "association": {
                  "isPrimary": true,
                  "assocType": "cm:contains"

      I have added a custom target / source association but no information on this is returned (see attached screenshot from Node Browser)

      Reproduction Steps:
      1/. Install OOTB ACS v5.2.5
      2/. Deploy custom model 'pauloModel.xml' (attached) that defines this association:

          <association name="paulo:insert">

      3/. Create / Upload some content and (if using above custom model) change type to 'paulo:document'.
      4/. Edit properties of the content to create target / source associations (use 'INSERT).
      5/. Use the REST API to return the node properties.



      Observed Behaviour:
      The only assoication data returned is:

              "association": {
                  "isPrimary": true,
                  "assocType": "cm:contains"

      Expected Behaviour:
      As a minimum, I would expect the 'paulo:insert' association to be referenced in the REST API response.
      As a secondary request, the noderefs of the associated documents could also be returned and whether they are 'targets' or 'sources'.
      Customer Issue:
      The customer is using the REST API to return the properties of a node.  They then want to display the properties of the associated documents of that node.
      To do this with the current behaviour, they have to make 4 calls:
       1/. GET /nodes/{nodeid}     (where nodeid is the parent document)
       2/. GET /nodes/{nodeid}/sources
       3/. GET /nodes/{nodeid}/targets
       4/. GET /nodes/{nodeid}    (iterative - where nodeid is the associated document)
      If the initial GET /nodes/{nodeid}?include=association call returned the presence of an association then that would mean steps 2 & 3 could be avoided for nodes that do not have associations.  Currently, all nodes have to be checked because the first call does not provide the information required.
      If the initial GET /nodes/{nodeid}?include=association call returned the noderefs of the associated documents (and whether they are sources or targets) then steps 2 & 3 could be eliminated for all nodes.
      The cutomer is requesting the change to reduce the overhead of returning the data to the end-user.
      I would also add that the include=association option should return all association data and not just the OOTB cm:contains one.





              • Assignee:
                closedissues Closed Issues
                pbateman Paul Bateman
              • Votes:
                0 Vote for this issue
                8 Start watching this issue


                • Created:

                  Structure Helper Panel