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.
Make 'path', 'submit_button_text' and 'notice_text' dynamic based on
the factory.
Also adjusted the user. Budget investments require a level 2 user but do not need to be
an administrator.
Copied and renamed the 'documentable_fill_new_valid_budget_investment' method from
common actions, and introduced a 'fill_in_required_fields' method to manage multiple factories.
Added the two tests that were conditionally skipped in the shared example using
'unless: documentable_factory_name == "dashboard_action"', but omitted the call to
'documentable_redirected_to_resource_show_or_navigate_to', since it only applies to
proposals.
Note that when we create the documentable seems do not need use the user as author.
Removed 'documentable_path_arguments' and 'management'
parameters because they are not used by dashboard_action.
Also moved and renamed the 'documentable_fill_new_valid_dashboard_action' method
from the common actions helper to this file, since it is now only used here.
Hardcoded 'path', 'submit_button_text', and 'notice_text' for dashboard_action.
These remain fixed for now until dynamic values are required in future commits.
Since we use a version of Loofah supporting HTML5 since db2d0bb80, the
`Rails::HTML::Sanitizer.best_supported_vendor` method will return the
HTML5 sanitizer. As mentioned in the pull request introducting this
change [1], the libxml2 maintainer wrote:
> it's still a bad idea to use a 20+ years old, unmaintained HTML 4
> parser to sanitize input for the modern web
So we're going with the new default sanitizer.
Note we aren't uncommenting the `action_text.sanitizer_vendor` option
because we don't use Action Text and so it doesn't affect us , and
uncommeting it will raise an error.
Also note we need to change one test because the new sanitizer handles
whitespace slightly differently.
[1] Pull request 48293 in https://github.com/rails/rails
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 a warning since we upgraded to Rails 7.1:
> Rails 7.1 has deprecated the singular fixture_path in favour of an
> array.You should migrate to plural:
We were getting a warning after upgrading to Rails 7.1:
```
DEPRECATION WARNING: ActionDispatch::IllegalStateError is deprecated
without replacement.
```
We were getting a deprecation warning after upgrading to Rails 7.1:
```
DEPRECATION WARNING: Setting action_dispatch.show_exceptions to true is
deprecated. Set to :all instead.
```
So we're passing `:all`.
I've checked whether we can remove the `:show_exceptions` tag completely
now that the new default option is `:rescuable`. The answer is "no" ;).
Removing the `:show_exceptions` tag makes the tests fail.
We're disabling `action_controller.raise_on_missing_callback_actions`
because sometimes we include `before_action :something, only: actions`
in concerns, and we include these concerns in controllers that don't
have all these actions.
Note that Rails 7.1 logs to STDOUT by default [1]; we're re-adding the
condition `if ENV["RAILS_LOG_TO_STDOUT"].present?` because we're still
using files and we're rotating the logs to avoid running out of space.
Also note that the GraphQL controller test (which is actually a request
test, since it's got `type: :request`) that was raising an exception no
longer does it thanks to the new default value for the
`config.action_dispatch.show_exceptions` configuration option. So we're
updating the test accordingly. This option doesn't affect regular
controller tests (without the `type: :request` option), so in other
tests we're still checking exceptions.
[1] Pull request 47138 in https://github.com/rails/rails
We were using a rack browser and testing the
`FeatureFlags::FeatureDisabled` exception was raised. However, we don't
test this exception in any other system tests; we only check it in
controller tests.
So we're using a real browser for consistency and because in Rails 7.1
this test is failing when enabling the new default option
`config.action_dispatch.show_exceptions = :rescuable` in the test
environment.
We were using a placeholder, which is way less accessible than a label.
One issue here (which also happened before, but is now more obvious) is
that, when adding several options, there will be many fields with the
same label.
Another issue is that, for some languages, we're using texts like "Add a
closed answer", which might be confusing because we might be editing an
existing answer. The proper solution would probably be using the text
"Option 1", "Option 2", ... I'm not doing so right now because I'm not
sure that's a good option and because changing the text would mean
losing the existing translations.
This way the fields are easier to use, and we can get rid of the
placeholders.
Note we're simplifying the `answer_result_value` in order to make it
easier to return `0` instead of `nil` when the field is empty.
Also note there's a small change of behavior here; previously, these
fields were empty by default, and now their value is `0` by default, so
blindly clicking the "Save" button would send `0` instead of an empty
value. I don't think it's a big deal, though, but we need to keep that
in mind.
Back when we added all the missing labels (changes that we merged in
commit c34cab282), we forgot about fields which had placeholdes, since
Axe doesn't report an error when there are placeholders but there aren't
labels.
In this case, we were using an invalid <label> tag for the question
options, and <h3> tags as labels for the votes.
Using standard labels solves the issue.
We forgot to apply this change in commit f5f96ba86.
Note that, in this case, executing `proposal_notification.author.email`
in the middle of a test would also result in a database query. For some
reason (probably the same reason why the code that explicitly created
the author was added in this test but not in other moderation tests),
that doesn't seem to happen in other moderation tests, so for now we
aren't changing those ones.
The link to the comments page was an "expand" icon, which was confusing
because it wasn't really expanding the contents of the sidebar but going
to an entirely different page. Furthermore, it didn't have any text for
people using screen readers, which is why Axe was reporting the
following accessibility error:
```
link-name: Links must have discernible text (serious)
https://dequeuniversity.com/rules/axe/4.10/link-name?application=axeAPI
The following 1 node violate this rule:
Selector: #annotation-link > a
HTML: <a href="/legislation/processes/75/draft_versions/30/annotations/8?sub_annotation_ids=">
<span class="icon-expand" aria-hidden="true"></span>
</a>
Fix all of the following:
- Element is in tab order and does not have accessible text
Fix any of the following:
- Element does not have text that is visible to screen readers
- aria-label attribute does not exist or is empty
- aria-labelledby attribute does not exist, references elements that
do not exist or references elements that are empty
- Element has no title attribute
```
So we're removing the icon and turning the "N comments" text into a
link, so it's easier to guess that the link takes us to the page showing
all the comments for this annotation.
This expectations in this test were true both before and after clicking
on the `.icon-expand` link, so it was possible that the test finished
before the request generated by that click did.
So we're adding an extra expectation to make sure we're testing what we
want to test: the content of the page after the request has finished.
Just like we do with the rest of the phases.
The reason why we're making this change right now is that we were
getting an accessibility error with processes with no result publication
date:
```
link-name: Links must have discernible text (serious)
https://dequeuniversity.com/rules/axe/4.10/link-name?application=axeAPI
The following 1 node violate this rule:
Selector: p:nth-child(6) > a
HTML: <a href="/legislation/processes/39/result_publication">
<strong></strong>
</a>
Fix all of the following:
- Element is in tab order and does not have accessible text
Fix any of the following:
- Element does not have text that is visible to screen readers
- aria-label attribute does not exist or is empty
- aria-labelledby attribute does not exist, references elements that
do not exist or references elements that are empty
- Element has no title attribute
```
People using screen readers had no idea what these links were about (not
that the icons are very usable for people seeing them either... but
that's a different topic). Axe was reporting this error:
```
link-name: Links must have discernible text (serious)
https://dequeuniversity.com/rules/axe/4.10/link-name?application=axeAPI
The following 1 node violate this rule:
Selector: #dashboard_action_2_execute
HTML: <a id="dashboard_action_2_execute" class="unchecked-link"
rel="nofollow" data-method="post"
href="/proposals/16-proposal-6-title/dashboard/actions/2/execute">
<span class="unchecked"></span>
</a>
Fix all of the following:
- Element is in tab order and does not have accessible text
Fix any of the following:
- Element does not have text that is visible to screen readers
- aria-label attribute does not exist or is empty
- aria-labelledby attribute does not exist, references elements that
do not exist or references elements that are empty
- Element has no title attribute
```
All these tests were basically checking the same things. Since system
tests are slow, we're grouping them together so executing them is
slightly faster.
When using a link, people using screen readers might think they're going
to a new page where the password is going to be shown. With a button,
they get a better idea about what to expect.
Furthermore, with a button, we can use the `aria-pressed` attribute to
indicate whether the password is currently being shown.
We were using an icon for this link, but people who can't see the icon
couldn't know what the link was about. Axe was reporting the following
accessibility error:
```
link-name: Links must have discernible text (serious)
https://dequeuniversity.com/rules/axe/4.10/link-name?application=axeAPI
The following 1 node violate this rule:
Selector: .show-password
HTML: <a href="#" class="show-password">
<span class="icon-eye"></span>
</a>
Fix all of the following:
- Element is in tab order and does not have accessible text
Fix any of the following:
- Element does not have text that is visible to screen readers
- aria-label attribute does not exist or is empty
- aria-labelledby attribute does not exist, references elements
that do not exist or references elements that are empty
- Element has no title attribute
```
This happened when previewing banners in the "new banner form", which
might cause accessibility issues when people access the list of links on
the page.
We were getting the following accessibility error:
```
link-name: Links must have discernible text (serious)
https://dequeuniversity.com/rules/axe/4.9/link-name?application=axeAPI
The following node violate this rule:
Selector: a[href$="new"]
HTML: <a href="/admin/banners/new"><h2></h2><h3></h3></a>
Fix all of the following:
- Element is in tab order and does not have accessible text
Fix any of the following:
- Element does not have text that is visible to screen readers
- aria-label attribute does not exist or is empty
- aria-labelledby attribute does not exist, references elements that
do not exist or references elements that
- Element has no title attribute
```
People using screen readers might have a hard time knowing what a
progressbar is about unless we provide a label for it. Axe was reporting
failures like:
```
aria-progressbar-name: ARIA progressbar nodes must have an accessible
name (serious)
https://dequeuniversity.com/rules/axe/4.10/aria-progressbar-name?application=axeAPI
The following 1 node violate this rule:
Selector: .progress
HTML: <div class="progress" role="progressbar" tabindex="0"
aria-valuenow="0.0" aria-valuemin="0" aria-valuemax="100">
<div class="progress-meter" style="width: 0.0%"></div>
</div>
Fix any of the following:
- aria-label attribute does not exist or is empty
- aria-labelledby attribute does not exist, references
elements that do not exist or references elements that are empty
- Element has no title attribute
```
Note that, in the case of the ballot progressbar, it's easier to use
`aria-labelledby`, while in other place it's easier to use `aria-label`,
so we using the easier solution in each scenario.
