Project

General

Profile

Development #35013

Implémenter un filtre pour l'algorithme de Luhn

Added by Benjamin Dauvergne 5 months ago. Updated 4 months ago.

Status:
Solution déployée
Priority:
Normal
Target version:
-
Start date:
23 Jul 2019
Due date:
% Done:

0%

Patch proposed:
Yes
Planning:
No

Description

Cela permettra de valider les numéros de SIREN, SIRET, CB. (Pas le numéro de sécu qui utilise une autre formule, http://marlot.org/util/calcul-de-la-cle-nir.php).

0001-template-filter-for-Luhn-algorithm-35013.patch View (3.9 KB) Benjamin Dauvergne, 23 Jul 2019 05:42 PM

0001-template-filter-for-Luhn-algorithm-35013.patch View (3.15 KB) Benjamin Dauvergne, 24 Jul 2019 06:27 AM

0001-template-filter-for-Luhn-algorithm-35013.patch View (4.66 KB) Benjamin Dauvergne, 24 Jul 2019 01:49 PM

0002-template-filter-for-Luhn-algorithm-35013.patch View (4.01 KB) Benjamin Dauvergne, 24 Jul 2019 04:59 PM

0001-template-filter-cleaning-numbers-35013.patch View (2.12 KB) Benjamin Dauvergne, 24 Jul 2019 04:59 PM

0001-template-filter-for-Luhn-algorithm-35013.patch View (4.89 KB) Benjamin Dauvergne, 24 Jul 2019 05:13 PM

0001-fields-add-Luhn-algorithm-to-string-field-validation.patch View (4.77 KB) Benjamin Dauvergne, 10 Aug 2019 06:35 PM

0001-fields-add-Luhn-algorithm-to-string-field-validation.patch View (5.67 KB) Benjamin Dauvergne, 13 Aug 2019 03:10 PM


Related issues

Related to w.c.s. - Development #30849: Filtres Django pour la validation des champs Rejeté 22 Feb 2019
Related to w.c.s. - Development #11455: Évolution de l'option "regex de validation" Solution déployée 21 Jun 2016

Associated revisions

Revision b7cbff13 (diff)
Added by Benjamin Dauvergne 4 months ago

fields: add Luhn algorithm to string field validation (#35013)

History

#1 Updated by Frédéric Péters 5 months ago

#2 Updated by Benjamin Dauvergne 5 months ago

  • Assignee set to Benjamin Dauvergne

#3 Updated by Benjamin Dauvergne 5 months ago

Testé sur les numéros SIRET/SIREN d'EO et leurs variations fausses.

#4 Updated by Benjamin Dauvergne 5 months ago

#5 Updated by Frédéric Péters 5 months ago

Les changements six.text_type ne sont pas souhaités ici (et |luhn lui-même ne devrait pas utiliser ça; quand l'heure sera venue de s'occuper des caractères/unicode dans le passage à python 3, je préférerai ne pas devoir m'interroger sur le pourquoi le code serait différent ici).

Il faudra un nom plus explicite que |luhn, |is_valid_xxx, en multipliant les _xxx, ou plus conservateur |has_valid_xxx_control ?

Dans #30849 un frein avait été mis sur ces filtres, en pointant plutôt #11455 (de mon côté je peux laisser glisser ça).

#6 Updated by Benjamin Dauvergne 5 months ago

Remarques intégrés, is_valid_luhn (non exposé) exposé sous les deux noms is_valid_siret et is_valid_siren.

#7 Updated by Benjamin Dauvergne 5 months ago

Frédéric Péters a écrit :

Dans #30849 un frein avait été mis sur ces filtres, en pointant plutôt #11455 (de mon côté je peux laisser glisser ça).

Je pense qu'on peut vivre avec les deux, il sera toujours temps au niveau documentation de favoriser l'un ou l'autre.

#8 Updated by Thomas Noël 5 months ago

Pour is_valid_siren et siret, tu ne peux pas ajouter une vérification de la longueur ? Et, pendant qu'on y est, laisser passer tous les SIRET de la Poste (356000000xxxxx, comme tu as remarqué https://fr.wikipedia.org/wiki/Formule_de_Luhn#Cas_particulier)

#10 Updated by Thomas Noël 5 months ago

Je me demande si on devrait pas exposer clean_number et si les gens veulent valider des trucs bizarres (non validés par une regex genre \d+) alors ils doivent faire un form_var_truc|clean_number|is_valid_siren

Dans l'idée que si ensuite tu dois appeler un webservice avec le siren en argument, ça se fera avec form_var_truc|clean_number (parce que si on n'a pas le clean_number ça sera pas marrant)

#11 Updated by Benjamin Dauvergne 5 months ago

Thomas Noël a écrit :

Je me demande si on devrait pas exposer clean_number et si les gens veulent valider des trucs bizarres (non validés par une regex genre \d+) alors ils doivent faire un form_var_truc|clean_number|is_valid_siren

Dans l'idée que si ensuite tu dois appeler un webservice avec le siren en argument, ça se fera avec form_var_truc|clean_number (parce que si on n'a pas le clean_number ça sera pas marrant)

Ok, mais c'est pour ça que je n'aime pas les conditions tels qu'elles sont faites, dans un outil de formulaire on doit valider et normaliser en même temps (clairement on devrait systématiquement faire des strip() par exemple, virer les caractères unicode non graphiques).

#12 Updated by Thomas Noël 5 months ago

Benjamin Dauvergne a écrit :

Ok, mais c'est pour ça que je n'aime pas les conditions tels qu'elles sont faites, dans un outil de formulaire on doit valider et normaliser en même temps (clairement on devrait systématiquement faire des strip() par exemple, virer les caractères unicode non graphiques).

Je sais et je suis d'accord mais ça c'est plutôt #11455 (étendre la notion de validation, et pourquoi pas y inclure un clean ensuite)... on n'en est pas là.

#14 Updated by Benjamin Dauvergne 5 months ago

Dernière version je l'espère, en renvoyant soit '' soit la chaîne valide et normalisée, les validateurs servent aussi à normaliser, ça évite d'exposer un clean_number un peu moche.

#15 Updated by Frédéric Péters 5 months ago

Vraiment je préfère que les is_whatever renvoient vrai/faux.

s/couting/counting/ dans un commentaire. Pas d'espace avant : en anglais (commentaires "special case : La Poste"). Pour la partie La Poste, être complet et coder la vérification supplémentaire ("somme simple des chiffres du SIRET est un multiple de cinq") pour le SIRET ?

#16 Updated by Benjamin Dauvergne 5 months ago

Frédéric Péters a écrit :

Vraiment je préfère que les is_whatever renvoient vrai/faux.

De mon coté je n'ai pas envie d'exposer clean_number c'est pas documentable/utile. Donc un clean_siren, clean_siret en plus ?

s/couting/counting/ dans un commentaire. Pas d'espace avant : en anglais (commentaires "special case : La Poste"). Pour la partie La Poste, être complet et coder la vérification supplémentaire ("somme simple des chiffres du SIRET est un multiple de cinq") pour le SIRET ?

Ok.

#17 Updated by Frédéric Péters 5 months ago

  • Subject changed from Implémenter un filtre pour l'agorithme de Luhn to Implémenter un filtre pour l'algorithme de Luhn

De mon coté je n'ai pas envie d'exposer clean_number c'est pas documentable/utile. Donc un clean_siren, clean_siret en plus ?

Je dirais que non, qu'il faut introduire le moins de choses ici, juste la validation, que le format doit pour le moment être forcé par une regex sur le champ, que plus avancé ça devra être #11455.

#20 Updated by Thomas Noël 4 months ago

Il faut vérifier que les int(x) vont pas planter si x n'est pas un chiffre, genre là avec ce test :

--- a/tests/test_widgets.py
+++ b/tests/test_widgets.py
@@ -668,6 +668,12 @@ def test_wcsextrastringwidget_siret_validation():
     mock_form_submission(req, widget, {'test': '44317013900037'})
     assert widget.has_error()

+    # failing case
+    widget = WcsExtraStringWidget('test', value='foo', required=False)
+    widget.field = fakefield
+    mock_form_submission(req, widget, {'test': 'ABC17013900037'})
+    assert widget.has_error()
+

ça fait boum :

>               checksum += sum(int(y) for y in str(2 * int(x)))
E               ValueError: invalid literal for int() with base 10: 'C'

J'ai envoyé un commit dans la branche qui fait du isdigit()... à merger avec ton patch si tu es ok, puis pousser le patch résultat.

#21 Updated by Benjamin Dauvergne 4 months ago

Voilà mergé pushé, yapuka ack.

#22 Updated by Benjamin Dauvergne 4 months ago

  • Status changed from Solution proposée to Résolu (à déployer)
commit b7cbff134c933b5cbe9808d3e9a305ee255c35c3
Author: Benjamin Dauvergne <bdauvergne@entrouvert.com>
Date:   Tue Jul 23 17:40:14 2019 +0200

    fields: add Luhn algorithm to string field validation (#35013)

#23 Updated by Frédéric Péters 4 months ago

  • Status changed from Résolu (à déployer) to Solution déployée

Also available in: Atom PDF