Commit graph

11 commits

Author SHA1 Message Date
James Edwards-Jones
96106287db Deduplicate protected ref human_access_levels
Previously these were duplicated so they could be different for push/merge,
but this was no longer necessary after
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/11232
2017-11-24 13:47:03 +00:00
James Edwards-Jones
d6dd9d712a Fix ProtectedBranch access level validations
Before an access_level was required in EE even when an
it had been set for a user/group.
2017-11-24 13:20:56 +00:00
Eric
fb5b2d8d0e Extending API for protected branches 2017-08-02 10:16:17 +00:00
Phil Hughes
4dd2195004 Style changes to Ruby file 2017-05-12 11:41:44 +01:00
Phil Hughes
025a1b0175 Enabled no-one as a merge access level in protected branches
Closes #31541
2017-05-10 17:19:40 +01:00
James Edwards-Jones
f16377e7dc Protected Tags backend review changes
Added changelog
2017-04-06 10:56:21 +01:00
James Edwards-Jones
f9e849c076 Cleaned up duplication with ProtectedRefAccess concern 2017-04-04 02:59:37 +01:00
Timothy Andrew
41bf093662 CE-specific changes gitlab-org/gitlab-ee#1137
- Extract all common {push,merge} access level model code into the
  `ProtectedBranchAccess` module

- Use the HTTP verb to define controller specs
2016-11-29 17:38:45 +05:30
Timothy Andrew
b803bc7bb8 Implement review comments from @DouweM. 2016-10-24 11:33:38 +05:30
Timothy Andrew
f79f3a1dd6 Fix branch protection API.
1. Previously, we were not removing existing access levels before
   creating new ones. This is not a problem for EE, but _is_ for CE,
   since we restrict the number of access levels in CE to 1.

2. The correct approach is:

    CE -> delete all access levels before updating a protected branch
    EE -> delete developer access levels if "developers_can_{merge,push}" is switched off

3. The dispatch is performed by checking if a "length: 1" validation is
   present on the access levels or not.

4. Another source of problems was that we didn't put multiple queries in
   a transaction. If the `destroy_all` passes, but the `update` fails,
   we should have a rollback.

5. Modifying the API to provide users direct access to CRUD access
   levels will make things a lot simpler.

6. Create `create/update` services separately for this API, which
   perform the necessary data translation, before calling the regular
   `create/update` services. The translation code was getting too large
   for the API endpoint itself, so this move makes sense.
2016-10-24 11:33:38 +05:30
Timothy Andrew
e805a64700 Backport changes from gitlab-org/gitlab-ee!581 to CE.
!581 has a lot of changes that would cause merge conflicts if not
properly backported to CE. This commit/MR serves as a better
foundation for gitlab-org/gitlab-ee!581.

= Changes =

1. Move from `has_one {merge,push}_access_level` to `has_many`, with the
   `length` of the association limited to `1`. This is _effectively_ a
   `has_one` association, but should cause less conflicts with EE, which
   is set to `has_many`. This has a number of related changes in the
   views, specs, and factories.

2. Make `gon` variable loading more consistent (with EE!581) in the
   `ProtectedBranchesController`. Also use `::` to prefix the
   `ProtectedBranches` services, because this is required in EE.

3. Extract a `ProtectedBranchAccess` concern from the two access level
   models. This concern only has a single `humanize` method here, but
   will have more methods in EE.

4. Add `form_errors` to the protected branches creation form. This is
   not strictly required for EE compatibility, but was an oversight
   nonetheless.
2016-08-16 11:05:14 +05:30