Are there official definitions for the following statuses below?
Filtered – Dependency
Filtered – Does Not Exist
Filtered – Exists
Filtered – Requested
I have a scenario where a de-provision could not happen due to Filtering. Tried adding “noFiltering” tag as many posts suggested but it didn’t help. Or I’m not sure if I added it in the correct way. Any help would be much appreciated!! Thanks.
Hello @Preethiarunagiri ,
Were you able to resolve this issue?
did you solve that problem?
Hello!
Any updated on that? Did anybody solve this problem?
In order force IIQ not filter, “noFiltering” option should be set to true in Provisioner API using setArgument() method well before sending the plan is passed to provisioning engine.
Hi kalyankumar_saha!
In my case, which is a JDBC connector provisioning, sometimes some values specified on the role’s Provisioning policy are getting filtered:
=> in the related Transaction (on the Administration/Provisioning tab) I can see these values in the “Filtered” cathegory with “Reason: Requested”.
As a result, in my JDBC provisioning rule I’m getting nulls. I dont understand why it’s filtered by default..
So the only solution for this would be a setting of “noFiltering” parameter to true on the ProvisioningPlan object in the Provisioning Rule?
Do you know if there any other workaround (may be in IQ configurations), without changing anything in the code of provisioning rules?
Best regards,
Hello@Preethiarunagiri,
the filter reason Requested implies that there is an open ProvisioningRequest asking for the same attribute operation with the same value on the same account.
You can check for ProvisioningRequests either on the debug pages by selecting that object type or you can head to the pending provisioning transactions in the admin console. If you find that item and if you decided to delete it a new provisioning attempt would no longer be filtered.
The question is why those requests are pending in the first place. One reason I had in the past was that during development of a new connector/application the features or integration configs where wrong for a while and requests where redirected to manual actions. Once fixed IIQ would like to properly call provision on the connector but decides not to because those requests are still present. If that was the case for you also you could savely delete the ProvisioningRequests.
Regards,
Patrick
Thanks @pwehinger . That’s how we resolved this issue back then!! Thanks everyone for ur input as well…
Thanks @pwehinger ! we were able to resolve the issue by overriding the previous provisioning transactions, then it stopped filtering the remove operation.
hi @pwehinger ,
I went ahead and deleted all the provisioningRequest and identity request objects related to the access request for my Web Service role. I am still seeing the Channel:Filtered under provisioning. This happens for a user for whom I have never made a provisioning request.
When I looked at the provisioning queue. I see multiple provisioning transactions. ( I only made one request). The source for one transaction is LCM and the source for the other , which I think is a duplicate is Rule. Not sure how this is happening. I have attached a screenshot.
