DavidePastore / codice-fiscale

A PHP library to calculate and check the italian tax code (codice fiscale).
GNU General Public License v2.0
100 stars 19 forks source link

Provide detailed validity information #46

Open galzetta opened 4 years ago

galzetta commented 4 years ago

Currently the Checker only gives a true/false result. This is suboptimal in what is, I believe, one of the most common use cases for this library: validating the form of data for a user:

This library should provide an "extended validation" that tells you exactly which parts of the CF do not match.

For example a result value might be:

[
   "valid" => false,
   "errors" => [
       "name" => "'Antonio' does not match 'BCA'",
       "checksum" => "F is not the correct checksum letter for the given tax code"
    ]
]

This is just to give an idea of which information this library could easily provide and that I currently have to manually compute (making this library basically useless... If I have to compute by hand a more detailed validity check than what the library provides, why do I have to use this library in the first place?) in order to provide good feedback on the form.

Instead of complete error messages (which might be troublesome since that would mean troubles with translations) you could simply provide the information extracted from the tax code So instead of "Antonio" does not match 'BCA'" you just return "name" => ["tax_code_portion" => 'BCA', "tax_code_without_omocodia_portion" => 'BCA'] Now I can easily display in the form, under the name "Antonio" a message like "This name does not match the name portion of the tax code (currently 'BCA').

DavidePastore commented 4 years ago

Hi @galzetta . Thanks for opening this issue. This is a useful use case. I think that the validation could have an advanced way to work, returning something like an array for every portion (name, surname, etc...), and each portion is made by an associative array with the section, value and expected_value keys. Here you have to be sure to return an array for the expected_value, because there are n possibilities based on the omocodia level.

I don't think this is really hard to implement but I need to find free time to do it, so in the meantime you could open a pull request for it.