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 way polls look more similar to the way they did when the answers
were buttons instead of checkboxes or radio buttons.
Note the styling is tricky because we need to add a `float` property to
the legend so it's actually inside the fieldset. This forces us to add a
`::before` pseudo-element in order to add margin between the legend and
the first label. Another option would be:
```
legend {
&:has(+ label) {
margin-bottom: calc($line-height / 2);
}
+ label {
clear: $global-left;
}
}
```
But the `:has` pseudo-class isn't universally supported yet, and we'd
still have to add `margin-top` to the first label when it comes after a
`.help-text` element.
Due to the presence of the border, we're increasing the margin between
elements a little bit.
Note that adding a pseudoelement to the label is a consequence of adding
the `float` property to the legend, so we're changing the order of the
code so the styles for `legend` appear before the styles in `label`.
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.
Some of the code was in its own component, while some of the code
remained in the polls/show view.
Note that we're re-structuring the code a little bit, so it's clear that
the "already voted" messages are only shown when users can vote. Also
note that now the `can?` condition involves the existence of a
`current_user` and that the poll is not expired, so we can simplify the
`voted_in_web` condition.
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`.
We used `margin-left` in commit b4eba055c, but when using right-to-left
layout, the property we should use is `margin-right`. So we're using
`margin-#{$global-left}` as usual.
We were using a `height: $line-height` property for this task. One of
the disadvantages of this approach is that things don't look so great
when the label expands over more than one line.
Back when we added that property, browser support for flex layouts
wasn't that great. Now there's universal support for it, so we can use
it instead.
This way changing it will be easier.
Note we're moving the `legislation-draft-versions-form` class into the
form component itself, which is wat we usually do in components.
This way changing it will be easier.
Note we're changing the name of the HTML class to follow our naming
conventions; the `edit_page` class wasn't used anywhere, so we don't
need to change anything else.
In the registration form, after changing the username, we were removing
the message about whether a username was available. However, we were
also removing every `<small>` tag on the page. This affected the demo
branch, where we add a `<small>` tag on every page.
So we're now removing a specific element instead.
This rule was introduced in RuboCop 1.76.0 to ensure methods ending
in '?' return boolean.
This commit applies suggested renames and code cleanup:
- Renames 'is_active?' to 'active_class' since it returns a string
- Renames 'parsed_value' to 'in_favor?' and 'is_request_active' to end with '?'
for boolean semantics
- Skips false positives like 'save', 'auto_labels' or 'save_requiring_finish_signup',
which are not predicate methods.
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 c5103d3025, the styles from application.scss no longer apply
to app/views/dashboard/poster/index.pdf.erb.
To recover the text-center alignment, we add the rule in dashboard.scss.
Note that we also remove text-center from the h2, since it wasn't applied
and there's no need to recover it because it doesn't exist in the preview
either.
We were using an <a> tag wrapping the whole content of the banner in
order to make the whole banner clickable. However, that made the text of
the link less concise, affecting people using screen readers. So,
instead, we're using the `card` mixin, which we introduced in commit
f285dfcba.
We're making this change now because the HTML5 Sanitizer that we're
about to enable in the next commit was handling the whitespace inside
the banner differently, causing one test to fail, and we didn't find a
different way to fix it.
We were getting the following warning after upgrading to Rails 7.1:
```
Rendered shared/_social_media_meta_tags.html.erb
DEPRECATION WARNING: Passing the class as positional argument is
deprecated and will be removed in Rails 7.2.
Please pass the class as a keyword argument:
serialize :metadata, type: Object
```
Apparently, the `ids` method, which originally was implemented as
`pluck(:id)`, sometimes returned duplicate ids [1]. Fixing that issue
generated another issue [2] when combining `.includes` and `order`.
There was an attempt to fix it [3], but it still doesn't fix the case
where the ordering column belongs to an association [4].
This means that, when upgrading to Rails 7.1, calling `.ids` on
`budget.investments.includes(:heading).sort_by_random.for_render`
results in an invalid SQL statement:
```
ActiveRecord::StatementInvalid:
PG::GroupingError: ERROR: column "ids.ordering" must appear in
the GROUP BY clause or be used in an aggregate function
LINE 1: ... = $4 GROUP BY "budget_investments"."id" ORDER BY
ids.orderi...
```
To solve it, we could once again use `.pluck(:id)` instead of `ids`, but
I'm not sure whether there would be a risk to get duplicate IDs in some
cases. We cannot call `.reorder` or `.unscope(:order)` either because we
need the IDs to be ordered randomly.
So we're removing the `includes(:heading)` part when getting the IDs.
Since using `includes` generates a separate query that doesn't affect
the query to get the IDs, removing it makes no difference.
Another option would be to remove the `for_render` call, since we're
including the headings to avoid the N+1 queries problem, but we're doing
so without benchmarks showing that it does actually make a difference.
[1] Issue 46455 in https://github.com/rails/rails
[2] Issue 48080 in https://github.com/rails/rails
[3] Pull request 48101 in https://github.com/rails/rails
[4] Issue 50263 in https://github.com/rails/rails
