The current tracking section had a few issues:
* When browsing as an admin, this section becomes useless since no
investments are shown
* Browsing investments in the admin section, you're suddenly redirected
to the tracking section, making navigation confusing
* One test related to the officing dashboard failed due to these changes
and had been commented
* Several views and controller methods were copied from other sections,
leading to duplication and making the code harder to maintain
* Tracking routes were defined for proposals and legislation processes,
but in the tracking section only investments were shown
* Probably many more things, since these issues were detected after only
an hour reviewing and testing the code
So we're removing this untested section before releasing version 1.1. We
might add it back afterwards.
Tags and help links can be edited, but aren't used anywhere. Since we
don't know what the intended behavior was, I'm removing them for now.
My best guess is tags were supposed to be used so investments for a
budget can only be assigned tags present in the budget. Achieving that
behavior wouldn't be a trivial task.
We need to add a hidden field for each group of check boxes, so if we
don't check anything, the hidden field is sent to the server, indicating
nothing was selected. Without the hidden field, the server will not know
anything has been done to the check boxes.
The easiest way to do it is using `collection_check_boxes`, which also
adds labels to every check box.
We were using two different systems to set translations in JavaScript:
to set the text for languages, we were using data attributes, and to set
the text for staff members, we were using AJAX calls.
I find data attributes keep the code more simple, since there's no need
to define an extra route and controller action. Furthermore, the user
experience is better because response times are faster.
So now both places use data attributes.
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.
Move the button so that it appears in the Winners tab of the
budget_investments index.
When the budget is in "Balloting projects", "Reviewing Ballots"
or "Finished budget" phases, the button will appear as a button
(clickable). If there are no winners calculated yet, the text
will be "Calculate winner investments"; if there are, the text
will be "Recalculate winner investments".
If the budget is in another phase, the button will be
disabled and a message will appear: 'The budget has to stay on
phase "Balloting projects", "Reviewing Ballots" or
"Finished budget" in order to calculate winners projects'
Why:
The Admin Budget form has a submit button for saving the record, adding
another submit input to destroy the record actually adds to the html:
`<input type="hidden" name="_method" value="delete">` and it collides
with the save button, forcing it to perform a destroy instead of save.
Previously the destroy button was not in the same div as the save button
How:
Just changing the Destroy from a button_to to a link_to.
