Issues with account self-deletion feature

We’ve recently finally had someone actually use the account deletion feature, but they did so in error, and now they can’t re-register because their email address is ‘in use’.

Is this by design? I get why their accounts can’t be recovered, that’s kinda the point of ‘deleting’ them, but why are retired users unable to start entirely new accounts? Surely keeping whatever list of email addresses wherever it is that prevents re-registering defeats the object of deleting them in the first place, and violates GDPR? We’re effectively still storing their email address somewhere, even if it’s not easily accessible, so the user has not been forgotten

1 Like

I’m not sure of the details here but perhaps @macdiesel may have links to relevant documents or an answer if that is possible?

First I want to say that while we decided to open up these end points to allow the open source community to build upon them it was never our intention to support this feature as edX’s GDPR requirements may not be the same as other organizations.

Having said that let me point you to a few things. The emails are not kept, but what is kept an asymetric hash of that users login to prevent a user from re-registering with the same email. Also if you are only running the Open edX application the retirement process isn’t being fully completed anyway. You also need to run these jenkins retirement jobs that do the actual work of removing the data: https://github.com/edx/jenkins-job-dsl/tree/master/platform/jobs. (look for the jobs that start with Retirement*).

My suggestion to you if you don’t want or like the feature of not allowing re-registration of an account using an existing email address, remove that block of code. That said please note again that if you are not configured and running the jenkins jobs above the users data is not actually removed. The reason this is put in to place is to ensure that an account can’t be re-created during the cool off period between when a user requests retirement and when that retirement is executed.

Another option would be to submit a PR with a new API endpoint that would remove this hashed email once the retirement is complete then add it as a step in the jenkins job to call that end point at the end of it’s process.

Brian

1 Like

Thanks @macdiesel for the context here - very helpful! Explains a lot, and glad to hear the emails are only stored as an asymetric hash. That makes it a lot easier. Will take a look into this and see how to make it work better for us - thanks for the map to how to do so.

@MHaton it would be a good feature.
Could you inform people here if you figured a way to approach this?

@MHaton @macdiesel Do we have any news about this?

Thank you in advance