We can remove the `new_framework_defaults_6_1` file by using Rails 6.1
default options and overwriting the one we haven't enabled.
We've experienced problems while running the tests (probably the same
would happen on production) when enabling the `has_many_inversing`
option. For example, after creating a legislation answer for a question
with no answers, calling `question.answers_count` would then return `2`
instead of `1`.
So we aren't enabling this option.
This is the default setting in Rails 6.1, and generates an extra tag in
the HTML which tells the browser to download and cache these files as
soon as possible, even before they're needed.
This might not be that relevant in our application, since on most pages
we only generate one CSS and one JS file. But it might make it easier to
move the `javascript_include_tag` statement to the bottom of the page in
the future if we detect that doing so increases performance.
Since we aren't using the old way to handle multiple databases (because
we don't use multiple databases), we can safely enable this option
without breaking anything.
This way user agents will know that the redirection from HTTP to HTTPS
is permanent and not temporary, which is the case if we activate the
`force_ssl` option (which we do by default).
These measures increase protection against CSRF ataks. The only reason
Rails provides them as a configuration option is there are complex
applications that run one version of the code in some servers while
running an old version of the code in other servers might run into
issues because the the old version won't handle the tokens or cookies
generated by the new version.
Since most Consul applications use just one server and the ones with
more servers would only face this issue for a few seconds (while
upgrading to a new version of Consul Democracy), we can safely enable
these configuration options.
Not sure this configuration option does anything, though, since it's
been removed in Rails 7.0 because it was not halting the callbacks.
But, if it does nothing, it's the same as disabling it, which is what we
were doing until now, so in the end using the Rails 6.1 default value
does no harm.
This mostly benefit people using external services, as now there's no
need to query the service to check whether a variant exists.
For most Consul Democracy installations, this will probably not be
relevant, so we're sticking wih the default value.
This patch was added in commit baefc249f because both ViewComponent and
Wicked PDF monkey-patched the `render` method and so they were
incompatible.
However, Rails 6.1 includes the patch used by ViewComponent, meaning
ViewComponent doesn't monkey-patch the `render` method anymore, and so
it's compatible with Wicked PDF.
Note that `Capybara.app_host` now returns `nil` by default and that
breaks tests using `lvh.me` or our custom `app_host` method, so we're
setting `Capybara.app_host` to the value it had in earlier versions of
Rails. I also haven't found a way to remove the code to set the
integration session host in relationable tests which I mentioned in
commit ffc14e499.
Also note that we now filter more parameters, and that they match
regular expressions, so filtering `:passw` means we're filtering
`passwd`, `password`, ...
Internet Explorer 8 was released in 2009 and people using it already
know that most web pages look broken on it, so we don't need to warn
them.
Removing it makes our application layout file much easier to read and
modify.
The code based on the logger Rails uses by default; as mentioned in the
Rails configuration guide:
> [the logger] defaults to an instance of ActiveSupport::TaggedLogging
> that wraps an instance of ActiveSupport::Logger which outputs a log to
> the log/ directory. You can supply a custom logger, to get full
> compatibility you must follow these guidelines:
>
> * To support a formatter, you must manually assign a formatter from
> the config.log_formatter value to the logger.
> * To support tagged logs, the log instance must be wrapped with
> ActiveSupport::TaggedLogging.
> * To support silencing, the logger must include
> ActiveSupport::LoggerSilence module. The ActiveSupport::Logger class
> already includes these modules.
Note we're excluding a few files:
* Configuration files that weren't generated by us
* Migration files that weren't generated by us
* The Gemfile, since it includes an important comment that must be on
the same line as the gem declaration
* The Budget::Stats class, since the heading statistics are a mess and
having shorter lines would require a lot of refactoring
For the HashAlignment rule, we're using the default `key` style (keys
are aligned and values aren't) instead of the `table` style (both keys
and values are aligned) because, even if we used both in the
application, we used the `key` style a lot more. Furthermore, the
`table` style looks strange in places where there are both very long and
very short keys and sometimes we weren't even consistent with the
`table` style, aligning some keys without aligning other keys.
Ideally we could align hashes to "either key or table", so developers
can decide whether keeping the symmetry of the code is worth it in a
case-per-case basis, but Rubocop doesn't allow this option.
We were already applying these rules in most cases.
Note we aren't enabling the `MultilineArrayLineBreaks` rule because
we've got places with many elements whire it isn't clear whether
having one element per line would make the code more readable.
Code based on the logger Rails uses by default; as mentioned in the
Rails configuration guide:
> [the logger] defaults to an instance of ActiveSupport::TaggedLogging
> that wraps an instance of ActiveSupport::Logger which outputs a log to
> the log/ directory. You can supply a custom logger, to get full
> compatibility you must follow these guidelines:
>
> * To support a formatter, you must manually assign a formatter from
> the config.log_formatter value to the logger.
> * To support tagged logs, the log instance must be wrapped with
> ActiveSupport::TaggedLogging.
> * To support silencing, the logger must include
> ActiveSupport::LoggerSilence module. The ActiveSupport::Logger class
> already includes these modules.
Just like the documentation mentions, we're enabling log rotation using
"1" as the number of old files to keep and then the maximum size of the
log file.
DelayedJob offers the `--monitor` (aliased as `-m`) option to create a
process that monitors the workers and restarts them when they crash.
This change implies that, in order to stop the delayed job workers, we
now need to pass the `-n` option when running `bin/delayed_job stop`:
`RAILS_ENV=production bin/delayed_job -n 2 stop`.
By using the bindPopup function instead of the click event
popups work when using the keyboard.
Note that now we are loading all the map markers in the first
request in a single query to the database (needed when there
is a lot or markers to show). Because of that we removed the
AJAX endpoint.
Note that in the budgets wizard test we now create district with no
associated geozone, so the text "all city" will appear in the districts
table too, meaning we can't use `within "section", text: "All city" do`
anymore since it would result in an ambiguous match.
Co-Authored-By: Julian Herrero <microweb10@gmail.com>
Co-Authored-By: Javi Martín <javim@elretirao.net>
Quoting `errbit/errbit/blob/main/app/views/apps/_configuration_instructions.html.erb`
> airbrake.io supports various features that are out of scope for Errbit.
We had two different keys with the same text and were passing it as a
parameter. Since the text is the same in any case, we don't need a
parameter for it.
Note we are using the `proposals` i18n key instead of creating a new one
in a `shared` namespace one because creating a new key would mean that
we'd lose the already existing translations in Crowdin.
The only view that linked to this action was never used and so it was
deleted in commit 0bacd5baf.
Since now the proposals controller is the only one place rendering the
`shared/map` partial, we're moving it to the proposals views.
We were using `server` on staging but `server1` and `server2` on
preproduction and production.
The reason behind it is we've always used one server on staging but
sometimes we've used several servers on preproduction and production.
However, this is a bit of a mess on installations which have only one
server on preproduction or production and need to use the `server` key
for the staging environments but `server1` for other environments.
So, in order to keep compatibility with existing Consul installations,
we're now allowing either `server` or `server1` on any environment.
It doesn't make much sense that by default we use one server on
production on two servers on preproduction.
Note we're keeping `server1` instead of using just `server` in order to
keep compatibility with existing installation.
