Branch Unprotection Restrictions using group/user access levels
What
Extends https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/17982 by adding UnprotectAccessLevels
and using them to restrict who can update/destroy ProtectedBranch rules. Also prevents creating rules the user wouldn't be able to destroy, to avoid shooting oneself in the foot.
These new access levels can be set when creating a protected branch through the API.
Why
Helps provide tighter control over protected branches. An organization can use the API to add a rule to each project which cannot be removed by owners or masters, but instead requires membership of a specified group or administrator access.
Database Checklist
When adding migrations:
-
Updated db/schema.rb
-
Added a down
method so the migration can be reverted -
Ordered columns based on the Ordering Table Columns guidelines -
Added foreign keys to any columns pointing to data in other tables -
Added indexes for fields that are used in statements such as WHERE, ORDER BY, GROUP BY, and JOINs -
Added the output of the migration(s) to the MR body:
== 20180325034910 CreateProtectedBranchUnprotectAccessLevels: migrating =======
-- create_table(:protected_branch_unprotect_access_levels)
-> 0.0174s
-- add_foreign_key(:protected_branch_unprotect_access_levels, :namespaces, {:column=>:group_id, :on_delete=>:cascade})
-> 0.0024s
== 20180325034910 CreateProtectedBranchUnprotectAccessLevels: migrated (0.0201s)
Acceptance criteria?
-
Changelog entry added, if necessary -
Documentation created/updated -
API support added -
Tests added for this feature/bug - Review
-
Has been reviewed by UX -
Has been reviewed by Frontend -
Has been reviewed by Backend -
Has been reviewed by Database
-
-
Internationalization required/considered -
If paid feature, have we considered GitLab.com plan and how it works for groups and is there a design for promoting it to users who aren't on the correct plan -
End-to-end tests pass ( package-qa
manual pipeline job)
Related
Edited by James Edwards-Jones