- So that the server doesn't have to be restarted for every change in dev.

This button depends on Issue#can_be_worked_on? which in turn depends on
Issue#related_branches. By rendering this button asynchronously we can
finally remove all usages of Issue#related_branches and
Issue#referenced_merge_requests from the issues "show" page.

Sent emails in the development environment will no longer automatically
be opened in the browser. If a sent email needs to be viewed, it can be
found at the `/rails/letter_opener` route.

Closes #4228

Issue: https://gitlab.com/gitlab-org/gitlab-ce/issues/12785
Merge Request: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/3514

Report: https://github.com/gitlabhq/gitlabhq/issues/10138Signed-off-by: NRémy Coutable <remy@rymai.me>

Currently this works by loading the HAML partials via XHR. While this is
not the nicest setup it _is_ the easiest setup using the tools we
currently have.

Loading this data asynchronously doesn't make loading the related
MRs/branches itself faster, it merely ensures that loading the issue
itself is not slowed down.

Fixes gitlab-org/gitlab-ce#14949

Since a user cannot have multiple NotificationSettings records for one
group/project we can use singular resource.

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

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

They would try to load JSON from a project even though it isn't a single project

When a build status changes a notification will popup.
Fixes #10851

1. Allow subscribing (the current user) to a label

- Refactor the `Subscription` coffeescript class
  - The main change is that it accepts a container, and conducts all
    DOM queries within its scope. We need this because the labels
    page has multiple instances of `Subscription` on the same page.

2. Creating an issue or MR with labels notifies users subscribed to those labels

- Label `has_many` subscribers through subscriptions.

3. Adding a label to an issue or MR notifies users subscribed to those labels

- This only applies to subscribers of the label that has just been
  added, not all labels for the issue.

Previously we were doing all of kinds of code gymnastics and flash abuse
in order to work with a Doorkeeper controller but have it _appear_ at
the `/profile/applications` path. Fortunately we can just tell Rails to
use a different controller to handle that route, and we get the best of
both worlds.

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

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

Fixes #3768

The only major difference with the EE version is the change from a light and dark logo to only a header logo
The dark logo wasn't used anyway, so it seemed to make sense to me to rename the field to the actual function of it