[Django] #22654: DecimalField and DECIMAL_SEPARATOR (in admin)
Django
-------------------------------+--------------------
Reporter: matija@… | Owner: nobody
Type: Uncategorized | Status: new
Component: Uncategorized | Version: 1.6
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------+--------------------
DecimalField with following settings:
LANGUAGE_CODE = 'hr-hr'
TIME_ZONE = 'CET'
USE_I18N = True
USE_L10N = False
USE_TZ = False
DATE_FORMAT = 'd.m.Y.'
DATE_INPUT_FORMATS = ('%d.%m.%Y.', '%d.%m.%Y', '%Y-%m-%d')
DECIMAL_SEPARATOR = ','
Correctly shows Decimal field in admin, but raises validation error.
As most of our customers do not set their preferences to Croatian, and we
need to show Croatian locale for all users. So with settings above, things
sdhould work.
Tried in 1.6 and 1.7.
In order to reproduce, all you need is a single model with a DecimalField,
registered in Admin. And the above settings. Input any non-integer value
and press save_and_continue_editing. If you encounter no errors, press it
again. Now it will show an error.
I added a new ticked because related ones were closed years ago.
--
Ticket URL: <https://code.djangoproject.com/ticket/22654>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: matija@… | Owner: sabinemaennel
Type: Uncategorized | Status: assigned
Component: Uncategorized | Version: 1.6
Severity: Normal | Resolution:
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by sabinemaennel):
* owner: nobody => sabinemaennel
* needs_docs: => 0
* status: new => assigned
* needs_tests: => 0
* needs_better_patch: => 0
--
Ticket URL: <https://code.djangoproject.com/ticket/22654#comment:1>
Django
Reporter: matija@… | Owner: sabinemaennel
Type: Uncategorized | Status: assigned
Severity: Normal | Resolution:
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by sabinemaennel):
I think this is clearly an error. I tested it with a decimal field. The
settings `DECIMAL_SEPARATOR = ','` is taken into account when the field is
shown in the admin, but when validating the field only input with a `.` as
delimiter is accepted. The field validation needs to be adapted to the
delimiter given in the settings as well. I tested this with the new 1.7
Django.
--
Ticket URL: <https://code.djangoproject.com/ticket/22654#comment:2>
Django
Reporter: matija@… | Owner:
Type: Bug | Status: new
Component: Forms | Version: 1.6
Severity: Normal | Resolution:
Keywords: | Triage Stage: Someday/Maybe
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by sabinemaennel):
* status: assigned => new
* type: Uncategorized => Bug
* component: Uncategorized => Forms
* owner: sabinemaennel =>
* stage: Unreviewed => Someday/Maybe
Comment:
This is actually an HTML5 Problem. The admin form for the input of a
number uses the following HTML5 statement:
`<input id="id_decimal_number" name="..." step="0.01" type="number" />`.
`step=` in HTML5 can only be defined that way with a `.`as delimiter. Then
the browser will show it on the screen according to local browser
settings. Mine showed it as a dot, but I read on stackoverflow, that some
other users see it with a
comma.[http://stackoverflow.com/questions/6178332/force-decimal-point-
instead-of-comma-in-html5-number-input-client-side].
I think HTML5 will develop further and this behaviour can be corrected via
a Javascript-Library-Use in the meantime. I am not sure what to do with
this bug. I would probably place it outside the influence of Django even
though I can see that it is annoying. Django decided to use HTML5 for its
forms and this is due to the actual state of HTML5. I feel Django is not
responsible to correct HTML5 behaviour, but I would really like to know
the opinion of some more experienced Django contributers on this. So I am
handing the ticket back.
--
Ticket URL: <https://code.djangoproject.com/ticket/22654#comment:3>
Django
Reporter: matija@… | Owner:
Type: Bug | Status: new
Component: Forms | Version: 1.6
Severity: Normal | Resolution:
Keywords: | Triage Stage: Someday/Maybe
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by matija@…):
ACTUALLY this is DJANGO problem. Remove type="number". The ValidationError
on Django side is the issue, not browser side.
--
Ticket URL: <https://code.djangoproject.com/ticket/22654#comment:4>
Django
Reporter: matija@… | Owner:
Type: Bug | Status: new
Component: Forms | Version: 1.6
Severity: Normal | Resolution:
Keywords: | Triage Stage: Someday/Maybe
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by claudep):
Could you please give us a little more information: what is displayed
exactly in your widget (dot or comma), what value is actually posted to
the request, what validation error message do you get ?
--
Ticket URL: <https://code.djangoproject.com/ticket/22654#comment:5>
Django
Reporter: matija@… | Owner:
Type: Bug | Status: new
Component: Forms | Version: 1.6
Severity: Normal | Resolution:
Keywords: | Triage Stage: Someday/Maybe
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by anonymous):
Sure. With settings above, everything works as excpected, comma is shown,
but when I try to save, ValidationError is shown.
Error is, of course, in croatian, but it comes back to this:
invalid': _('Enter a number.'),
https://github.com/django/django/blob/master/django/forms/fields.py
If L10N is set tu True, everything actually works. The problem is in this
line. When self.localize is set to true, this works fine, but this should
be run when localization is off, but DECIMAL_SEPARATOR is anything other
than '.'. Would anything break if this "if" is simple removed?
if self.localize:
value = formats.sanitize_separators(value)
--
Ticket URL: <https://code.djangoproject.com/ticket/22654#comment:6>
Django
Reporter: matija@… | Owner:
Type: Bug | Status: new
Component: Forms | Version: 1.6
Severity: Normal | Resolution:
Keywords: | Triage Stage: Someday/Maybe
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by claudep):
So do you really get a comma in the widget value, even when L10N is off?
Is that dot-to-comma conversion done by the browser itself (AFAIK Django
is sending a dot in the HTML source)?
--
Ticket URL: <https://code.djangoproject.com/ticket/22654#comment:7>
Django
Reporter: matija@… | Owner:
Type: Bug | Status: new
Component: Forms | Version: 1.6
Severity: Normal | Resolution:
Keywords: | Triage Stage: Someday/Maybe
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by matija@…):
Ok, I got it.
This is definitely a design problem. Date/Datetime settings work
regardless of L10N, and Decimal-related only when L10N is set.
(sanitize_separators checks L10N first).
These two things are closely related and should follow the same logic.
IMHO the key question is should Dates AND Dacimals (and other L10N-related
stuff) follow DATE_FORMATS, DECIMAL_SEPARATOR and other L10N related
setting when L10N is False. The answer should be Yes or No for all of
them.
Yes, I do get a comma in the output. However, on re-saving, errors are
shown. If I replace it with a dot, it works, and comma is shown in
response.
--
Ticket URL: <https://code.djangoproject.com/ticket/22654#comment:8>
Django
Reporter: matija@… | Owner:
Type: Bug | Status: new
Component: Forms | Version: 1.6
Severity: Normal | Resolution:
Keywords: | Triage Stage: Someday/Maybe
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by anonymous):
Sorry, no comma with the default widget. However, with TextInput, it is
there.
This design problem still exists, at least docs should be updated
indicating what works when. This definitely does not work as one may
expect.
However, there SHOULD be a way to work with a fixed locale other than en-
us ;)
--
Ticket URL: <https://code.djangoproject.com/ticket/22654#comment:9>
Django
Reporter: matija@… | Owner:
Type: Bug | Status: new
Component: Forms | Version: 1.6
Severity: Normal | Resolution:
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by claudep):
* stage: Someday/Maybe => Accepted
Comment:
I think we should be as much as flexible as possible on the input side of
things (potentially removing the `is_localize`/`USE_L10N` tests).
However, it's a bit tricky when you get ambiguous inputs like `24,637`...
--
Ticket URL: <https://code.djangoproject.com/ticket/22654#comment:10>
Django
Reporter: matija@… | Owner:
Type: Bug | Status: new
Component: Forms | Version: 1.6
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by matija):
Well, it is clear that nothing should be done quickly. The whole thing
seems a bit messy. I did test many different configs and mostly got
unexpected results, either in Decimal or Date.
Id say this is 1.8 issue.
My deadline is approaching and I already spent too much time on this,
right now I have a middleware forcing locale I want and L10N turned on and
formats ... works fine.
Ill do an update when I find time to re-test from scratch (weekend
perhaps).
--
Ticket URL: <https://code.djangoproject.com/ticket/22654#comment:11>
Django
Reporter: matija@… | Owner: (none)
Type: Bug | Status: new
Component: Forms | Version: 1.6
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by tonnzor):
I have the same issue.
It is very easy to reproduce:
{{{#!python
# in settings.py
LANGUAGES = (('de', 'German'),)
LANGUAGE_CODE = 'de'
# in models.py
CHOICES = (
(Decimal('0.25'), '0.25d'),
(Decimal('0.50'), '0.5d'),
(Decimal('0.75'), '0.75d'),
(Decimal('1.00'), '1d'),
)
class Number(models.Model):
num = models.DecimalField(max_digits=3, decimal_places=2,
choices=CHOICES)
# in admin.py
@admin.register(Number)
class NumberAdmin(admin.ModelAdmin):
pass
}}}
If you go to admin and try to save it would give you a validation error.
Reason is that it generates following HTML -- see comma in value:
{{{
<select name="num" id="id_num">
<option value="0,25">0.25d</option>
<option value="0,50">0.5d</option>
<option value="0,75">0.75d</option>
<option value="1,00" selected="">1d</option>
</select>
}}}
But when you provide choices -- it would be TypedChoiceField. Somehow it
cannot handle comma in value and convert it correctly to decimal.
Interesting here if you drop choices. Then DecimalField would be used and
everything would work -- you would use comma in the field.
BUT if you check HTML, it would use dots internally:
{{{
<input name="num" value="0.25" step="0.01" required="" id="id_work_days"
type="number">
}}}
Also, POST request would send dot-separated value, not comma (though comma
is shown in UI).
It seems if we force TypedChoiceField generate dot-separated HTML for
Decimals despite of localization and i18n -- it would fix the issue.
--
Ticket URL: <https://code.djangoproject.com/ticket/22654#comment:12>
Django
Reporter: matija@… | Owner: (none)
Type: Bug | Status: new
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by tonnzor):
* version: 1.6 => 1.11
Comment:
It is still present in Django 1.11rc1
--
Ticket URL: <https://code.djangoproject.com/ticket/22654#comment:13>
Django
Reporter: matija@… | Owner: (none)
Type: Bug | Status: new
Component: Forms | Version: 1.11
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by tonnzor):
* cc: tonnzor (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/22654#comment:14>
Django
Reporter: matija@… | Owner: (none)
Type: Bug | Status: new
Component: Forms | Version: 1.11
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by inoks):
Replying to [comment:13 tonnzor]:
> It is still present in Django 1.11rc1
Also present in Django 1.11 release
--
Ticket URL: <https://code.djangoproject.com/ticket/22654#comment:15>
Django
Reporter: matija@… | Owner: Raphael Michel
Type: Bug | Status: assigned
Component: Forms | Version: 1.11
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Raphael Michel):
* owner: (none) => Raphael Michel
* status: new => assigned
--
Ticket URL: <https://code.djangoproject.com/ticket/22654#comment:16>
Django
Reporter: matija@… | Owner: Raphael Michel
Type: Bug | Status: assigned
Component: Forms | Version: 1.11
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Raphael Michel):
* has_patch: 0 => 1
Comment:
https://github.com/django/django/pull/8312
--
Ticket URL: <https://code.djangoproject.com/ticket/22654#comment:17>
Django
Reporter: matija@… | Owner: Raphael Michel
Component: Forms | Version: 1.11
Severity: Normal | Resolution: fixed
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Florian Apolloner <apollo13@…>):
* status: assigned => closed
* resolution: => fixed
Comment:
In [changeset:"bde814142a933bd96c3fa54a64cb1f74a575bb38" bde81414]:
{{{
#!CommitTicketReference repository=""
revision="bde814142a933bd96c3fa54a64cb1f74a575bb38"
Fixed #22654 -- Broken decimal validation
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/22654#comment:18>
Django
Reporter: matija@… | Owner: Raphael Michel
Type: Bug | Status: closed
Component: Forms | Version: 1.11
Severity: Normal | Resolution: fixed
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Claude Paroz):
I think this change warrants a note in backwards incompatibilities:
For example, with following settings:
{{{
LANGUAGE_CODE='de'
USE_L10N=False
USE_THOUSAND_SEPARATOR=True
}}}
Before: "1.345" => 1.345
After: "1.345" => 1345
--
Ticket URL: <https://code.djangoproject.com/ticket/22654#comment:19>
Django
Reporter: matija@… | Owner: Raphael Michel
Type: Bug | Status: closed
Component: Forms | Version: 1.11
Severity: Normal | Resolution: fixed
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Tim Graham <timograham@…>):
In [changeset:"504e7782fef74cb78768092780a3476866379c21" 504e778]:
{{{
#!CommitTicketReference repository=""
revision="504e7782fef74cb78768092780a3476866379c21"
Refs #22654 -- Added additional tests and amended release note.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/22654#comment:20>