As pointed out in PR #2734:
"After clicking the first link, there's an AJAX request which replaces
the existing `.in-favor a` and `.against a` links with new elements. So
if Capybara tries to click the existing `.against a` link at the same
moment it's being replaced, clicking the link won't generate a new
request".
Making Capybara check the page for new content before clicking the
second link solves the problem, in the same way 4ddc869 solved the same
problem in the comments section.
Banners were not been shown in certain pages; now
they are.
Spec to check if the banner is been shown correctly
added. Before it was in admins specs, now it has it's
own spec out of admins folder.
Rebase master branch so that this PR can
be updated with the latest changes.
Conflicts has been solved. dev_seeds
has been also adapted to the new format
(it all separated to be easier to manage).
Some specs has been updated to work with
selenium-webkit.
* Delete all things related to banner images and styles (in code)
* Add a new test to check that the banner is showing correctly
* Update the specs accordingly to match the changes
Update dev_seed to set a random background_color and a font_color for banners (and remove everything about image and style)
Add a rake task to migrate the banner style to backgroun_color and font_color (so that the banners have the same colors than before)
Banner sections can be saved (one banner can appear in several sections)
If the hex color is changed in the textfield, the color of the color picker changes.
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.
