1. Previously, we had a separate test for each and every possible role,
   and another test for access by user, each multiplied by the access
   types (merge and push), and further multiplied by the type of CRUD
   operation (create or update).

2. Since we allow selecting multiple access levels at once, it makes
   sense to collapse a lot of these tests. Now, in single test, we check
   access levels for all roles and 5 different users. Multiply that by
   4 (as mentioned above), and we only have 4 tests total (that still
   test everything the previous tests did).

3. Use a shared example to reduce potential conflicts in the future,
   since CE access control specs are significantly different.

1. This has been moved to the `#index` page.

1. For a user-based access level, don't validate `access_level`
2. For a role-based access level, don't look at `access_level` of user-based access levels

Add tests supporting this behavior.

1. A validation restricts a protected branch so it can only have a
   single access level for a given role or user.

2. More context:

    - https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/581#note_14051822
    - https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/581#note_14052756
    - https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/581#note_14056066
    - https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/581#note_14058676

[ci skip]

[ci skip]

[ci skip]

[ci skip]

[ci skip]

[ci skip]

[ci skip]

[ci skip]

[ci skip]

[ci skip]

[ci skip]

[ci skip]

[ci skip]

1. We might need to update/delete access levels that were created in
   this `update` call without a page refresh.

2. The JS relies on the JSON response for the IDs of the newly created
   access level records.

- Using the `allow_destroy` option for `accepts_nested_attributes_for`

1. No need to change the spec for `UserAccess#can_push_to_branch?` for
   EE anymore.

2. Make the `dropdowns_helper` change additive to CE, so as to reduce
   the potential for merge conflicts.

- In 5b92c54319cd0e10f879a35bf6aab85a8e04e540, we destroyed all the
  default access levels for a factory-created protected branch.

- Inadvertently, we also destroyed all spec-created access levels,
  leading to a number of failures, which should now be fixed.

- As part of gitlab-org/gitlab-ce!5824, the `protected_branches` factory
  creates default `MASTER` access levels for merging and pushing.

- Some specs rely on the condition that no pre-existing access levels
  exist when a protected branch is created, and these specs were
  failing.

- Added a factory trait to remove the default access levels.

- Project needs to be loaded before `find_users` is called.

1. Check if a project is readable by the current user when fetching
   users for autocomplete.

2. Remove duplication relating to gon variables in
   `ProtectedBranchesController`

3. Remove unnecessary colons in view labels.

4. Remove an explicit `false` check in the `branches` API.

- Primarly whitespace and code style changes.

- Improve feature spec dealing with removing a user from a protected
  branch. Previously, we were only asserting on a "Deleted" flash
  notice. Now the assertion looks at the database to make sure that the
  right access level was removed.

1. Set `gon.current_project_id` in a protected branches controller,
   since that's the only place this is used.

2. Move flash notice to the redirect message.

3. Rename the `js_access_levels` method to `access_levels_options`

4. Scope a `find` while sending a branch protection email.

5. Use scopes to simplify finding users with push/merge access for a
   project.

6. Use `change_column_null`  to avoid an `ActiveRecord::IrreversibleMigration`

- While selecting user access for a protected branch.

-  When a user leaves a project, any access levels that they were
   granted specifically are destroyed.

-  When a user is removed from a project, any access levels that they
   were granted specifically are destroyed.

To work with restricting access to a specific user.

1. While creating a protected branch, you can set a single user / role
  for each setting ("Allowed to Merge", "Allowed to Push").

2. More users / roles can be set subsequently.

3. Repurposed 'users_select.js.coffee` for the needs of this page.

4. Move protected branch settings to the `show` page.

    - Too many settings on the single index page can be overwhelming. Also,
      if the number of users that can access a protected branch is large,
      the amount of space between protected branches in the table can be
      unwieldy.

    - This is the simplest design I can think of - we can use this
      until we have someone from the frontend/ux team take a look at
      this.

    - Move protected branches javascript under a `protected_branches`
      directory.

    - The dropdowns don't show access levels / users that have already been
      selected.

    - Allow deleting access levels using two new access level controllers.

- A protected branch now `has_many` access levels (as opposed to
  `has_one`, which CE will continue to have). Each access level
  represents either a user or a role that is allowed to access the
  protected branch.

- Update `git_access_spec` to test cases where a specific user is given
  access to a protected branch.

- Remove the explicit `push_check` for protected branches. This is
  because a non-developer user (such as a reporter) should be able to
  push code if they are added to a protected branch specifically.

- Fix specs (git_access_spec) that were implicitly depending on a
  master push access level being created (previously, a protected
  branch's default state was "masters can push + masters can merge").
  Since the current default is "none", the dependency needs to be
  explicitly declared.

- Update `git_push_service` so default branch protection (for new repos)
  works as expected.