Page Comparison

Decision:

• Deactivating a user won't delete ANY of the content, but associate a Ghost User (or Deactivated User) (anonymisation) with the content, that can be treated as the user itself
  
  • We offer a deactivation feature, because we do not want to loose user-data
• Users should be able to to delete their accounts
  • Remark: this needs to be implemented as routes in some services (that will be called by the user-service) (only a service is allowed to handle it's own data)
  • Deleting a user will exchange (override) his/her data in the actual database, delete his/her private data (decks + all comments, questions, pictures, ....), but no public data (as this was created using an open license and intended to share)
  • We will offer a summarization view of what will be deleted and what will not be deleted (with explore feature (links to the content))
  • If the user owns some groups/organizations/group works, he/she will be prompted to hand it over to another user (no option to skip)
  • Deleting actual content leads to not having it in the database or the filesystem anymore OR to exchange (override) the whole content with some dummy content (like the deleted user above)
  • A deleted user will be deleted from any groups, ...
  • The account name and email (and all other blocked items) become available again, as soon as a user is deleted
  • The user will need to create a new account if he/she wants to come back
  • This is basically the same Github does. So we might be able to reuse their legal/explenation texts
• Deactivated and deleted users will be stripped from the mailing list, reactivated users will be added back
  
  • two options to implement this:
    • sending a newsletter requests an up to date (dynamically created) list from the user-service to get all emails of all active users (Mongo-DB query)
    • the user-service manipulates a list of e-mail addresses by event, that is used by the newsletter functionality

Background

Atm a user is able to deactivate her/his account. How should the services and the frontend handle such a user and her/his data/decks/slides/images/questions/...?

Such an deactivated account (has the flag deactivated: true) is ignored by the user-service (returns Locked 423) for all actions (like login, get user data). But the other services are not aware of this flag.

Action items

...

1. What is the workflow to re-activate a user?

...

2. How to handle data of a deactivated user? Searchable, viewable

...

1. - decks/slides/images/questions/...
2. Is the public profile still available? Perhaps with a deactivated mark.

...

2. Other topics to handle?