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.
The reason for this rule is similar to dynamic factories: we want
dynamic dates to be evaluted relative to the current time, and not
relative to the moment the application was loaded.
Factory bot has stopped supporting dynamic attributes, and we'll have to
change all factories before upgrading.
In order to apply the rubocop rule, we need to bump rubocop-rspec to its
latest version.
These rules are now defined under `Style/`. However, we don't really use
them, so they add noise to the rubocop configuration file without
solving any issues we actually have.
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.
We forgot to add these changes to pull requests which were in
development before we upgraded to Rails 5.
We're also moving the rubocop rules to the basic files, so we're
notified when we inherit from `ActiveRecord::Base`.
Each time we were loading the seeds file, more web sections were
created.
On production it meant running `db:seeds` several times created the
records even if they already existed.
During the test, it meant 5 more records were created before every test,
so after ending a test run, thousands of records existed, making banner
tests very slow.
- 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'
}
}
Currently after each update of any Settings is redirected to the first
tab by default.
As this new tab remote_census_configuation has a lot of fields to fill
in it is a bit uncomfortable to have to go back to the tab after each
update.
- Add hidden field :tag to set current tag value
- After update add tag value to request.referer
- To avoid errors when partial call has not param :tag, add the "define?"
method on hidden_field value.
In these cases "setting" is the value expected by the new helper method for
everything to continue rendering in the usual way.
Note:
All the new calls to _setting_table partial will need add setting_name param.
