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.
We were very inconsistent regarding these rules.
Personally I prefer no empty lines around blocks, clases, etc... as
recommended by the Ruby style guide [1], and they're the default values
in rubocop, so those are the settings I'm applying.
The exception is the `private` access modifier, since we were leaving
empty lines around it most of the time. That's the default rubocop rule
as well. Personally I don't have a strong preference about this one.
[1] https://rubystyle.guide/#empty-lines-around-bodies
Having exceptions is better than having silent bugs.
There are a few methods I've kept the same way they were.
The `RelatedContentScore#score_with_opposite` method is a bit peculiar:
it creates scores for both itself and the opposite related content,
which means the opposite related content will try to create the same
scores as well.
We've already got a test to check `Budget::Ballot#add_investment` when
creating a line fails ("Edge case voting a non-elegible investment").
Finally, the method `User#send_oauth_confirmation_instructions` doesn't
update the record when the email address isn't already present, leading
to the test "Try to register with the email of an already existing user,
when an unconfirmed email was provided by oauth" fo fail if we raise an
exception for an invalid user. That's because updating a user's email
doesn't update the database automatically, but instead a confirmation
email is sent.
There are also a few false positives for classes which don't have bang
methods (like the GraphQL classes) or destroying attachments.
For these reasons, I'm adding the rule with a "Refactor" severity,
meaning it's a rule we can break if necessary.
Settings are stored in the database, and so any changes to the settings
done during the tests are automatically rolled back between one test and
the next one.
There were also a few places where we weren't using an `after` block but
changing the setting at the end of the test.
