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.
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.
For now we're only adding rules related to spacing and double quotes,
following the same rules we use in Ruby, which are the same rules
CoffeeScript followed when compiling these files.
We're also using the recommended ESLint rules, which will warn us about
many JavaScript common pitfalls, the `strict` rule which enforces using
strict mode, and the `no-console` rule, which will prevent us from
shipping code meant for debugging.
Although it's arguably more common to use the JSON format to define
these rules, I've chosen YAML because it's the format we use in all our
linters.
These statements were automatically added by CoffeeScript.
I'm only removing the obvious cases; there might be more cases where the
`return` statement isn't necessary.
