GDPR Testing: user can't delete their account without activating it first.

Description

ISSUE
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.

REPRODUCTION STEPS
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.

Acceptance Criteria

  1. Verify that a learner who hasn't activated their account has the button deactivated and sees an error message.

    1. Use same pattern as the social auth error as seen in the screen shot.

    2. If the learner is both inactive and has social auth links, only show the activation error.

  2. Verify that when the learner activates and refreshes the page, the button is active again.

Implementation Details

  1. Speak to product () for copy.

Steps to Reproduce

None

Current Behavior

None

Expected Behavior

None

Reason for Variance

None

Release Notes

None

User Impact Summary

None

Activity

Show:
Brian Mesick
May 9, 2018, 4:19 PM

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.

Sandy Student
May 9, 2018, 5:34 PM

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.

Brian Beggs
May 10, 2018, 3:14 PM

FYI

Mike Dikan
May 10, 2018, 3:31 PM

@team - my thought is we can use the same approach for oauth check with a modal.

Diana Huang
May 15, 2018, 2:51 PM

Blocked on copy and the existing flow for third party auth checking.

Fixed

Assignee

Diana Huang

Reporter

Alessandro Roux

Reach

None

Impact

None

Platform Area

Archived Product Areas - LMS

Customer

None

Partner Manager

None

URL

None

Contributor Name

None

Groups with Read-Only Access

None

Actual Points

None

Category of Work

None

Platform Map Area (Levels 1 & 2)

None

Platform Map Area (Levels 3 & 4)

None

Story Points

2

Sprint

None

Priority

CAT-3
Configure