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.
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.
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.
By default, in order to increase performance during IO operations, Ruby
doesn't immediately write to the standard output but uses a buffer
internally and writes the output in chunks [1].
It looks like this results in some output being missed when running
Docker Compose [2], so we're activating the sync mode, which flushes all
output immediately.
[1] https://ruby-doc.org/core-2.6.5/IO.html#method-i-sync-3D
[2] See issue 1118 in the sinatra/sinatra repository
The map feature was never implemented for debates (only for proposals
and budget investments) and it was crashing for debates because the page
didn't load the geozones. And we don't have a "geozone" field in the
debates form either.
So we're removing the map page alongside its (pending implementation)
tests.
There are CONSUL installations where the validations CONSUL offers by
default don't make sense because they're using a different business
logic. Removing these validations in a custom model was hard, and that's
why in many cases modifying the original CONSUL models was an easier
solution.
Since modifying the original CONSUL models makes the code harder to
maintain, we're now providing a way to easily skip validations in a
custom model. For example, in order to skip the price presence
validation in the Budget::Heading model, we could write a model in
`app/models/custom/budget/heading.rb`:
```
require_dependency Rails.root.join("app", "models", "budget", "heading").to_s
class Budget::Heading
skip_validation :price, :presence
end
```
In order to skip validation on translatable attributes (defined with
`validates_translation`), we have to use the
`skip_translation_validation` method; for example, to skip the proposal
title presence validation:
```
require_dependency Rails.root.join("app", "models", "proposal").to_s
class Proposal
skip_translation_validation :title, :presence
end
```
Co-Authored-By: taitus <sebastia.roig@gmail.com>
We were getting a warning in Rails 6.0:
DEPRECATION WARNING: Class level methods will no longer inherit scoping
from `public_for_api` in Rails 6.1. To continue using the scoped
relation, pass it into the block directly. To instead access the full
set of models, as Rails 6.1 will, use
`ActsAsTaggableOn::Tag.default_scoped`.
In SQL, conditions like:
```
tag_id IN (x) AND taggable_type='Debate' OR taggable_type='Proposal'
```
Don't work as intended; we need to write:
```
tag_id IN (x) AND (taggable_type='Debate' OR taggable_type='Proposal')
```
Due to this bug, we were returning taggings for proposals without
intending to do so.
Since the code was very hard to read, we're also simplifying it.
When there was a custom JavaScript file, we weren't loading the original
one, meaning that, in order to customize it, it was necessary to copy
the whole original file and then changing it.
Now we're loading both the original and the custom file, so the custom
file can simply add more functions or overwrite the ones we'd like to
customize, without copying the whole file.
Existing copies of original files will still overwrite the whole file
and won't be affected.
Since we're going to remove Paperclip and Active Storage doesn't provide
any validations, we have to either write our own validation rules or use
a different gem.
We're using the file_validators gem instead of the
`active_storage_validations` gem because the latter doesn't support
proc/lambda objects in size and content type definitions. We need to use
them because in our case these values depend on settings stored in the
database.
We were using the same logic six times regarding when we should show a
"participation not allowed" message. Since we're going to change the
current behavior, we're unifying the logic in one place so the changes
will be easier.
Hovering over the votes showed a "participation not allowed" message
which was annoying when scrolling with the browser or simply moving the
mouse around the page. Furthermore, it hid the information about the
number of votes, links to show/collapse replies, ...
We're planning to change the behavior of all the "participation not
allowed" messages in order to show them on click instead of showing them
on hover (just like it's done on touchscreens). In the case of comments,
supports, however, there's very limited space in the part showing the
number of supports for comments, so adding this message without breaking
the layout is challenging.
So, for now, we're simply redirecting unauthenticated users to the login
page. If find an easy way to implement a better user interface in the
future to display the "participation not allowed" message, we might
change this behaviour.
Note we're using the `budgets.investments.investment.add_label` and
`budgets.ballots.show.remove_label` internationalization keys so they're
consistent with the `budgets.investments.investment.add` and
`budgets.ballots.show.remove` keys which were already present. We aren't
unifying these keys in order to keep existing translations.
This way blind screen reader users will know which proposal they're
supporting. In a list of proposals, context might not be clear when a
link saying "Support" or "Support this proposal" is announced, but a
link saying "Support Create a monthly transport ticket" is less
ambiguous.
Just like we did with investments in commit de436e33a, we're keeping the
title attribute because when visiting a proposal page, the connection
between the "Support" link and the proposal is not as clear as it is in
the proposals index page, so it might not be clear what you're
supporting.
The action and the views were almost identical, with the supports
progress and the HTML classes of the success message element being the
only exceptions; we can use CSS for the styles instead.
The `legislation_proposals#index` action was never used because it used
the same URL as `legislation_processes#proposals`.
In commit 702bfec24 we removed the view, but we forgot to remove the
controller action, the route, and some partials which were rendered from
the index view.
Currently the translation:
"Notify me by email when someone comments on my proposals or debates"
It only refers to proposals and debates, but actually it also refers to budget
investments, topics and polls.
We modified the link that previously redirected us to the "My content"
page to redirect us to the new page for managing subscriptions.
We also adapted the existing generic text by adding a description of
the related notification.
You can update the same "notifications" section that we allow you to
update in "my account".
This "subscriptions" section differs from the "my account" section
because we do not need to be logged in to update the status of the
notifications.
The user can access this page without being logged in.
We identify the user through the "subscriptions_token" parameter and
show a list of the notifications that can be enable/disable.
We will return a 404 error in case someone accesses the page with a
non-existent token.
We also control the case that some anonymous user tries to access the
page without any token, by returning the CanCan::AccessDenied exception.
It was a bit confusing to press the "hide" button and then see the user
listed as "blocked". Some moderators might think they accidentally
pressed the wrong button.
In the moderation section there's no clear indicator as to what the
"Hide" and "Block" buttons do and the difference between them.
Since we're using confirmation dialogs in all moderation actions except
these ones, we're adding them here as well, so the difference will
appear in the dialog.
This isn't a very good solution, though, since the confirmation dialog
comes after clicking the button and users have already been wondering
whether clicking that button will be the right choice. A better solution
would be making the purpose clear before the button is clicked, although
that's something we don't do anywhere in the admin/moderation sections.
The `hide` action was calling the `block` method while the `soft_block`
action was calling the `hide` method.
Combined with the fact that we also have a `block` permission which is
used in `ModerateActions` the logic was hard to follow.
Other than removing a redundant action, we're fixing two bugs when
blocking an author using the links in the public views:
* We were always redirecting to the debates index, even if we blocked
the author of a proposal or an investment
* We weren't showing any kind of success message
We're going to add geozones as user segments, so it's handy to have the
method in the UserSegments class.
We're also changing the `user_segment_emails` parameter name for
consistency and simplicity.
We were using the word "registered" in English as an equivalent of the
Spanish word "empadronado". However, the term "registered" is very
confusing because it might be understood as being registered in the
CONSUL website.
In the message, we're saying "cannot participate" in order to make the
message consistent with the message regarding the required age.
Due to the way Madrid handled postal code validations (see issue 533),
by default we were requiring everyone to validate against the local
census *and* to specify valid postal codes.
This could be useful in some cases, but in other cases, the census
validation will be enough and there'll be no need to manually define the
valid postal codes. Besides, some CONSUL installations are used in
organizations or political parties where the postal code validation
doesn't make sense.
