This way we remove duplication in the HTML.
We're also adding a test checking what happens when users can vote in
order to test the `render?` method we've added.
This could be the case when JavaScript is disabled.
Note that, in `Poll/WebVote` we're calling `given_answers` inside a
transaction. Putting this code before the transaction resulted in a test
failing sometimes, probably because of a bug that might be possible to
reproduce by doing simultaneous requests.
With the old interface, there wasn't a clear way to send a blank ballot.
But now that we've got a form, there's an easy way: clicking on "Vote"
while leaving the form blank.
This way it'll be easier to refactor it.
Note there was a system test which tested both the callout and the form
when unverified users visit a poll. We've split this system test in two
component tests.
Our original interface to vote in a poll had a few issues:
* Since there was no button to send the form, it wasn't clear that
selecting an option would automatically store it in the database.
* The interface was almost identical for single-choice questions and
multiple-choice questions, which made it hard to know which type of
question we were answering.
* Adding other type of questions, like open answers, was hard since we
would have to add a different submit button for each answer.
So we're now using radio buttons for single-choice questions and
checkboxes for multiple-choice questions, which are the native controls
designed for these purposes, and a button to send the whole form.
Since we don't have a database table for poll ballots like we have for
budget ballots, we're adding a new `Poll::WebVote` model to manage poll
ballots. We're using WebVote instead of Ballot or Vote because they
could be mistaken with other vote classes.
Note that browsers don't allow removing answers with radio buttons, so
once somebody has voted in a single-choice question, they can't remove
the vote unless they manually edit their HTML. This is the same behavior
we had before commit 7df0e9a96.
As mentioned in c2010f975, we're now adding the `ChangeByZero` rubocop
rule, since we've removed the test that used `and change`.
Until now, when writing `create(:poll_answer, option: option)`, the
`answer` field would take the title of a random option instead of taking
the title from the `option` variable.
So now, if we're given the option, the `answer` field will be taken from
the option itself.
Note that writing something like:
```
option { question.question_options.find_by(title: answer) }
answer { option.title }
```
Would create an infinite loop when creating a poll answer if we don't
pass the `option` and/or the `answer` attributes.
So, instead, we're making the `option` depend on the `answer` attribute
exclusively when we pass the `answer` attribute to the factory.
Bumps [rubocop](https://github.com/rubocop/rubocop) from 1.71.2 to 1.75.8.
- [Release notes](https://github.com/rubocop/rubocop/releases)
- [Changelog](https://github.com/rubocop/rubocop/blob/master/CHANGELOG.md)
- [Commits](https://github.com/rubocop/rubocop/compare/v1.71.2...v1.75.8)
---
updated-dependencies:
- dependency-name: rubocop
dependency-version: 1.75.8
dependency-type: direct:development
update-type: version-update:semver-minor
...
Notes:
This commit also includes several style and lint fixes required after
updating RuboCop:
- Removed redundant parentheses now detected by improved
'Style/RedundantParentheses' (1.72 and 1.75.3).
- Replaced ternary expressions with logical OR when the ternary was
returning 'true', as flagged by 'Style/RedundantCondition' (1.73).
- Adjusted block variables to resolve new 'Lint/ShadowingOuterLocalVariable'
offenses (1.75), helping avoid future conflicts during upgrades with
'rails app:updates'
Signed-off-by: dependabot[bot] <support@github.com>
Since commit 23682fadd8, we have had the comment:
> # Review
> # Doble check why the file is stored with a name different to empty.pdf
This might be outdated.
These expectations are already covered by attach_new_file, so they are no longer needed:
> expect(page).to have_css ".loading-bar.complete"
We can remove the tests:
> "Should update loading bar style after invalid file upload"
because the expectation:
> expect(page).to have_css ".loading-bar.errors"
It is already tested in "Should not update document cached_attachment field after invalid file upload"
Note that this commit also applies a similar change to the
imageable_attach_new_file method by removing an unnecessary variable.
In order to testing with more than 1 max documents allowed we
keep one test with this value.
Removed the now-unused 'documentable_fill_new_valid_proposal' method
from common actions.
Note that it does not seem necessary to create an administrator with the user, as was
done in the original shared example. Also, as in the previous commit, it appears that
we do not need to set the user as the author when creating the documentable.
Also removed the documentable_redirected_to_resource_show_or_navigate_to method,
which was only used for the :proposal factory but was not necessary.
- In the "Proposal new" case (this commit), after submitting the form we are
redirected to the "created" page, where the link "Not now, go to my proposal"
does not appear. This caused the method to always raise a
Capybara::ElementNotFound and return nil.
Instead, this "created" page already displays a preview of the proposal
and a link to publish it. Since we can verify that the proposal was created
successfully here, no redirection or click is needed.
- In the "Proposal edit" case (next commit), the user is redirected directly
to the proposal's "show" page after update, so again, the method is
unnecessary and has been removed.
Replaced 'login_as' with 'do_login_for' using 'management: management_section?' to
handle login requirements correctly for each context.
Also removed the now-unused 'documentable_fill_new_valid_budget_investment' helper
from common actions.
Note that it does not seem necessary to create an administrator with the user, as was
done in the original shared example. Also, as in the previous commit, it appears that
we do not need to set the user as the author when creating the documentable.
While reviewing this, we also noticed that the create(:administrator, user: user) call
was unnecessarily included in the nested_imageable system spec in commit cdfaec5217 when
the path is a management section. So we use this commit to remove the unnecessary condition.
