Deprovisioning a user via SCIM works… except for many quirks that are issues - I’m hoping you guys will have a good laugh at how I’m doing it wrong and provide corrective guidance…
- The result of the DELETE call is a 404 error. But the call succeeded. This seems like a bug. Makes it hard to see if something went wrong, or if everything is fine.
Good news - The DELETE does create the “First Last’s Previously Assigned Tasks” project which is a relief, but…
2. It then adds this project to a team. In our case it is ‘Administrative’ but I think that is ‘random’ because that team appears to be a regular team in our organization.
3. It then adds every admin in the company to the project and spams them a notification.
4. I then have to list every project in the ‘team’ to find this thing and assign it to the manager because there is no API to find a project, only APIs to bulk list them then search on the client side.
5. There is no way to remove a project from a team so this team will accumulate projects for terminated users until something blows up I guess?
What would be helpful is if we could at lest get the project gid back in the result from the delete call to allow setting the correct owner/member information. In an ideal world, just let us specify the owner at termination time so this is handled. Also, the team concept is basically junk in this scenario - unfortunately enterprise customers are stuck with it so how about at least an API to move the things into a ‘Terminated Users’ team that has no members or something?
I’m very concerned that this is fragile code on my end. I cannot reasonably pull down all projects since there are many thousands in our company - and having to find it by name is also weak since there is nothing stopping a duplicate from existing. Which team a project gets added to appears undocumented so that makes me believe ‘unstable’ behavior. And lastly, spamming all the admins every time there is a term is really nasty and a way to avoid that would be very helpful.