[Django] #22878: DateTimeField auto_now_add, auto_now & CreateView
Django
-------------------------------+--------------------
Reporter: foxmask | Owner: nobody
Type: Bug | Status: new
Component: Uncategorized | Version: 1.6
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------+--------------------
Hi,
I think I spotted a bug with auto_now_add and auto_now in the models.
Here are the details to reproduce it
'''in a models.py'''
{{{#!python
class Foobar(models.Model):
created = models.DateTimeField(auto_now_add=True)
}}}
'''in a views.py'''
{{{#!python
class FoobarCreateView(CreateView):
model = Foobar
fields = [ 'created' ]
}}}
will produce the error :
{{{
Unknown field(s) created specified for Foobar
}}}
To try to trakc the error, I put a "print fields" line 285 of the file
django/forms/models.py in the class ModelFormMetaclass just before
{{{#!python
# make sure opts.fields doesn't specify an invalid field
none_model_fields = [k for k, v in six.iteritems(fields) if
not v]
}}}
which gives :
{{{
{u'created': None}
}}}
if I drop the auto_now_add from the model I get :
{{{
u'created': <django.forms.fields.DateTimeField object at 0x23bca10>
}}}
and get no error
The exact same behavior occurs with '''auto_now'''
Regards
--
Ticket URL: <https://code.djangoproject.com/ticket/22878>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: foxmask | Owner: nobody
Type: Bug | Status: closed
Component: Uncategorized | Version: 1.6
Severity: Normal | Resolution: invalid
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 timo):
* status: new => closed
* needs_better_patch: => 0
* resolution: => invalid
* needs_tests: => 0
* needs_docs: => 0
Comment:
[https://docs.djangoproject.com/en/dev/ref/models/fields/#datefield As
documented], "As currently implemented, setting auto_now or auto_now_add
to True will cause the field to have editable=False and blank=True set."
Since the field isn't editable, you can't add it to a form.
--
Ticket URL: <https://code.djangoproject.com/ticket/22878#comment:1>
Django
Reporter: foxmask | Owner: nobody
Type: Bug | Status: closed
Component: Uncategorized | Version: 1.6
Severity: Normal | Resolution: invalid
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by foxmask):
thank you - i didnt notice this subtility
--
Ticket URL: <https://code.djangoproject.com/ticket/22878#comment:2>
Django
Reporter: FoxMaSk | Owner: nobody
Type: Bug | Status: closed
Component: Uncategorized | Version: 1.6
Severity: Normal | Resolution: invalid
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Daniel Hahler):
It can be useful to use `editable=True` to have it included in admin forms
by default (where the whole form might be readonly then).
If the current behavior is kept it should probably throw a `TypeError` if
`editable=True` or `blank=False´ is passed instead of silently
overriding/ignoring it, which causes confusion e.g. with django-extensions
(https://github.com/django-extensions/django-extensions/issues/745).
--
Ticket URL: <https://code.djangoproject.com/ticket/22878#comment:3>