Filter collectionCondition appears to be broken?

IdentityIQ (IIQ) IIQ Discussion and Questions
1

Is anybody else seeing some odd behavior with Filter.collectionCondition? Specifically, it doesn’t seem to be joining only once on the table, but rather many times. This is the example query from the Filters and Filter Strings documentation page on Compass:

links.collectionCondition("application.name == \"AD\" && privileged == \"true\"")

With HQL debugging on, this renders as follows:

select
  identityAlias.id,
  identityAlias.name
from
  sailpoint.object.Identity identityAlias
  inner join identityAlias.links identity_linksAlias0
  inner join identity_linksAlias0.application identity_applicationAlias0
  inner join identityAlias.links identity_linksAlias1
where
  (
    (
      identity_applicationAlias0.name = ?
      and identity_linksAlias1.extended1 = ?
    )
    and identityAlias.workgroup != ?
  )

IIQ seems to be joining a second time on the Link table, which is resulting in the behavior that collectionCondition is intended to prevent. It’s going to return any Identity that has a privileged Link and, separately, an AD link. I would expect only a single join on Link, which would have the expected behavior.

I’m seeing this in 8.2 and 8.3.

If you’re seeing this, the following join filter does work, but translates to a potentially less efficient “IN”:

id.subquery(sailpoint.object.Link, "identity", "application.name == \"AD\" && privileged == \"true\"")

2 Likes
2

I can’t recall seeing that before myself, but I also haven’t gone down to HQL-level logging. It’s possible your filterString is being evaluated as an OR condition instead of an AND as you intend. Can you try this filterString out and see if it works properly?

links.collectionCondition("(application.name == \"AD\" && privileged == \"true\")")

Here’s one that I just tested out in my sandbox (8.3p2) that returns everyone with an AD account sAMAccountName (which is my AD account displayName attribute) starting with the letter H:
links.collectionCondition("(application.name == \"AD\" && displayName.startsWithIgnoreCase(\"h\"))")

3

No difference with the parens.

I agree that you’ll get at least the result set you want with your query (AD + display name starting with H), but I suspect you’d actually get MORE than that. You’ll get all identities who have at least one link with display name starting with H who also have an AD account - even if the “H” displayName is on some other Link.

In a small environment, that may be the same result set.

4

If this is behavior you can easily replicate and could document how to reproduce, I’d suggest opening a support case. Sounds like this might be a product regression/bug.

5

Here’s another instance of the same problem.

6

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.