1. 25 Mar, 2019 1 commit
  2. 06 Mar, 2019 1 commit
    • Patrick Bajao's avatar
      Allow protected branch creation via web and API · e371520f
      Patrick Bajao authored
      This commit includes changes to add `UserAccess#can_create_branch?`
      which will check whether the user is allowed to create a branch even
      if it matches a protected branch.
      
      This is used in `Gitlab::Checks::BranchCheck` when the branch name
      matches a protected branch.
      
      A `push_to_create_protected_branch` ability in `ProjectPolicy` has been
      added to allow Developers and above to create protected branches.
      e371520f
  3. 08 Aug, 2018 1 commit
  4. 13 Jun, 2018 1 commit
  5. 06 Jun, 2018 1 commit
  6. 16 Apr, 2018 1 commit
  7. 02 Apr, 2018 1 commit
  8. 04 Dec, 2017 1 commit
  9. 31 Oct, 2017 1 commit
  10. 14 Oct, 2017 1 commit
  11. 14 Jul, 2017 1 commit
  12. 22 Jun, 2017 1 commit
  13. 07 Jun, 2017 1 commit
  14. 06 Mar, 2017 2 commits
  15. 10 Jan, 2017 1 commit
  16. 20 Oct, 2016 2 commits
  17. 06 Aug, 2016 1 commit
  18. 29 Jul, 2016 5 commits
    • Timothy Andrew's avatar
      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.
      cebcc417
    • 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
         `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.
      0a8aeb46
    • Timothy Andrew's avatar
      Implement review comments from @axil. · 88fd401d
      Timothy Andrew authored
      1. Align "Allowed to Merge" and "Allowed to Push" dropdowns.
      
      2. Don't display a flash every time a protected branch is updated.
         Previously, we were using this so the test has something to hook onto
         before the assertion. Now we're using `wait_for_ajax` instead.
      88fd401d
    • Timothy Andrew's avatar
    • Timothy Andrew's avatar
      Allow setting "Allowed To Push/Merge" while creating a protected branch. · 12387b4d
      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.
      12387b4d
  19. 22 Jul, 2016 1 commit
  20. 18 Jul, 2016 1 commit
  21. 14 Jul, 2016 1 commit
  22. 13 Jul, 2016 2 commits
  23. 12 Jul, 2016 1 commit
  24. 11 Jul, 2016 1 commit
  25. 07 Jul, 2016 1 commit
    • Timothy Andrew's avatar
      Use the `GLDropdown` component to select protected branches. · d8d5424d
      Timothy Andrew authored
      1. Modify the component to support a callback for every key press in the
         filter. We need this so we can update the "Create: <branch_name"
         label.
      
      2. Modify the component to use `$(<selector>).first().click()` instead
         of `$(selector)[0].click()`, because the latter is non-standard, and
         doesn't work in PhantomJS.
      d8d5424d
  26. 05 Jul, 2016 3 commits
    • Timothy Andrew's avatar
      5de79c4f
    • Timothy Andrew's avatar
      Improve the error message displayed when branch creation fails. · eb16e1e3
      Timothy Andrew authored
      Note: This feature was developed independently on master while this was
      in review. I've removed the conflicting bits and left the relevant
      additions, mainly a test for `Gitlab::Git::Hook`. The original commit
      message follows:
      
      1. `gitlab-shell` outputs errors to `stderr`, but we weren't using this
         information, prior to this commit. Now we capture the `stderr`, and
         display it in the flash message when branch creation fails.
      
      2. This can be used to display better errors for other git operation
         failures with small tweaks.
      
      3. The return value of `Gitlab::Git::Hook#trigger` is changed from a
         simple `true`/`false` to a tuple of `[status, errors]`. All usages
         and tests have been updated to reflect this change.
      
      4. This is only relevant to branch creation _from the Web UI_, since SSH
         and HTTP pushes access `gitlab-shell` either directly or through
         `gitlab-workhorse`.
      
      5. A few minor changes need to be made on the `gitlab-shell` end. Right
         now, the `stderr` message it outputs is prefixed by "GitLab: ", which
         shows up in our flash message. This is better removed.
      eb16e1e3
    • Timothy Andrew's avatar
      Modify the frontend for wildcard protected branches. · 2a5cb7ec
      Timothy Andrew authored
      1. Allow entering any branch name for a protected branch.
      
          - Either pick from a list of options, or enter it manually
          - You can enter wildcards.
      
      2. Display branches matching a protected branch.
      
          -  Add a `ProtectedBranches#show` page that displays the branches
             matching the given protected branch, or a message if there are no
             matches.
      
          - On the `index` page, display the last commit for an exact match,
            or the number of matching branches for a wildcard match.
      
          -  Add an `iid` column to `protected_branches` - this is what we use for
             the `show` page URL.
      
          -  On the off chance that this feature is unnecessary, this commit
             encapsulates it neatly, so it can be removed without affecting
             anything else.
      
      3. Remove the "Last Commit" column from the list of protected branches.
      
          - There's no way to pull these for wildcard protected branches, so it's
            best left for the `show` page.
      
          - Rename the `@branches` instance variable to `@protected_branches`
      
          - Minor styling changes with the "Unprotect" button - floated right
            like the "Revoke" button for personal access tokens
      
      4. Paginate the list of protected branches.
      
      5. Move the instructions to the left side of the page.
      2a5cb7ec
  27. 26 Apr, 2016 1 commit
  28. 05 Apr, 2016 1 commit
    • Robert Speicher's avatar
      Standardize the way we check for and display form errors · 7a2370f7
      Robert Speicher authored
      - Some views had a "Close" button. We've removed this, because we don't
        want users accidentally hiding the validation errors and not knowing
        what needs to be fixed.
      - Some views used `li`, some used `p`, some used `span`. We've
        standardized on `li`.
      - Some views only showed the first error. We've standardized on showing
        all of them.
      - Some views added an `#error_explanation` div, which we've made
        standard.
      7a2370f7
  29. 08 Dec, 2015 1 commit
  30. 02 Dec, 2015 1 commit
  31. 30 Apr, 2015 1 commit