The expectation that there isn't a link with the text "Español" wasn't
updated in commit f7417d647, when the tests were updated after switching
the user interface from a list of links to a select field.
We're also adding an additional expectation after the `visit` to make
sure the request has finished before selecting English from the selector
(which probably doesn't make sense because it's the only option, but
changing it is out of the scope of this commit).
We were checking that, after a `visit`, we're redirected to the account
page, but, since we were already in the account page, the page doesn't
change at all. In order to be 100% that the request caused by the call
to `visit` has finished before checking the expectations, we're visiting
a different page first.
We weren't checking whether the request creating the proposal had
finished before checking the document. That's probably why this test has
recently failed on our CI:
```
1) Documents Metadata download document without metadata
Failure/Error: io = URI.parse(
"#{app_host}#{polymorphic_path(
Document.last.attachment)}"
).open
NoMethodError:
undefined method `attachment' for nil:NilClass
```
We weren't checking that the requests had finished before checking the
last sent email. That's probably why one of these tests has recently
failed on our CI:
```
1) System Emails Preview Pending #send_pending
Failure/Error: email = open_last_email
RuntimeError:
No email has been sent!
```
These tests don't use the browser to send emails since commit e21588ec1.
However, note that this commit actually actually decreased our test
coverage somehow; since then, we're no longer testing whether we send an
email to the author after clicking the "Publish comment" button. We
might need to add a test for this in the `spec/system/comments_spec.rb`
file... but that's a story for another time.
Note we need to stub the `deliver_later` method; otherwise,
`open_last_email` would raise an exception since no email would have
been delivered.
We're moving them now because these tests use the `open_last_email`
method, and we're looking for places where using this method might
result in a flaky test when used inside a system test.
These tests were testing mailer methods, but were inside a file for
system tests.
We're moving them now because these tests use the `open_last_email`
method, and we're looking for places where using this method might
result in a flaky test when used inside a system test.
These tests were testing model methods, but were inside files for system
tests.
We're moving them now because these tests use the `open_last_email`
method, and we're looking for places where using this method might
result in a flaky test when used inside a system test.
This way it's more clear what the user experience is during the process.
Note this did not result in flaky tests, since the tests continue by
clicking links, that are only present after the request has finished.
However, we're adding expectations so we don't have to think whether the
tests could be flaky and because this way we're also testing the user
experience; it would be strange for a user if they were redirected to a
page without a flash message.
Quoting from commit 57bda006b5:
> When clicking the button "Search", the link "newest" is already
> present, so capybara might click the "newest" link before the "Search"
> request is finished, leading to unexpected results.
>
> Checking the page to make sure the "Search" request has finished
> before clicking the "newest" link solves the problem.
We're doing the same thing for the other tests that click the "Search"
button and then clicked on a link. We're also making sure the language
selector changes before clicking it again.
In most tests calling this method, we were doing another visit right
after calling this method, so by removing this `visit` call we're making
the tests slightly faster and easier to follow.
This way we're 100% sure we won't have simultaneous requests since the
test will wait for one request to finish before continuing.
In the debates spec, we're also making sure the expectations between the
two consecutive visits are different.
There were many cases where we were clicking on a link or (most of the
time) a button and then calling the `visit` method. In the past, it
worked just fine because clicking on buttons usually results in non-AJAX
requests, meaning that the test waited for the request to finish before
continuing.
That's no longer the case, though. In the last few months/years (not
sure since when) we're getting sporadic failures because the test
doesn't wait for the request to finish before making another request
with the `visit` method. This sometimes results in flaky tests.
Some of these tests have recently failed in our CI. Here are a few
examples (note the numbers don't follow an order because these tests
failed in different jobs):
```
1) Admin edit translatable records Current locale translation does not
exist For ActivePoll Shows first available fallback
Failure/Error: expect(page).to have_content "Sondage en Français"
expected to find text "Sondage en Français" in "Language: \n
\nEnglish\nDeutsch\nEspañol\nFrançais\nNederlands\nPortuguês
brasileiro\n中文\n Go back to CONSUL DEMOCRACY\nCONSUL
DEMOCRACY\nADMINISTRATION\nMenu\nNotifications\nMy content\nMy
account\nSign out\nProposals\nDebates\nComments\nPolls\n
Collaborative Legislation\nParticipatory budgets\nVoting booths
\nSignature Sheets\nMessages to users\nSite content\nModerated
content\nProfiles\nStatistics\nSettings\nProposals dashboard\n×
\nPolls description updated successfully.\nList of polls\nPolls
description\nCreate poll\nThere are no polls."
2) Public area translatable records Existing records Update a
translation With valid data Changes the existing translation
Failure/Error: expect(page).to have_field "Debate title",
with: "Title in English"
expected to find field "Debate title" that is not disabled but
there were no matches
2) Admin collaborative legislation Update Edit milestones summary
Failure/Error: expect(page).to have_content "There is still a long
journey ahead of us"
expected to find text "There is still a long journey ahead of us"
in "Language: \n
\nEnglish\nDeutsch\nEspañol\nFrançais\nNederlands\nPortuguês
brasileiro\n中文\n Go back to CONSUL DEMOCRACY\nCONSUL
DEMOCRACY\nADMINISTRATION\nMenu\nNotifications\nMy content\nMy
account\nSign out\nProposals\nDebates\nComments\nPolls\n
Collaborative Legislation\nParticipatory budgets\nVoting booths
\nSignature Sheets\nMessages to users\nSite content\nModerated
content\nProfiles\nStatistics\nSettings\nProposals dashboard\n×
\nProcess updated successfully. Click to visit\nBack\nAn example
legislation process\nInformation\nHomepage\nDebate\nProposals\n
Drafting\nFollowing\n1 language in use\nCurrent language\n
English\nSummary\n Format\n ◢\n Milestone\nManage progress
bars\nDon't have defined milestones\nCreate new milestone".
(However, it was found 1 time including non-visible text.)
3) Admin collaborative legislation SDG related list create Collaborative
Legislation with sdg related list
Failure/Error:
within("tr", text: "Legislation process with SDG related content") do
expect(page).to have_css "td", exact_text: "17"
end
Capybara::ElementNotFound:
Unable to find css "tr"
4) Valuation budget investments Valuate Feasibility can be marked as
pending
Failure/Error: expect(find("#budget_investment_feasibility_undecided"))
.not_to be_checked
Capybara::ElementNotFound:
Unable to find css "#budget_investment_feasibility_undecided"
3) Custom information texts Show custom texts instead of default ones
Failure/Error:
within("#section_help") do
expect(page).to have_content "Custom help with debates"
expect(page).not_to have_content "Help with debates"
end
4) Admin budgets Update Deselect all selected staff
Failure/Error: expect(page).to have_link "Select administrators"
expected to find link "Select administrators" but there were no
matches
3) Admin polls SDG related list edit poll with sdg related list
Failure/Error:
within("tr", text: "Upcoming poll with SDG related content") do
expect(page).to have_css "td", exact_text: "17"
end
Capybara::ElementNotFound:
Unable to find css "tr"
4) Admin polls SDG related list create poll with sdg related list
Failure/Error:
within("tr", text: "Upcoming poll with SDG related content") do
expect(page).to have_css "td", exact_text: "17"
end
Capybara::ElementNotFound:
Unable to find css "tr"
5) Admin custom images Image is replaced on admin newsletters
Failure/Error:
within(".newsletter-body-content") do
expect(page).to have_css("img[src*='logo_email_custom.png']")
end
Capybara::ElementNotFound:
Unable to find css ".newsletter-body-content"
6) Admin custom images Image is replaced on front views
Failure/Error:
within("#map") do
expect(page).to
have_css("img[src*='custom_map.jpg'][alt='Districts list']")
end
Capybara::ElementNotFound:
Unable to find css "#map"
```
Set cookie duration to 365 days based on the AEPD's cookie usage guidelines.
Note from the document: "Cookies with a duration of up to 24 months are
considered acceptable as long as they are periodically updated."
Reference: https://www.aepd.es/guias/guia-cookies.pdf
Create cookie consent "all" when accept all cookies
Set cookie duration to 365 days based on the AEPD's cookie usage guidelines.
Note from the document: "Cookies with a duration of up to 24 months are
considered acceptable as long as they are periodically updated."
Reference: https://www.aepd.es/guias/guia-cookies.pdf
Set cookie duration to 365 days based on the AEPD's cookie usage guidelines.
Note from the document: "Cookies with a duration of up to 24 months are
considered acceptable as long as they are periodically updated."
Reference: https://www.aepd.es/guias/guia-cookies.pdf
Allow enabling from settings admin section.
Note that we set the z-index to 20 in order to will be greater than
the others z-index elements in the application like <header> on
mobile devices.
According to the GeoJSON specification [1]:
> * A linear ring is a closed LineString with four or more positions.
> * The first and last positions are equivalent, and they MUST contain
> identical values; their representation SHOULD also be identical.
> (...)
> * For type "Polygon", the "coordinates" member MUST be an array of
> linear ring coordinate arrays.
Note that, for simplicity, right now we aren't checking whether the
coordinates are defined counterclockwise for exterior rings and
clockwise for interior rings, which is what the specification expects.
[1] https://datatracker.ietf.org/doc/html/rfc7946#section-3.1.6
Note we're adding a `name` property to the geozones investments sidebar
map even if we don't render the geozones in the map, in order to
simplify the JavaScript function `geozoneLayers`.
We're reworking the format validation to correctly interpret feature
collection, feature, and geometry, according to RFC 7946 [1].
Since Leaflet interprets GeoJSON format, we're rendering the GeoJSON as
a layer instead of as a set of points. For that, we're normalizing the
GeoJSON to make sure it contains either a Feature or a
FeatureCollection. We're also adding the Leaflet images to the assets
path so the markers used for point geometries are rendered correctly.
Note we no longer allow a GeoJSON containing a geometry but not a
defined type. Since there might be invalid GeoJSON in existing Consul
Democracy databases, we're normalizing these existing geometry objects
to be part of a feature object.
We're also wrapping the outline points in a FeatureCollection object
because most of the large GIS systems eg ArcGIS, QGIS export geojson as
a complete FeatureCollection.
[1] https://datatracker.ietf.org/doc/html/rfc7946
Co-authored-by: Javi Martín <javim@elretirao.net>
The `show_caption_for?` method was used to determine whether to check for the
presence of a `figcaption` element, but its only purpose was to skip the check
when the factory was `:budget.
The reason we skip the `figcaption` check for `:budget` is that it is the only case
where the test is verifying the form's edit page, where displaying a `figcaption` does
not make sense.
This method was removed as its logic was redundant or unnecessary:
- For "Proposal" new:
After creating a proposal, we are redirected to the "created" page, where the text
"Not now, go to my proposal" is not present, leading to a constant
`rescue Capybara::ElementNotFound`.
Instead, the "created" page shows a preview of how the proposal will look when
published and a link saying "No, I want to publish the proposal". Since the click's
purpose was to navigate to the proposal's "show" page, and this can already be
verified on the "created" page, no additional handling is needed for this case.
- For "Proposal" edit:
After updating the proposal, we are directly redirected to the proposal's "show" page,
so no click_link logic is necessary here either.
- For "Budget":
The redirection is now handled directly with:
`visit edit_admin_budget_path(imageable) if factory == :budget`.
In the imageable_attach_new_file method used in this tests the:
> expect(page).to have_css ".loading-bar.errors"
is already being checked.
Therefore, to leave only the line:
> imageable_attach_new_file(file_fixture("logo_header.png"), false)
in the test, since there is another test that verifies it,
I think we can remove the test altogether.
In the imageable_attach_new_file method used in these tests the:
> expect(page).to have_css ".loading-bar.complete"
is already being checked, so there is no need to verify it twice.
This is the only it_behaves_like "nested imageable" call where the has_many_images parameter is set to true.
Previously, the shared example skipped or altered expectations based on this parameter. Now, this behavior is
moved to the factory level (:future_poll_question_option).
Since this is an administrative section, a related administrator is created for the user.
Make `path`, `fill_resource_method_name`, `submit_button`, and
`imageable_success_notice` dynamic based on the factory.
Also adjusted the user. The proposals no longer require the user to be an
administrator but do require them to be a level 2 user.
Note that we are adding the Style/CaseLikeIf rubocop rule.
Removed `imageable_path_arguments`, `has_many_images`, and `management` parameters
because they are not used by budgets.
Hardcoded `path`, `fill_resource_method_name`, `submit_button`, and
`imageable_success_notice`parameters for budgets. These remain fixed for now until dynamic
values are required in the next commits.
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.
