fields with editable=False do not render

[davidschein@…]

At least 3 issues (#455,#342,#262), I think, are related to this problem:
When a field has editable=False, it is not added to the FormWrapper's field list in the change manipulator __init__().

We have,

def manipulator_init(opts, add, change, self, obj_key=None):
    if change:
    ...
    self.fields = []
    for f in opts.fields + opts.many_to_many:
        if f.editable and not (f.primary_key and change) and (not f.rel or not f.rel.edit_inline):
            self.fields.extend(f.get_manipulator_fields(opts, self, change))

I do not know the design, but it is evident that django *intends* for editable=False to do something akin to render with the html disable attribute ON. Other comments imply that editable=False means "do not display", but of course there are other mechanisms for this, e.g via the fields attribute admin UI.

My workaround is to not use editable and instead add javascript to add the disable attribute to the fields I want displayed readonly.

[mdt@…]

i would also expect that editable=False-fields apear but are not editable (just static output).

if i try to add the field to my custom fields list my datetime-fields are shown but integerfields get an error.

the datefield that is shown is even editable but never gets stored.

[konrad@…]

I have an object with some foreign keys to objects that have thousands of possible values. I don't want to load all those values into a drop down, but I do want to see what value the object is associated with. It would be really nice if editable=False displayed the field as text.

[anonymous]

It is indeed very annoying for fields not being displayed when editable = False.

It shoul do what it says, it should not be editable, it should however display its value.

[James Bennett]

At this point changing the behavior of editable would be a pretty big backwards-incompatible move, so personally I'd be wary of it, especially given that it's pretty easy in the template to display the value of the non-editable field.

[James Bennett]

At this point changing the behavior of editable would be a pretty big backwards-incompatible move, so personally I'd be wary of it, especially given that it's pretty easy in the template to display the value of the non-editable field.

[smurf@…]

What if you'd left the default behavior of editable ... except that it's rendered statically (as a link, in case of foreign-key fields) when its name is mentioned in Admin.fields?

Doing it this way would not backwards-incompatible because right now, doing that doesn't work anyway. :-/

[Chris Beaven]

This issue is obsolete with the upcoming newforms.

[rogerdpack]

I'm not sure if this is obsoleted with newforms. The problem it generated for me was that say I have a User with a field 'registered' which is, of course, not editable, then in the admin interface (where I DO want to be able to edit it--of course the admin would want to edit most everything), then it does not appear, nor can it. This prevents me from using form_for_class and forces me to write all my forms 'by hand' unfortunately. ugh. I move that admin have some new specification that says 'admin can edit it' like admin_edit=true or what not, and that newforms be written to work with that. Does that make sense? Is this a true problem?

[MichaelRadziej <mir@…>]

This ticket is not about any particular implementation but about the specification that "editable" actually also means "invisible". This decision has been reiterated in the newforms documentation (see "USING A SUBSET OF FIELDS ON THE FORM").

If you want to question it, it's better to use the developer mailing list (but please don't open the ticket again, as such a discussion doesn't work well in the ticket system).

Please note also that newforms will give you several other ways to sensibly scratch your specific itch.