ISC Search API includeNested=false returns wrong data

Feedback Bugs
, , ,
1

Hi all, :slight_smile:

Calling the search API with this body to find an access profile:

{
  "indices": [
    "accessprofiles"
  ],
  "query": {
    "query": "{access_profile_id}",
    "fields": []
  },
  "includeNested": false,
  "sort": [
    "created"
  ]
}

It returns something like this:

[
  {
    "entitlements": [],
    "requestCommentsRequired": ...,
    "owner": ...,
    "entitlementCount": 2,
    "synced": ...,
    "created": ...,
    "description": ...,
    "source": ...,
    "segmentCount": 1,
    "enabled": ...,
    "segments": [
      ...
    ],
    "name": ...,
    "modified": ...,
    "requestable": ...,
    "id": ...,
    "apps": [],
    "_type": "accessprofile",
    "type": "accessprofile",
    "_version": "v2"
  }
]

Note that it says that there are 2 entitlements in that access profile, even though the entitlements attribute is an empty list.

If we call the same query, but with "includeNested": true, it will show the 2 entitlements in that list.

Since we say "includeNested": false, it should not mention the entitlements attribute at all. Now the results are mentioning it, but with a wrong value (an array with 0 elements). Instead of giving a wrong value, it shouldn’t give that attribute at all.

2

Update from SailPoint Support:

@jordan_mandernach This is one of the issues I mentioned regarding the search API. I reached out to SailPoint Support regarding this issue, but I received this not a bug, working by design message. Could you please provide a second opinion on this?

I personally don’t think it should be an enhancement request through an idea portal to ensure that SailPoint is not giving attributes with wrong values in the API response.

For reference, the support ticket is: CS0324817

Kind regards,
Angelo

3

This issue threw me off just the other day. I saw that the entitlementCount is 1, but the entitlements listed was an empty array.

I wonder what it is written in the design document:

Make sure to always return a entitlements attribute, don’t even set it to null, but set it to an empty array.

1 Like
4

I’ll validate this with SailPoint Support.

5

Hello @angelo_mekenkamp ,

Our Engineering team is looking into this.
For reference: here is the internal ticket number (SAASTRIAGE-5682)

2 Likes
6

Thank you for this post and the update @imrankhan!

I’ll stay tuned :slight_smile:

1 Like
7

New update from @imrankhan on the support ticket:

I’m afraid this might be a “Yeah, we created a ticket such that we can stop looking at it for the upcoming years. Sure, the given value is wrong, but it will not be fixed” type of thing.
Of course this is a small thing, and it is too low priority for us too chase it, but it is yet another example of wrong data in ISC that will not get treated as a bug with a quick fix like it deserves.

To me it feels as if the statement “this seems to be the behavior for a long time.” is used as an excuse to not fix it anymore.

1 Like
8

New update from @imrankhan on the support ticket:

This is great news! It took us a month to convince SailPoint that this is really a bug, but it is now officially treated as a bug by them :slight_smile:

Thanking @adamian on his input here, as I was able to use the fact that another person saw it as a bug and his well-defined statment below as munition to go to SailPoint and challenge them on not agreeing with my statement that this is a bug.

Now that we are over this hurdle, we can start waiting again for the fix to be implemented.

1 Like