Many pages had this tag, but many other didn't, which made navigation
inconsistent for people using screen readers.
Note that there are slight changes in two pages:
* The homepage now includes the banner and the content of the
`shared/header` element inside the <main> tag
* The budgets index now includes the banner inside the <main> tag
I see both potential advantages and disadvantages of this approach,
since banners aren't necessarily related to the main content of a page
but on the other hand they aren't the same across pages and people using
screen readers might accidentally skip them if they jump to the <main>
tag.
So I'm choosing the option that is easier to implement.
Note we're adding a `public-content` class to the <main> element in the
application layout. This might be redundat because the element could
already be accessed through the `.public main` selector, but this is
consistent with the `admin-content` class used in the admin section, and
without it the <main> element would sometimes have an empty class
attribute and we'd have to use `if content_for?(:main_class)` or
`tag.main` which IMHO makes the code less consistent.
The Capybara::DSL monkey-patch is only done on the `visit` method
because it's the only reliable one. Other methods like `click_link`
generate AJAX requests, so `expect(page).to have_css "main", count: 1`
might be executed before the AJAX request is finished, meaning it
wouldn't properly test anything.
This way it'll be easier to change them.
Note that there were two `.document-link` elements which aren't part of
a `.documents` element. We're renaming the HTML class of the link in
investments because it didn't contain links to download documents and
are slightly duplicating the CSS in the poll answer documents in order
to keep the `word-wrap` property.
The outline was invisible when we had the link containing block
elements, and I didn't manage to fix it, so the easiest solution is to
use an inline link and style the card with CSS.
We were manually generating the IDs in order to pass them as data
attributes in the HTML in a component where we don't have access to the
form which has the inputs.
However, these data attributes only make sense when there's a form
present, so we can pass the form as a parameter and use it to get the
IDs.
We can now define a map as editable when there's an associated form,
which makes sense IMHO.
We were rendering the whole sidebar again, which wasn't necessary since
most of it remains unchanged. This resulted in complicated code to pass
the necessary information to render the same map that was already
rendered. Furthermore, when users had been moving the map around or
zooming out, we were resetting the map to its default settings after
voting, which was potentially annoying.
This also fixes the wrong investments being displayed in the map after
voting; only the investments on the current page were displayed in this
case while the index displayed all of them.
This is the only part of the sidebar that needs to be re-rendered after
an AJAX request adding or removing investments to a ballot, so having a
separate view just for it will make it easier to simplify the code.
We've experienced some caching issues with this code for years. We've
fixed some of them in commits 9979b5399 and 3645c333a, but we're still
running into other issues. In order to really cache this section, we'd
need to cache:
* Whether or not the investment should show the aside and vote/support
buttons (we could do it by caching its budget)
* Whether its budget is balloting or finished (we could do it by caching
its budget)
* Whether the current user is following the investment
* Whether the `remove_investments_supports` feature is enabled
* Whether the `community` feature is enabled
* The value of the `org_name` setting
* The value of the `twitter_handle` setting
We weren't caching all these elements, meaning that (for instance), we
didn't display the button to vote when a budget moved into the voting
phase if we had already cached this section without the button.
And chances are the list is incomplete. So, instead of trying to take
into account every single possible factor that should make us expire the
cache, we're restricting the cache so it only affects the content of the
investment. This is similar to what we do in the investments index,
where we cache the content of the investment but we don't cache the
vote/support buttons.
When voting investment projects, the sidebar was rendered without the
`@heading_content_blocks` being set. That resulted in a 500 error when
the heading had content blocks.
By extracting the logic to a component, we make sure the heading content
blocks are properly set every time this code is rendered, no matter
which controller is rendering the view.
We were showing the header when there were no search terms but there
were advanced search filters, unlike what we do for debates and
proposals. Besides, we were already hiding the header when there were
search terms, so it makes sense to hide it when using the advanced
search too.
We're using the `@search_terms` and `@advanced_search_terms` instance
variables in order to be consistent with what we do in the debates and
proposals sections.
We were using very similar code for proposals, debates and investments,
so we might as well share the code between them.
Note we're using the `proposals.index.search_results` key even for
debates and investments. This will still work because the translations
shared the same text, but IMHO we should rename the key to something
like `shared.search_results_summary`. We aren't doing so because we'd
lose all the existing translations.
The background wasn't expanding to the edge of the page because we
forgot to do this when we did the same thing for proposals and debates
in commit 4c47eab60.
When using the advanced search in the debates and proposals sections, we
were not displaying the search term in the search results summary.
However, we were displaying it when using the advanced search in the
investments section.
Now we're doing the same thing everywhere.
This way we fix a bug we mentioned in commit 930bb753c which caused
links to documents to be broken when editing their title because the
title was used to generate the URL of the document.
Note we're still using Paperclip to render cached attachments because
this is the only case where we store files with just Paperclip and not
Active Storage.
With Active Storage, we render attachments just like any other resource,
using `polymorphic_path`. Paperclip included the `url` method in the
model; since the model doesn't have access to the request parameters
(like the host), this was inconvenient because it wasn't possible to
generate absolute URLs with Paperclip.
In order to simplify the code and make it similar to the way we used
Paperclip, we're adding a `variant` method accepting the name of a
variant and returning the variant.
Very similar code is present in the `votes.js` file. Since the only
elements with the `js-participation-not-allowed` class also matched the
`div.supports div.participation-not-allowed` selector, for these
elements the events were executed twice.
So we can get rid of the `js-participation` class alongside all the
JavaScript code referencing it.
Note that in proposal notifications we're writing the call to
render the component in the same line as the <div class="reply">
definition in order to be able to use the `:empty` selector when the
component renders nothing. No browser matches whitespace with the
`:empty` selector, so we can't add newline characters inside the tag. A
more elegant solution would be extracting the proposal notification
actions to a component and only rendering it if the moderation actions
component is rendered.
As mentioned in commit 36d795f69, investment filters aren't that
important; actually, most citizens won't use them at all, and are there
mainly for transparency purposes.
So we're moving them to the bottom of the sidebar, just like the links
for selected/archived/retired proposals in the proposals section.
The interface was a bit confusing, since after clicking on "See
unfeasible investments" (or similar), we were on a page where no
investments were shown.
Besides, since commit 7e3dd47d5, the group page is only linked from the
"my ballot" page, through a link inviting the user to vote in that
group, and it's only possible to vote selected investments (which is the
default filter during the final voting phase).
The only reason we had these links here was these links weren't present
in the investments page. But they're present there since commit
04605d5d5, so we don't need them in the group page anymore.
As mentioned in commit bc0f04075, a <select> field which submits its
form on change causes many accessibility and usability issues. In this
case there was also an incompatibility with the advanced search filter
which caused a bug solved in commit 541a5fa89.
So the question is where to position the filters and how to display
them. One factor to take into the account is how relevant these filters
are, particularly compared to the links to select the prefered order,
since we don't usually give users the choice of both filters and orders.
Our filters don't really make sense until the valuation phase starts,
since before that phase investments aren't selected nor their
feasibility is decided.
After that phase, the only phase where citizens are really involved
is the final voting; the rest of the phases are done by valuators and
administrators. In the final voting, citizens can only vote on selected
projects, and that's the default filter during that phase.
So these filters are mainly there for information purposes, and not to
help citizens in the phases where they're actually involved (accepting
projects, selecting projects and balloting).
Orders, on the other hand, play a crucial role during the final voting
phase. Since citizens might have already voted for a few projects and
have, let's say, 100,000€ left, ordering by price allows them to find
which projects are within their remaining budget.
In conclusion, orders are more important than filters, and so they
should have a more prominent place.
For consistency with the proposals section, where we've got some links
in the sidebar (bottom part of the page on small screens) providing a
similar funcionality, like accessing selected proposals or archived or
retired proposals, we're moving the investments filters to the sidebar
(bottom part of the page on small screens) as well.
A <div> can't be a direct child of a <ul>. In this case the <ul> tag
didn't make much sense because there isn't a list; just a map.
Note the `z-index` rule which was added in commit 25e1afea48 is ignored
because the map element is statically positioned. I'm not sure why it
was added; can't reproduce the rendering problem both that commit and
commit c5a749212 mention. Maybe back then the element had a `position:
relative` rule or similar somewhere.
When render the investment list component with the link "see all
investments", now we redirect to groups index page when a budget has
multiple headings.
The budget header was supposed to be huge, but only in the participatory
budgets index or show actions. It was still huge, with plenty of empty
space, when there was no budget, or in the "submit my ballot" and
"select a heading" pages.
