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

Inconsistent behaviour when using objects in conditional filters



    • Type: Improvement
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: 7.0.0
    • Fix Version/s: None
    • Labels:
    • Environment:
      IDM 7, DS repo and Postgres repo (MySQL not tested)


      While trying to find workarounds/best practice recommendations around the related issues (see issue links), I've come across inconsistent behaviour in the way conditional filters are evaluated against properties of type object,  or array of objects:

       1) With a Postgres repo and generic mappings, I can queryFilter on arrays of objects like this:

      _queryFilter='effectiveRoles co "managed/role/roleA'

      However, this does not work when using a DS repo, here I need to specify the index and actual field to match against, like this:

      _queryFilter='effectiveRoles/0/_ref co "managed/role/roleA'

      I've tried all sorts of variations including wildcards and full objects, to no avail.

      Same for delegated admin - privilege filters only work when they reference the actual field - meaning that they don't work for arrays of objects, as returned by virtual property lookups.

      2) Apparently, a conditional filter referring to a field of an object only fires when either

      • the condition itself is updated and objects that match the filter already exist,
      • or, the triggering update operation targets the specific field that contains the match, rather than the containing object.

      For example:
      The following PATCH operation does trigger a condition defined as `/testobjectproperty co "abc"`:

      [{"operation":"replace","field":"testobjectproperty/a","value": "abc"}]

      While the following does not:

      [{"operation":"replace","field":"testobjectproperty","value": {"a":"abc"}}]

      This is problematic for two reasons:
      1) The admin UI uses the latter format, hence any object updates submitted via the admin UI will never trigger such a condition.
      2) In case the object property is an array (as is the case for effectiveRoles), we'll always have a full object in the value of the update payload. I suspect the same is true for updated through virtual property calculation.
      The resulting behaviour is essentially unpredictable.

      The bottom line being: It is currently not possible to use virtual properties derived from relationships in conditional filters without additional onStore scripting, except for single path relationships.

      Furthermore, because of https://bugster.forgerock.org/jira/browse/OPENIDM-15259, relationship-based conditions will need an additional trigger to take effect, which again results in a certain unpredictability unless handled using a postUpdate routine.




            brmiller Brendan Miller
            tim.vogt Tim Vogt
            0 Vote for this issue
            2 Start watching this issue