We had inconsistent indentation in many places. Now we're fixing them
and adding a linter to our CI so we don't accidentally introduce
inconsistent indentations again.
We had some duplication because the `css_for_process_header` was using
an instance variable, and so it couldn't be called from a partial where
this instance variable wasn't available.
Using a local variable and passing it as a parameter (as we should
always do) solves the issue and lets us simplify the code.
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
Note that in order to avoid display duplicated vertical scroll when
render a modal, we are add an `overflow: unset` rule. This rule
overwrite a vendor rule both in the modal we are adding and in the
modal we already have when creating a budget in admin section.
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.
Note that, while we're no longer including them as part of the
`execute_release_2.2.0_tasks` task, we're keeping the tasks to remove
duplicate poll voters and poll options just in case there are some
unexpected issues when adding a unique database index while upgrading to
version 2.3.0. We'll remove them in version 2.4.0.
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.
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.
