gitlab-org--gitlab-foss/app/models/concerns/protected_branch_access.rb

# frozen_string_literal: true

module ProtectedBranchAccess
  extend ActiveSupport::Concern
  include ProtectedRefAccess

  included do
    belongs_to :protected_branch

    delegate :project, to: :protected_branch
  end

  def check_access(user)
    return false if access_level == Gitlab::Access::NO_ACCESS

    super
  end
end
Enable more frozen string in app/models/*/.rb Partially addresses #47424. 2018-08-03 13:22:24 -04:00			`# frozen_string_literal: true`

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 01:09:13 -04:00			`module ProtectedBranchAccess`
			`extend ActiveSupport::Concern`
Fix how we use EE::ProtectedRefAccess 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. 2018-08-30 14:49:26 -04:00			`include ProtectedRefAccess`
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 01:09:13 -04:00
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-09-06 01:05:34 -04:00			`included do`
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 06:21:50 -05:00			`belongs_to :protected_branch`
Protected Tags backend review changes Added changelog 2017-04-05 13:59:46 -04:00
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 06:21:50 -05:00			`delegate :project, to: :protected_branch`
Fix how we use EE::ProtectedRefAccess 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. 2018-08-30 14:49:26 -04:00			`end`
Enabled no-one as a merge access level in protected branches Closes #31541 2017-05-10 04:46:50 -04:00
Fix how we use EE::ProtectedRefAccess 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. 2018-08-30 14:49:26 -04:00			`def check_access(user)`
			`return false if access_level == Gitlab::Access::NO_ACCESS`
Enabled no-one as a merge access level in protected branches Closes #31541 2017-05-10 04:46:50 -04:00
Fix how we use EE::ProtectedRefAccess 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. 2018-08-30 14:49:26 -04:00			`super`
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 06:21:50 -05:00			`end`
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 01:09:13 -04:00			`end`