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.
Fixesgitlab-org/gitlab-ce#14949
Decouple membership and notifications
This allow you to have notification setting per project even if you are member of group.
It also creates background for having notification settings in project you are not member of.
- [x] Make it work
- [x] Migrations
- [x] CHANGELOG
- [x] More tests
- [x] API
For #3359
After this merge request there is still some work to be done:
* create migration that remove duplicates in notification settings table and create uniq index (8.8 probably)
* remove notification_level field from Member model in 9.0
* make proper API for notification settings
* use `MemberCreateService` instead of Member#after_create callback for creating notification settings (after #14709)
* maybe more tests
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
See merge request !3421
Instrumenting this class together with Gitlab::ReferenceExtractor causes
a StackError for some reason. Since Gitlab::ReferenceExtractor has most
of the interesting code we'll only instrument that class.
Redis connection pool
Split from https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/3232
Having an easily accessible Redis connection pool allows us to do more
cool stuff with Redis in GitLab (instead of having to go through e.g.
the Rails cache).
See merge request !3521
Allow SAML to identify external users and set them as such
Related to #4009Fixes#14577
This allows SAML to retrieve group information form the `SAML Response`
and match that to a setting that will flag all matching users as external.
See merge request !3530
Wiki preview URL converting problem [via Markdown]
Current implementation when rendering the preview, thinks relative links are for project repository files.
We are creating a new preview route that will define correct context data to render for wikis instead.
Fixes#2380, #1184
See merge request !3461
A few things to note:
- The IncomingEmail feature is now enabled even without a
correctly-formatted sub-address
- Message-ID for new thread mail are kept the same so that subsequent
notifications to this thread are grouped in the thread by the email
service that receives the notification
(i.e. In-Reply-To of the answer == Message-ID of the first thread message)
- To maximize our chance to be able to retrieve the reply key, we look
for it in the In-Reply-To header and the References header
- The pattern for the fallback reply message id is "reply-[key]@[gitlab_host]"
- Improve docs thanks to Axil
Support Wiki with UTF-8 page name
## What does this MR do?
Support Wiki with UTF-8 page name.
See https://github.com/gollum/gollum/pull/929
## Why was this MR needed?
Relax constraints for wiki slug in aac6598482.
It allows to create a wiki with UTF-8 name, but creating a wiki with UTF-8 name causes 500 error.
Creating a wiki with UTF-8 name once, then creating or updating wiki with ascii name also cause 500 error i.e. no one can create and update any wiki pages in the project.
## Workaround
1. Go to `https://DOMAIN/repo/wikis/git_access` -> this page display the link to git clone
2. Clone the wiki repo
3. Find the page with UTF-8 name
4. Rename or Delete these files
5. Commit and push
## What are the relevant issue numbers?
- #13979
- #13891
- #13698
- #13603
- #13317
- #12906
- #12825
- #10945
## Todo
- [x] Waiting for 'gollum-rugged_adapter' that support rugged v0.24.0 release
'gollum-rugged_adapter' gem doesn't allow to install rugged v0.24.0 (it's still beta version),
but 'gitlab_git' gem depends on rugged v0.24.0b13.
So it can't install both 'gollum-rugged_adapter' and 'gitlab_git' now.
See merge request !2999
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.