A user creates an account that they don't activate and they try to delete the account. The delete button's request returns a 403.
I'm testing GDPR features in a sandbox spun off master. I created an account and didn't activate it (i.e. I didn't click the link in the activation email it sent me).
I delete my account with the Delete button in the "Accounts" menu. The UI tells me something went wrong. Using the developer console, I see that the request sent by the delete button returns a 403. Now, I activate my account with the emailed link. I try deleting again. The deletion works.
Verify that a learner who hasn't activated their account has the button deactivated and sees an error message.
Use same pattern as the social auth error as seen in the screen shot.
If the learner is both inactive and has social auth links, only show the activation error.
Verify that when the learner activates and refreshes the page, the button is active again.
Speak to product () for copy.
The user is logged in upon account creation, but cannot login again after that initial session. Problem here is that we are trying to authenticate them to check their password, and that's what is failing (resulting in the 403) because the user's is_active flag is still False.
I think the solution is to check if the user is active when they go to delete the account and tell them to activate if they want to delete. We won't be able to validate the password otherwise, and I don't think it makes sense to force-validate them if we don't have the password confirmation.
That lands in UI land, which is rather out of my wheelhouse. I think and did this initial work on this, not sure who should pick it up from here.
Side note - as part of the fix we should update the comments in DeactivateLogoutView as they are out of date:
"If a user who is not a superuser tries to deactivate a user, the request returns an HTTP 403 "Forbidden" response." etc.
I did the initial work on the deactivate/logout endpoint and can certainly contribute more there. While I'd be happy to help with the frontend side, I think things will move most quickly if Growth takes on that part.
@team - my thought is we can use the same approach for oauth check with a modal.
Blocked on copy and the existing flow for third party auth checking.