#14593 closed (fixed)
CZBirthNumberField expects two arguments to clean()
Reported by: | Idan Gazit | Owned by: | Idan Gazit |
---|---|---|---|
Component: | contrib.localflavor | Version: | 1.2 |
Severity: | Keywords: | ||
Cc: | Triage Stage: | Accepted | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
See cz/forms.py, line 53. The field's clean() takes two arguments, but clean() should only take one (value).
From looking at the source, it seems that the conditional block on L72 can simply be excised along with the invalid_gender error message. Without explicit knowledge of the associated gender, it looks like the additional gender-based validation logic isn't possible.
Attachments (2)
Change History (11)
comment:1 by , 14 years ago
Status: | new → assigned |
---|
comment:2 by , 14 years ago
milestone: | → 1.3 |
---|---|
Triage Stage: | Unreviewed → Accepted |
gender is not necessary to determine whether a birth number is valid, it just validates some further restrictions and shouldn't be part of the field's validation. It should remain for some time with a deprecation warning and will be removed in the future (probably replaced by a method that anybody can call manually from their form.clean for convenience).
comment:3 by , 14 years ago
Above patch issues the agreed-upon warning, new unittest updated to silence said warning: https://github.com/idangazit/django/compare/cz_clean_fix#diff-1
comment:4 by , 14 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
comment:5 by , 14 years ago
This needs to be a either PendingDeprecationWarning (and noted in the deprecation docs) or a backwards incompatible change (and noted in the release notes).
comment:6 by , 14 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
Oops, my bad. Preparing new patch with proper warning.
by , 14 years ago
Attachment: | 14593_PendingDeprecationWarning.diff added |
---|
Changes issued warning to PendingDeprecationWarning
comment:7 by , 14 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
Looking at this some more, it seems like a nice solution would be to use a ComboField, consisting of two charfields: one for the number, one for the gender. Most of the validation that takes place today would happen on the ID number field. The gender charfield would simply validate that the value is either "m" or "f". The combofield's validation would take care of the interaction between the two.
Talked this idea over with alex_gaynor on IRC, he liked it, generally.