Add notification_settings API calls ## What does this MR do? It adds API calls to get/update notification settings, globally and at the group/project level. ## Are there points in the code the reviewer needs to double check? None ## Why was this MR needed? Notification settings were updated, but related API calls were never created. ## What are the relevant issue numbers? gitlab-org/gitlab-ce#19359 ## Does this MR meet the acceptance criteria? - [x] [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG) entry added - [x] [Documentation created/updated](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/doc_styleguide.md) - [x] API support added - Tests - [x] Added for this feature/bug - [x] All builds are passing - [x] Conform by the [style guides](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#style-guides) - [x] Branch has no merge conflicts with `master` (if you do - rebase it please) - [x] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits) Closes #19359 See merge request !5632
Restrict ldap return attributes ## What does this MR do? Fixes the CE part of #13821. We really only ever need uid, dn, cn, and mail attributes, and in some cases, even less. This merge request strips the request down to those four attributes by default, and allows the caller to specify others, if needed. ## Why was this MR needed? This will improve performance especially in cases where the connection is slow between GitLab and LDAP, or when the LDAP object has lots of attributes we don't care about. See merge request !6187
Use NotificationSetting::EMAIL_EVENTS for params
Security and safety improvements for gitlab-workhorse integration Companion to https://gitlab.com/gitlab-org/gitlab-workhorse/merge_requests/60 - Use a custom content type when sending data to gitlab-workhorse - Verify (using JWT and a shared secret on disk) that internal API requests came from gitlab-workhorse This will allow us to build features in gitlab-workhorse that require more trust, and protect us against programming mistakes in the future. This is designed so that no action is required for installations from source. For omnibus-gitlab we need to add code that manages the shared secret. See merge request !5907
Smartly calculate real running time and pending time ## What does this MR do? Try to smartly calculate the running time and pending time for pipelines, instead of just use wall clock time from start to end. The algorithm is based on: > Suppose we have A, B, and C jobs: > * A: from 1 to 3 > * B: from 2 to 4 > * C: from 6 to 7 > The processing time should be accumulated from 1 to 4, and 6 to 7, totally 4, excluding retires, and calculate on `%w[success failed running canceled]` jobs (if a job is not finished yet, assume it's `Time.now`) ## Are there points in the code the reviewer needs to double check? I would actually like to test `Gitlab::Ci::PipelineDuration#process_segments`, but it's a private method right now and it's not very convenient to test it. Is there a way to test it without changing the original code too much? Note that I would like to avoid saving merged segments because it's not used and should be garbage collected. ## Screenshots:  ## Does this MR meet the acceptance criteria? - [x] [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG) entry added - [ ] [Documentation created/updated](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/doc_styleguide.md) - Tests - [x] Added for this feature/bug ## What are the relevant issue numbers? Closes #18260, #19804 See merge request !6084
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/6084#note_15091858
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>