Re: field cannot be specified for model form as it is a non-editable field

On Monday 08 May 2017 08:18:46 Tim Graham wrote:

> If you have a patch in mind, I'll take a look, however, considering

> there's talk of deprecating those options [0] in favor the

> alternatives that the docs mentioned, I don't think we should spend

> much time reconsidering their semantics.

 

Interesting read. No one stepped up in 3 years though and for good reason: The cure is worse then the disease IMHO.

 

I'll do some more reading to see what the challenges are for a real fix (my gut says, fix it at the database level, but for Postgres you'd have to install triggers).

 

Since pre_save only sets the value when appropreate, the patch would only be in __init__ and deconstruct.

 

The scope for DateField is like so:

 

diff --git a/django/db/models/fields/__init__.py b/django/db/models/fields/__init

index 0af100efd9..fa4932e670 100644

--- a/django/db/models/fields/__init__.py

+++ b/django/db/models/fields/__init__.py

@@ -1176,8 +1176,9 @@ class DateField(DateTimeCheckMixin, Field):

auto_now_add=False, **kwargs):

self.auto_now, self.auto_now_add = auto_now, auto_now_add

if auto_now or auto_now_add:

- kwargs['editable'] = False

kwargs['blank'] = True

+ if auto_now:

+ kwargs['editable'] = False

super(DateField, self).__init__(verbose_name, name, **kwargs)

 

def _check_fix_default_value(self):

@@ -1230,8 +1231,10 @@ class DateField(DateTimeCheckMixin, Field):

if self.auto_now_add:

kwargs['auto_now_add'] = True

if self.auto_now or self.auto_now_add:

- del kwargs['editable']

del kwargs['blank']

+

+ if self.auto_now:

+ del kwargs['editable']

return name, path, args, kwargs

 

def get_internal_type(self):

 

>

> [0] https://code.djangoproject.com/ticket/22995

>

> On Monday, May 8, 2017 at 10:47:25 AM UTC-4, Melvyn Sopacua wrote:

> > On Monday 08 May 2017 04:07:09 Tim Graham wrote:

> > > The change to raise FieldError for non-editable fields was meant

> > > to

> > >

> > > prevent bugs, not to block devs from doing what they want.

> >

> > But auto_now_add without auto_now is not a reason to make the field

> > non-editable. I should be able to use it in a model form, since the

> > update case is unhandled.

> >

> >

> >

> > However, this has always (at least 1.8.x and up) been the case for

> > the field and as you say, it now exposes a bug.

> >

> >

> > Melvyn Sopacua

 

--

Melvyn Sopacua