#12444 closed (fixed)
Inline Forms in the admin interface are always required when using L10N
Reported by: | Owned by: | Jannis Leidel | |
---|---|---|---|
Component: | contrib.admin | Version: | dev |
Severity: | Keywords: | Internationalization | |
Cc: | Triage Stage: | Accepted | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
I'm having a few admin pages with inline forms. If I navigate to the admin change form which contains one or more inline forms and click "Save" I'm getting the error that some of the inline fields are required. But I doesn't changed something in the inline form. This action works without problems in a earlier version. I'm using the latest svn trunk at the moment
Attachments (1)
Change History (9)
comment:1 by , 15 years ago
Resolution: | → worksforme |
---|---|
Status: | new → closed |
comment:2 by , 15 years ago
Keywords: | Internationalization added |
---|---|
Resolution: | worksforme |
Status: | closed → reopened |
Summary: | Inline Forms in the admin interface are always required → Inline Forms in the admin interface are always required when using L10N |
@russellm: sorry, you're right.
So I dig into the problem and it seams that it has something todo with changeset:11964.
I am able to reproduce the problem with the following files
## models.py from django.db import models from datetime import datetime class Partner(models.Model): name = models.CharField(max_length=50) slug = models.SlugField() url = models.URLField(verify_exists=True) valid_from = models.DateTimeField(blank=True, default=datetime.now) valid_to = models.DateTimeField(blank=True, default=datetime(2999,12,31,23,59,59,0)) def __unicode__(self): return u'%s' % (self.name) class PartnerLogo(models.Model): partner = models.ForeignKey(Partner) slug = models.SlugField() logo = models.ImageField(upload_to='uploads/partner') valid_from = models.DateTimeField(blank=True, default=datetime.now) valid_to = models.DateTimeField(blank=True, default=datetime(2999,12,31,23,59,59,0)) def __unicode__(self): return u'%s - %s' % (self.partner, self.slug)
## admin.py from django.contrib import admin from myproject.myapp.models import Partner, PartnerLogo class PartnerLogoInline(admin.TabularInline): model = PartnerLogo class PartnerAdmin(admin.ModelAdmin): inlines = (PartnerLogoInline, ) admin.site.register(Partner, PartnerAdmin)
You have to change the following settings in your settings.py file to reproduce the problem
## settings.py USE_L10N = True LANGUAGE_CODE = 'de-at'
comment:3 by , 15 years ago
The problem could be in the method "BaseForm._get_changed_data" of "django/forms/forms.py"
If you are using L10N with the LANGUAGE_CODE = 'de-at' the date format is "d.m.Y H:i:s" (e.g: 27.12.2009 18:55:00).
The method "_get_changed_data" now compares the value of the widget "31.12.2999 23:59:59" with the initial date value "2999-12-31 23:59:59". And so the form contains changed values and the formset is invalid because the required fields are empty.
The initial value is the problem here. If django would translate the initial date value the the L10N date value the problem is solved, isn't it? The other question is why the widget stores/compares string values instead of date values?
comment:4 by , 15 years ago
Triage Stage: | Unreviewed → Accepted |
---|
comment:5 by , 15 years ago
Owner: | changed from | to
---|---|
Status: | reopened → new |
comment:6 by , 15 years ago
independent from the Internationalization changes there are users who have also the same issue with the DateTime fields in the admin:
http://www.hoboes.com/Mimsy/hacks/django-formsets-and-datetime-fields/
comment:7 by , 15 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
We're going to need a little bit more detail than this. A bug report isn't complete unless it contains complete instructions on how to reproduce the bug.
Marking worksforme because... well... it does. I don't doubt you are seeing a problem, though - so if you can provide a minimal example that demonstrates how to reproduce the problem, feel free to reopen the ticket with that extra detail.