Previously the draft mode was a phase of the PB, but that had some
limitations.
Now the phase drafting disappears and therefore the PB can have the
status published or not published (in draft mode).
That will give more flexibility in order to navigate through the
different phases and see how it looks for administrators before
publishing the PB and everybody can see.
By default, the PB is always created in draft mode, so it gives you
the flexibility to adjust and modify anything before publishing it.
It was removed in commit 128a8164 because we hadn't reviewed it nor
tested it properly. We're now adding it again, fixing the issues we've
found while reviewing.
There's no reason to allow administrators to check stats and results for
a poll when it isn't finished or when results and stats are not enabled.
Now admins have the same permissions as everyone else.
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.
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 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.
Unfortunately this feature wasn't properly reviewed and tested, and it
had many bugs, some of them critical and hard to fix, like validations
being skipped in concurrent requests.
So we're removing it before releasing version 1.1. We might add it back
in the future if we manage to solve the critical issues.
This commit reverts commit 836f9ba7.
When accessing the URL `/admin/stats/budget_balloting?budget_id=X'
for a budget in a phase prior to the balloting phase, the following
error was raised due to the stats where not calculated yet.
Instead, we'll now show a flash message.
NoMethodError:
undefined method `[]' for nil:NilClass
./app/controllers/admin/stats_controller.rb:82
Added check in poll card that allows setting the value of
results_enabled flag.
Access to stats/results now is controlled with abilities.
Polls related to proposals will be accessible to the proposal author
like they were administrators.
Why:
Only admins or valuators (for those investments they've assigned) can
create internal valuation comments on them.
How:
* Creating a new `comment_valuation` ability for admins and valuators in
the same manner the `valuate` ability works.
* Adding a validation at Comment model for those with `valuation` flag
active that checks if the author can make a valuation comment on the
commentable, as well as the respective active record error messages.
This will prevent comments from being created at a controller level as
well.
* Improving comment factory trait `valuation` to have an associated
investment, author that is a valuator and setting the valuator on the
valuators list of the investment
