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

Update of manager field in admin UI patches manager/_ref, preventing virtual property calculation based in this field


    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 7.0.0
    • Fix Version/s: 7.0.0
    • Component/s: Module - Web UI
    • Labels:
    • Target Version/s:
    • Verified Version/s:
    • Story Points:
    • Sprint:
      2020.08 - IDM


      This likely affects versions prior to 7.0.

      When the manager field of a managed user is updated (i.e. not created, not deleted, but changed via the update button on the manager field), the UI will dispatch a patch request which looks like:


      which will essentially corrupt the manager edge state as the _ref will no longer accord with the _refResourceId. Thus, in ManagedObjectSet#patchResource, or in ManagedObjectSet#update, the state of the manager field in the new object will look as follows:

       "manager": { "_ref": "managed/user/75515e8a-da58-4b64-b4bf-4092ba4745f8", "_refResourceCollection": "managed/user", "_refResourceId": "jnelson", "_refProperties":{ "_id": "17135c45-e57e-4230-a42c-7fd1f12acb42", "_rev": "0" }}

      Here we see that the patch operation has essentially corrupted edge state, as the resource id in the _ref and in the _refResourceId differ, the result of patching manager/_ref, instead of simply patching manager.

      Because relationship derived virtual property calculation is based upon the _refResourceCollection and _refResourceId of the edge state, and because this edge state does not reflect the updated edge state, any virtual property calculation based upon this patch state will traverse the old edge state, as this logic consults the _refResourceCollection and _refResourceId, which reference the old edge state, again because the UI-dispatched request patches manager/_ref, not manager.

      Note that the edge state which ultimately ends up in the repo is correct, as edge creation layers consult _ref to parse out _refResourceId and _resourceId. 

      Yet even in the edgeContainerDiff in VertexToEdgeSignaler#performEdgeMutations reflects this corrupted edge state:

      "updateEdges": { "manager": { "edgeId": "17135c45-e57e-4230-a42c-7fd1f12acb42", "oldEdgeState": { "_ref": "managed/user/jnelson", "_refResourceCollection": "managed/user", "_refResourceId": "jnelson", "_refProperties":

      { "_id": "17135c45-e57e-4230-a42c-7fd1f12acb42", "_rev": "0" }

      }, "newEdgeState": { "_ref": "managed/user/75515e8a-da58-4b64-b4bf-4092ba4745f8", "_refResourceCollection": "managed/user", "_refResourceId": "jnelson", "_refProperties":

      { "_id": "17135c45-e57e-4230-a42c-7fd1f12acb42", "_rev": "0" }

      } } }

      Again, the fact that the correct edge state ends up in the repo is only due to the fact that the edge internals logic consults the _ref state to constitute the _refResourceId and _refResourceCollection. 




            • Assignee:
              katie.gonzalez Katie Gonzalez
              dhogan Dirk Hogan
              QA Assignee:
              Alexander Dracka
            • Votes:
              0 Vote for this issue
              5 Start watching this issue


              • Created: