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

[ES] Add explanation comments



See merge request !650

Allow LDAP `sync_ssh_keys` setting to be set to `true`

In that case `sync_ssh_keys` will default to the `sshPublicKey` value

Fixes #8

See merge request !670

In that case `sync_ssh_keys` will default to the `sshPublicKey` value.

[ES] Fix for unborn head

Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/21038

See merge request !669

Allow syncing a group against all providers at once

## What does this MR do?

Allows `Sync::Group` to sync members for a single group across all providers at once. Closes #399 

## Are there points in the code the reviewer needs to double check?

No

## Why was this MR needed?

The current implementation of LDAP group sync manages members based on a single LDAP provider. This is optimal because we can open a single connection to a given LDAP server (provider) and run all queries needed to sync all GitLab groups with links to that provider. If we want to sync a single group at a time we need to flip that model - for a single group, run the sync for all providers. 

This presents a few challenges since we have a state machine on the group. In the former/current model we need to set the state inside the loop. However, if we do that in the latter model we will likely run into a race condition. At least, it will execute unnecessary queries against the database. Other than adding the functionality needed to sync a single group, the MR moves the state machine handling to the respective class method. 

## What are the relevant issue numbers?

#399

See merge request !636