For the HashAlignment rule, we're using the default `key` style (keys
are aligned and values aren't) instead of the `table` style (both keys
and values are aligned) because, even if we used both in the
application, we used the `key` style a lot more. Furthermore, the
`table` style looks strange in places where there are both very long and
very short keys and sometimes we weren't even consistent with the
`table` style, aligning some keys without aligning other keys.
Ideally we could align hashes to "either key or table", so developers
can decide whether keeping the symmetry of the code is worth it in a
case-per-case basis, but Rubocop doesn't allow this option.
We were already applying these rules in most cases.
Note we aren't enabling the `MultilineArrayLineBreaks` rule because
we've got places with many elements whire it isn't clear whether
having one element per line would make the code more readable.
When accessing the valuation area, we were only displaying the
investments directly assigned to the current valuator, but we weren't
displaying the investments assigned to that valuator's group.
Using the `assigned_investments_ids` method, which takes the valuator
group into account, solves the issue.
We've also found an issue on our development machines: since we don't
have a unique index per `investment_id` and `valuator_id` in the
`budget_valuator_assignments` table, we've found duplicate records on
this table. When that happened, we were displaying the same investment
several times.
Since now we no longer join this table in the query returning the
investment, this issue is also solved, and we're adding a test for it.
We can now remove the call to the `distinct` method when calculating the
number of investments per heading.
We weren't allowing the `budget_id` parameter and then we were adding it
manually. We were also allowing other parameters that aren't used in the
valuation section.
So we're allowing budget and heading, which are the only parameter we're
offering filters for in the user interface. Note the `budget_id`
parameter doesn't seem to make sense because we're already inside a
`@budget.investments` statement, but the `budget_id` parameter is
required by the `scoped_filter` method.
Since we allow many active budgets at the same time, the
controller should now check the budget given by params.
Before this change the controller was checking the latest
published budget, ignoring the request parameter `budget_id`.
When customizing CONSUL, one of the most common actions is adding a new
field to a form.
This requires modifying the permitted/allowed parameters. However, in
most cases, the method returning these parameters returned an instance
of `ActionController::Parameters`, so adding more parameters to it
wasn't easy.
So customizing the code required copying the method returning those
parameters and adding the new ones. For example:
```
def something_params
params.require(:something).permit(
:one_consul_attribute,
:another_consul_attribute,
:my_custom_attribute
)
end
```
This meant that, if the `something_params` method changed in CONSUL, the
customization of this method had to be updated as well.
So we're extracting the logic returning the parameters to a method which
returns an array. Now this code can be customized without copying the
original method:
```
alias_method :consul_allowed_params, :allowed_params
def allowed_params
consul_allowed_params + [:my_custom_attribute]
end
```
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.
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
Joining the translations table caused duplicate records to appear.
Ordering with SQL is simply too hard because we need to consider
fallback locales.
Thanks Senén for providing most of the tests in the poll spec.
Why:
Heading filter where not being correctly displayed
How:
Increasing scenario to cover all possible combinations, and fixing the
heading_filters method of the Valuation Budget Investment Controller to
correctly:
* Find how many investments the valuator can access
* Count investments for each heading
Why:
Heading filter where not being correctly displayed
How:
Increasing scenario to cover all possible combinations, and fixing the
heading_filters method of the Valuation Budget Investment Controller to
correctly:
* Find how many investments the valuator can access
* Count investments for each heading
When a valuator tries to edit/valuate an investment outside valuating
phase, an explanatory message will be shown along with a redirect to
prevent access.
Why:
Budget Investment's valuators should be able to see internal valuation
comments thread at both show and edit views.
How:
At Valuation::BudgetInvestmentsController:
* Include CommentableActions to gain access to the entire feature, with
required resource_model & resource_name methods.
* Add the only possible order (oldest to newest)
* Load comments on both show & edit actions, passing `valuations` flag
to the CommentTree in order to only list those.
At CommentTree:
* Use `valuations` flag as instance variable to decide wich
comment threat to load: valuations (if relation exists) or comments.
