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.
The "foundation_rails_helper" gem is no longer maintained and is
incompatible with Rails 7.1. To avoid blocking the upgrade, we've vendored
the vendor/foundation_rails_helper/form_builder.rb as a copy of the
original FormBuilder class.
To mantain compatibility with auto_labels and button_class variables, that
are used in the original builder, we are overwriting in the foundation
form builder initializer.
The gem has been removed from the Gemfile and replaced with this vendored
fallback. This workaround is safe to remove once legacy Foundation CSS
support is dropped.
All vendored code retains the original MIT license and attribution.
ros-apartment 3.0.0+ includes official support for connection handling in Rails 7,
so we no longer need to override `ActiveRecord::ConnectionHandling#connected_to`.
References: PR #194 and #243 in ros-apartment
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.
Saying that we're supposed to introduce a descriptive title in a field
labelled as "Title" is redundant. Besides, the text of the placeholder
was barely distinguishable, making it harder to fill in the form.
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
```
This way we simplify the CSS and, in the case of the "check" icon, using
an SVG icon instead of an icon font offers several advantages, as
mentioned in commit 925f04e3f.
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.
