Skip to content

Next

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
    • Help
    • Support
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
GitLab FOSS
GitLab FOSS
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 0
    • Issues 0
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 0
    • Merge Requests 0
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Security & Compliance
    • Security & Compliance
    • Dependency List
    • License Compliance
  • Packages
    • Packages
    • Container Registry
  • Analytics
    • Analytics
    • CI / CD
    • Code Review
    • Insights
    • Issues
    • Repository
    • Value Stream
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • GitLab.org
  • GitLab FOSSGitLab FOSS
  • Merge Requests
  • !7393

You need to sign in or sign up before continuing.
Merged
Opened Nov 10, 2016 by Timothy Andrew@timothyandrew35 of 38 tasks completed35/38 tasks
  • Report abuse
Report abuse

Deleting a user shouldn't delete associated issues.

  • Overview 115
  • Commits 11
  • Pipelines 34
  • Changes 18

What does this MR do?

  • Deleting a user should not delete associated issues

Are there points in the code the reviewer needs to double check?

  • The User.ghost method creates a ghost user whose email/user doesn't conflict with any existing user in the system. This uses an Enumerator - it works well, but the code feels a little complicated.

  • A user's issues are deleted in one-by-one (user.issues.each(&:destroy)). We could potentially use update_all here, although that would skip all callbacks.

Tasks

  • Ideas to look into
    • Permissions for the ghost user
    • Turn off anything else for the ghost user?
    • Any other options while creating the ghost user?
  • Implementation
    • A user's issues are assigned to a ghost user when the user is deleted
    • EE pricing by user - exclude ghost user
      • Ghost user is a user with state = 'ghost' (which automatically makes the user inactive)
      • Don't allow state transitions from 'ghost' to anything else
      • Verify that the ghost user doesn't count towards the license limit
    • Turn off notifications for the ghost user
    • Performance: A user with 1000s of created issues is deleted
  • Tests
    • Added
    • Passing
  • Meta
    • CHANGELOG entry created
    • API support added
    • Branch has no merge conflicts with master
    • Squashed related commits together
    • Added screenshots
    • Check for clean merge with EE
  • Review
    • Miniboss (nick.thomas)
      • Reuse Namespace#clean_path to create the ghost user
      • Avoid race condition while creating ghost users
      • Bulk update issues (update_all)
      • Make ghost a boolean, and enforce that all ghosts are blocked
    • Endboss (rymai)
      • Write tests for Uniquify
      • Tests for database advisory locks
      • User who is continually creating issues can't be deleted
  • Final implementation
    • Don't allow deleting the ghost user (validation)
      • Backend validation
      • Hide the "Delete" button if the user doesn't have access
    • Describe the ghost user in the "Bio" section
  • Wait for merge

What are the relevant issue numbers?

  • Closes #12726 (closed)
  • Equivalent EE MR: gitlab-org/gitlab-ee!862
Assignee
Assign to
9.0
Milestone
9.0
Assign milestone
Time tracking
1
Labels
bug
Assign labels
  • View project labels
Reference: gitlab-org/gitlab-foss!7393

Revert this merge request

This will create a new commit in order to revert the existing changes.

Switch branch
Cancel
A new branch will be created in your fork and a new merge request will be started.

Cherry-pick this merge request

Switch branch
Cancel
A new branch will be created in your fork and a new merge request will be started.