Upgrade Rails to v7.1 & update gems (mostly only minor versions)

[Splines]

This fixes #554. See the upgrade guide and all config keys.

Commands used to perform the update:

# Edit Gemfile manually and update Rails version there. Then run
bundle update

# And then (development env variable was only set later in the process)
RAILS_ENV="development"  bin/rails app:update --trace

# I've also run `bin/rails app:update --trace` inside a local dev mampf container to finish the process
# (active record needed to connect to the database)

Notable changes

Only changes I found noteworthy in particular.

• ⚠ Memcache is using connection pooling by default. Let's see if that will cause any troubles in production.
• raise_on_missing_translation is great, I guess. So i've activated it.
• Set default log level in production to info instead of warn. This will log a bit more information that may be helpful in production. info is also the default by Rails.
• Set config.require_master_key = true. With this config option activated, If the Rails master key is not available in production, the app won't boot, which is good.
• ❓ I'm unsure whether this hash change affects us: allow_deprecated_parameters_hash_equality
• Transactions callbacks are handled in a better way to avoid stale data. See here.
• ❓❗ Active Record Encryption now uses SHA-256 as its hash digest algorithm.
  --> Not affected as we don't use Active Record Encryption.
• Some migrations were introduced by the Rails updater. I don't really know what they do, will have to review them.
  --> Deleted them as we don't use ActiveStorage, but shrine instead.
• globalize_attribute_names, see this comment

For the future

• Content-Security-Policy might be useful to set up but we have to watch out if this is working in conjunction with nginx.

TODO

• Go through notable changes list and update new_framework_defaults_7_1.rb accordingly
• Check if everything is working locally
• Check if everything is working in mampf-experimental
• The Rails updater introduced some migrations and I'm not sure yet what their purpose is. Will have to review them. (see above)

[fosterfarrell9]

Some migrations were introduced by the Rails updater. I don't really know what they do, will have to review them.

I think we can delete them since we do not use ActiveStorage (but the shrine gem instead for uploads). They would not do anything anyway since they all contain the line

return unless table_exists?(:active_storage_blobs)

and this table does not exist in our setting.

Active Record Encryption now uses SHA-256 as its hash digest algorithm.

At least as of now, this does not affect us since we do not use ActiveRecord Encryption (which was introduced in Rails 7.0).

I'm unsure whether this hash change affects us: allow_deprecated_parameters_hash_equality

Me as well. This seems to refer to this:

Comparing equality between `ActionController::Parameters` and a
`Hash` is deprecated and will be removed in Rails 7.2. Please only do
comparisons between instances of `ActionController::Parameters`. If
you need to compare to a hash, first convert it using
`ActionController::Parameters#new`.
To disable the deprecated behaviour set
`Rails.application.config.action_controller.allow_deprecated_parameters_hash_equality = false`

I would expect we do not use the deprecated comparisons but to be sure one would have to go through all the controllers.

[Splines]

I think we can delete them since we do not use ActiveStorage (but the shrine gem instead for uploads).

Thanks, I just deleted these migrations.

At least as of now, this does not affect us since we do not use ActiveRecord Encryption (which was introduced in Rails 7.0).

Ah, great, one less thing to worry about.

[Splines]

This seems to refer to this:

@fosterfarrell9, Where do you have that info from, i.e. the code block with the explanation for the parameter?

[fosterfarrell9]

In the Rails source code: https://github.com/rails/rails/blob/v7.1.3.2/actionpack/lib/action_controller/metal/strong_parameters.rb

So I think we just have to look if for == with params involved in our controllers.

[Splines]

So I think we just have to look if for == with params involved in our controllers.

I've checked that for our controllers by searching for "==". I could only find comparison to string or integers but not to any hashes. Maybe you can take a look as well?

In the comments_controller we have @comment.thread.config.comment_voting.to_sym == :ld, but that's not an issue, I guess, since the first argument is not an action controller parameter.

In the future, before upgrading to Rails 7.2, we should check our production log and see if the warning you mentioned pops up there. If it does, we know where to fix this in the code.

[Splines]

In f486935, I made the changes regarding globalize_attribute_names according to this mobility issue.

For reviewers

• I've verified that it works for Division, could you @fosterfarrell9 verify it for Program and Subject? (since I don't know where to find the latter two in the UI and I'd have to look through the code where we use it, maybe you can show it to me today in persona).

[Splines]

@fosterfarrell9 Could you resolve the one missing conversation?