The `type: :feature` is automatically detected by RSpec because these
tests are inside the `spec/features` folder. Using `feature` re-adds a
`type: :feature` to these files, which will result in a conflict when we
upgrade to Rails 5.1's system tests.
Because of this change, we also need to change `background` to `before`
or else these tests will fail.
If budget is in balloting phase and there are voted investments, it
was not possible to print budgets investments because the ballot was
never being loaded in the controller and therefore an error was raised
when rendering the view.
Failure/Error: <% if ballot.has_investment?(investment) %>
ActionView::Template::Error:
undefined method `has_investment?' for nil:NilClass
app/views/budgets/investments/_ballot.html.erb:3
app/views/budgets/investments/_investment.html.erb:88
app/views/custom/management/budgets/investments/print.html.erb:26
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.
The tests that will check the featute
is working well added. There are four test:
1. Checks that the emails are been send to
the user. The test looks for the link in there
and takes the token. Visits the page and
changes the password.
2 and 3. Both change the password by hand. One
uses a password written by the manager, whilst
the other uses the 'Generate random password'
option. Both tests check that the user can
sign in with the new passwords.
4. Checks that the password can be printed
when it is saved.
JS modals/browser alerts are not automatically accepted now with
Selenium, events that trigger such events must be wrapped in one
of the following methods: `accept_alert`, `accept_confirm` or
`dismiss_confirm`
In the specs, some investment were missing a heading_id, thus creating
another unexpected budget
By explicitly setting the heading_id we can control better which
budgets are created in each test
allows managers to create users without email
hides email preferences from account page for email-less users
prevents email delivery to users with no email
adds spec for user creation from management
adds specs for user's email requirement
adds spec for no deliveries if no email
