1. Previously, we were not removing existing access levels before
   creating new ones. This is not a problem for EE, but _is_ for CE,
   since we restrict the number of access levels in CE to 1.

2. The correct approach is:

    CE -> delete all access levels before updating a protected branch
    EE -> delete developer access levels if "developers_can_{merge,push}" is switched off

3. The dispatch is performed by checking if a "length: 1" validation is
   present on the access levels or not.

4. Another source of problems was that we didn't put multiple queries in
   a transaction. If the `destroy_all` passes, but the `update` fails,
   we should have a rollback.

5. Modifying the API to provide users direct access to CRUD access
   levels will make things a lot simpler.

6. Create `create/update` services separately for this API, which
   perform the necessary data translation, before calling the regular
   `create/update` services. The translation code was getting too large
   for the API endpoint itself, so this move makes sense.

Fix lint-doc error

See this build error -> https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/817

I didn't add a CHANGELOG entry because I don't think is needed but just let me know if you think we should add it

See merge request !817

Update license API docs [ci skip]

Docs for gitlab-org/gitlab-ee!400

I forgot the docs in the above merge request so here they are. This adds the new `POST /license` endpoint. 

See merge request !413

Re-organize queues for EE

See merge request !815

This builds on
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7006 and adjusts
various parts to take care of EE specific workers.

Dumping too many jobs in the same queue (e.g. the "default" queue) is a
dangerous setup. Jobs that take a long time to process can effectively
block any other work from being performed given there are enough of
these jobs.

Furthermore it becomes harder to monitor the jobs as a single queue
could contain jobs for different workers. In such a setup the only
reliable way of getting counts per job is to iterate over all jobs in a
queue, which is a rather time consuming process.

By using separate queues for various workers we have better control over
throughput, we can add weight to queues, and we can monitor queues
better. Some workers still use the same queue whenever their work is
related. For example, the various CI pipeline workers use the same
"pipeline" queue.

This commit includes a Rails migration that moves Sidekiq jobs from the
old queues to the new ones. This migration also takes care of doing the
inverse if ever needed. This does require downtime as otherwise new jobs
could be scheduled in the old queues after this migration completes.

This commit also includes an RSpec test that blacklists the use of the
"default" queue and ensures cron workers use the "cronjob" queue.

Fixes gitlab-org/gitlab-ce#23370

Port gitlab-org/gitlab-ce!7033 to EE

See merge request !814

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

Fix a search for non-default branches when ES is enabled

The issue was introduced in 8.12

Closes https://gitlab.com/gitlab-org/gitlab-ee/issues/1143

See merge request !811

Merge branch 'ce-22457-reset-filters-button-should-be-invisible-when-no-filters-are-active-ee' into 'master'

`Reset filters` link should only be visible when filters are active

**EE version of gitlab-org/gitlab-ce!6497.**

## What does this MR do?

> Adds `issuable_filters_present` helper method to check for any filters before rendering the reset link.

## Why was this MR needed?

> `Reset filters` link is always visible.

See merge request !785

Update merge_requests.md.

Error in 'Approve merge request'  section in API documentation

## What does this MR do?

Just fix an error in API Documentation in 'Approve Merge Request' section. 

Url in documentation : 
`POST /projects/:id/merge_requests/:merge_request_id/approvals`

Should be : 
`POST /projects/:id/merge_requests/:merge_request_id/approve`

(Verified on gitlab 8.12.7-ee 4051516)

See merge request !809

Cache the last usage data to avoid unicorn timeouts

On GitLab.com, the usage data cache was never populated because it takes longer than 60 seconds to generate.

This MR also improves usage data performance. The Event default_scope was causing the query to use the wrong index, causing the query to scan through all rows unnecessarily.

Closes #1044

See merge request !779

Added tests

Use Ruby 2.1-compatible hash syntax for boards

This broke the master build, because we only run Ruby 2.1 specs on master. https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/6978 wouldn't help because this is in Haml 😞

See merge request !808

Add a wait_for_ajax call to prevent Spinach failure

There may be a race condition after a user clicks "Rebase" and when
the DatabaseCleaner wipes all data.

See https://gitlab.com/gitlab-org/gitlab-ee/builds/5302296

See merge request !810

Show a flash message in the project's main view when it's repo is
over the limit.

Fixes #1042 

See merge request !762

There may be a race condition after a user clicks "Rebase" and when
the DatabaseCleaner wipes all data.

See https://gitlab.com/gitlab-org/gitlab-ee/builds/5302296

The Event default_scope was causing the query to use the wrong index,
causing the query to scan through all rows unnecessarily.

Closes #1044

Restrict pushes / merges to a protected branch to specific groups

- Closes #675 and https://gitlab.com/gitlab-org/gitlab-ce/issues/21153
- Related to #179 

**Default State**
![Screen_Shot_2016-09-22_at_12.53.27_PM](/uploads/3777bc09fc5b0f9ddeccbf52dbf0277e/Screen_Shot_2016-09-22_at_12.53.27_PM.png)

**Filtering**
![Screen_Shot_2016-09-22_at_12.53.39_PM](/uploads/1e649e2a3720a4b0d7ff3e4fbafe5a72/Screen_Shot_2016-09-22_at_12.53.39_PM.png)

# Tasks

- [ ]  ee#675 !645 Restrict pushes/merges to specific groups
    - [x]  Implementation
        - [x]  Basic model-level implementation
        - [x]  Test / refactor
        - [x]  Rudimentary frontend (controller actions + autocomplete for the dropdown)
            - [x]  Groups that a project hasn't been shared with can't be selected
        - [x]  Look for edge cases
    - [x]  Questions
        - [x]  What are LDAP group links?
            - A GitLab group can be synced with one or more LDAP groups
            - The sync happens in an async task, an the LDAP group users are _imported_ into the GitLab group
            - `group.users` on a GitLab group returns the LDAP group users as well (after the import task has run)
            - We check `group.users` for this feature, so we shouldn't need any additional work to support LDAP groups
    - [x]  CHANGELOG
    - [x]  Removing a group should remove the access
    - [x]  `autocomplete/groups` issue
    - [x]  Fix uniqueness validation
    - [x]  Assign to @alfredo1 for UI work
    - [x]  Wait for !581 to be merged
    - [x]  Rebase against EE master instead of !581
    - [x]  Add feature specs
    - [x]  Implement frontend
    - [ ]  Assign to endboss
    - [ ]  Get backend + frontend reviewed
    - [ ]  Wait for merge


See merge request !645

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

Error in approve merge request api url in API documentation

Add ability to have multiple issue boards for a single project.

https://gitlab.com/gitlab-org/gitlab-ee/issues/929

https://gitlab.com/gitlab-org/gitlab-ee/issues/1084

See merge request !782