delta/gitlab/gitlab-ce.git/app/services/users/destroy_service.rb, branch docs-pages-https

Remove soft removals related code

2018-01-08T16:04:45+00:00

This removes all usage of soft removals except for the "pending delete"
system implemented for projects. This in turn simplifies all the query
plans of the models that used soft removals. Since we don't really use
soft removals for anything useful there's no point in keeping it around.

This _does_ mean that hard removals of issues (which only admins can do
if I'm not mistaken) can influence the "iid" values, but that code is
broken to begin with. More on this (and how to fix it) can be found in
https://gitlab.com/gitlab-org/gitlab-ce/issues/31114.

Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/37447

Fix user membership destroy relation

2018-01-02T15:06:44+00:00

Make sure repository's removal work for legacy and hashed storages

2017-08-22T04:33:20+00:00

Fix current feature related specs

2017-06-28T10:32:34+00:00

Refactor the DeleteUserWorker

2017-06-05T12:08:06+00:00

Hard delete users' associated records deleted from AbuseReports

2017-04-16T15:36:33+00:00

In the case of spammers, we really want a hard delete to avoid retaining spam.

Closes #31021

Implement review comments from @DouweM for !10467.

2017-04-06T17:09:40+00:00

1. Have `MigrateToGhostUser` be a service rather than a mixed-in module, to keep
   things explicit. Specs testing the behavior of this class are moved into a
   separate service spec file.

2. Add a `user.reported_abuse_reports` association to make the
   `migrate_abuse_reports` method more consistent with the other `migrate_`
   methods.

Move a user's merge requests to the ghost user.

2017-04-06T13:28:57+00:00

1. When the user is deleted.

2. Refactor out code relating to "migrating records to the ghost user" into a
   `MigrateToGhostUser` concern, which is tested using a shared example.

Fix race condition where a namespace would be deleted before a project was deleted

2017-04-02T12:37:04+00:00

When deleting a user, the following sequence could happen:

1. Project `mygroup/myproject` is scheduled for deletion
2. The group `mygroup` is deleted
3. Sidekiq worker runs to delete `mygroup/myproject`, but the namespace and routes have
   been destroyed.

Closes #30334

Don't allow deleting a ghost user.

2017-02-24T11:20:20+00:00

- Add a `destroy_user` ability. This didn't exist before, and was implicit in
  other abilities (only admins could access the admin area, so only they could
  destroy all users; a user can only access their own account page, and so can
  destroy only themselves).

- Grant this ability to admins, and when the current user is trying to destroy
  themselves. Disallow destroying ghost users in all cases.

- Modify the `Users::DestroyService` to check this ability. Also check it in
  views to decide whether or not to show the "Delete User" button.

- Add a short summary of the Ghost User to the bio.