I have a web services SaaS source, where I get an account attribute status which can have values Active and Disabled. In the UI β source β edit configuration β Connection settings, there is an attribute called Account Enable Status Attribute. This field (and others) is not documented in the corresponding connector documentation.
If left empty, the field suggests status = Active (with spaces around the equality sign). The instructions next to it suggest status=Active (without spaces around the equality sign). I tried out both and noticed that this is giving a different behavior. This is not user friendly and also not matching to the regular Web Services connector. Both options are not completely working, but I noticed it comes closest when having status=Active without spaces.
Also I noticed that the UI value for status is not always matching the expectations. Upon closer inspection in the json object of the account when fetching it through GET /v3/accounts/id, I noticed the account attributes have two values on top of the account attributes that we have defined. They are IIQDisabled and IIQLocked, which I have seen sometimes for sources from other connectors as well. However, if one tries to enable an account that was disabled, the value IIQDisabled disappears and the attribute disabled wait value true appears in the account attributes (and thus not only outside of the attributes array). As a consequence, the UI gives the wrong value for status. (I think the UI should both show the value for the account attribute status as known in the account schema, as the value calculated from status=Active, AKA, the IIQDisabled value.
I think another round of testing should be done by SailPoint on this connector. As it does not seem to behave correctly.
Hi @angelo_mekenkamp, could you please raise a support ticket if not done yet. Looks like this needs to be investigated in detail considering specific scenario. Thanks!
New update form SailPoint Support, who told me the reply of the connector team
They confirm that using status = Active as suggested by the UI field when left empty can lead to incorrect results, but I did not get an internal ticket number for the fix. I will ask them for it.
FYI @dinesh_mishra, I will reply to support again as the connector team does not seem to get my point yet that either they should start supporting status = Active, or they should stop suggesting they support it through the UI.
Hi @angelo_mekenkamp, so basically due to space, the status validation is getting failed and it should be corrected so that config should be respected. There is an internal ticket and we are on top of it. Be rest assured that this use case will be handled appropriately. The ticket ID will be also communicated with you via support ticket, it is already in open state.
Hi @adamian, we are going to support the white space, i.e. no matter whether the input is with space or without space. It will work once the changes are available.
For ticket status, I would suggest to follow up via support ticket in case you are also looped in there.
@dinesh_mishra, @adamian is from a different organization and therefore has no access to our support tickets. This would be one additional argument for SailPoint to have a list of current bugs available for all partners/customers, such that everyone can track the issues there, and see when they are fixed.
In addition, if you allow partners/customers to click a +1 button to show they experience the same issue, we would not need to waste time submitting bug tickets to SailPoint Support, provide all kinds of details and reproduction steps, just to then figure out that SailPoint is already aware of the bug (for weeks).
I tested again and now it works!
I have asked SailPoint Support to only ask to confirm an issue has been resolved after the fix has been deployed, in order to save time on useless bug testing.
@community_moderators, can you please mark this bug as fixed, as I unfortunately canβt do this myself.