1. 29 Jul, 2016 12 commits
    • Timothy Andrew's avatar
      Fix all specs related to changes in !5081. · d7366dd20b80
      Timothy Andrew authored
      1. Remove `Project#developers_can_push_to_protected_branch?` since it
         isn't used anymore.
      
      2. Remove `Project#developers_can_merge_to_protected_branch?` since it
         isn't used anymore.
      d7366dd20b80
    • Timothy Andrew's avatar
      Fix default branch protection. · a3cdb25bdf9e
      Timothy Andrew authored
      1. So it works with the new data model for protected branch access levels.
      a3cdb25bdf9e
    • Timothy Andrew's avatar
      Update protected branches spec to work with the `select`s. · 75329c1ed685
      Timothy Andrew authored
      1. Get the existing spec passing.
      
      2. Add specs for all the access control options, both while creating and
         updating protected branches.
      
      3. Show a flash notice when updating protected branches, primarily so
         the spec knows when the update is done.
      75329c1ed685
    • Timothy Andrew's avatar
      Allow setting "Allowed To Push/Merge" while creating a protected branch. · ac2b6a007f16
      Timothy Andrew authored
      1. Reuse the same dropdown component that we used for updating these
         settings (`ProtectedBranchesAccessSelect`). Have it accept options
         for the parent container (so we can control the elements it sees) and
         whether or not to save changes via AJAX (we need this for update, but
         not create).
      
      2. Change the "Developers" option to "Developers + Masters", which is
         clearer.
      
      3. Remove `developers_can_push` and `developers_can_merge` from the
         model, since they're not needed anymore.
      ac2b6a007f16
    • Timothy Andrew's avatar
      Enforce "No One Can Push" during git operations. · 6c4eb21ce643
      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
         necessary.
      
      3. Fix and augment `user_access` and `git_access` specs.
      6c4eb21ce643
    • Timothy Andrew's avatar
      Add "No One Can Push" to the protected branches UI. · 5764fe5dee35
      Timothy Andrew authored
      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.
      5764fe5dee35
    • Timothy Andrew's avatar
      Add seeds for protected branches. · 10281817db60
      Timothy Andrew authored
      10281817db60
    • Timothy Andrew's avatar
      Use the `{Push,Merge}AccessLevel` models in the UI. · e501583d476a
      Timothy Andrew authored
      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`
      e501583d476a
    • Timothy Andrew's avatar
      Add models for the protected branch access levels. · 3e5a467458f9
      Timothy Andrew authored
      - And hook up their associations.
      3e5a467458f9
    • Timothy Andrew's avatar
      Add a series of migrations changing the model-level design of protected branch access levels. · 3c117cb9a09b
      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]
      3c117cb9a09b
    • Yorick Peterse's avatar
      Merge branch 'cache-commit-author-lookup' into 'master' · 563a478ea882
      Yorick Peterse authored
      Cache the commit author in RequestStore to avoid extra lookups in PostReceive
      
      See merge request !5537
      563a478ea882
    • Yorick Peterse's avatar
      Merge branch... · f9d3a3848e38
      Yorick Peterse authored
      Merge branch '17073-tagscontroller-index-is-terrible-response-time-goes-up-to-5-seconds' into 'master'
      
      Update to gitlab_git 10.4.1 and take advantage of preserved Ref objects
      
      See merge request !5536
      f9d3a3848e38
  2. 28 Jul, 2016 20 commits
  3. 27 Jul, 2016 8 commits