Using rubocop-rails_config is a nonsense because:
- it relies on rubocop-minitest which is useless here (we use RSpec)
- it relies on rubocop-packaging but disables all its cops
- it targets ruby version 2.7, but we use 3.0
This (unreleased) version contains a fix for a pre-Ruby 3.0 kwargs use.
It fixes a warning in specs using zip files:
> warning: Using the last argument as keyword parameters is deprecated
In the previous commit, we cleaned up the localization of the
Dossier.state enum. This prevented administrate from crashing, but now
the dossier enum are no longer localized in the Manager.
By using a `Field::Enum` type, we instruct the administrate plugin
to look up our localized name for the Dossier state enum.
Rails 6.1.3.2 is a security upgrade, and we had to upgrade quickly.
Unfortunately that broke the administrate gem.
A PR has been opened to fix the issues with the newest Rails version,
and will probably be merged quickly. Meanwhile we can fix the manager
by using the version from the PR for now.
Once the PR is merged and a new version of administrate is released,
we can use a released version of administrate again.
This fixes an error message on app startup about autoloaded
constants:
> DEPRECATION WARNING: Initialization autoloaded the constants ActionText::ContentHelper and ActionText::TagHelper.
The reason for this error is that the Mailjet gem forces the
immediate loading of `action_mailer`. Which leads to the
following sequence of events:
On app init, when bundler requires all the gems in the Gemfile:
- The Mailjet gem is required,
- It loads `ActionMailer::Base`.
Later, when Rails initializes itself:
- `ActionText` creates an `action_text.helpers` initializer,
- This initializer register hooks to add `ActionText` helpers
when either `action_controller_base` or `action_mailer` are loaded,
- But as `action_mailer` has already been loaded, the hook is trigerred
immediately,
- ActiveSupport::Dependencies notices `ActionText` constants do not
exist yet, auto-load them, and add the constants to
`ActiveSupport::Dependencies.autoloaded_constants`.
And even later, at the end of the Rails initialization process:
- The `:warn_if_autoloaded` initializer is run,
- It notices that `autoloaded_constants` is not empty, and prints the
warning message.
See https://github.com/mailjet/mailjet-gem/issues/213
Bootsnap speeds up the initial loading of the Rails app by:
- Optimizing the LOAD_PATH dynamically
- Caching the result of Ruby bytecode compilation
Cached data are written to `tmp/cache/bootsnap*`.
This is enabled in the default Rails app template.
It was unsed by CircleCI to generate test reports in the JUnit XML
format, but:
- We now use Github Actions, which has its own reporting system,
- It prevents us to upgrade to rspec > 3.
i18n-tasks is only used as a standalone command-line tool. It doesn't
need to be included in the app.
It also prevent a parser warning from appearing when running any rails
command:
> warning: parser/current is loading parser/ruby27, which recognizes
> warning: 2.7.2-compliant syntax, but you are running 2.7.1.
> warning: please see https://github.com/whitequark/parser#compatibility-with-ruby-mri.
Now this (legitimate) warning only appears when running the i18n-tasks
command.
- It was included to make Rubymine happy, but nowadays Rubymine seems
to load the debugger without touching the Gemfile
- It keeps matching an invalid version when `bundle upgrade`-ing the
dependencies.
when trying to access manager, if superadmin did'nt enable otp, he/she is redirected to a page to enable 2FA. When superadmin is enabling 2FA, he has to to scan a qrcode with the 2FA application client. And afterwards, the superadmin has to log in with email, password and OTP code.
Re-generate the schema using `bin/rake erd`.
NB: there's a way to update the PDF automatically after each migration.
But it requires `graphviz` to be installed locally, which I'm not
sure I want to require by default.
Annotations will be generated only for models, and sorted (to avoid differences
depending on the order in which migrations are ran).
The annotations will be automatically updated every time `rails db:migrate`
is run on a development environment.
