Skip to content

GitLab Next

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • See what's new at GitLab
    • 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
  • Requirements
    • Requirements
    • List
  • Security & Compliance
    • Security & Compliance
    • Dependency List
    • License Compliance
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • Code Review
    • Insights
    • Issues
    • Repository
    • Value Stream
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
  • GitLab.org
  • GitLab FOSSGitLab FOSS
  • Merge Requests
  • !12373

Merged
Opened Jun 22, 2017 by Toon Claes@toon8 of 9 tasks completed8/9 tasks
  • Report abuse
Report abuse

Add User#full_private_access? to check if user has access to all private groups & projects

  • Overview 7
  • Commits 1
  • Pipelines 4
  • Changes 7

What does this MR do?

In CE only the admin has access to all private groups & projects. In EE also an auditor can have full private access.

To overcome merge conflicts, or accidental incorrect access rights, abstract this out in User#full_private_access?.

User#admin? now only should be used for admin-only features. For private access-related features User#full_private_access? should be used.

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

Any other situations where this method should be used?

I searched the EE codebase for the use of admin_or_auditor? and replaced those.

Why was this MR needed?

Backported from gitlab-org/gitlab-ee!2199

Does this MR meet the acceptance criteria?

  • Changelog entry added, if necessary
  • Documentation created/updated
  • API support added
  • Tests
    • Added for this feature/bug
    • All builds are passing
  • Conform by the merge request performance guides
  • Conform by the style guides
  • Branch has no merge conflicts with master (if it does - rebase it please)
  • Squashed related commits together

What are the relevant issue numbers?

Closes #31745 (closed).

Edited Jun 23, 2017 by Toon Claes
Assignee
Assign to
9.4
Milestone
9.4
Assign milestone
Time tracking
2
Labels
backend technical debt
Assign labels
  • View project labels
Reference: gitlab-org/gitlab-foss!12373

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.