DRAFT - Ability to request to remove an account

[srenault-meeds]

Rationale

Currently, users cannot remove their account. So they still:

• receive notifications
• are considered active and thus existing to any other people
• can be mentioned

However, any other platform proposes a way to remove its own account with some business rules to make sure the user knows what he is doing.

1. Functional Requirements

The proposition is about to give one way to remove its account as a user (any kind of user).
Of course, we have to manage these exceptions:

• if the user is the only admin of the platform, this couldn't be possible.
• if the user has an account synced with an external users management base like an active directory, etc, this option shouldn't be proposed

And as the removal of an account is something not revokable for the user, we should warn the user that this action has consequences. Thus, we propose to make sure the user understands before confirming its removal.

Mockup here:

Consequences of the account deletion confirmation:

• Users who did request its account removal cannot use the platform anymore once done
• They won't receive notifications anymore
• They won't be seen by other members as their profile will be deactivated
• Their activities will remain displayed but there will be identified as deactivated user's activities
• They won't be able to reuse this profile in the future

Proposition:

• To avoid any "human" mistake, we propose to only deactivate the profile once requested
• And a filter will be added to users management "Deletion by user" so the admin can decide to definitely delete the account after some time (if right to do it as only the superuser can do so)

2. Technical Requirements

Expected Volume & Performance

Security

Extensibility

Configurability

User Data

Existing Features

Feature Flags

No feature flag needed IMO

Other Non Functional Requirements

3. Impacts

Documentation

Training

4. Software Architecture

Security

Access

• GUI
• API

Services & processing

• Ex: Scheduled Jobs

Data and persistence

• Macro data model
• Persistence layer
• Use of caches

Clustering

Multitenancy

Integrations

Migration strategy

5. Annexes

• Reasoning that explain the technical choices
• Impacts
• References

[margondicco]

Coud we add an optional option : "anonymize first name, last name and email"