The user was able to vote as many investments as wanted in the first
heading voted. However in the second heading voted, only one investment
could be voted
This was due to the previous implementation, where you could only vote
in one heading. Note the `first` call in method
`heading_voted_by_user?(user)`
This commits simplifies the logic and allows voting for any investment
in any heading that the user has previously voted in
This method was used only in Madrid’s fork, but it is now needed to
complete the backport for voting in multiple headings
There wasn’t a test in Madrid, so here goes one too. Even though, the
responsibility should probably be moved soon to the `Budget::Heading`.
For consistency with the related methods and tests it has been left in
the investment_spec
Now that we have the option of voting in multiple headings per group,
the method of voting in a “different heading assigned” has become
deprecated and thus removed
The old method have_css didn't wait, apparently,
the Capybara's max_wait_time.
It has been changed in favor of find,
one that waits the stablished time for
an element to appear in the screen.
Budget Investment factory creates a secondary budget as a collateral
effect because it has a Heading factory that has a Group factory that
creates a Budget.
This was resulting in problems due to having two "active" Budgets created
and `current_budget` method not choosing the one that we expected
When a valuator tries to edit/valuate an investment outside valuating
phase, an explanatory message will be shown along with a redirect to
prevent access.
Valuators should not be able to edit a finished valuation (only admins
should).
The valuation form is only shown to the valuator if he has that ability
(we've previously modified app/models/abilities/valuator.rb to be able
to rely on `valuate` over an investment to check that)
If the valuator can't see the form, we present him just the data in
plain text.
Why:
Avoid instance variables as we agreed upon with RSpec/InstanceVariable
How:
Using a let(:invsetment) and replacing all `@investment` with
`investment`, as well as adding a let(:admin) for the administrator.
Why:
Both Newsletters and Email Downloads need the same logic: To extract the
emails from all the users in the segment that have newsletter flag
active, removing all empty email values.
How:
1- UserSegments#user_segment_emails holds that repeated logic and is used
on both Newsletter & EmailDownload.
2- Rename Newsletter#list_of_recipients to list_of_recipient_emails as
it is more descriptive. There is no need to pass entire Users around,
only the emails are needed at Mailer#newsletter method.
3- Cleanup Newsletter#list_of_recipient_emails model spec scenario
Why:
User with an empty email value (nil) should not appear in the recipient
list for a given UserSegment at Newsletters or Email Downloads.
How:
Using Enumerable#compact and Enumerable#select to filter out empty emails
Increasing Email Download feature spec and Newsletter model spec to cover
all possible scenarios including the nil email one.
Why:
When there is not Budget accepting (Investment creation) the guide page
doesn't have much sense as it will give the user an option that can't be
used (creating an Investment).
How:
Using `Budget.current&.accepting?` conditional at GuidesHelper to link
to new proposal link instead of guide page, and adding an scenario to
guides feature spec for it.
