- 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?
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
* Create admin controller and routes
* Add pagination
* Add search by document_number
* Add EN and ES translations
* Add index specs
* Add missing model specs
* Add to menu as a Settings sub-options
* Add translations for EN and ES locales
* Activate menu sub-option when user is at any LocalCensusRecords page
During any translatable resource edit, if you remove all translations
you will be redirected to same form with errors showing you one of
persisted but marked to destroy translations, without this patch
_destroy field value wil be true and you will no able to persist without
re-addding the same language through translation interface.
When a translation not exists yet we can mark them all for destruction
by default. They already should be initialized correctly from database
or via nested attributes.
Now we take into consideration locales persisted but marked for
destruction to complete some logic and to be able to show best
translations on different situations.
In order to not allow users to remove all persited
translations from any resource. A few exceptions were
added:
* Does not apply to globalizable models without
translatable attributes required
* Make a copy of main model error on current translations to be more realistic
