There was a flaky spec supporting proposals. It's hard to reproduce and
be sure about what was going on, so here is my best guess. Given the
code:
```
within(".proposals-list") { click_link proposal.title }
within("#proposal_#{proposal.id}_votes") { click_link('Support') }
```
The first clicked link generates an AJAX request. Usually, Capybara
would wait for the AJAX request to generate a "Support" link in the
element `#proposal_XX_votes`. However, there's already a
`#proposal_XX_votes` element with a "Support" link on the proposals
index page!
So Capybara doesn't have to wait for the AJAX request to finish before
clicking the "Support" link. From then on, anything can happen.
Another option that works:
```
within(".proposals-list") { click_link proposal.title }
within(".proposal-show #proposal_#{proposal.id}_votes") { click_link('Support') }
```
With this code, the link selector fails on the proposals index page, and
Capybara waits for the AJAX request to finish.
Related to issue #2558.
These tests were failing randomly because there is no guarantee
the methods `Budget#email_selected` and `Budget#email_unselected` will
always send the emails in the same order, because `investments.selected`
and `investments.unselected` don't necessarily return the records in the
order they were created.
Ordering by id is certainly not very elegant; however, ordering by
another field like `created_at` is dangerous because the record could be
created at (almost) the exact same time.
Related to issue #2446 and issue #2519.
The test "Budget Investments Show milestones" was failing in certain
cases where `Globalize.locale` had been changed in a previous test.
Since having different values in `Globalize.locale` and `I18n.locale`
has proven to be an issue on the test enviroment, this commit also
changes application code in order to avoid similar situations on
production.
See issue #2718.
As stated in #1196, compiling everything related to CKEditor made
compilations slower. However, not compiling any plugins meant Travis had
to compile them while running a test. It often resulted in a test
failing because the time Travis took to compile the plugins the
application uses exceeded Capybara's wait time.
The restore feature was not working properly. When pushed, the button
was removing the notification from the admins panel, but it was not
restoring in the proposal.
I added an `after_restore` function (that I missed in the first PR)
so that the notification is unmarked as moderated.
Add the admin UI needed to restore the hidden proposal notifications
when hidden by moderator. The admin can restore them or confirm
the moderation made by moderator, just like proposals.
The little menu with the hide notification link and block user link
has been added to each proposal notification.
JS for adding the fade efect has also been added.
Add new routes for the proposal notifications edition and
abilities to let moderators edit it (mark as ignored, hide, etc.).
The notifications are not flaggable because they doesn't work like that,
but in a similar way. The moderator/administrator is in charge of hidding
them through the UI, so the normal users don't flag it as inappropriate.
New controller Moderation::ProposalNotification to manage the moderators
work.
The migration to generate the columns needed for the feature.
There are three new columns:
moderated: a boolean that, when true, it means a moderator has
hidden a proposal notification. The notification is hidden immediately
and it's shown in the moderators proposal notifications index.
hidden_at: used by acts_as_paranoid to hide the notification from the list.
It's like deleting it, but without deleting definitely from DB.
ignored_at: used to mark as a notification as ignored, so that it will
appear in marked as reviewed and not in the pending list. WARNING! this
doesn't mean that it will disappear from the 'All' filter.
The browser was generating one AJAX request per keystroke, ignoring the
timeout. The clearTimeout() function needs to be called with the ID
value returned by setTimeout().
