The current tracking section had a few issues:
* When browsing as an admin, this section becomes useless since no
investments are shown
* Browsing investments in the admin section, you're suddenly redirected
to the tracking section, making navigation confusing
* One test related to the officing dashboard failed due to these changes
and had been commented
* Several views and controller methods were copied from other sections,
leading to duplication and making the code harder to maintain
* Tracking routes were defined for proposals and legislation processes,
but in the tracking section only investments were shown
* Probably many more things, since these issues were detected after only
an hour reviewing and testing the code
So we're removing this untested section before releasing version 1.1. We
might add it back afterwards.
We need to add a hidden field for each group of check boxes, so if we
don't check anything, the hidden field is sent to the server, indicating
nothing was selected. Without the hidden field, the server will not know
anything has been done to the check boxes.
The easiest way to do it is using `collection_check_boxes`, which also
adds labels to every check box.
We were inconsistent on this one. I consider it particularly useful when
a method starts with a `return` statement.
In other cases, we probably shouldn't have a guard rule in the middle of
a method in any case, but that's a different refactoring.
We were very inconsistent regarding these rules.
Personally I prefer no empty lines around blocks, clases, etc... as
recommended by the Ruby style guide [1], and they're the default values
in rubocop, so those are the settings I'm applying.
The exception is the `private` access modifier, since we were leaving
empty lines around it most of the time. That's the default rubocop rule
as well. Personally I don't have a strong preference about this one.
[1] https://rubystyle.guide/#empty-lines-around-bodies
Having exceptions is better than having silent bugs.
There are a few methods I've kept the same way they were.
The `RelatedContentScore#score_with_opposite` method is a bit peculiar:
it creates scores for both itself and the opposite related content,
which means the opposite related content will try to create the same
scores as well.
We've already got a test to check `Budget::Ballot#add_investment` when
creating a line fails ("Edge case voting a non-elegible investment").
Finally, the method `User#send_oauth_confirmation_instructions` doesn't
update the record when the email address isn't already present, leading
to the test "Try to register with the email of an already existing user,
when an unconfirmed email was provided by oauth" fo fail if we raise an
exception for an invalid user. That's because updating a user's email
doesn't update the database automatically, but instead a confirmation
email is sent.
There are also a few false positives for classes which don't have bang
methods (like the GraphQL classes) or destroying attachments.
For these reasons, I'm adding the rule with a "Refactor" severity,
meaning it's a rule we can break if necessary.
These feature tests were taking too long, we can't run them for every
single model.
I'm taking the approach of using one different model for each test, but
in theory only using a few models covering every possible scenario
would be enough.
Now factories define default headings for investments, so there's no
need to create a group and a heading to create an investment.
Likewise, in order to create a heading it isn't necessary to specify a
group anymore; specifying the budget is enough.
It's possible that there are more similar cases we haven't simplified
yet; I'm only addressing the obvious ones.
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.
To make it more consistent with the rest of the Admin panel,
the CRUD for budget groups and headings has been changed
from the old "all-in-one" form to a separate form for each resource.
Add feature spec to test if the 'Calculate winners'
button is enabled or not, depending on the phase.
It also checks the message that clarifies why the
button is disabled.
We were seeing this warning when running specs
`spec/features/admin/budgets_spec.rb:322: warning: circular argument
reference - phase_kind`
This commit should fix the warning
Why:
The Admin Budget form has a submit button for saving the record, adding
another submit input to destroy the record actually adds to the html:
`<input type="hidden" name="_method" value="delete">` and it collides
with the save button, forcing it to perform a destroy instead of save.
Previously the destroy button was not in the same div as the save button
How:
Just changing the Destroy from a button_to to a link_to.
Cambios para hacer commit:
modificado: app/controllers/admin/budget_headings_controller.rb
modificado: app/models/budget/heading.rb
nuevo archivo: app/views/admin/budget_headings/_errors.html.erb
nuevo archivo: app/views/admin/budget_headings/edit.js.erb
nuevo archivo: app/views/admin/budget_headings/update.js.erb
modificado: app/views/admin/budgets/_group.html.erb
nuevo archivo: app/views/admin/budgets/_heading.html.erb
nuevo archivo: app/views/admin/budgets/_heading_form.html.erb
modificado: config/locales/en/activerecord.yml
modificado: config/locales/es/activerecord.yml
modificado: spec/features/admin/budgets_spec.rb
modificado: spec/models/budget/heading_spec.rb
