The group is automatically assigned when we assign the heading. The
budget isn't needed either, except for a special case related to the
reason to be rejected.
When creating a budget investment with an unverified manager (for
example, a manager who isn't part of the local census), there's a
request to `Budgets::InvestmentsController#suggest`. Since the manager
isn't verified, suggestions can't be obtained.
There are serveral ways to fix this problem:
* Add a `suggest` action to Management::Budgets::InvestmentsController,
doing the same thing the main `suggest` action does.
* Give unverified users permission to access investment suggestions
* Give managers permission to access investment suggestions
I've chosen the last one because I thought it was simple and only
changed existing behaviour for managers, but any other solution would be
as valid. I haven't added the `phase: "accepting"` condition to keep it
simple, since a read-only action like this one in the management portal
isn't gonna create security risks.
After adding investment translatable fields to forms, they will be
generated with nested translations names and ids so we can no longer
use standard id locator.
Using input label text to fill in fields works with both types of forms.
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
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