These methods were added in 2009 and are supported by 98.5% of the
browsers, including Internet Explorer 9, 10 and 11. We were already
using them in some places.
Calling it directly might make it difficult to detect bugs, particularly
when we don't trust the data we receive:
https://eslint.org/docs/rules/no-prototype-builtins
If we trust the data we receive, then IMHO we shouldn't even check for
`hasOwnProperty`, since we know what we're going to receive.
In JavaScript, when there isn't a `break` or `return` statement inside a
`switch` case, the next case will be executed as well.
That wasn't a problem here because CoffeeScript automatically inserts a
`return` statement in this specific situation. However, since we don't
want to return the result of the `hide()` operation, it might be easy to
accidentally remove the `return` statement, causing the code to break.
I've added a test for the scenario where neither `break` nor `return`
statements are present, so we don't run into this error.
This code requires the variable `_paq` to be set somewhere, but we never
set it.
In the past Decide Madrid added some custom JavaScript using this code.
However, in CONSUL we're using Ahoy to track events, and we don't have
any documentation about adding custom JavaScript to use piwik nor we've
got any other piwik integration.
The `removeCookie` function is never called, and the `initialize`
function doesn't do anything. The only functions we use here are
`getCookie` and `saveCookie`.
The `initialize` functions don't need to return anything, since their
returned value is never used.
Returning false is a common practice in jQuery to stop an event, but in
plain JavaScript methods it doesn't have any side effects.
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.
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.
The dates are saved on UTC times on the database. So, for example,
if living in West Australia, `Date.current.beginning_of_day` will be
stored as UTC's yesterday at 15:15:00, while `Date.current.end_of_day`
will be stored as UTC's today at 15:14:59.
When we use the `DATE` database function, PostgreSQL will select the
records with the same UTC date as the current UTC date. However, we need
the records with the same application date (as defined in
`config.time_zone`) as the current application date. The test passed
(for us) because we were using `beginning_of_day + 3.hours` to make sure
we were creating records when the date in Madrid was the same as the UTC
date.
Using a ruby interval for the time condition solves the problem.
The label text was always in English, and it wasn't associated with any
input field.
The `SecureRandom` part is a quick hack so we don't get duplicate IDs.
Using "your_answer_#{question.id}" might work as well, but right now I'm
not sure if the form is sometimes rendered twice for the same question.
The statement executed the method twice if the `present?` condition was
true. If the condition was false, it executed it once anyway.
It's probably a typo and originally we probably meant we wanted to
execute the method if the method existed.
We're moving the code for the phases translation class to the same place
in the code the other translation classes are: right after including the
Globalizable module.
