Age | Commit message (Collapse) | Author |
|
!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.
|
|
1. Instantiate `ProtectedBranchesAccessSelect` from `dispatcher`
2. Use `can?(user, ...)` instead of `user.can?(...)`
3. Add `DOWNTIME` notes to all migrations added in !5081.
4. Add an explicit `down` method for migrations removing the
`developers_can_push` and `developers_can_merge` columns, ensuring that
the columns created (on rollback) have the appropriate defaults.
5. Remove duplicate CHANGELOG entries.
6. Blank lines after guard clauses.
|
|
1. It makes sense to reuse these constants since we had them duplicated
in the previous enum implementation. This also simplifies our
`check_access` implementation, because we can use
`project.team.max_member_access` directly.
2. Use `accepts_nested_attributes_for` to create push/merge access
levels. This was a bit fiddly to set up, but this simplifies our code
by quite a large amount. We can even get rid of
`ProtectedBranches::BaseService`.
3. Move API handling back into the API (previously in
`ProtectedBranches::BaseService#translate_api_params`.
4. The protected branch services now return a `ProtectedBranch` rather
than `true/false`.
5. Run `load_protected_branches` on-demand in the `create` action, to
prevent it being called unneccessarily.
6. "Masters" is pre-selected as the default option for "Allowed to Push"
and "Allowed to Merge".
7. These changes were based on a review from @rymai in !5081.
|
|
1. This is a third line of defence (first in the view, second in the
controller).
2. Duplicate the `API::Helpers.to_boolean` method in `BaseService`. The
other alternative is to `include API::Helpers`, but this brings with it
a number of other methods that might cause conflicts.
3. Return a 403 if authorization fails.
|
|
1. The new data model moves from `developers_can_{push,merge}` to
`allowed_to_{push,merge}`.
2. The API interface has not been changed. It still accepts
`developers_can_push` and `developers_can_merge` as options. These
attributes are inferred from the new data model.
3. Modify the protected branch create/update services to translate from
the API interface to our current data model.
|
|
1. Remove `master_or_greater?` and `developer_or_greater?` in favor of
`max_member_access`, which is a lot nicer.
2. Remove a number of instances of `include Gitlab::Database::MigrationHelpers`
in migrations that don't need this module. Also remove comments where
not necessary.
3. Remove duplicate entry in CHANGELOG.
4. Move `ProtectedBranchAccessSelect` from Coffeescript to ES6.
5. Split the `set_access_levels!` method in two - one each for `merge` and
`push` access levels.
|
|
1. So it works with the new data model for protected branch access levels.
|
|
1. Move to dropdowns instead of checkboxes. One each for "Allowed to
Push" and "Allowed to Merge"
2. Refactor the `ProtectedBranches` coffeescript class into
`ProtectedBranchesAccessSelect`.
3. Modify the backend to accept the new parameters.
|
|
1. Improve error handling while creating protected branches.
2. Modify coffeescript code so that the "Developers can *" checkboxes
send a '1' or '0' even when using AJAX. This lets us keep the backend
code simpler.
3. Use services for both creating and updating protected branches.
Destruction is taken care of with `dependent: :destroy`
|