These changes fix a bug that causes categories
of a legislation process to be wiped on update
of the process. It also adds a regression test
for this fix.
Generating a random title with `Faker::Lorem.sentence` sometimes caused
validation errors in tests because the generated sentence was more than
80 characters long.
The test environment was using the file in `config/puma.rb`, meaning it
wouldn't work with Rails 5.1, which uses a different setup for Puma.
I've decided to create a new file called `defaults.rb`, which will be
used in every environment but development and test. We could also add an
empty file in `config/puma/test.rb`; I think that's less intuitive, but
it's a subjective opinion.
While the browser gem is great, we don't need it in this case for such a
simple usage.
There are a few really small differences between this code and the old
one: matching `/MSIE/` will return true for Opera 12 and false for
certain versions of IE11. Since we're only rendering a comment for IE8
and below, we don't care about IE11, and Opera 12 is six years old and
its users won't be affected by the comment.
Note we're still using the browser gem because ahoy_matey depends on it,
but now it's an indirect dependency.
The task `deploy:restart` was doing nothing since we moved from unicorn
to puma.
Now we're also restarting delayed jobs on `deploy:restart`, which is
probably what's expected in most cases.
So now the way to restart the application does not depend on whether we
use puma or passenger.
What this plugin actually does is restarting puma when we touch the
`tmp/restart.txt` file, which is what `rails restart` does.
This way we don't have to start it manually every time the server is
restarted.
Note if we start the application with `bin/rails s start -e production`,
as we'd probably want to do so this task doesn't depend on the server we
use, the application will crash when we restart it because it will be
restarted in the development environment. Maybe this issue will be fixed
in future versions of Rails and/or Puma.
Also note we're passing `2` workers to delayed job, and this number must
be the same number we use for the `delayed_job_workers` variable in
capistrano. I haven't found a way to share this variable between
whenever and capistrano.
We need to download the most recent CONSUL and check its `.ruby-version`
file before installing Ruby.
The `rvm1-capistrano` gem knows it and was invoking the `updating` task
before installing Ruby. So we were getting a warning in Capistrano about
the `updating` task being executed twice.
New CONSUL instances who didn't use the newest installer and haven't
done any deployments with capistrano would get an exception because the
`current` capistrano folder doesn't exist yet.
In this case using `joins` doesn't prevent N+1 queries to get titles for
every record, and since we cannot order translations with just SQL due
to fallbacks, we don't need it.
Automatic SQL injection checks were showing a false positive in this
scope; there was no real vulnerability here because foreign keys, table
names and locales were under our control.
Using `sanitize` we make sure the `href` attribute does not execute any
dangerous code. The possibility of a banner pointing to a dangerous URL
was very reduced, though, since only administrators can edit this
attribute.
We make the code easier to read and at the same time we remove a SQL
injection false positive regarding the use of `WHERE id = #{id}`.
We still get a warning about SQL injection regarding the `tsv =` part.
It's a false positive, since the value of that parameter does not
depend on user input.
We were using Capistrano's shared folder because it was the default
folder used by the capistrano-puma gem. However, it's easier to manage
it if it's under version control.
So we're moving the old `puma.rb` to `puma/development.rb`, and we use
the new `puma.rb` file for all environments except development. Anyone
installing CONSUL can change these files at will or change the specific
files for preproduction, production and staging environments.
This was actually a false positive, since our new regular expression
does the exact same thing. However, false positives generate noise and
make it harder to deal with real issues, so I'm changing it anyway.
We could add a more advanced regular expression, like
`URI::MailTo::EMAIL_REGEXP`. However, this expression marks emails with
non-English characters as invalid, when in practice it's possible to
have an email address with non-English characters.
It was being incorrectly detected as used in a dangerous send. We can
get rid of the warning by taking advantage of the `has_orders` method
and getting rid of this code.
Deploy environment files were loaded after config/deploy.rb was loaded,
meaning if we used settings like `deploy_to` or `current_path` to set
variables inside the config/deploy.rb file, we'd be using the default
settings instead of the ones dictated by the deploy environment files.
These files are only loaded when the stage already has the value set
inside them, so we don't need to set it again.
On the other hand, the `rails_env` setting is configured in the
`config/deploy.rb` file.
