We split the section about pull requests, reducing the steps needed to
contribute since there's already a link to help people working on their
first pull request, and the rest don't need to be told to fork the repo.
Current team members don't use twitter very often, the `Not-ready` label
has has been removed, and issue assignees are sometimes deceiving.
We're also removing the "Limpiar" section from the Spanish document,
which had already been removed from the English document in commit
8eb8bb9a.
Although we weren't showing links in the views to execute certain
actions, forms could be still sent using a PUT/PATCH pull request to the
controller actions.
The new CSV report was more configurable and could work on proposals,
processes and comments. However, it had several issues.
In the public area, by default it generated a blank file.
In the admin section, the report was hard to configure and it generated
a file with less quality than the old system.
So until we improve this system, we're bringing back the old investment
CSV exporter.
This commit reverts most of commit 9d1ca3bf.
We were adding the condition to show the form in the view. However, that
doesn't prevent users from sending a POST/PUT request to the controller
action.
We could add the condition to the controller as well, but since the
`valuate` permission is only used in one place, it's easier to restrict
that permission to valuators who can edit the dossier.
Don't use <label> tags for things that are not labels, add a proper
<title> for the page, add a back link, remove an unnecessary
`inline-block` style for a header, localize dates and field names, ...
The interface could be further improve: proper diffs for long texts,
better separation between fields, ...
The name of the changed field is translated, values are truncated so
descriptions with thousands of character would make this table huge and
impossible to read, dates are localized, and values like arrays and
booleans are displayed properly.
Our manual implementation had a few issues. In particular, it didn't
track changes related to associations, which became more of an issue
when we made investments translatable.
Using audited gives us more functionality while at the same time
simplifies our code. However, it adds one more external dependency to
our project.
The reason for choosing audited over paper trail is audited seems to
make it easier to handle associations.
If we validate the presence of the old value and the new value, changes
in optional fields will not be stored if either the old value or the new
value are blank.
Since we were saving the same budget investments several times, once for
every language, we were creating more than 1000 changelog entries.
Assigning the language attributes when creating the investments
generates less entries, making it easier to work with them.
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.
If we didn't run this task, investments for existing budgets wouldn't
show their administrator/valuators as an option when we're editing them,
leading to data loss.
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 were ordering one group of tags alphabetically and then adding
another group of tags which wasn't ordered alphabetically, which didn't
make much sense.
Since budgets now have milestone tags, the name of this method was
confusing and will conflict with the name generated by acts_as_taggable.
Note the new name could be improved too.
We were manually doing the same thing, generating inconsistent results,
since the method `valuation_tag_list` was using the `valuation` context,
when actually the expected behavior would be to use the `valuation_tag`
context.
