gitlab-org--gitlab-foss/app/services/protected_branches/update_service.rb

# frozen_string_literal: true

module ProtectedBranches
  class UpdateService < BaseService
    def execute(protected_branch)
      raise Gitlab::Access::AccessDeniedError unless can?(current_user, :update_protected_branch, protected_branch)

      protected_branch.update(params)
      protected_branch
    end
  end
end

ProtectedBranches::UpdateService.prepend_if_ee('EE::ProtectedBranches::UpdateService')
Enable more frozen string in app/services/*/.rb Partially addresses #47424. 2018-07-18 12:03:33 -04:00			`# frozen_string_literal: true`

Use the `{Push,Merge}AccessLevel` models in the UI. 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` 2016-07-07 03:36:28 -04:00			`module ProtectedBranches`
Use `Gitlab::Access` to protected branch access levels. 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. 2016-07-29 02:13:07 -04:00			`class UpdateService < BaseService`
			`def execute(protected_branch)`
Branch unprotection restriction starting point Explored Policy framework to create something I can use as a starting point. 2018-03-23 14:24:06 -04:00			`raise Gitlab::Access::AccessDeniedError unless can?(current_user, :update_protected_branch, protected_branch)`
Authorize user before creating/updating a protected branch. 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. 2016-07-27 00:44:38 -04:00
Protected Tags backend review changes Added changelog 2017-04-05 13:59:46 -04:00			`protected_branch.update(params)`
			`protected_branch`
Use the `{Push,Merge}AccessLevel` models in the UI. 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` 2016-07-07 03:36:28 -04:00			`end`
			`end`
			`end`
Add latest changes from gitlab-org/gitlab@master 2019-09-17 08:06:48 -04:00
			`ProtectedBranches::UpdateService.prepend_if_ee('EE::ProtectedBranches::UpdateService')`