Uploaded image for project: 'OpenIDM'
  1. OpenIDM
  2. OPENIDM-16242

effectiveRoles missing in onUpdate object when relationship created with PATCH



    • Support Ticket IDs:
    • Status:


      Using the default managed/user config, there are two properties of the "object" binding presented to the onUpdate script which are not always defined - effectiveRoles and effectiveAssignments. They are missing when the user is granted access to a role using the "PATCH" method of relationship creation; everything works fine when using the "POST" method. To demonstrate the issue, consider this setup:


      Add this to your onUpdate script:

      console.log("EFFECTIVE ROLES: " + JSON.stringify(object.effectiveRoles)) 

      Then, add a role to a user with a POST to the "roles" endpoint, like so:

      await $.ajax({method: 'POST', url: '/openidm/managed/user/e5504ec5-cda4-451b-bd13-74cc4dbc060c/roles?_action=create', data: JSON.stringify({_ref: "managed/role/8ce97982-5e5a-489b-9634-a2de239bc4d3"}), headers : { 'Content-type': 'application/json'}}); 

      The output from the log statement is something like this:

       EFFECTIVE ROLES: {"0":{"_refResourceCollection":"managed/role","_refResourceId":"8ce97982-5e5a-489b-9634-a2de239bc4d3","_ref":"managed/role/8ce97982-5e5a-489b-9634-a2de239bc4d3"}}

      Now try using PATCH to update the "roles" field on the base user endpoint, like so:

      await $.ajax({method: 'PATCH', url: '/openidm/managed/user/e5504ec5-cda4-451b-bd13-74cc4dbc060c', data: JSON.stringify([{"operation":"add","field": "/roles/-", "value": {_ref: "managed/role/8ce97982-5e5a-489b-9634-a2de239bc4d3"} }]), headers : { 'Content-type': 'application/json'}}); 

      Using this method, we see this output to the console:

      EFFECTIVE ROLES: undefined 


      Semantically, these two operations should be identical. However, as you can see they are producing very different behavior for effectiveRoles within the onUpdate script. Testing with effectiveAssignments shows the same inconsistent behavior.


      Considering these are both "relationship-derived virtual properties" (e.g. they use the "queryConfig" with "isVirtual"), it's likely that plays a significant part in the unusual behavior for these attributes. It's also likely that other RDVP properties (such as the new org-model attributes) suffer from this same issue.


      It is worth noting that the Native IDM Admin UI uses the POST method for creating relationships, while the new Platform Admin UI uses the PATCH method.


          Issue Links



              brmiller Brendan Miller
              jake.feasel Jake Feasel
              0 Vote for this issue
              7 Start watching this issue