Produits Entr'ouvert » w.c.s.

Donc dites-moi si je vire le NIR et/ou le RIB du patch, d'autant plus qu'ils n'apparaissent pas dans le titre du ticket.

Ce serait bien de les conserver.

Nicolas Roche a écrit :

En fait seul l'algo du RIB est issu du document de la poste. Cet algo est rendu limite obsolète par celui du code IBAN.

Ce n'est pas l'algo qui est obsolète, c'est la notion de RIB ; ça n'existe plus. Aujourd'hui c'est l'IBAN qui est toujours demandé. Ca m'irait de ne pas avoir la validation de RIB, pour ne pas avoir à maintenir du code déjà mort (et ne plus jamais oser le retirer ensuite de peur qu'il soit utilisé quand même).

J'ai également repris la validation du numéro de sécurité sociale,
mais on peut se demander si c'est une bonne idée d'inciter à le saisir (dixit Thomas).

Je trouve effectivement ça assez malsain. Pour moi ce numéro n'est utile que dans une communication entre assuré et l'assurance santé. Mais bon, on peut ajouter ce validateur, à la rigueur ça nous fera une bonne façon de détecter son usage :-)

Mikaël Ates a écrit :

Ce serait bien de les conserver.

En fait y'a rien à conserver, car tout cela est nouveau. Je propose donc de ne pas ajouter la notion de RIB, ça sert à rien du tout. Et ok pour la validation du numéro de sécu.

• il faut vérifier que iban_key.isdigit()
• même chose pour string_value[13:].isdigit() (tu pourrais créer une variable nir_key = string_value[13:] pour gagner un poil de lisibilité de l'algo)

Ensuite, avant les calculs de clés, je pense qu'on pourrait vérifier d'autres choses sur le numéro SS (genre le premier chiffre ne peut pas être 0, le mois de naissance doit être entre 01 et 12, etc). Sur l'IBAN c'est plus délicat, mais j'ai le sentiment qu'on pourrait par exemple vérifier que les deux premiers codes sont un pays...? (mais où avoir la liste... no sé)

En tout cas il faudrait arriver à dire, quelque part, que ces vérifications sont juste "par calcul", on ne valide pas du tout que le numéro de sécu ou l'IBAN existe réellement, juste qu'il semble avoir une bonne tête... Peut-être qu'au lieu de

        ('iban', {'title': N_('IBAN Code'), 'function': 'validate_iban'}),

on pourrait plus explicitement déclarer :

        ('iban', {'title': N_('IBAN Code format'), 'function': 'validate_iban_format'}),

En fait si, mais pour les IBAN français uniquement (commençant par 'FRxx') on peut valider le RIB sous-jacent.

zut, c'était pour m'aligner sur l'existant

        ('zipcode-fr', {'title': N_('Zip Code (France)'), 'regex': '\d{5}'}),
        ('siren-fr', {'title': N_('SIREN Code (France)'), 'function': 'validate_siren'}),
        ('siret-fr', {'title': N_('SIRET Code (France)'), 'function': 'validate_siret'}),

Oui, il existe des codes postaux, des numéros SIRET et des numéros SIREN ; mais on ne dit pas "numéro IBAN" ou "code IBAN", on dit juste "IBAN" car le N est déjà "numéro". Même pour NIR.