Projet

Général

Profil

Development #35013

Implémenter un filtre pour l'algorithme de Luhn

Ajouté par Benjamin Dauvergne il y a plus de 4 ans. Mis à jour il y a plus de 4 ans.

Statut:
Fermé
Priorité:
Normal
Assigné à:
Version cible:
-
Début:
23 juillet 2019
Echéance:
% réalisé:

0%

Temps estimé:
Patch proposed:
Oui
Planning:
Non

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).


Fichiers


Demandes liées

Lié à w.c.s. - Development #30849: Filtres Django pour la validation des champsRejeté22 février 2019

Actions
Lié à w.c.s. - Development #11455: Évolution de l'option "regex de validation"Fermé21 juin 2016

Actions

Révisions associées

Révision b7cbff13 (diff)
Ajouté par Benjamin Dauvergne il y a plus de 4 ans

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

Historique

#1

Mis à jour par Frédéric Péters il y a plus de 4 ans

#2

Mis à jour par Benjamin Dauvergne il y a plus de 4 ans

  • Assigné à mis à Benjamin Dauvergne
#3

Mis à jour par Benjamin Dauvergne il y a plus de 4 ans

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

#4

Mis à jour par Benjamin Dauvergne il y a plus de 4 ans

#5

Mis à jour par Frédéric Péters il y a plus de 4 ans

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

Mis à jour par Benjamin Dauvergne il y a plus de 4 ans

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

#7

Mis à jour par Benjamin Dauvergne il y a plus de 4 ans

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

Mis à jour par Thomas Noël il y a plus de 4 ans

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

Mis à jour par Thomas Noël il y a plus de 4 ans

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

Mis à jour par Benjamin Dauvergne il y a plus de 4 ans

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

Mis à jour par Thomas Noël il y a plus de 4 ans

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

Mis à jour par Benjamin Dauvergne il y a plus de 4 ans

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

Mis à jour par Frédéric Péters il y a plus de 4 ans

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

Mis à jour par Benjamin Dauvergne il y a plus de 4 ans

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

Mis à jour par Frédéric Péters il y a plus de 4 ans

  • Sujet changé de Implémenter un filtre pour l'agorithme de Luhn à 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

Mis à jour par Thomas Noël il y a plus de 4 ans

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.

#22

Mis à jour par Benjamin Dauvergne il y a plus de 4 ans

  • Statut changé de Solution proposée à 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

Mis à jour par Frédéric Péters il y a plus de 4 ans

  • Statut changé de Résolu (à déployer) à Solution déployée

Formats disponibles : Atom PDF