search

fiplus / fiplus-backend

2 stars 0 forks source link

Delete user #7

Open seanmikalson opened 9 years ago

seanmikalson commented 9 years ago

Needs dreamfactory event listener for when a user is deleted Arangodb extension that deletes the specified user

bkhurshi commented 9 years ago

Do we want to delete the user from the database, or just set the user as deactivated and keep the user's data? Soft-deleting might be safer, especially if we want to allow "revert account" type functionality.

bkhurshi commented 9 years ago

Other issues:

  1. Event creator unregisters. What happens to his event? Does "organizer" status get passed on to another participant. Which brings forward an interesting point: "creator" and "organizer" should be two different relationships to an event.
  2. We'll have to deal with stale links (user was just deleted, was still visible so you clicked on him, what happens?) -- App side
  3. User self-delete vs. Developer-ban-user-delete
bkhurshi commented 9 years ago

According to todappleton "The way the system is designed it's not possible to delete or change the active status of your own user."

seanmikalson commented 9 years ago
  1. Maybe we can delay either this issue until we have events, or delay the whole delete user until we have events? I prefer the former.
  2. Stale links will be dealt with within 'click user' functionality and not delete user?

Yeah, we need to find a way to get around that. I think this also creates an issue with assigning users to roles, which only the system can do. The way that happens now is that there is a setting where any person who is registered, is auto assigned to a role.

bkhurshi commented 9 years ago
  1. The other option is to deal with transferring organizer role when we implement events.
  2. Yep. I'm just putting down things to consider. Brainstorming
  3. The way I was hoping to get around the self-delete issue was to soft-delete instead - set a deleted flag in the user creds table.
  4. Have we configured the auto-assigned role to be general user and not say system admin? I think in terms of roles we only need to have admin and 'general user'. All other "roles" as defined by our use-case can be dealt with relationships.
seanmikalson commented 9 years ago

\1. I like this idea. \3. I think deleting a whole users information when they choose to delete is good practice. First, because it's more transparent from a privacy/data ownership perspective and then, it's simpler. \4. Through the 'open registration' users are auto-assigned the 'fiplus' role which gives them access to the ANDROID api key and also the arango web service, and are not system administrators.

bkhurshi commented 9 years ago

\3. That is a really good point. Even though soft-deleting may be common practice, deleting user info is more in honest. It might be a little messier to implement, but I'm sure it can be done. \5. An interesting concept: http://www.quora.com/What-are-some-UX-best-practices-for-user-account-cancellation

bkhurshi commented 9 years ago

\3. On second thought, I think soft-deleting is the better option for us in terms of data integrity, account re-activation, and data analytics. Additionally, in terms of users having security concerns, even if we do delete the info from the database, in case of a security breach, hackers may still be able to access the "deleted" data. To keep things open and honest with our customers, we can make it clear to them (not in legal lingo), that we reserve the right to keep their data and will do our best to keep it protected. On Unregistering, users be by default soft-deleted and the account "de-activated". In case they really don't want to have anything to do with us, we can provide an option to "hard delete account" which would either delete their data, or anonymize it to maintain data analytics and graph integrity as necessary.