Introduce a specialized Fiscal Code

[fpietrosanti]

It should be implemented a field of type Identity/Fiscal Code.

the field should allow the configuration/selection of the alghorithm to be used for validation (e.g. italian fiscal code validation).

Original ticket: Validazione codice fiscale front-end Dovrà essere effettuata una validazione del codice fiscale all’atto dell’inserimento della identità nel formulario di segnalazione, tenendo in considerazione le particolari situazioni di casi di omocodia.

[marceloomens]

Just a suggestion, couldn't you have a general purpose 'regex validated field'? Then you'd just need to develop a regular expression for each case with domain specific validation requirements.

[evilaliv3]

@marceloomens each fied input already have the possibility to define a manual regexp :)

with this ticket we are simply thinking to implement a really specific field with specialized validation.

[marceloomens]

Ah, okay, just ignore my comment then :fearful:

[vodkina]

Assigned to Bruno

[NSkelsey]

I came up with a solution to this problem that keeps the number of fields down.

Instead of adding a new field type for each text based field that somebody might want to use, utilize the regular expression validation field in a different way.

This way if an admin needs another structured text field, we can just add an item to this list without adding to field types that everyone must wade through. The image below should show how easy this makes it to add these kinds of fields as well.

[evilaliv3]

@NSkelsey nice patch nick, really simply and effective.

any as you are identifying, relying on regexps and still giving the user visibility of the regexp even for suggested new user types is not good anyhow this would remain acceptable. there is only one reason why it would be better to not implemted it like this: specialized fields would need to be subject to statistics and searches, and so with this proposed implementation it won't be possible to look for answers that corresponds to a SSN except from looking for the regexp set.

given the work already done for having stats but also specialized fields i would suggest in the general to go for this different road; tell me your feedback ! :)

• globaleaks has basic simple fields (inputbox, textareads, checkboxes)... https://github.com/globaleaks/GlobaLeaks/blob/master/client/app/views/admin/add_field.html#L13
• among different fields the above follow in the general basic field of type 'inputbox'
• since a few globaleaks allows to compose basic fields to create special fields that can handle custom logic, custom, validator etc (e.g here you find the whistleblower identity_field https://github.com/globaleaks/GlobaLeaks/blob/devel/client/app/data_src/fields/whistleblower_identity.json) and each of this field is one of the basic fields (a fieldgroup or a basic other field, with assigned some properties and identified by a 'key', e.g. 'whistleblower_identity'

the suggested pattern i would recommend given the design we have currently identified is:

• create this new specialized fields in https://github.com/globaleaks/GlobaLeaks/blob/devel/client/app/data_src/fields/whistleblower_identity.js
• each of them should be a new field, with a name (e.g. SSN), a key (e.g. 'ssn') and and an automatically written regexp.

this way the will bacame fields reusable to composin other fields using the fieldgroup hierarchy and it will be possible to look in the database for all the answer to fields of kind key='ssn' even if this fields will be used inside the whistleblower identity field or the involved person field.

this way creating a type it will be possible eventually to hook a particular field type, assigning it a template (https://github.com/globaleaks/GlobaLeaks/blob/devel/client/app/views/submission/fields/whistleblower_identity.html) a specialized javascript function for validation and so on.

what do you think?

[NSkelsey]

I see that this is a better approach given the way the system actually works -- not how I think it works.

At the moment, the automated upload of questionnaires is not working on my deployment (with my HEAD pointed at devel). So I cannot import, use, or interact with whistleblower_identity.json. That being said, why would these new fields live in whistleblower_identity.json and not some other json file?

[evilaliv3]

ah you are correct @NSkelsey.

i was intending in the directory https://github.com/globaleaks/GlobaLeaks/blob/devel/client/app/data_src/fields/ where the whistleblower_identity.json file and we should then implement a loader of them so that they are loaded in an ordered way that would allow to build one on top of others

[br1n0]

Hi, I'am Bruno, I wrote a fiscal code directive that extract the omocodia number is here: https://github.com/br1n0/codice_fiscale_validator/tree/master

The Agenzia delle Entrate is the bureau that is entitled of fiscal codes of peaple living in italy. Each code is generated using some letter of surname and name, date and place of birth. Two or more codes can point to the same string beacuse of its data, in this case called omocodia, this breau change the code progressively replacing numbers with letter from right to left. Because there are 7 numbers, and each one could be replaced or not, the maximum multiplicity of the same code is 128!. The omocodia happen quite rarely around 1400 times at year, but distributed with different fiscal codes. Let me know your impressions.

Ciao