We're using the `aria-label` attribute instead of a label because this
is a page where only one field is rendered and the text of the label is
the same as the text of the <h1> tag.
We're using `aria-label` instead of `aria-labelledby` because the former
is supported by Capybara.
We were using one label for both date selectors, but it wasn't
associated with any of them.
So we're now rendering one label per control and, just like we only show
one of these date selectors at a time, we're only showing one label at a
time.
The default `date_select` used in fields presents an accessibility
issue, because in generates three select controls but only one label.
That means that there are two controls without a label.
So we're using a date field instead. This type is field is supported by
about 99% of the browsers, and we've already got JavaScript code
converting this field to a jQuery UI datepicker in case the browser
doesn't support date fields.
Note that, since we no longer need to parse the three date fields into
one, we can simplify the code in both the models and the tests.
Another slight improvement is that, previously, we couldn't restrict the
month and day controls in order to set the minimum date, so the maximum
selectable date was always the 31st of December of the year set by the
minimum age setting. As seen in the component test, now that we use only
one field, we can set a specific date as the maximum one.
We reduce code duplication thanks to that, and make it easier
to change this field.
Note that there was one place where the "16.years" value was
hardcoded. We're moving the test for this case to the
component and changing it so the test doesn't use the default
age.
We're also removing the redundant helper method that had the
same code as a method in the User class which is called
everywhere else.
All the expectations checked after the `click_link "Check my votes"`
action were already true before clicking the link, meaning the test
could finish before the request did.
It's possible that this request caused a test run 8274, job 2 [1], since
a multitenancy test failed and a possible cause could have been
simultaneous requests to both a tenant subdomain and the application's
main domain. The failure was:
```
1) Multitenancy PostgreSQL extensions work for tenants
Failure/Error: expect(page).to have_content "Proposal created
successfully."
expected to find text "Proposal created successfully." in
"Language: \n
\nEnglish\nDeutsch\nEspañol\nFrançais\nNederlands\nPortuguês
brasileiro\n中文\n Notifications\nMy content\nMy account\nSign
out\nDebates\nYou are in\nProposals\nVoting\nCollaborative
legislation\nParticipatory budgeting\nSDG\nHelp\nProposals\nCreate new
proposal\nHow do citizen proposals work?\nRecommendations for creating a
proposal\nDo not use capital letters for the proposal title or for whole
sentences. On the internet, this is considered shouting. And nobody
likes being shouted at.\nAny proposal or comment suggesting illegal
action will be deleted, as well as those intending to sabotage the
debate spaces. Anything else is allowed.\nEnjoy this space and the
voices that fill it. It belongs to you too.\n×\n1 error prevented this
Proposal from being saved.\nPlease check the marked fields to know how
to correct them:\nREQUIRED FIELDS\nProposal title\nProposal
summary\n(maximum 200 characters)\ntsvector for María the
Martian\nProposal text\n Format\n ◢\n If you are human, ignore
this field\nOPTIONAL FIELDS\nExternal video URL\nYou may add a link to
YouTube or Vimeo\nDescriptive image\nYou can upload one image of
following content types: jpg, up to 1 MB.\nAdd image\nDocuments\nYou can
upload up to a maximum of 3 documents of following content types: pdf,
up to 3 MB per file.\nAdd new document\nTags\nTag this proposal. You can
choose from proposed categories or add your own\nCategories\n\nFull name
of the person submitting the proposal\n(individually or as
representative of a collective; will not be displayed publically)\ncan't
be blank, is too short (minimum is 6 characters)\nSustainable
Development Goals and Targets\nYou can choose one or several SDGs
aligned with your citizen proposal\nGoals and Targets\nYou can introduce
the code of a specific goal/target or a text to find one. For more
information visit the SDG help page.\nI agree to the Privacy Policy and
the Terms and conditions of use\nOpen government\nThis portal uses the
CONSUL DEMOCRACY application which is open-source
software.\nParticipation\nDecide how to shape the city you want to live
in.\nCONSUL DEMOCRACY, 2024 Privacy Policy Terms and conditions of use
Accessibility"
```
Note the `can't be blank, is too short` reference to the responsible
name, which is only checked when user verification is not skipped. In
this test, the `mars` tenant skips the verification while the default
tenant does not. The mentioned possibility of simultaneous requests
might have caused the issue.
[1] https://github.com/consuldemocracy/consuldemocracy/actions/runs/11747689680/job/32730131655
Note that adding the labels broke the layout because the button was no
longer aligned with the fields, so we're now using a flex layout.
Since we're using labels, we no longer need a placeholder (which wasn't
very informative, by the way) in the text field.
The text for the unfeasible checkbox wasn't correctly defined as a
label, while the fields to search investments and select the heading
weren't intuitive since their purpose wasn't obvious.
This way it'll be easier for people using screen readers to know which
element the checkbox is related to.
Note that we're using the `aria-label` attribute because it makes
testing with Capybara easier than using the `aria-labelledby` attribute.
The only exception are the comments, since comments don't have a title
and there isn't a proper label for them. In this case, we're using the
title of the associated commentable as the label; we might change it in
the future since there might be many comments for the same commentable.
We were rendering one label and many textarea fields for that label.
This meant that, when switching to a different language, the label
wasn't correctly associated with the textarea.
So we're now rendering one label for each textarea. We could use
`aria-label` or `aria-labelledby` instead, but using a label offers some
advantages like the fact that clicking on the label makes the textarea
take the focus.
The absence of labels in these controls made them hard to use,
particularly for people who use screen readers.
Note we're removing the "Choose language" prompt, since we always
automatically choose a language and not choosing a language doesn't
really make sense. The only scenario where the prompt was used took
place when all languages had been removed but, in that case, the "Choose
language" prompt was misleading because there were no languages to
choose from.
We were using `check "Valuation finished"` everywhere except here.
This way it's easier to realize, while reading the test, that we're
interacting with a checkbox and not a link or a button.
As mentioned in commit 5311daadf, there are several reasons to use
buttons in these situations. And, as mentioned in the previous commits,
using buttons instead of links for actions requiring confirmation will
help us test for accessibility issues.
As mentioned in commit 5311daadf, there are several reasons to use
buttons in these situations. And, as mentioned in the previous commits,
using buttons instead of links for actions requiring confirmation will
help us test for accessibility issues.
As mentioned in commit 5311daadf, there are several reasons to use
buttons in these situations. And, as mentioned in the previous commits,
using buttons instead of links for actions requiring confirmation will
help us test for accessibility issues.
As mentioned in commit 5311daadf, there are several reasons to use
buttons in these situations. And, as mentioned in the previous commits,
using buttons instead of links for actions requiring confirmation will
help us test for accessibility issues.
Since we're adding styles for this button, we're also adding the
`font-size` property instead of using the `small` class. We'll deal with
the `float-right` property in the next commit.
Note that, since the button now generates a `form` tag, we need to
adjust the styles of this section.
As mentioned in commit 5311daadf, there are several reasons to use
buttons in these situations. And, as mentioned in the previous commits,
using buttons instead of links for actions requiring confirmation will
help us test for accessibility issues.
Note we're simplifying the `table .button` margin rules because the
`.button` class already defines `0` for all its margins except the
bottom margin. Otherwise, the margins defined by the `flex-with-gap`
mixin would be overwritten by the margins defined in the `table .button`
class.
As mentioned in commit 5311daadf, there are several reasons to use
buttons in these situations. And, as mentioned in the previous commit,
using buttons instead of links for actions requiring confirmation will
help us test for accessibility issues.
We forgot to do so in commit f0ab7bcfc. We're still leaving one system
spec to test that these images are rendered when browsing the site.
We're also changing the existing component tests to check the `alt`
attribute, just like the remaining system test does.
In commit 96ae69fe9, we stopped using cookies to track Ahoy visits and
started using a combination of the IP and the browser agent instead.
However, since we're still using the legacy logic from Ahoy 1.x to track
visits (which we had to add in commit b5220effd), this way of tracking
visits doesn't work and counts every page visited by a user as an
independent visit.
Maybe we could migrate existing data, which uses the `visitor_id` column
so it uses the new `visit_token` and `visitor_token` columns, but
there's no mention in the Ahoy documentation regarding how to do so.
While deciding what to do about this, we found something interesting.
For two years, we've been seeing random failures in the
`system/admin/tenants_spec.rb` tests, with messages like:
```
1) Tenants Create Tenant with subdomain
Failure/Error:
raise TenantNotFound, <<~EXCEPTION_MESSAGE
Could not set search path to schemas, they may be invalid:
"#{tenant}" #{full_search_path}.
Original error: #{exception.class}: #{exception}
EXCEPTION_MESSAGE
Apartment::TenantNotFound:
Could not set search path to schemas, they may be invalid:
"earth" "public", "shared_extensions".
Original error:
ActiveRecord::StatementInvalid: Could not find schema earth
```
And we've found one of the causes: the AJAX requests done by Ahoy to
track visits. Sometimes a test that creates or updates a tenant finishes
but the Ahoy AJAX request to, say, `earth.lvh.me/ahoy/visits`, is
handled by the next test, when the `earth` schema no longer exists, thus
raising an `Apartment::TenantNotFound` exception.
So by disabling these AJAX requests and tracking the visits in the
server instead, we're killing two birds in one stone: we're fixing the
bug regarding the visits count and we're reducing the flakiness in our
test suite. It looks like we're also removing the "phantom ahoy cookie"
we were getting since the mentioned commit b5220effd: an ahoy cookie was
quickly set and unset in the browser.
Note that, even though we aren't migrating any data, we're still adding
the new fields, because some tests started to fail because, when
tracking visits in the server without cookies, Ahoy expects the Visit
model to have a `visit_token` field.
One of these tests has failed in our CI with the following message:
```
1) Users Public activity user can hide public page
Failure/Error: expect(page).to have_content("activity list private")
expected to find text "activity list private" in "Language: \n
\nEnglish\nDeutsch\nEspañol\nFrançais\nNederlands\nPortuguês
brasileiro\n中文\n Notifications\nYou are in\nMy content\nMy
account\nSign out\nDebates\nProposals\nVoting\nCollaborative
legislation\nParticipatory budgeting\nSDG\nHelp\nM\nManuela124\nUser has
no public activity\nOpen government\nThis portal uses the CONSUL
DEMOCRACY application which is open-source
software.\nParticipation\nDecide how to shape the city you want to live
in.\nCONSUL DEMOCRACY, 2024 Privacy Policy Terms and conditions of use
Accessibility"
```
Note how the text "User has no public activity" is present, which is a
message that appears when the user's activity is public.
A possible explanation is that we didn't check that the request done by
the "Save changes" button had finished before continuing with the tests.
Back when we wrote this test, submitting a form in a test would always
wait for the request to be finished before continuing, but a lot has
changed since then.
So we're adding an expectation to make sure the the changes have been
saved before making a new request.
We're also rearraging the blank lines in these tests and removing the
parenthesis in `have_content` expectations to be consistent with the
expectations we're adding.
When the `multitenancy_management_mode` is enabled.
In order to avoid infinite redirects when regular users try to access
the admin section, we're redirecting to the account page in this case.
Otherwise, the admin section would redirect to the root path, which
would redirect to the admin section, which would redirect to the root
path, and so on.
We only want to render the account link and login items in the header.
And we want only render the Multitenancy and Administrators sections in
the admin sidebar.
We include the administrators management so it's possible to give
permissions to other users to manage tenants.
In order to restrict access to other sections by typing the URL or
following a link, we're only enabling the rest of the routes when we
aren't in the multitenancy management mode.
Using a checkbox wasn't very intuitive because checkboxes are
checked/unchecked when clicked on even if there's an error in the
request. Usually, when checkboxes appear on a form, they don't send any
information to the server unless we click a button to send the form.
So we're using a switch instead of a checkbox, like we did to
enable/disable phases in commit 46d8bc4f0.
Note that, since we've got two switches that match the default
`dom_id(record) .toggle-switch` selector, we need to find a way to
differentiate them. We're adding the `form_class` option for that.
Also note that we're now using a separate action and removing the
JavaScript in the `update` action which assumed that AJAX requests to
this action were always related to updating the `visible_to_valuators`
attribute.
We were performing 3 requests in order to refresh the page and check the
content was still there. We can use `refresh` instead.
We're also reusing the `investment1` variable in every test, instead of
redifining it in one of them.
Just like it happened with proposals, the button to select/deselect an
investment wasn't very intuitive; for example, it wasn't obvious that
pressing a button saying "selected" would deselect the investment.
So we're using a switch control, like we do to enable/disable features
since commit fabe97e50.
Note that we're making the text of the switch smaller than in other
places because the text in the investments table it is also smaller
(we're using `font-size: inherit` for that purpose). That made the
button look weird because we were using rems instead of ems for the
width of the button, so we're adjusting that as well.
Also note we're changing the width of the switch to `6em` instead of
`6.25em` (which would be 100px if 1em is 16px). We're doing so because
we used 100 for the minimum width because it's a round number, so
now we're using another round number.
Since we were checking something that was already there, if the form
were submitted using an AJAX request (which is the default with Turbo,
although we don't use it yet), there would be a chance that the request
didn't finish before the test does, leading to potential failures in the
next test.
This way we're also checking that the "Filter" button actually does
something when selecting the "Selected" filter.
The button to select/deselect a proposal wasn't very intuitive; for
example, it wasn't obvious that pressing a button saying "selected"
would deselect the proposal.
So we're using a switch control, like we do to enable/disable features
since commit fabe97e50.
In commit f638e5017 we introduced some methods to avoid race conditions
in tests that created debates, proposals or investments.
However, since we don't have a way to effectively make sure we use these
methods in new code, we forgot to do so when adding tests in commits
c483c6036 and 84b88c0ec.
So we're using them now.
There's a chance that this is what was causing multitenancy tests to
fail sometimes; if we don't wait for the request to get the suggestions
to finish, the application might still be dealing with this request when
we make another request to a different subdomain, or when the test has
finished and the tenant has already been deleted.
On my machine, the test "Creating content in one tenant doesn't affect
other tenants" failed about 5% of the time without these changes, and I
haven't been able to reproduce this failure after applying them. Having
said that, it's possible that this is a coincidence and that this test
will fail for a different reason in the future (like `login_as` not
working properly with subdomains).
Even after disabling the turbolinks previews in the previous commit
(which is still necessary, even with the changes in this commit), these
tests were still finishing before the "Go back" requests did. To
reproduce an issue caused by this behavior, run:
```
rspec spec/system/budgets/ballots_spec.rb:425 spec/system/users_auth_spec.rb:701 --seed 40358
```
Apparently, a `have_current_path` expectation isn't enough to check that
the request has finished and it only checks that the request to that
path has started or it's being processed.
Adding an additional expectation to check that the content of the page
has changed solves the issue.
Since the PR "Do not use third-party cookies in embedded videos #5548", the logic from
"embed_videos_helper" was extracted to the "embedded_video_component" and the
"videoable" model concern.
However, during this refactor, the "regex" method, which uses record.class:: to handle
video embeds, was left inaccessible for Legislation Proposals.
This commit fixes the issue by including the concern in the Legislation Proposal model.
We had a trait called `:admin_request` for actions that are requests to
administrators, but the default factories were also requests to
administrators.
The tests checking that the "Request" button is not present, which
shouldn't pass with the wrong default factories, were passing by
coincidence. The issue was that we weren't checking whether that the
request had finished before checking that the "Request" button wasn't
present. That meant that we were checking that the "Request" button
wasn't there right at the moment we pressed the link, before the request
was finished.
So we're now checking that the request is finished before checking that
the button isn't there.
On the other hand, the tests checking for the "Request resource" link
being present were checking a behavior that's no longer there since
commit 9d85b3935, when we changed the conditions affecting that link.
We were checking the proposal video URL, but its value was `nil` since
commit bedcb5bca2. This resulted in a warning:
```
Checking for expected text of nil is confusing and/or pointless since it
will always match. Please specify a string or regexp instead.
spec/system/admin/hidden_proposals_spec.rb:14
```
We were doing it most of the time, but in some cases we were clicking
the "Sign out" link instead. These actions aren't the same, just like
using `login_as` is not the same as visiting the sign in page and
submitting the form.
Some of these tests failed sometimes because the user wasn't signed in
after using `login_as`. One possible cause could be that we weren't
adding an expectation after clicking the "Sign out" link.
So using `logout` adds consistency, simplifies the code, and might
reduce the chance of these tests failing in the future (although they
might still fail in the future because some of these tests check the
database after a `visit` call).
