We were inconsistent on this one. I consider it particularly useful when
a method starts with a `return` statement.
In other cases, we probably shouldn't have a guard rule in the middle of
a method in any case, but that's a different refactoring.
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.
Using the `_html` suffix automatically marks texts as HTML safe, so
doing so on sanitized texts is redundant.
Note flash texts are not sanitized the moment they are generated, but
are sanitized when displayed in the view.
Some of our team members don't like using `do...end` for scopes, and
some other team members don't like using `{ ... }` for multi-line
blocks, so we've agreed to use class methods instead.
Investments can be reclassified to a different heading during the participatory budget process.
Whilst we are recording this change of heading in the `previous_heading_id` attribute, we are only keeping the _last_ heading. If there are multiple reclassifications we lose this chain of reclassifications.
In this commit we are adding an `original_heading_id` attribute, that will only be set once, when creating the investment, and will not get lost with multiple reclassificaitons of an investment.
As we cannot order budget investments by any translatable field through
AR queries we are doing the same using ruby Array sort method and doing
array pagination manually with Kaminari 'paginate_array' helper method.
Results were not including records without translations for current
locale (I18n.locale). Now we search for given title against all
translation fallbacks for current locale.
Also fix sort_by_title method [1]
[1] Use ruby sort instead of active record order scope because Globalize
does not provide a way to search over all available fallbacks when
translation for current locale does not exist.
Some queries were accessing original column instead of the new
translatable one. This should have been causing unexpected behavior
for requests maded in a different locale than the application default.
When params[:budget_investment][:valuation_tag_list] was not present,
which is the case when updating an investment using the "mark as visible
to valuators" checkbox, we were removing all valuation tags.
Using a virtual attribute to assign the tags only if the parameter is
present simplifies the code in the controller and avoids the issue.
So under the tab "without valuator" we don't show investments assigned
to a valuator group, just as expected by administrators.
There was a conflict while applying this commit to the CONSUL repo. I've
decided to re-introduce the test which was deleted in commit dddf026a,
which hadn't been deleted in AyuntamientoMadrid@192f1182.
The right syntax would have been:
`after_save :recalculate_heading_winners, if: :incompatible_changed?`
However, since the method `recalculate_heading_winners` already executes
the `if incompatible_changed?` condition, removing it keeps the intended
behaviour.
