How:
Using a local variable at partials to set a hidden true/false value for
`valuation` parameter on the comment creation form.
Allowing that new param at the comment controller and using it when
building a new Comment.
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.
Why:
Budget Investments already has an existing `comments` relation that is
on use. We need to keep that relation unaltered after adding the
internal valuation comments, that means scoping the relation to only
public comments (non valuation ones) so existing code using it will
remain working as expected.
A new second relation will be needed to explicitly ask for valuation
comments only where needed, again scoping to valuation comments.
How:
Adding a second `valuations` relationship and filtering on both
with the new `valuation` flag from Comment model.
Why:
Internal valuation comments are only for admins and valuators,
not for the public view.
How:
Adding a `not_valuations` scope and use it at the `public_for_api` one
Why:
Budget Investment's valuators need to be able to comment on investments
without making those comments public. We need a way to clearly make a
distinction to avoid "leaking" internal valuation comments.
How:
Adding a boolean `valuation` attribute defaulted to false to the Comments
table, and index on it with concurrent algorithm as explained at
https://robots.thoughtbot.com/how-to-create-postgres-indexes-concurrently-in
The name `valuation` was chosen instead of `internal` because of the more
specific meaning as well as avoiding a collision with existing internal_comments
attribute on Budget::Investment model (soon to be deprecated & removed)
Clear instance variable names help understand what's going around when
you're deep 2 or 3 partials. In this case @budget is only used to carry
around the current_budget so @current_budget is more descriptive.
Using `current_budget` directly around would be an alternative, but
maybe not as maintainable in case we want to change which budget is
being shown (for example the drafting one if you're admin).
We only need finished budget's at budget's index "Finished budgets"
section. So we add the `finished` scope to @budgets variable, and rename
it so its clear what it contains.
Also avoid showing the "Finished budgets" section if there is none
