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

Non-required single relationship properties should be nullable

    Details

    • Sprint:
      OpenIDM Sprint 88

      Description

      1) Start the default project
      2) Create two users, the second managed by the first:

      curl -u openidm-admin:openidm-admin -X PUT --data '{"userName":"jfeasel","givenName":"Jake","sn":"Feasel","mail": "jfeasel@example.com"}' -H 'Content-type: application/json' -k https://localhost:8443/openidm/managed/user/jfeasel
      
      curl -u openidm-admin:openidm-admin -X PUT --data '{"userName":"afeasel","givenName":"Andrew","sn":"Feasel","mail": "afeasel@example.com","manager": {"_ref":"managed/user/jfeasel"}}' -H 'Content-type: application/json' -k https://localhost:8443/openidm/managed/user/afeasel
      

      3) Attempt to "promote" the second user by setting their manager to null:

      curl -u openidm-admin:openidm-admin -X PUT --data '{"userName":"afeasel","givenName":"Andrew","sn":"Feasel","mail": "afeasel@example.com","manager": null}' -H 'Content-type: application/json' -k https://localhost:8443/openidm/managed/user/afeasel
      

      Expected: a successful update

      Actual:

      {"code":403,"reason":"Forbidden","message":"Policy validation failed","detail":{"result":false,"failedPolicyRequirements":[{"policyRequirements":[{"params":{"invalidType":"null","validTypes":["object"]},"policyRequirement":"VALID_TYPE"}],"property":"manager"}]}}
      

      Note, if the relationship is changed using a PATCH operation, like so:

      curl -u openidm-admin:openidm-admin -X PATCH --data '[{"operation": "remove", "field": "manager"}]' -H 'Content-type: application/json' -k https://localhost:8443/openidm/managed/user/afeasel?_fields=*,manager
      

      Then the user is updated correctly (and "manager" is returned with a null value). This is how the UI performs the removal when the admin edits the user.

      If the managed.json schema for "user" is adjusted, so that the "type" of the "manager" property is ["relationship","null"] instead of just "relationship", then the expected result is produced when updating the user with an explicit null value for the relationship property.

      When a sync event produces a target value, the internal request to the target system is an update, not a patch. As a result, this behavior is particularly troublesome for mappings which specify values for "manager" (and any other single relationship property). Unless the schema configuration is changed as described in the above paragraph, there would be no way for a sync mapping to remove a such relationship.

      The behavior observed of a non-nullable, non-required single relationship property seems to be incorrect and inconsistent. Something needs to be changed so that properties declared in this way work as expected. Perhaps this state should be considered an error state; if so, the backend should reject it, the front-end should prevent it, and the default configuration should not include it.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                brmiller Brendan Miller
                Reporter:
                jake.feasel Jake Feasel
              • Votes:
                1 Vote for this issue
                Watchers:
                5 Start watching this issue

                Dates

                • Created:
                  Updated: