Add sentry integration
Sentry is an event logging platform primarily focused on capturing and
aggregating exceptions. With this MR it will be possible to log and
track exceptions from GitLab to Sentry.
https://gitlab.com/gitlab-com/operations/issues/39
See merge request !2485
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
Suppress e-mails on failed builds if allow_failure is set
Every time I push to GitLab, I get > 2 emails saying a spec failed when I don't care about the benchmarks and others that have `allow_failure` set to `true`.
@ayufan mentioned creating a summary e-mail to prevent getting one e-mail per build, but the latter might actually be desirable. For example, I do want to know if Rubocop errors fail right away.
See merge request !2178
Every time I push to GitLab, I get > 2 emails saying a spec failed when
I don't care about benchmarks and other specs that have `allow_failure` set to `true`.
* upstream/master: (307 commits)
Update CHANGELOG
spinach fix
Updated allocations Gem to version 1.0.3
Removed various default metrics tags
Update CHANGELOG
Fix "I see current user as the first user" step
Swap Author and Assignee Selectors on issuable index view
Update CHANGELOG
Make sure that is no pending migrations in Gitlab::CurrentSettings
Added additional config environmental variables to help Debian packaging
We don't use whenever anymore. Lets remove the schedule file
Fix project transfer e-mail sending incorrect paths in e-mail notification
Update CHANGELOG
Use Gitlab::CurrentSettings for InfluxDB
Write to InfluxDB directly via UDP
Strip newlines from obfuscated SQL
Add hotfix that allows to access build artifacts created before 8.3
note votes methids implementation
When reCAPTCHA is disabled, allow registrations to go through without a code
Downcased user or email search for avatar_icon.
...
Revert vote buttons back to issue and MR pages
https://gitlab.com/gitlab-org/gitlab-ce/issues/3672
/cc @dzaporozhets @JobV
See merge request !2206
Robert SpeicherandRobert Speicher
Douwe MaanandRobert Speicher
Kamil Trzcinski
Douglas Barbosa Alexandre
Grzegorz Bizon
Rémy Coutable
Gabriel Mazetto
Stan Hu
Dmitriy Zaporozhets
Valery Sizov
Mike Wyatt
Valery Sizov