After a user assigned as a budget admin deletes their account or gets blocked by
a moderator, the application throws an exception while loading the admin
investment index page.
As an erased user is not really deleted and neither its associated roles, the
application was failing when trying to sort and administration without a
username. In this case, the application was throwing an `ArgumentError:
comparison of NilClass with String failed` exception.
As a blocked user is not deleted or its roles, the application failed when trying
to access the user name through the delegation in the Administrator. In this
case, the application was throwing a `NoMethodError: undefined method `name' for
nil:NilClass` exception.
We had a link to `/census_terms`, and by looking at the code, it wasn't
so clear where this URL came from.
Using `page_path`, it's easier to understand that it comes from a page
with the `census_term` slug. It also means we'll find this line when
searching for usages of `page_path` in the code.
While reviewing commit 7702b551e, I forgot to test whether selecting
text in the budget header or clicking its link worked properly.
The negative index (-5) meant it was impossible to select its text or
click on its link.
The good news is the pseudoelement with a negative index (-1) is
considered a child of the .budget-header element, so having a negative
index will cause the pseudoelement to be render behind the content of
the .budget-header element but in front of the background of the
.budget-header element.
This is exactly what we want.
Originally, we didn't have a z-index in the .budget-header element,
meaning the pseudoelement was rendered behind the background of the
.budget-header element, meaning both backgrounds were visible. This was
OK when the background was a plain color, but it wasn't when the
background was an image.
To stress the fact that the budget header is only affected when we use
an image, I'm also moving the code inside the `.with-background-image`
selector, although it would be interesting to check whether it's a good
idea to add `z-index: 0` to the `full-width-background` mixin.
Add missing relation between administrator and budget_administrators, otherwise
we'd get the following exception when deleting and administrator with assigned budgets:
PG::ForeignKeyViolation:
ERROR: update or delete on table "administrators" violates foreign key constraint "fk_rails_ee7dc33688" on table "budget_administrators"
DETAIL: Key (id)=(3) is still referenced from table "budget_administrators".
We forgot to do so in commit 04605d5d5. Before that commit, we were
testing the links weren't displayed in the "informing" phase as opposed
to the "finished" phase. After that commit, they weren't displayed
anywhere since a <select> field was shown instead.
Since then, we've replaced the <select> field with the links generated
by the `Budgets::Investments::FiltersComponent`. We've already got tests
for these links.
We're going to make a change, and it's easier if we've already got a
component with tests so we don't have to write system tests to check
whether the map is rendered.
We were returning an (empty) association of users instead of empty
associations of proposals, debates or comments. The code worked because
in the end it returned an empty array, but looked weird nevertheless.
After commit 0214184b2, this method was only used in two places and was
only useful in one of them. IMHO it isn't worth it add a monkey-patch
for such a minor usage.
After upgrading to Chrome/Chromium 101, the test "Cross-Site Scripting
protection banner URL" was failing with the message:
Element <a>...</a> is not clickable (...) Other element would receive
the click: <div class="banner" style="background-color:#FF0000;">...</
div>
The reason was that, when using the structure of a link with one <h2>
and one <h3> inside, previous versions of Chrome/Chromium considered the
margin between the <h2> and the <h3> part of the link. Version 101 does
the same thing Firefox does and so clicking on the space between the
<h2> and the <h3> doesn't result in clicking the link.
In order to keep the previous behavior, we're adding a `display: block`
tag to a link.
Note that, in the future, we might change the structure of the banner,
since using <h3> as a subheading is discouraged by the W3C, and we
aren't sure about the usability of making the whole banner clickable.
But, for now, we're just fixing the issue so our test suite is green
again.
Since we've already got a banner component, we follow the convention of
using one CSS file per component. We also reduce the number of lines in
the huge layout.scss file.
Now the sections in layout.scss from "17" to "19", just like they jump
from "08" to "10".
Currently the application does not send any email to confirm the
account for already confirmed users. But we show a notice message
that may look like you will recive one:
"If your email address exists in our database, you will receive
an email with instructions for how to confirm your email address
in a few minutes."
In this commit we keep the original message, but send an email to
the user informing them that their account is now registered.
This way no one can know if someone else's account is confirmed and
we don't have to worry about GDPR either.
Co-Authored-By: taitus <sebastia.roig@gmail.com>
Add a help text on admin budget show page and improve text from Admin::Budgets::HelpComponent in order to
clarify its functionality when we are using the wizard.
Currently we were using the wizard component to edit a
phase when we were no longer in the wizard.
This was a bit strange, as it took us out of the context
and showed us information such as the
CreationTimelineComponent or the HelpComponent
that is meant for when navigating the Wizard.
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.
In commit f374478dd, we enabled the possibility to use HTML in the
search results translations in order to add a <strong> tag to these
results. However, that meant we were also allowing HTML tags inside the
search term itself, and so it was possible to inject HTML on the page.
Stripping the HTML tags solves the issue.
Note the issue wasn't a high severity issue because tags such as
`<script>` weren't allowed since we were using the `sanitize` helper.
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.
