This code was added in commit b3f570512 in order to rotate existing
cookies used by Consul Democracy 2.1 and earlier. Since the code was
included in Consul Democracy 2.2, existing installation using Consul
Democracy 2.2 will have already rotated the old cookies, which means we
don't need the cookie rotator anymore.
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.
It looks like not all screen readers identify SVG images with empty aria
labels as a decorative image, as reported by the Axe accessibility
engine.
So we're using `aria-hidden` instead, since we don't want the text of
the SVG to be read by screen readers. We're using `aria-hidden` instead
of the `presentation` role for the reasons mentioned in commit
35659d441.
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.
In order for this attribute to be applied, due to the syntax of the
`select` method, it should be in a separate hash.
We're removing it instead of correctly applying it because we never use
the `tabindex` attribute with a positive value, since it might break
keyboard navigation.
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.
