Create a workflow to deprovision a user, who has left Kitware as an employee

[mgrauer]

The problem is that when users leave the company, we want to cut off their access to potentially private data, but we don't want to delete that data.

Paraphrasing from @zachmullen email.

disabling login / removing access to the account seems like the best option to me. If the employee wants access to the instance after leaving, we can work with them ad hoc for that, but I suspect that will be rare. [ed: we need to ensure this works in an oauth world where access to e.g. GitHub credentials are not tied to an employer domain email]

We should probably add a button to disable a user's access altogether, which would need to deactivate all their API keys and remove all their session tokens.

[jbeezley]

Setting User.is_active will probably do all of that, but we should verify all of the associated libraries respect it.

[jeffbaumes]

Probably worth mentioning that we will likely also want something stronger: a GDPR-compliant wipe of user data when requested.

[brianhelba]

Probably worth mentioning that we will likely also want something stronger: a GDPR-compliant wipe of user data when requested.

That's often very problematic when it comes to database integrity, retained backups, etc. In some other cases, when users have requested that their account be deleted, we've deactivated the account and ensured that it was made invisible to any external APIs.

There is a lot more to "GDPR compliance", so if targeting that is a requirement, I think it may involve much more work (e.g. making cookies opt-in disrupts a lot of Django's default behavior). I don't think we should attempt to casually introduce legal compliance as part of other feature implementations, rather, we should do a dedicated planning session to gather all the legal requirements first.

[jeffbaumes]

@brianhelba Agreed this is out of scope for this issue, just mentioning it so we don't follow a path that boxes us out of adding that kind of compliance in the future.