We were testing the creation of newsletters and admin notifications for
each existing segment, which IMHO is a bit overkill, considering how
slow system tests are.
So far we don't have any reasons to believe creating newsletters and
admin notifications will only work for some user segments, so we're
testing a random one instead.
Running these tests on my machine is now about 15 seconds faster.
This way we don't have to use the `send` method in other places, like
the AdminNotification class, and we can change the internal
implementation at any point.
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're going to make it dynamic using the geozones. Besides, class
methods can be overwritten using custom models, while constants can't be
overwritten without getting a warning [1].
Makes the definition of segments with geozones a little cleaner. I
think it’s worth it, compared to the slight memory gain of using a
constant [2].
[1] warning: already initialized constant UserSegments::SEGMENTS
[2] https://stackoverflow.com/questions/15903835/class-method-vs-constant-in-ruby-rails#answer-15903970
Programmers can take advantage of this feature when defining custom
default settings. And, since many CONSUL installations had custom
changes in the `custom/verification/residence.rb` model and those
changes might use regular expressions, we're making it easier to migrate
that code to the new system to define valid postal codes.
We aren't documenting this feature in the description in the admin
section because most administrators don't know what regular expressions
are.
Note that, in order to simplify the setting, we already define the `/\A`
and `\Z/` characters. So, if the custom code had something like
`postal_code =~ /^280/`, the setting would have to be "280*" (without
the quotes) or, in order to comply with a length validation,
"280[0-9]{2}" (without the quotes).
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 weren't using the `be_valid` matcher because we had errors in the
census data.
Removing the `before_validation` callback and using a method to get the
census data instead allows us to stub the `census_data` method in the
tests, and so we can use the `be_valid` matcher instead of calling
`valid?` manually and then checking for errors.
Using a field with `type="tel"` causes most mobile phone browsers to
show a numeric keyboard which makes it easy to enter phone numbers.
We aren't using a number field because some browsers show "spinners" to
increment/decrement numbers (which doesn't make much sense in a phone
number) and because they don't allow characters like spaces. Phone
numbers can have characters like spaces, dashes, parenthesis, asterisks,
the plus sign, ...
Since phone number formats vary depending on the region, and sometimes
even within the same region several different formats can be used, for
now we aren't offering any kind of format validation. We could offer a
format validation that rejects just letters (although there are cases
where letters are actually allowed). However, this causes issues at both
the server side and the client side.
We could use a client-side validation adding a `pattern` attribute to
the field, but that would be something unlike anything else we use in
the application, and we would need to to write some JavaScript in order
to use a proper error message.
On the other hand, if we add a server-side validation, we might find out
existing users are invalid, and it would be impossible to update them in
the many places where we update users assuming they were valid in the
first place. We'd have to add a rake task to update existing user
records and make sure they contain a valid phone number or create a
setting so this validation only applies to new CONSUL installations.
Another option would be to add a per-form validation, so the phone
number is only validated in pages where it is introduced.
All the mentioned scenarios offer certain complexities. So, for now,
we're keeping things simple.
Co-Authored-By: decabeza <alberto@decabeza.es>
Now that we also have the "go back to CONSUL" link, the layouts are so
similar that it isn't worth it maintaining both of them separately.
With this change, people using small screens also get the "menu" button
in the management section, just like they do everywhere else.
We're adding the `namespace != "management"` condition so the menu still
shows up in the officing namespace.
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.
These locales are officially maintained by CONSUL developers, so we're
using them when available.
This way we'll be able to use `random_locales` in places where we're
manually using English and Spanish, giving support to other locales
while maintaining compatibility with the current version.
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.
The `commentable_url` method wasn't updated when we added legislation
proposals.
Back when we first created this method, we couldn't pass budget
investments or topics directly to `polymorphic_url` because they are
nested resources. That isn't the case since commit ff93f5a59, so now we
can simplify this method.
We're keeping the `commentable_url` method for now in order to keep
compatibility with custom changes that might use it, although this
method isn't consistent with the `commentable_path` method (which
receives a comment, and not a commentable), and so we might have to
revisit this code in the future.
With the `update_without_changes`, previous translations are kept
even when the source string changed utterly. Using this option caused
some problems when updating source language strings, as the
translators do not get any notification, and the old translation keeps
approved, so translators do not have an easy way to find those strings
in Crowdin.
With the `update_as_unapproved` option, translators and Crowdin
managers can find those translations that need to be updated by
searching among not approved translations.
Quoting Crowdin's docs [1]:
> update_without_changes - preserve translations and validations of
changed strings
> update_as_unapproved - preserve translations of changed strings
and remove validations of those translations if they exist
[1] https://support.crowdin.com/configuration-file/#changed-strings-update
