We have a working source that supports direct provisioning. We want to turn this source into a read only source, for testing purposes (for example to do what-if analysis before a go-live).
So what we do is remove the ENABLE and PROVISIONING features from the source JSON.
We then create a role, which points to an entitlement from this source. We don’t assign any approvers to this role. We do allow access requests though
This should not occur. There is no approval flow, so no approval needed, so there can’t even be such a thing as a self-approval here. So it should directly create a manual task to the source owner, which is me (angelo_mekenkamp) in this case. In the same way how, when we had the features added, it immediately provisioned the access. Now the requests gets forwarded to a random IdentityNow admin.
This makes it more difficult for developers to test the source by temporarily blocking direct provisioning to the source. I believe similar behavior occurs to sources that actually do not support direct provisioning, not just sources where we deliberately removed the PROVISIONING feature flag.
I mentioned this to @jennifer_mitchell, who agreed with me that this behavior is wrong and asked me to submit a bug report for this.
In addition see the following configuration where we would even allow self-approval on roles that have approval steps defined. I don’t think this configuration should actually be relevant here, since we specifically have no approval flow on this role, but I still want to show it for completeness sake:
Hi @angelo_mekenkamp , we are also running into the same issue , did we get any fix on this. It would be great if you can share the inputs on the resolution.
Thanks
Narendra
@jennifer_mitchell is aware of this issue existing and asked me to communicate this issue to Support, which I did 24 days ago. SailPoint Support wasn’t able to reproduce the issue on their side and asked tenant access, and I have given them 2 weeks worth of tenant access 10 days ago. I have not heard anything from Support since then, nor have I received an internal ticket from SailPoint Support. SailPoint Support has assigned this issue as a P4 issue.
Since @bkumar592 is noticing the same issue as I and is also interested in the resolution, this might be a good argument or use case for you to use in the attempt to improve the process of reporting and handling of bugs?
Until then, do you advice @bkumar592 and others to submit a support ticket for the same issue as well? Or should they do something else instead?
I think it’s a good idea to open a support ticket for this. I don’t have the time right now to try and reproduce this, but at least support can take a look and help out.
FYI, I have been able to reproduce this and have shared the steps I used with support as well. Hopefully that will help them with clarity so the work can be considered and prioritized. (I don’t own this area, but I am doing what I can to help.)
We’re also experiencing the same “Self-approval reassigned” issue when no approval flow is set, it’s making access request testing very difficult
We faced a similar issue regarding “Self-Approval reassigned” in one of the access requests. The line manager went to OOO and assigned the work reassignment to one person, however, the pending approval request was not assigned to that person, instead it was assigned to the line manager.
ReassignmentChain:
AAA > Automatically reassigned to BBB > Self-approval reassigned to AAA
Can anyone help me understand if this happens anonymously with any access request and it is a product issue, or is there any particular reason behind this “Self-approval reassigned”?
It took 10 months, where SailPoint Support continuously told us that the engineering team is working on a fix (see screenshot above), but we have a new update now. Where the engineering team is showing that they were able to reproduce the issue.
I have to say that I am shocked that it takes so much time, and the next update was not that it was fixed, but that they were only able to reproduce the issue. @colin_mckibben, @jennifer_mitchell, @harshamin9, @christina_gagnon. I think it might be good to check out this case (CS0285986), see the screenshots above, including all the updates from SailPoint Support, and check if either the handling of bug reports in this manner (both actions and speed) is as SailPoint expects, or to see what the cause of this bug handling is here and how it can be fixed).
I’ll follow up with support and our internal teams, think we might have some internal (mis)communications passing each other in the night. We don’t need that confirmation. I became aware of it last week, and I’ve got what I need.
I’ve got a solid understanding of the problem and we know how we’ll solve it. (feel free to correct me if I’ve got it wrong here, in my own words):
Problem State: Delimited file source manual provisioning tasks sometimes will be done by the user who requested or otherwise needs the access. Today, ISC treats that as a “self” action, which is blocked across the platform. It’s not unusual for a user to handle their own manual provisioning in a disconnected system, especially in the case of testing functionality.
Desired State: Provisioning tasks can be assigned to the user for whom the task is for without the “self governance” platform-wide logic applying.
We are having conversations about when we can tackle this now, assuming the above summary is correct. We know what changes we’ll need to make to improve this. I cannot commit anything to you at this point on timing, unfortunately.
Cool, thank you @christina_gagnon! I am curious on both the issue itself as well as why it should 10 months for issues like these making progress with SailPoint Support (as can be seen in the screenshot). For the former it seems @aaron_andrew is on it, so your help for the latter would be most appreciated
Thank you for looking at this issue @aaron_andrew!
I think you have the crux of the issue, with the small, but crucial addition that this is not only for Delimited file sources, but for any source where we (temporarily) remove the (de-)provisioning based features from the source JSON, to ensure that provisionings (temporarily) occur through a manual task.
And indeed, if the manual task should go to the source owner, it should always go to he owner, even if the owner was the one who requested the access themselves. Self-Approval prevention and messages should only be applicable for the approval part, not for the execution bit.
