Deleting user deletes should not delete...
Closed
Deleting user deletes should not delete...
Created by: mvrhov
Thanks to this bug I just lost about 40 tickets 👎
When user is deleted the tickets assigned to him should just lost the assignee.
IMO something like that should also apply to the tickets created by a user which is about to be deleted.
Created by: bbodenmiller
Thanks for the issue report. Please reformat your issue to conform to the issue tracker guidelines found in our contributing guidelines.
By Administrator on 2013-06-13T18:32:46 (imported from GitLab project)
Created by: dblessing
I think the best bet would be to block the user. JIRA handles this in a similar way. If the user is 'removed' the user is marked as inactive in the database and cannot log in but they remain owner of issues, etc. Anywhere you encounter that user's name in JIRA it says "John Doe (inactive)". To my knowledge you cannot delete a user in JIRA. With that in mind I think there are 2 options. 1: Disallow deleting users completely. Block is the only option. 2: Keep as is with the recent functionality where it warns the user that blocking may be the best bet.
By Administrator on 2014-01-07T16:21:36 (imported from GitLab project)
Created by: thajek
Just came across this issue as well and I have a hard time understanding the rationale for deleting issues if the submitter or assignee is deleted. The issue is most likely still an issue and even closed issues should be persistent to allow for historical tracking of bugs.
I can see us using our students (which we may only have for a single project or a short period of time) to test a project and submit an issue they may have but once the students are no longer employed with us I don't really want a bunch of orphaned accounts in the system.
I'm not sure that blocking accounts is sufficient. It seems that there should be a better process during deletion. Perhaps an option to transfer ownership of an issue to another user or have a dummy anonymous user that gets ownership upon deletion or as suggested issues that are assigned to a deleted user become unassigned.
The issue I think should remain regardless of user deletion. The question I think might be is there value in maintaining the history of what user submitted the issue or was assigned to work on the issue? Thus requiring at least some tie back to the users table to get name or email data. If there isn't value in the historical data then perhaps upon deletion changing the author_id or assignee_id to a system type "anonymous" or "orphaned" user might work or simply having an option to globally re-assign all issues authored or assigned to a user about to be deleted to another user.
By Administrator on 2014-02-19T13:59:06 (imported from GitLab project)
Created by: dblessing
A duplicate was reported in https://gitlab.com/gitlab-org/gitlab-ce/issues/260.
By Administrator on 2014-05-11T14:29:29 (imported from GitLab project)
Created by: dblessing
@jvanbaarsen I see your PR with the warning. I'm trying to recall - didn't we also discuss other ideas? Like having a user's issues assigned to an placeholder author?
What about not ever allowing deleted users? Just mark them as "deleted" in the database? Kind of like blocking but a little more serious? i.e. They wouldn't show up in UI lists anymore but issues and comments would still refer to them.
By Administrator on 2014-05-11T14:31:32 (imported from GitLab project)
Created by: jvanbaarsen
@dblessing I dont recall talking about it any further, but what about the https://github.com/goncalossilva/acts_as_paranoid gem for this? That way when deleted_at is present, the record is deleted.
By Administrator on 2014-05-11T15:49:41 (imported from GitLab project)
Created by: dzaporozhets
I agree we should keep issues and merge requests but replace author and assingee of removed user to something else.
I like idea of
ghostuser since it will allow us to place minimal changes in code base. Not sure how to deal with cases when username forghostuser is already taken :)
Anyway it looks pretty simple to me:- create a migration with ghost user
- add ghost user to fixtures for new installations
- remove dependent destroy for issue/merge request in User model
- when deleted -> replace author_id with ghost user and assignee_id with nil
It would be great if someone could contribute this improvement - otherwise we will do in 7.10 or 7.11
By Administrator on 2015-03-14T00:50:39 (imported from GitLab project)
Created by: bbodenmiller
How about just removing the ability to delete an account or converting the current blocked functionality to delete? Essentially allow accounts to be deleted but don't actually delete the account just mark it as inactive. Then give admins the ability to restore accounts.
By Administrator on 2015-03-14T01:22:32 (imported from GitLab project)
Created by: 123Haynes
if we go with disabled, I think we should mark these users somehow so other people know they won't repsond anymore. Maybe another color of the username or add "(deleted)" at the end of the name or something like that. The disabled user mustn't receive emails for mentions anymore either.
By Administrator on 2015-03-14T08:24:25 (imported from GitLab project)
Created by: Razer6
This is the user GitHub maps all deleted users to.
By Administrator on 2015-03-14T08:40:45 (imported from GitLab project)
Created by: vsizov
I think we should avoid the user deletion. it is conventional. But locked users shoud be marked with icon or something like that. On Mar 14, 2015 10:40 AM, "Robert Schilling" notifications@github.com wrote:
https://github.com/ghost is the user GitHub maps all deleted users to.
— Reply to this email directly or view it on GitHub https://github.com/gitlabhq/gitlabhq/issues/4295#issuecomment-80155186.
By Administrator on 2015-03-14T15:31:04 (imported from GitLab project)
Created by: 123Haynes
I actually prefer the ghost user solution. That way people who want to delete their account also delete their personal data. There isn't really much value in keeping the deleted accounts and it'll allow a cleaner user management.
Imagine a university using gitlab for example. Every semester a lot of students will get access to gitlab, but also a lot of students leave so they delete the accounts. If we only disable the accounts the database will only get bigger and bigger with lots of dead accounts that noone really needs anymore.
By Administrator on 2015-03-14T22:09:43 (imported from GitLab project)
Created by: bbodenmiller
I disagree. If a user deletes their account I still want to know where the data originated from. I agree we can hide their email, profile, prevent tagging, etc. but I'd still like issues, comments, etc. to show who originally made them. Additionally let's say they leave the company or university for awhile and then return, I'd like to reenable their previous account rather than create a new one.
By Administrator on 2015-03-15T00:31:41 (imported from GitLab project)
Created by: dblessing
@123haynes I worked with online course management systems in my previous job. They all take the approach that users can't be deleted. Comments, submissions, etc should continue to be attributed to the user that created them. It's perfectly reasonable to delete private content - repos and things when disabling. I don't think a growing database should be a concern.
By Administrator on 2015-03-15T00:47:44 (imported from GitLab project)
Created by: 123Haynes
@dblessing @bbodenmiller Ok... I get you point. It's still different from blocking a user when we delete things like mails or private repos. I also think that deleting a user is somewhat final. Even if we keep the account, I don't think we need to add the ability to revive it. The user can just create a new account. In case they want to use their old username, the admin could simply change it on the old account. This case won't occur very often so I don't think it's worth the hassle of implementing a revive function.
I'd like to make it clear to the admin that deleting a user is different from blocking them.
- Blocking
- retains all data
- prevents access
- can be reverted
- Deleting
- deletes private data
- prevents access
- can't be reverted.
By Administrator on 2015-03-15T09:05:41 (imported from GitLab project)
- Blocking
Created by: dzaporozhets
I think that for private instances users are managed by companies and as a company you don't want user to remove account with all data. I don't even think it makes sense to have block/remove feature available for user. The only difference is GitLab.com where I have no idea yet. Wondering how services like dropbox handle i.
By Administrator on 2015-03-15T18:25:51 (imported from GitLab project)
Created by: dosire
I agree with @123Haynes, blocking is reversible, deleting removes the name of the user everywhere. I think we should have a setting where you prevent users from deleting themselves, some enterprises might want want this for traceability.
By Administrator on 2015-03-15T20:51:35 (imported from GitLab project)
Created by: dzaporozhets
With current behavior user can remove oneself only if signup enabled.
We anyway need ghost user for instances like GitLab.com. We dont want to lose issues and merge requests when user removes oneself.
By Administrator on 2015-03-16T06:58:57 (imported from GitLab project)
Created by: bbodenmiller
I still disagree that delete & block should be different (e.g. Delete profile on Facebook is a reversible action, delete branch on GitHub is reversible, etc.) however I can live with that. That being said in the delete scenario I'd still like to see names remain with the public content (issues, comments, etc.). Many other systems treat writing & author name as irreversible once wrote:
- Facebook comments remain in original form on account deletion
- Sent emails remain in original form on account deletion
- git commits remain
- Books & papers cannot be unwrote
By Administrator on 2015-03-16T15:06:59 (imported from GitLab project)
Created by: 123Haynes
@bbodenmiller I think the deleting is important for privacy reasons. It doesn't make much sense for companies, but for instances like gitlab.com it may attract more people if they know that they are able to delete their private data. But I'm ok with keeping the name. So delete could be:
- Delete everything in the personal namespace of that user and all private projects where noone else has access
- Delete his mail addresses/ replace with a dummy mail
- Disable all notifications in the settings of that user
- Delete his ssh keys
- Delete his authorized applications
- Prevent access (maybe block the user, but add a deleted flag?)
- Make it known to other people that this account is deleted (i.e. with an icon)
Like this it would be like blocking a user, but the user doesn't have to manually delete all his private data.
By Administrator on 2015-03-16T15:26:21 (imported from GitLab project)
