Using the `_html` suffix in an i18n key is the same as using `html_safe`
on it, which means that translation could potentially be used for XSS
attacks.
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.
The name `safe_html_with_links` was confusing and could make you think
it takes care of making the HTML safe. So I've renamed it in a way that
makes it a bit more intuitive that it expects its input to be already
sanitized.
I've changed `text_with_links` as well so now the two method names
complement each other.
This way we can simplify the way we generate form fields. In some cases,
we also use the human attribute in table headers, which IMHO makes
sense.
I haven't moved all of them: for example, sometimes a label is
different depending on whether it's shown to administrators, valuators,
or users. And I haven't touched the ones related to devise, since I
wasn't sure about possible side effects.
Note I've also removed placeholders when they had the same text as their
labels, since they weren't helpful. On the contrary, the added redundant
text to the form, potentially distracting users.
I'm not sure why it isn't already done by foundation's form builder. It
doesn't make any sense to change an ID of a form field without changing
the `for` attribute of its label.
Using the block syntax to generate the label with a <span> tag inside
isn't necessary after upgrading foundation_rails_helpers. Before the
upgrade, we couldn't do so because the <span> tag was escaped.
Rails automatically calls the `id` method inside scopes and the variable
name makes more sense if it represents investments instead of the number
of investments.
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
Valuators should not be able to edit a finished valuation (only admins
should).
The valuation form is only shown to the valuator if he has that ability
(we've previously modified app/models/abilities/valuator.rb to be able
to rely on `valuate` over an investment to check that)
If the valuator can't see the form, we present him just the data in
plain text.
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.
Before we could have multiple current budgets, as we now only have one
current_budget, some specs broke.
As there is no need to display multiple budgets to Valuators, only the
current budget is necessary, we can remove arrays and assume that only
a single budget, the current budget, is displayed to Valuators
