1. 16 Aug, 2016 3 commits
    • Timothy Andrew's avatar
      Fix failing tests relating to backporting ee!581. · dd3b738d
      Timothy Andrew authored
      1. `GitPushService` was still using `{merge,push}_access_level_attributes` instead
         of `{merge,push}_access_levels_attributes`.
      2. The branches API creates access levels regardless of the state of the
         `developers_can_{push,merge}` parameters. This is in line with the UI,
         where Master access is the default for a new protected branch.
      3. Use `after(:build)` to create access levels in the
         `protected_branches` factory, so that `factories_spec` passes. It
         only builds records, so we need to create access levels on `build` as
    • Timothy Andrew's avatar
      Fix the protected branches factory. · 37651d2f
      Timothy Andrew authored
      1. Previously, we were using `after_create` to create access levels.
      2. At the time of protected branch creation, there are _no_ access
         levels present, which is invalid, and creation fails.
      3. Fixed by setting access levels before the protected branch is created.
    • Timothy Andrew's avatar
      Backport changes from gitlab-org/gitlab-ee!581 to CE. · e805a647
      Timothy Andrew authored
      !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
  2. 29 Jul, 2016 2 commits
    • Timothy Andrew's avatar
      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
      3. Move API handling back into the API (previously in
      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.
    • Timothy Andrew's avatar
      Enforce "No One Can Push" during git operations. · 828f6eb6
      Timothy Andrew authored
      1. The crux of this change is in `UserAccess`, which looks through all
         the access levels, asking each if the user has access to push/merge
         for the current project.
      2. Update the `protected_branches` factory to create access levels as
      3. Fix and augment `user_access` and `git_access` specs.
  3. 04 Mar, 2016 1 commit