LDAP Sync blocked user edgecases
Allow GitLab admins to block otherwise valid GitLab LDAP users
(https://gitlab.com/gitlab-org/gitlab-ce/issues/3462)
Based on the discussion on the original issue, we are going to differentiate "normal" block operations to the ldap automatic ones in order to make some decisions when its one or the other.
Expected behavior:
- [x] "ldap_blocked" users respond to both `blocked?` and `ldap_blocked?`
- [x] "ldap_blocked" users can't be unblocked by the Admin UI
- [x] "ldap_blocked" users can't be unblocked by the API
- [x] Block operations that are originated from LDAP synchronization will flag user as "ldap_blocked"
- [x] Only "ldap_blocked" users will be automatically unblocked by LDAP synchronization
- [x] When LDAP identity is removed, we should convert `ldap_blocked` into `blocked`
Mockup for the Admin UI with both "ldap_blocked" and normal "blocked" users:
There will be another MR for the EE version.
See merge request !2242
Show referenced MRs & Issues only when the current viewer can access them
This addresses both issues identified in #6066.
## The private MR by user `remy2` with a note referencing to a public issue
---
## The public issue viewed by user `remy` **who doesn't have access to `remy2/private-project`** before the fix
---
## The public issue viewed by user `remy` **who doesn't have access to `remy2/private-project`** with the fix
---
## The public issue viewed by user `remy2` with the fix (no change)
See merge request !2405
This is intended to prevent the user from creating new objects while the
transaction that removes them is being run, resulting in objects with
nil authors which can then not be edited.
See https://gitlab.com/gitlab-org/gitlab-ce/issues/7117
Improve performance of getting issues on group level
For testing I used the URL http://localhost:3000/groups/gitlab-org/issues?milestone_title=8.1. Prior to these changes said URL would take about 10-12 seconds to load. By applying these changes the loading time has been reduced to roughly 2-3 seconds.
There's still some stuff going on in some views that I have to look at, resolving those changes might reduce the loading time a bit more. I also still have to check if I didn't break too many tests.
Fixes: gitlab-org/gitlab-ce#3707 gitlab-org/gitlab-ce#4071
See merge request !2318
Sorting by "id" has the same effect as sorting by created_at while
performing far better and without the need of an extra index (in case
one wanted to speed up sorting by "created_at").
Sorting by "Recently updated" still uses the physical "updated_at"
column as there's no way to use the "id" column for this instead.
This removes the need for Sidekiq and any overhead/problems introduced
by TCP. There are a few things to take into account:
1. When writing data to InfluxDB you may still get an error if the
server becomes unavailable during the write. Because of this we're
catching all exceptions and just ignore them (for now).
2. Writing via UDP apparently requires the timestamp to be in
nanoseconds. Without this data either isn't written properly.
3. Due to the restrictions on UDP buffer sizes we're writing metrics one
by one, instead of writing all of them at once.
Grzegorz Bizon
Douwe Maan
Rémy Coutable
Robert Speicher
Yorick Peterse
Robert Speicher
Dmitriy Zaporozhets
Gabriel Mazetto
Jeroen Nijhof
Jacob Vosmaer
Valery Sizov
Douglas Barbosa Alexandre
Stan Hu