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

Explicit repo table: validate mapping before CREATE

    Details

    • Target Version/s:
    • Verified Version/s:
    • Story Points:
      3
    • Sprint:
      2019.14 - IDM
    • Support Ticket IDs:

      Description

      1) . Set up IDM 6.5.0.1 with SQL repo and explicit mapping

      2).  Set disable openidm.policy.enforcement.enabled in boot.properties

      3).  Make sure to restart

      4).  import in a user using REST:

      POST  http://localhost:8080/openidm/managed/user/?_action=create

      payload:

      { "userName": "FR-asdfasdf", "givenName": "ForgeRock", "sn": "BNS", "password": "Welcome1", "mail": "test.user1@example.com", "preferences" : "ABC" }

       

      Results:

      { "code": 500, "reason": "Internal Server Error", "message": "Unable to map JSON_MAP value for preferences" }

       
      While we understand that disabling openidm.policy.enforcement.enabled allows REST to pass any type of data, what is happening is that this data is getting written to the repo.  If a customer see the 500 internal server error, they cannot correct the payload and update the repo.  They have to remove the data from the backend in order to correct their situation.  We should not be writing data to the repo when we get a 500 error like this.
       
      Looks like openidm.policy.enforcement.enabled​ acts on all parts of the managed object's attribute, e.g. type​, whereas from the documentation, it should only act on the policies​.
       

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                travis.haagen Travis Haagen
                Reporter:
                jesse.ontiveros Jesse Ontiveros
                QA Assignee:
                Brayden Roth-White
              • Votes:
                0 Vote for this issue
                Watchers:
                6 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: