BigW Consortium Gitlab

  1. 29 Jul, 2016 4 commits
    • Implement final review comments from @rymai. · cebcc417
      Timothy Andrew authored
      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.
    • Use `Gitlab::Access` to protected branch access levels. · 0a8aeb46
      Timothy Andrew authored
      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.
    • Implement review comments from @dbalexandre. · 7b2ad2d5
      Timothy Andrew authored
      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.
    • Add a series of migrations changing the model-level design of protected branch access levels. · f1e46d1e
      Timothy Andrew authored
      1. Remove the `developers_can_push` and `developers_can_merge` boolean
         columns.
      
      2. Add two new tables, `protected_branches_push_access`, and
         `protected_branches_merge_access`. Each row of these 'access' tables is
         linked to a protected branch, and uses a `access_level` column to
         figure out settings for the protected branch.
      
      3. The `access_level` column is intended to be used with rails' `enum`,
         with `:masters` at index 0 and `:developers` at index 1.
      
      4. Doing it this way has a few advantages:
      
         - Cleaner path to planned EE features where a protected branch is
           accessible only by certain users or groups.
      
         - Rails' `enum` doesn't allow a declaration like this due to the
           duplicates. This approach doesn't have this problem.
      
             enum can_be_pushed_by: [:masters, :developers]
             enum can_be_merged_by: [:masters, :developers]