They were added in Rubocop 1.24.0.
Even if we were already applying FileRead everywhere, this is something
we've manually fixed in the past. Another reason to add it is that these
rules are deeply related.
This rule was added in Rubocop 1.18.0, but we didn't add it back then.
Since we're applying it most of the time, we might as well be consistent
and apply it everywhere.
The scripts crashed when the `data` folder wasn't present, which is the
common situation in development environments or production environments
not using Capistrano, since this folder isn't under version control.
The `reload` method added to max_votes validation is needed because the
author gets here with some changes because of the around_action
`switch_locale`, which adds some changes to the current user record and
therefore, the lock method raises an exception when trying to lock it
requiring us to save or discard those record changes.
In case we receive consecutive requests we are locking the poll author record
until the first request transaction ends, so the author answers count during
subsequent requests validations is up to date.
This mixin was being called twice for the `.budget-investment-show`
selector; once in the CSS including this code for all the "Show
participation" pages, and once in the CSS for budget investments.
The Google response contains an `email_verified` field instead of a
`verified_email` field, and so we weren't treating verified Google
accounts as verified.
In the past, we've run into situations where we commited a version of
the schema.rb to version control which wasn't in sync with what you get
when you create the database and run the migrations. This is something
that might happen if you're working on different branches at the same
time, run the migrations in all those branches, and then commit the
current status of your database to your current branch. That will result
in a schema file which contains the database changes done in all these
branches instead of just the current one.
Although this hasn't happened to us for years, we see it happening
sometimes in other COSUL installations, and there's always a chance that
we make a mistake and do it again.
Until now, it wasn't a big deal because the installer sets up the
database by running `db:create db:migrate`, which runs the migrations
instead of using the `schema.rb` file.
However, we're going to add multitenancy using the Aparment gem, and
this gem uses the `schema.rb` file when creating a new schema for a new
tenant [1]. If the `schema.rb` file contains changes that shouldn't be
there, this will lead to different database schemas having different
tables and/or columns and future migrations might crash on production
when applied to some of these schemas. In other words, this mistake
could now result in a disastrous situation.
To help preventing that, we're adding a CI workflow that checks the
current `schema.rb` file is in sync with the database migrations.
[1] https://medium.com/infinite-monkeys/our-multi-tenancy-journey-with-postgres-schemas-and-apartment-6ecda151a21f#7e97
