There was a rare case we've found on some Travis builds where the system
time suddenly moved back to the past a couple of tenths of a second,
meaning `Time.current - resource.created_at` returned a negative number,
which lead to a division by zero.
We're reading the value from the database, but the
`ApplicationMailer.default` method is evaluated when the application is
started. So if we don't use a Proc, we'll need to restart the server
every time we change the value in the database, or else the old value
will still be used.
Using a Proc makes sure the mailer from address is evaluated at runtime,
so emails are sent using the from address currently defined in the
database.
The same situation took place using the devise mailer. Now we don't need
to check for the settings table being present because the Proc in the
devise initializer won't be evaluated before the settings table is
created and populated.
We were performing an AJAX request and then a "normal" request without
checking the AJAX request had finished. Sometimes it resulted in the
normal request finishing because the AJAX request did, causing the test
to fail.
We're getting a failure on Travis in one of these tests. Debugging shows
the AJAX request rendering the first page (after clicking the "Previous"
link) takes too long and sometimes it exceeds Capybara's timeout.
After running the test thousands of times, the only way I've found to
clearly reduce the number of times the test fails is to reduce the
number of records shown on the first page. Other experiments, like
adding an `includes(:author)` to the query getting the proposals in the
controller, or adding `author: user` to the `create_list` part of the
test (so only one author needs to be fetched when rendering the
proposals) show inconsistent results regarding performance.
Note we still need at least 10 proposals for the test for several users,
to guarantee two users will never get the same records during the test
(or at least the probability they get the same records is one in
millions).
The tests in the `spec/lib/graphql_spec.rb` failed sometimes because
creating a record with a tag list of ["health"] when both "health" and
"Health" tags exist might assign either one of them. These tests usually
pass because we create two records and just by chance usually one of the
records gets one tag and the other one gets the other tag. However, the
test was written as if we expected the first record to get the first tag
and the second record to get the second tag, while very often the tests
were passing because the first record got the second tag and the second
record got the first tag. And when both records get the same tag, the
tests fail.
So I've changed these tests to tags are assigned directly and, since we
want to test the `tag_list` method, I've also added some tests to the
Tag model, which reflect the current behaviour: a random tag is assigned
when several tags with the same case-insensitive name exist.
Another option to assign the right tag to the record we're creating
would be to add `ActsAsTaggableOn.strict_case_match = true` to an
initializer. However, that would also create new tags on the database
when we accidentally assign a tag like "hEaLth" (like in the test we add
in this commit). Ideally we would have a strict case match for existing
tags and a non-strict case match for new tags, but I haven't found a way
to do it.
We don't need to create a heading every time we create an investment; we
can use an existing one by default.
Some tests are now much faster and don't fail on Travis due to reaching
Capybara's timeout anymore.
The images from OpenStreetMap take a while to load, sometimes even
causing Net::ReadTimeout errors if the internet connection is slow. It's
happened a lot recently on Travis builds.
Using capybara-webmock we guarantee the test suite doesn't fail due to
network issues.
While the correct usage would require an `in_time_zone` call, the code
can be simplified and the relationship between the current date and the
last `proposal.created_at + index.days` is now a bit easier to notice.
We use the beginning of the month as the date of the first action
because we expect all 8 actions to be created on the same month.
The dates are saved on UTC times on the database. So, for example,
if living in West Australia, `Date.current.beginning_of_day` will be
stored as UTC's yesterday at 15:15:00, while `Date.current.end_of_day`
will be stored as UTC's today at 15:14:59.
When we use the `DATE` database function, PostgreSQL will select the
records with the same UTC date as the current UTC date. However, we need
the records with the same application date (as defined in
`config.time_zone`) as the current application date. The test passed
(for us) because we were using `beginning_of_day + 3.hours` to make sure
we were creating records when the date in Madrid was the same as the UTC
date.
Using a ruby interval for the time condition solves the problem.
This number was not the important one; the important one is the one
given by the recounts.
Note we're also removing the votes by date, since they're also system
votes.
System count isn't a relevant number because the important one is the
number of votes counted by poll officers. We're still maintaining it for
a month in case poll officers would like to review the results.
Sometimes during this test some comments are not created (so far we
don't know why), but since all comments had the same text, we didn't
notice when checking the text of the comment was on the page.
When clicking the button "Search", the link "newest" is already present,
so capybara might click the "newest" link before the "Search" request is
finished, leading to unexpected results.
Checking the page to make sure the "Search" request has finished before
clicking the "newest" link solves the problem.
The `type: :feature` is automatically detected by RSpec because these
tests are inside the `spec/features` folder. Using `feature` re-adds a
`type: :feature` to these files, which will result in a conflict when we
upgrade to Rails 5.1's system tests.
Because of this change, we also need to change `background` to `before`
or else these tests will fail.
We're also adding a rubocop rule so we dont' accidentally add these
keywords again.
- Add :date_of_birth and :postal_code
- Only display new fields when aplication has configured the Remote
Census API and contains values for fields. Check with Setting Class
methods:
- force_presence_date_of_birth?
- force_presence_postal_code?
- Add new translations on SignatureSheet show page.
Changes:
-> "document number" to "sigantures"
-> "documents" to "users"
- Remove unused translations from the others yml
- Display help text and example text according to
remote census configuration:
Examples with expecte results:
* With remote census without :date_of_birth and :postal_code:
-> "To verify a user, your application needs: Document number"
-> "Required fields for each user must be separated by commas and
each user must be separated by semicolons."
-> "Example: 12345678Z; 87654321Y"
* With remote census with :date_of_birth required:
-> "To verify a user, your application needs: Document number,
Day of birth (dd/mm/yyyy)"
-> "Required fields for each user must be separated by commas and
each user must be separated by semicolons."
-> "Example: 12345678Z, 01/01/1980; 87654321Y, 01/02/1990"
* With remote census with :date_of_birth and :postal_code required:
-> "To verify a user, your application needs: Document number,
Day of birth (dd/mm/yyyy) and Postal Code"
-> "Required fields for each user must be separated by commas and
each user must be separated by semicolons."
-> "Example: 12345678Z, 01/01/1980, 28001; 87654321Y, 01/02/1990, 28002"
- Add the methods "parse_date_of_birth" and "parse_postal_code"
to recover the correct position of their values depending on the
configuration of the remote census.
- In the previous version, each signature was equivalent to a document
and we separated them by commas.
Now each signature may also need the fields birth date and postal code.
So we separated each signature with a semicolon and separated each of
its fields by commas.
Example old version: "12345678X, 87654321Y"
Example new version:
"12345678X, 31/12/1980, 28001; 87654321Y, 31/12/1981, 28002"
- Update translations:
"Write the numbers separated by commas (,)" to
"Write the numbers separated by semicolons (;)"
- Add :date_of_birth and :postal_code to Signature to allow send these
fields to CustomCensusAPI
- Add new model presence validates: Only validate :date_of_birth and
:postal_code presence when the application has configured Remote Census
and their alias fields has values.
This new functionality will allow to retrieve in the signature sheet
the document number, the date of birth and the postal code.
So we renamed :document_numbers to :required_fields_to_veriry to
clarify and adjust the name to its use.
- Only validate :date_of_birth and :postal_code presence when the application
has configured Custom Census and their alias fields has values.
- Only validate :year_of_birth presence when :date_of_birth is not configured
to send to Custom Census
- Add :date_of_birth and :postal_code
- Only display new fields when aplication has configured the
custom census API and contains alias values for fields. Add 2
class Setting methods to check this feature:
- force_presence_date_of_birth?
- force_presence_postal_code?
Regroup DocumentParser spec. Now they're duplicates in
local_census_specs and census_api_spec.
Move duplicate private method "dni?(document_type) from
LocalCensus and CensusAPI to DocumentParser
New RemoteCensusAPI allow receive :date_of_birth and
:postal_code and use in request to endpoint always that have
been configured on remote_census_configuration:
- Setting["remote_census.request.date_of_birth"]
- Setting["remote_census.request.postal_code"]
Add new params to CensusCaller 'call' method.
Create a new RemoteCensusAPI with the same functionality as
the old CensusAPI.
In the new RemoteCensusAPI both the request and the
processing of the response are made according to the
parameters defined in the "Remote Census Configuration"
page.
Same as old Census API we only consider document_type and
document_number on API request.
* request(document_type, document_number))
On "Remote Census Configuration" we allow to define request
structure on Setting["remote_census.request.structure"]
The information text of this field on "Remote Census Configuration" is:
> The "static" values of this request should be filled.
> Values related to Document Type, Document Number, Date of Birth and
Postal Code should be nil value.
An Example with the expected value for this field:
"{ request:
{
codigo_institucion: 1,
codigo_portal: 1,
codigo_usuario: 1,
documento: nil,
tipo_documento: nil,
codigo_idioma: '102',
nivel: '3'
}
}"
Where 'codigo_institucion', 'codigo_portal', 'codigo_usuario' and
'nivel' are "static" and filled in with their expected static values.
On the other hand 'documento' and 'tipo_documento' are fields
related with 'document_type','document_number' and filled in with
nil value.
On 'request' method we fill in thats 'nil values' with their
correct argument value. We can fill_in correctly because on
"Remote Census Configuration" we allow to define request path for
'document_type','document_number'
Setting["remote_census.request.document_type"]
Setting["remote_census.request.document_number"]
An Example with the expected values:
Setting["remote_census.request.document_type"] = "request.tipo_documento"
Setting["remote_census.request.document_number"] = "request.documento"
With this information with 'fill_in(structure, path_value, value)'
method, we can update structure with correct argument ('document_type',
'document_number', 'date_of_birth' and 'postal_code') value.
An Example of fill_in(structure, path_value, value) where:
structure = "{ request:
{
codigo_institucion: 1,
codigo_portal: 1,
codigo_usuario: 1,
documento: nil,
tipo_documento: nil,
codigo_idioma: '102',
nivel: '3'
}
}"
path_value = "request.documento"
value = "12345678X"
The result expected is:
{ request:
{
codigo_institucion: 1,
codigo_portal: 1,
codigo_usuario: 1,
documento: "12345678X",
tipo_documento: nil,
codigo_idioma: '102',
nivel: '3'
}
}
