We made a few experiments with forked repositeries after applying commit
dc1e0209a and everything seems to work fine, but it looks like that
isn't the case. For instance, on pull requests opened by external
contributors, the tests aren't running.
The fix we're applying is mentioned on the Knapsack Pro repository [1]
(pull request 197).
[1] https://github.com/KnapsackPro/knapsack_pro-ruby
Previously the condition was needed because _without it_ the Admin::Poll::Questions::Answers::ImagesController would have resulted in settings? evaluating to true. This was undesired because that controller was scoped under Polls, so only polls? should have evaluated to true. Now that we have moved the images link to the customization menu, this check is not necessary anymore.
There were already some menu items to customization pages under the "Site content" menu. It therefore makes sense to move "Custom images" and "Custom content blocks" (which were previously
located under "Settings") to "Site content" as well.
In order to leave the page using turbolinks and then going back, we were
clicking on the "Help" page link, but this link doesn't have to be
available on every Consul Democracy installation.
So we're using the link to the homepage instead.
We originally set a daily interval because we hadn't updated our gem
dependencies for a year.
However, we usually wait a few days/weeks between the time a gem is
released and the moment we update it, and there are gems releasing new
versions every few days, so maintaining daily updates would become
tedious quickly.
So we're now doing it once a month. We're also increasing the limit of
open pull requests so we don't need to worry about whether dependabot is
opening pull requests for every dependency.
We added this option in commit d17b2523c, but Bundler now keeps
descriptors by default. While this behavior was backported to Ruby
3.0.x, we're changing it now because, we've only noticed it now that
we're upgrading to Ruby 3.1.x, since it was first developed for that
version [1].
[1] https://github.com/rubygems/rubygems/pull/4812/commits/88b7a3e7e2
This syntax has been added in Ruby 3.1.
Not using a variable name might not be very descriptive, but it's just
as descriptive as using "block" as a variable name. Using just `&` we
get the same amount of information than using `&block`: that we're
passing a block.
We're still using `&action` in `around_action` methods because here we
aren't using a generic name for the variable, so (at least for now) we
aren't running this cop on controllers using `around_action`.
Ruby 3.1 adds the option for hash shortcuts, so it's possible to write
`{ user: , poll: }` instead of `{ user: user, poll: poll }`.
By default, Rubocop expects the new syntax in Ruby 3.1. While right now
I absolutely hate this new syntax, we're allowing both the old and the
new styles because we might start adopting it once we get used to it.
Note we updated the `mail` gem in commit 103742847, which is necesary
for Ruby 3.1 because it adds the net-smtp dependency. The net-smtp
library was removed from Ruby in Ruby 3.1, and if we don't include it,
we get an error:
```
cannot load such file -- net/smtp (LoadError)
```
We're also updating the Bundler version in the Gemfile.lock so it's the
one included in Ruby 3.1. Without updating it, we get a warning:
```
Calling `DidYouMean::SPELL_CHECKERS.merge!(error_name => spell_checker)'
has been deprecated. Please call `DidYouMean.correct_error(error_nam e,
spell_checker)' instead.
```
Finally, in order to make Capistrano work, we need to add a couple more
changes:
* Make the net-ssh gem compatible with SSL 3.0; done in commit b2eec088b
* Explicitly allow aliases in the `deploy-secrets.yml` file because
Psych 4.x (included in Ruby 3.1) doesn't load aliases without this
option
We were getting a warning since upgrading to Rails 6.1:
DEPRECATION WARNING: Calling `delete` to an ActiveModel::Errors messages
hash is deprecated. Please call `ActiveModel::Errors#delete` instead.
So we're deleting the error instead of deleting the message.
We were getting a deprecation warning:
DEPRECATION WARNING: Rendering actions with '.' in the name is
deprecated: welcome/_recommended_carousel.html.erb
We were getting a warning in one of the tests:
DEPRECATION WARNING: Rendering actions with '.' in the name is
deprecated: application/nonExistentJavaScript.js
I haven't found a case where the behavior on production environments is
different due to this change; the application seems to behave the same
way as it used to. So I'm not adding tests for this change.
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`, ...
