| Age | Commit message (Collapse) | Author |
|---|
|
This is a mess... Using prepend will give a different ancestors
chain we're not expecting. To fix this we'll need to know what
exactly methods we want to use in each classes using this module.
|
|
Partially addresses #47424.
|
|
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
|
|
Before an access_level was required in EE even when an
it had been set for a user/group.
|
|
|
|
|
|
Closes #31541
|
|
Added changelog
|
|
|
|
- Extract all common {push,merge} access level model code into the
`ProtectedBranchAccess` module
- Use the HTTP verb to define controller specs
|
|
|
|
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.
|
|
!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.
|
