Internet Explorer 9 was released eight years ago. Besides that, we don't
really support IE8 anyway, since we show a popup to IE8 users saying
we don't support it, we haven't maintained the IE8-specific CSS file for
years, and we don't test our JavaScript against IE8.
The code `where(id: ids)` is equivalent to `where(id: ids.uniq)`.
Since Rails 5 uses `distinct` instead of `uniq` and in most cases where
we use `uniq` with `pluck` we should simply remove the `uniq` call (as
done in this commit), we're also removing the `Rails/UniqBeforePluck`
rubocop rule.
For performance purposes, we need to find bottlenecks in our
application. Optimizing the performance of small methods doesn't make
the application faster.
I've kept a few cops because applying these ones IMHO make the code
easier to read.
These are rules we were already applying.
We've excluded the `factories` folder for some rules because there's a
factory defining a `context` attribute, which rubocop thought was the
`context` RSpec keyword.
We use staging and preproduction environments, which are not valid by
default.
This rule is useful because misspelling the name of an environment might
otherwise go unnoticed.
The Rakefile and config.ru files are now included by default, and the
behaviour of `Include` changed in Rubocop 0.56.0 (see rubocop's pull
request 5882) so now it **only** includes the files defined there, while
in the past it included those files in addition to the default files.
There was a rare case we've found on some Travis builds where the system
time suddenly moved back to the past a couple of tenths of a second,
meaning `Time.current - resource.created_at` returned a negative number,
which lead to a division by zero.
We're reading the value from the database, but the
`ApplicationMailer.default` method is evaluated when the application is
started. So if we don't use a Proc, we'll need to restart the server
every time we change the value in the database, or else the old value
will still be used.
Using a Proc makes sure the mailer from address is evaluated at runtime,
so emails are sent using the from address currently defined in the
database.
The same situation took place using the devise mailer. Now we don't need
to check for the settings table being present because the Proc in the
devise initializer won't be evaluated before the settings table is
created and populated.
We were performing an AJAX request and then a "normal" request without
checking the AJAX request had finished. Sometimes it resulted in the
normal request finishing because the AJAX request did, causing the test
to fail.
