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.
In some countries, postal codes are defined with a dash in the middle,
so we're using a colon to define ranges instead. We could also use two
dots, like in Ruby ranges, but IMHO this would cause typos since people
would enter codes separated with three dots or just one dot.
We were making some typos during development in the name of the keys and
tests were still passing.
We're also removing some texts that were never used.
Some developers work on CONSUL installations where Spanish and/or
English aren't part of the available locales. In those cases, the
`dev_seed` task was crashing because we were using attributes like
`name_en` and `name_es`.
So we're using attributes for random locales instead.
We're using a proc so we don't have code like this all over the place:
random_locales.map do |locale|
I18n.with_locale(locale) do
phase.name = I18n.t("budgets.phase.#{phase.kind}")
phase.save!
end
end
This would make the code harder to read and would execute a `save!` once
per locale, which would make the task much slower.
We could also avoid the procs writing something like:
def random_locales_attributes(**attribute_names_with_values)
random_locales.each_with_object({}) do |locale, attributes|
I18n.with_locale(locale) do
attribute_names_with_values.each do |attribute_name, (i18n_key, i18n_args)|
value = I18n.t(i18n_key, (i18n_args || {}).merge(language: I18n.t("i18n.language.name")))
attributes["#{attribute_name}_#{locale.to_s.underscore}"] = value
end
end
end
end
And calling the method with with:
random_locales_attributes(name: ["seeds.budgets.name", year: Date.current.year - 1])
However, this code would also be different that what we usually do, we'd
have to apply some magic to pass the `language:` parameter, and the
strings wouldn't be recognized by i18n-tasks, so we aren't sure we're
really gaining anything.
Originally there was a link pointing to the FAQ page but it was removed
in commit e14b7b67fb because by default the FAQ page in CONSUL only
contains a placeholder text.
We aren't sure where this link should point:
* FAQ page, only if the FAQ page is published
* Help page, only when the help feature is enabled
* CONSUL technical documentation page
So, for now, we're choosing the easiest solution which is removing the
text completely.
We already support Errbit and Airbrake as error monitoring services.
Since some people might not want to setup Errbit and might prefer
Rollbar over Airbrake, we're referencing it in the custom gemfile.
We haven't updated the gem for years and don't know whether it
still works with our current Ruby and Rails versions.
Besides, dependabot keeps opening pull requests to update it. In theory
we could just ignore the dependabot pull requests for this dependency,
but unfortunately right now we can't add a dependabot config file
because it would open pull requests on forks as well.
Finally, there are other companies offering similar services for Rails
applications, and it's up to each CONSUL installation to decide which
one is better for them. We might add a self-hosted performance
monitoring tool in the future.
Since other CONSUL installations might be using Newrelic, and in general
we recommend adding an application monitoring tool, we're suggesting it
in the custom gemfile. In the name of neutrality, we're also adding
Sentry. We might add other services in the future.
So now:
* In the first few phases, no filters are shown (just like before)
* During the valuation phase, we show "Active" and "Unfeasible"
* During the final voting, we show "Active" (which now refers to the
selected investments), "Not selected for the final voting" and
"Unfeasible"
* When the budget is finished, we show "Winners", "Not selected for the
final voting" and "Unfeasible"
Now each investment is shown in one (and only one) of the filters
(except when the budget is finished; in this case we don't show selected
investments which didn't win), and we remove the confusing "Not
unfeasible" filter by only showing it during the valuation phase (before
filters are selected) and renaming it to "Active". We also rearrange the
filters so the default one for each phase is shown first.
The idea of using the "Active" text for investments which can be
selected during the selection phase and voted during the final voting is
experimental. Right now, for simplicity, since we assume filters will
always use the same text, we're removing the "Active" filter when the
budget is finished, since having both "Winners" and "Active" filters
would be confusing.
Placeholders are hard to read due to their low contrast, and users might
want to read them after they're already gone, and so they cause both
accessibility and usability issues.
The installer creates the application in the following path:
home_dir: "/home/{{{ deploy_user }}"
We update the variable "deploy_to" in the deploy-secrets
file to be consistent with the installer.
While we are modifying the file we also update the "user"
variable in staging and preproduction sections with the
installer default value: "deploy_user: deploy" the same as
we already have in the production 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.
We removed it in commit c322b2c4a because it was hard to know the
difference between "Feasible" and "Not unfeasible". We're renaming the
"Not unfeasible" filter instead.
We're also moving the "selected" filter so it appears before the
"unselected" filter, just like the "feasible" filter appears before the
"unfeasible" filter.
The text "Groups and headings" might cause users to think both groups
and headings have the same hierarchy, and wonder whether what they
immediately see are groups or headings.
Using "Heading groups" we make it clear that what comes immediately is a
group, and then we see each group has headings.
