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.
When we reuse the partial '_setting_table' to render the 3 types
of remote census settings, we need customize setting_name key by
default to clarify the information to render.
- Add new param 'setting_name' to partial '_setting_table'
- Create new setting helper method to use new setting_name param
to display a more clarify setting name on table.
According to the feature setting["remote_census"]:
- Display info to enable tab when remote_census feature is disabled.
- Display all related setting to remote_census when feature is enabled
- Render remote census configuration content on settings index.
- Update type method from Setting
On Admin::SettingsController#index we are using 'all_settings' to
group all settings by 'type' method.
'type' method return the first part of key when split by '.'
To allow use by example: all_settings["remote_census.general"]
and recover only settings related with this key we have added new
'elsif' on 'type' method.
After adding new namespace `admin/local_census_records` cancancan
`load_and_authorize` method started to crash because it was getting
confused when loading and authorizing controller resources. Specifying
class to load and authorize solves this situation.
This model without database allow us to validate incoming file extension and
headers and also does the following during importation process:
* Ignore empty rows
* Classifiy rows in two groups: created_records, invalid_records
