We were seeing an exception when a user was following a proposal and
that proposal becomes hidden
With this commit we are skipping this proposals and hopefully fixing
this exception
We are also adjusting the count of followed proposals, without
including hidden proposals. It might be cleaner, to remove a `Follow`
when its `Followable` becomes hidden. But then we should probably
activate the `Follow` again if the `Followable` becomes non-hidden…
For now this commit should suffice 😌
We were seeing an exceptions in the home page when displaying
recommendations. This was due to trying to load tags of hidden proposals
With this commit we are skipping proposals that that have been hidden,
which will hopefully solve this exception
As it happened with results (commit 4a559ed), these tests failed if
`Date.current` changes between the moment records are created and the
moment the rest of the test is executed.
The tests depending on the date changing were still failing because
Date.current was being stubbed after loading the factories. The
following lines affected these specific tests:
factory :poll_officer_assignment, class: 'Poll::OfficerAssignment' do
(...)
date Date.current
end
So if the tests were executed right before midnight, the sequence was:
1. The factories file was loaded, assigning Date.current to the date of
every Poll::OfficerAssignment to be created.
2. Time passed, so now it was after midnight.
3. The `travel_to` method freezed time, after midnight.
4. A Poll::OfficerAssignment factory was created, using the date it was
before midnight.
Using dynamic fixtures solves the problem:
factory :poll_officer_assignment, class: 'Poll::OfficerAssignment' do
(...)
date { Date.current }
end
Now the sequence is:
1. The factories file is loaded, and since it finds a block, doesn't
assign a static value to every Poll::OfficerAssignment to be created.
2. Time passes, so now it's after midnight.
3. The `travel_to` method freezes time, after midnight.
4. A Poll::OfficerAssignment factory was created, and in executes the
block, using the current date, that is, after midnight.
As explained by @iagirre with pinpoint accuracy [1]:
"If the officer_assignments are created at 23:59:59 and the rest of the
test is executed after 00:00:00, the dates for the objects and the
`Date.current` (used to check if there are any shifts today) won't be
the same, because the shift will be for, lets say, 07/03/2018 and
`Date.current` will be 08/03/2018, so, there are no shifts."
Freezing time avoids this issue.
Related to issues #2520 and #2521.
[1] https://github.com/AyuntamientoMadrid/consul/pull/1342
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.
