Users to be able to disable and delete their account

[aishwaryashikshalokam]

With updated guidelines of iOS, it is important that users have a choice of disabling or deleting their accounts.
Without this option, iOS will reject all the new app versions.

I recommend the following flow:

1. Users can disable the account: Users will be logged out of the app immediately if they choose to disable their account. They can log in to the app with the same credentials. Once they log in, their account will be reactivated again.

2. Users can delete the account: Users will be logged out of the app immediately if they choose to delete their account. They will not be able to log in to the app with the same credentials. They will need to create a new account in this case and will be treated as new users.

Before taking any of the above-mentioned actions, they will receive a warning message stating what the action will impact.

Can we please come together and detail the flows and requirements for the same? This is an important activity before the transition may happen. ( as discussed in the last call ).

Please add others as relevant to the thread.

@madhucr @alok-os @kameshbhr @mmanimegalai @vijiurs @Prateek-slokam @aks30 @varsha-sl @rhwarrier @Krishnaj20 @kiranharidas187

[Krishnaj20]

@aishwaryashikshalokam - thanks for starting this thread. Is both disabling and account removal mandated by iOS?
Do we know how others are addressing this? Are there any common workflows which can be referred to?
Also, for the various stakeholders on the platform - such as content creators, consumers, administrators what should be the workflow.
For ex., if a creator deletes his/her account what should happen to the content created by the creator?
If you can take the lead and create a draft document of these possibilities, we can bring in specific volunteers from the community to finalize the document and take it forward.

[aishwaryashikshalokam]

@Krishnaj20 in my understanding iOS only mandates deleting account flow. But we should definitely give a choice to the user to disable it as well.
Deleting an account will have more impact than disabling the account, thus it is important to give both options.

I have referred to Instagram and Facebook and both of them give both options to users.

Yes, we need to see how will consumption and creation of data at the backend will get impacted for different roles on the platform.

We will need to brainstorm on it together. Can all the relevant folks come together and brainstorm on the same?
Will 4:30-5:30 work tomorrow?

[rhwarrier]

There's multiple angles that this needs to be looked at from.

1. What does 'deletion of an account' mean?
2. What data about the user remains within the system, what gets deleted? How will we have access to this data?
3. What does the iOS policy specify, in terms of what can we retained, and what needs to be dropped - when a 'delete' happens?
4. We have Managed User Accounts - what happens to these if the parent account gets dropped?
5. How do we deal with certificates that have been generated for the user?
6. What about content generated on the platform - Content created, Reviews, DF posts, etc.?

These are just a few things that came to mind, I'm sure there is more.
We need to look at this holistically, and ensure all angles are thought about, before we roll something out.
Please initiate a confluence doc where all such concerns can be captured, and sufficiently addressed.

Also, given the size of the problem, it may make sense to think of a feasible work-around to unblock urgent use caes.

@SanthoshVasabhaktula
@vrayulu
@mmanimegalai
@maheshkumargangula
@reshmi-nair
@sharathkashyap
@vinukumar-vs
@anandp504
@coolbung
@luckynvdu

[SanthoshVasabhaktula]

Just to keep in mind - deleting an account can be a feature within Sunbird that would disable the user to login, but what should happen to the transactional data generated by the user is always instance specific. There cannot be any assumption or hardcoding within Sunbird. Even the iOS app is instance specific and the behaviour after account deletion should be within the instance. Of-course SB can provide a few default behaviours out of the box, but that is always configurable or overridable.

[aishwaryashikshalokam]

Adding @luckynvdu @sharathkashyap to the thread too

[kameshbhr]

While it is important to think of the problem holistically, detailing out all the requirements for disable, delete and all the possible scenarios of what they can/should do will take a lot of time and effort. So, if we want the iOS policy issue to be resolved asap for getting iOS app upgrades, I suggest there should be a sharp focus on it.

1. What is the minimal requirement from iOS policy team to enable iOS app upgrades?
2. Can that minimal requirement be implemented as the default implementation of the Sunbird, as a first cut?

As per the discussion we had with iOS team, here is my understanding of what is the minimal thing required for them:

1. There should be a delete account option for any registered user
2. The delete account option should clearly tell a user exactly what data will be deleted and what will be retained
3. The minimum requirement of delete functionality is:

• Delete login credentials so that user cannot login again
• Delete any PII information associated with the user. Essentially once the account is deleted, one should not be able to trace back any data to the deleted user, which is personally identifiable - name, email, mobile
• Deleting the following is not mandatory: Anonymous/Anonymized Transactional data, Content Created by the user (we can optionally make creator unknown, but that is not mandatory)
• Deleting Certificates - is this required or not was not clear from the discussion. But I guess once the account of a user is deleted, the certificates wouldn't be accessible through any API, so it might be fine to keep the artifacts.

4. The deletion process can be asynchronous if required. It can specify the user that the account will be deleted by certain time.

[Krishnaj20]

@aishwaryashikshalokam - Community has shared their views on this discussion thread. We can finalize the scope and next steps in a call and publish the minutes in this thread. Please include the below folks in the call.

@vinukumar-vs @SanthoshVasabhaktula @rhwarrier @kameshbhr

[aishwaryashikshalokam]

Dear Krishna

I have shared the invite for Thursday i.e 15th December at 5:00 pm

[aishwaryashikshalokam]

Dear All

As discussed, I have created a document based on our discussion.

Here is the link: https://project-sunbird.atlassian.net/l/cp/81J0n10j

For everyone's information:

Udemy, Coursera, Edx, and Google do not allow users to create a new account using the previously deleted ID and Username.
I have added this as well in the document. But we still need to discuss what route should we be taking on this.

At the end of the document, I have also captured a very high-level flow on how the deleted flow will be for users.

Requesting everyone to go through it to see if all the discussion points are correctly captured

[Krishnaj20]

@aishwaryashikshalokam - We will add this to ED backlog open for community members to pick up and contribute.

@rhwarrier @pallakartheekreddy - fyi

@madhucr @alok-os @kameshbhr @mmanimegalai @vijiurs @Prateek-slokam @aks30 @varsha-sl @rhwarrier @Krishnaj20 @kiranharidas187 @vinukumar-vs @chitranshu-keshav

[aishwaryashikshalokam]

Hi @Krishnaj20

Reviving this thread.

Can we start working on PRD from next week please?
Will Tuesday i.e 28th March from 4:30-5:15 work for us to come together for first round of PRD discussion.
As you mentioned earlier that you and Rahul can take up ED, Lern, Knowlg, Obsrv, inQuiry & coKreat BBs, we can start working on it together.

[Krishnaj20]

@aishwaryashikshalokam - we can do 29th Mar, 3-4, if it works for you? Both Rahul and I have another meeting on 28th.

@rhwarrier

[aishwaryashikshalokam]

Hi @Krishnaj20

Somehow I did not get notified of your response.

I am sharing the invite. Will you and Rahul be able to join?

If not today, will tomorrow 11:00-12:00 pm or 12:00-1:00 pm work for you and Rahul?

[aishwaryashikshalokam]

As discussed offline, shared invite for 4th April from 3:00-4:00pm with you @Krishnaj20 and @rhwarrier .

[Prateek-slokam]

As discussed in this thread, for this delete account functionality, @Krishnaj20, @rhwarrier and I have put together a deck summarising the basic details and how we can go about it. The deck mentions a short term approach (mainly to unblock iOS instance since the policy guidelines require it), where the idea is to directly let only the user without platform roles be able to delete the account but others directed to support keeping in mind that special roles might have a few more thought points like course creator in the mid of a course with running batch.
Please add your comments to it and let know if there are any questions.
The document https://project-sunbird.atlassian.net/l/cp/81J0n10j can be referred to for the details.

@madhucr @alok-os @kameshbhr @mmanimegalai @vijiurs @aks30 @kiranharidas187 @aishwaryashikshalokam
@vinukumar-vs @SanthoshVasabhaktula @vrayulu

[Prateek-slokam]

@ALL Please do let know if the solution approach is fine for the 1st phase by 16th June. It would be preferrable to start work towards this at the earliest.

[Prateek-slokam]

@vrayulu Can we please schedule a call to discuss this in the next week for the DC review also.