We were very inconsistent regarding these rules.
Personally I prefer no empty lines around blocks, clases, etc... as
recommended by the Ruby style guide [1], and they're the default values
in rubocop, so those are the settings I'm applying.
The exception is the `private` access modifier, since we were leaving
empty lines around it most of the time. That's the default rubocop rule
as well. Personally I don't have a strong preference about this one.
[1] https://rubystyle.guide/#empty-lines-around-bodies
Having exceptions is better than having silent bugs.
There are a few methods I've kept the same way they were.
The `RelatedContentScore#score_with_opposite` method is a bit peculiar:
it creates scores for both itself and the opposite related content,
which means the opposite related content will try to create the same
scores as well.
We've already got a test to check `Budget::Ballot#add_investment` when
creating a line fails ("Edge case voting a non-elegible investment").
Finally, the method `User#send_oauth_confirmation_instructions` doesn't
update the record when the email address isn't already present, leading
to the test "Try to register with the email of an already existing user,
when an unconfirmed email was provided by oauth" fo fail if we raise an
exception for an invalid user. That's because updating a user's email
doesn't update the database automatically, but instead a confirmation
email is sent.
There are also a few false positives for classes which don't have bang
methods (like the GraphQL classes) or destroying attachments.
For these reasons, I'm adding the rule with a "Refactor" severity,
meaning it's a rule we can break if necessary.
The `type: :feature` is automatically detected by RSpec because these
tests are inside the `spec/features` folder. Using `feature` re-adds a
`type: :feature` to these files, which will result in a conflict when we
upgrade to Rails 5.1's system tests.
Because of this change, we also need to change `background` to `before`
or else these tests will fail.
Eventhough some of us sentimentals still like the syntax `to_not` the current trend is to move to the new syntax `not_to`.
In this commit we are updating the references of expectations that used `to_not` to `not_to`.
When we were visiting a page showing the content of a record which uses
globalize and our locale was the default one and there was no
translation for the default locale, the application was crashing in some
places because there are no fallbacks for the default locale.
For example, when visiting a legislation process, the line with
`CGI.escape(title)` was crashing because `title` was `nil` for the
default locale.
We've decided to solve this issue by using any available translations as
globalize fallbacks instead of showing a 404 error or a translation
missing error because these solutions would (we thinkg) either require
modifying many places in the application or making the translatable
logic even more complex.
Initially we tried to add this solution to an initializer, but it must
be called after initializing the application so I18n.fallbacks[locale]
gets the value defined in config.i18n.fallbacks.
Also note the line:
fallbacks[locale] = I18n.fallbacks[locale] + I18n.available_locales
Doesn't mention `I18n.default_locale` because the method
`I18n.fallbacks[locale]` automatically adds the default locale.
Just like it's done everywhere else in the application. Not doing so
means users who aren't logged in receive a "you aren't authorized"
message when they try to create a new legislation proposal instead of
being redirected to the login page.
They were failing if executed right before midnight. If the process is
created right before midnight and then the date changes, when we visit
the process path the phase will aready be open.
