Improvements and refactorings were made while adding role based permissions for protected tags to EE. This doesn’t backport the feature, but should improve code quality and minimize divergence.

Added changelog

Fixes ProtectedBranches#create flash errors bug due to
typo in 'flash[:alert] = @protected_branches.errors'

Also fixed naming of a test in the deploy_keys_presenter

Added specs for the deploy_keys_presenter and added a new method in the presenter
called #key_available?

Fixed some minor UX inconsistencies and added a concern to handle
redirection

Also created changelog and removed redundant code

Also modified the render calls to the deploy_keys and protected_branches
partials

Changed views to partials, created the repository view,
created a repository_helper to further aid the creation of variables
across different controllers

CE part of https://gitlab.com/gitlab-org/gitlab-ee/issues/1294

!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.

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.

1. The model now contains this humanization data, which is the once
   source of truth.

2. Previously, this was being listed out in the dropdown component as well.

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.

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`

This reverts commit 530f5158.

See !4892.

Signed-off-by: Rémy Coutable <remy@rymai.me>

This reverts commit 9ca633eb, reversing
changes made to fb229bbf.

- Cherry-picked from `mvestergaard:branch-protection-dev-merge`
- https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/4220

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.

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.

This reverts commit 3e991230.

# Conflicts:
#	app/models/project.rb

`render nothing: true` has been deprecated.
For more information see [pr](https://github.com/rails/rails/pull/20336)

Signed-off-by: Jeroen van Baarsen <jeroenvanbaarsen@gmail.com>

Make the following changes to deal with new behavior in Rails 4.1.2:

* Use nested resources to avoid slashes in arguments to path helpers.

Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>

Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>

Didn't bother with files in db/, config/, or features/