Opened 6 years ago

Closed 6 years ago

Last modified 4 years ago

#12444 closed (fixed)

Inline Forms in the admin interface are always required when using L10N

Reported by: Bernd Schlapsi <brot@…> Owned by: jezdez
Component: contrib.admin Version: master
Severity: Keywords: Internationalization
Cc: Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

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)

screenshot-12444.png (67.5 KB) - added by Bernd Schlapsi <brot@…> 6 years ago.
Screenshot of the admin error

Download all attachments as: .zip

Change History (9)

comment:1 Changed 6 years ago by russellm

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Resolution set to worksforme
  • Status changed from new to 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.

comment:2 Changed 6 years ago by Bernd Schlapsi <brot@…>

  • Keywords Internationalization added
  • Resolution worksforme deleted
  • Status changed from closed to reopened
  • Summary changed from Inline Forms in the admin interface are always required to 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'

Changed 6 years ago by Bernd Schlapsi <brot@…>

Screenshot of the admin error

comment:3 Changed 6 years ago by Bernd Schlapsi <brot@…>

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 Changed 6 years ago by jezdez

  • Triage Stage changed from Unreviewed to Accepted

comment:5 Changed 6 years ago by jezdez

  • Owner changed from nobody to jezdez
  • Status changed from reopened to new

comment:6 Changed 6 years ago by Bernd Schlapsi <brot@…>

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 Changed 6 years ago by jezdez

  • Resolution set to fixed
  • Status changed from new to closed

(In [12029]) Fixed #12444 - Date based widgets now correctly handle input values when using locale-aware formatting. Also fixes #7656.

comment:14 Changed 4 years ago by jacob

  • milestone 1.2 deleted

Milestone 1.2 deleted

Note: See TracTickets for help on using tickets.
Back to Top