Add missing import source
I realised https://gitlab.com/projects/new is missing the `gitlab export` option, while this worked fine in GDK it seems that something was missing here.
This _should_ fix it unless I'm missing any other `import_sources` (did a grep and couldn't find it anywhere else though).
See merge request !4825
Avoid autoload issue such as 'Mail::Parsers::AddressStruct'
This is mostly a shot in the dark but at least it shouldn't break anything.
Fixes#18810.
See merge request !4793
Fix images in emails
Closes#18474. The confirmation email is actually the only one that uses the `image_tag` helper at the moment, but this will work for all of them:
```shell
$ ag image_tag -G mailer
app/views/layouts/devise_mailer.html.haml
13: = image_tag('mailers/gitlab_header_logo.png', id: 'logo', alt: 'GitLab Wordmark')
24: = image_tag('mailers/gitlab_tanuki_2x.png', alt: 'GitLab Logo')
```
See merge request !4705
Resolve "Track the number of new Redis connections per transaction"
## What does this MR do?
Add a new metric counter, `new_redis_connections`, that contains the number of calls to `Redis::Client#connect` in the current transaction.
## Are there points in the code the reviewer needs to double check?
Not sure. I tested this in kind of a brute-force way:
1. Add a debugger in the monkey-patched `connect` method.
2. With metrics enabled, start the app and load a page.
3. The first Redis connection is created by `Rack::Attack` and isn't in a transaction, but still works fine.
4. The second Redis connection is within a transaction (the page load), and increments the counter.
5. If I reload the page, neither debugger is hit.
6. If I use a Redis client and do `CLIENT KILL` on my two existing clients, then reload the page, I get 3 and 4 again.
7. If I disable metrics collection, the debugger never gets hit.
## Why was this MR needed?
We may have a Redis connection leak somewhere, so adding metrics will let us track this.
## What are the relevant issue numbers?
Closes#18451.
## Screenshots (if relevant)
Hahaha nope, not relevant.
## Does this MR meet the acceptance criteria?
- [ ] [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)
- [ ] API support added
- [ ] Tests
- [ ] Added for this feature/bug
- [ ] All builds are passing
- [ ] Conform by the [style guides](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#style-guides)
- [ ] Branch has no merge conflicts with `master` (if you do - rebase it please)
- [ ] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits)
cc @yorickpeterse
See merge request !4649
By default instrumentation will instrument public,
protected and private methods, because usually
heavy work is done on private method or at least
that’s what facts is showing
Improve Gitlab::Auth method names
Auth.find was a very generic name for a very specific method.
Auth.find_in_gitlab_or_ldap was inaccurate in GitLab EE where it also
looks in Kerberos.
See merge request !4589
Upgrade devise, devise-two-factor, and attr_encrypted
Devise 4 includes support for Rails 5, working towards #14286. devise-async doesn't support Devise 4.0 and in 4.1 the bug that was blocking using Devise's built-in ActiveJob integration was fixed. So devise-async is removed. devise-two-factor 3.0.0 is required for Devise 4 support.
attr_encrypted and encryptor are optional but recommended upgrades for devise-two-factor 3.0.0. The mode and algorithm will need to be changed in order to update to attr_encrypted 4.x in the future.
See merge request !4216
Enable Style/NegatedIf Rubocop cop
Favor `unless` over `if` for negative conditions (or control flow ||).
```ruby
# bad
do_something if !some_condition
# bad
do_something if not some_condition
# good
do_something unless some_condition
# good
some_condition || do_something
```
See #17478
See merge request !4355
fix#15127 ActiveJob::DeserializationError thrown
`send_devise_notification` pre-maturely enqueued the task when the user instance
has not yet been committed into the database, causing a record-not-found in the
other sidekiq process.
`devise-async` has already been taking care of asynchronous mail sending, we just
need to run it inside queue `mailers` instead of `mailer` to enable it.
The implementation of `devise-async` enqueues the task in `after_commit` hook
which is the right way to do it.
See merge request !3647
Yorick PeterseandRobert Speicher
Robert SpeicherandRobert Speicher
Douwe MaanandRobert Speicher
Sean McGivern
Paco Guzman
Kamil Trzcinski
Jacob Vosmaer
Alejandro Rodríguez
Z.J. van de Weg
Rémy Coutable
Felipe Artur
Connor Shea
Grzegorz Bizon
Stan Hu
Fatih Acet