ISC Workflow jsonpath array becomes single object

Feedback Bugs
,
1

Hi all, :slight_smile:

I noticed a bug in workflows. To show this bug, let’s take a simplified use case where we want workflows to send an email that displays the native identity of all disabled accounts of a specific source.

We start with the action Get Accounts and get all accounts from a specific source, then use the Send Email action. In the Send Email action, we use the templating context and define the variable disabledAccounts to be $.getAccounts.accounts[?(@.disabled)].
We then loop over the disabledAccounts in the body of the Send Email using apache velocity:

#if (${disabledAccounts}) The following accounts are disabled: #foreach ( $account in ${disabledAccounts})${account.nativeIdentity}, #end#else No accounts are disabled.#end

This usually works. $.getAccounts.accounts[?(@.disabled)] is a JSONPath expression and SailPoint refers in the documentation to the Goessner implementation of JSONPath.

According to Goessner, this JSONPath expression will return an array of the objects, unless there is no match, in which case it might return false instead of an empty array.

However, the behavior of SailPoint here is different when only one account matches the filtering. It should, according to Goessner, give an array with one object in it, such that we can loop over this array of one object. Now, SailPoint returns the single object instead of the array. As a consequence, if we now loop over the results, it does not iterate over the array of one object and have one iteration where we can describe the account information. Instead, it loops over the attributes of the account.

This is causing issues to the workflow and we would as a workaround, build a special condition check to determine whether the object we iterate over contains accounts or account attributes.

I have contacted SailPoint Support about this (CS0259813) and as a response I hear that this is considered as an enhancement request rather than a bug description.

To me, If SailPoint documentation is saying that IdentityNow is behaving in a specific way, and it doesn’t, then ensuring that the system will behave this way is not an enhancement, but a bugfix, which should receive the correct priority.

Kind regards,
Angelo

2 Likes
2

Seconded, and think this issue might extend beyond workflows. I experienced it first hand using the REST API calls.

For example, if I call the list-accounts endpoint using PowerShell, being specific to a single identity (Documented here: list-accounts | SailPoint Developer Community). Initially I expected a JSON hashtable (list) returned, I ran into an issue where even though I knew there was an identity with a single account, I wasn’t getting any return. Here’s my first iteration of the important part of the PowerShell function:

$response = Invoke-RestMethod "
https://$($IdentityNowConfiguration.orgName).api.identitynow.com/v3/accounts?filters=identityId%20eq%20`"$($profileID)`""
-Method 'GET' -Headers @{Authorization = "$($v3Token.token_type) $($v3Token.access_token)"}

return ($response | convertfrom-json -AsHashtable | ConvertTo-Json)

The “convertfrom-json -ashashtable” can’t convert the response if a single object is returned because it’s not returned in a hashtable/list. This caused me to write the function to return whatever the API gives me and then deal with the two potential type returns, which is not ideal. I would also prefer the implementation to match the Goessner standard.

3

This issue is unfortunately still existing.

1 Like