Add a way for fields to be displayed in the admin without being editable

Personally, I think it's a good idea too (something like readonly=True).

What's the word from the men upstairs?

Yes, this is useful. However, they should just be displayed inline (perhaps surrounded with some styling), without using an input widget with readonly="true" or anything like that. These are truly non-editable fields, not just temporarily disabled. So insert them into the form as text.

related issue discussed at:

http://groups.google.com/group/django-developers/browse_thread/thread/1d7d8cb0662181c6

newforms-admin will obsolete this; you will, in theory, be able to write your own customized interface to do whatever you'd like, and in the current admin this goes against the explicitly-stated philosophy of the admin interface.

newforms-admin will not obsolete this. To have non editable fields in admin, even with newforms-admin, you have to inherit from the template and have some "if field in readonly_fields: skip" logic, thus hardcoding the list of readonly fields in a non-standard place, which is sub-optimal and doesn't scale. Having an option in ModelAdmin? like readonly_fields=... is the proper way to handle this.

No, really, you'll be able to write this in pure Python by using widget attributes when you set up the form. Plus, once again, it goes against the stated philosophy of the admin interface, which is that it's for actually administering data, not merely viewing it.

I emphatically disagree - in practical terms this comes up all the time. A bunch of examples:

* You set the "date added" field automatically when something is created but do not want editors to be able to change it because that would break your date-based URLs - but they still need to be able to see when it was created. * You're implementing finely grained permissions where only certain users can put something live on the site (by changing the published flag for example) - a very basic workflow mechanism. Lower level users still need to be able to see if something is published or not. * You don't want people to be able to edit the slug once something has been created, again to prevent URLs from breaking. * Items in your database were created by importing data from a third party (e.g. a sports feed, or pulling in photos from a Flickr photostream). You want people to be able to edit certain fields that are specific to your site, but not edit the fields that are determined by that external data source. * You want to automatically save "who created this", and allow that to be viewed but not edited later. * You're implementing a comment moderation interface. Users of that interface should not be able to edit the IP address for a comment, but should still be able to view it.

I've needed to do all of the above in the past. They all count as "administering" data, but all require certain fields to be visible but not editable.

(Plus it got a cheer at DjangoCon, so it should definitely be discussed further as a potential feature for a future release).

Here's that list properly formatted:

• You set the "date added" field automatically when something is created but do not want editors to be able to change it because that would break your date-based URLs - but they still need to be able to see when it was created.
• You're implementing finely grained permissions where only certain users can put something live on the site (by changing the published flag for example) - a very basic workflow mechanism. Lower level users still need to be able to see if something is published or not.
• You don't want people to be able to edit the slug once something has been created, again to prevent URLs from breaking.
• Items in your database were created by importing data from a third party (e.g. a sports feed, or pulling in photos from a Flickr photostream). You want people to be able to edit certain fields that are specific to your site, but not edit the fields that are determined by that external data source.
• You want to automatically save "who created this", and allow that to be viewed but not edited later.
• You're implementing a comment moderation interface. Users of that interface should not be able to edit the IP address for a comment, but should still be able to view it.

Intercepting the form, finding the field that you want to make read-only and then modifying its widget is a pretty nasty solution for something that's actually pretty common. It also seems a bit dirty to have a form field for something with a widget that doesn't actually let you edit it - if it's a form field, it should be editable. Widgets that display rather than edit seem pretty hacky to me.

+1 for "readonly_fields" in the admin options (or another name, if someone's got a better one). I need this ALL the time.

+1 here, Satchmo really needs this functionality for some of the incredible stuff we've got brewing in the store admin interface. Also, it really did get a large majority cheer at DjangoCon when I proposed it during the "give us your pony request" section.

I have the feeling that simon's list in large part contains data that shouldn't be edited once the item is created. If this is the case then I would rather thing about a readonly=True model option. Something similar to the DateField?'s auto_now_add argument. Basically, you never want to edit a DateField? with auto_now_add=True. That is there is rationale to have it specified in the model instead of admin option.

Moreover, even if it might be easier to define a readonly_fields in your admin class, logically this is about presenting your data, so it should be in you form. This way you can easily order the fields as well.

So my idea would be to implement it as a widget + an option in model definition.

I have a small patch in my personal version of django which adds editable=forms.VIEW_ONLY as a model field option.

This seems along the lines discussed above.

My patch still has these issues however: * the ViewOnlyWidget? currently just calls force_unicode(value) which is not appropriate for all field types (eg. ForeignKeys? are rendered as the id only) * the admin add form will only show the default value and not an input box. To support setting a value on create would require an additional option such as editable=forms.IMMUTABLE since some of the use cases above should allow setting an initial value and some should not

Send me an email if you would like the patch. It is just to django/db/models/fields/init.py, django/forms/forms.py and django/forms/widgets.py

If no one is working on this at the moment, I would like to give it a shot. My understanding is that this enhancement has made it into the 1.1 roadmap as a "maybe" feature.

* further discussion of this bug at #820, #7150, #8947

Re-targeting for 1.2.

See also #3990 (closed as duplicate of this) that has a somewhat different approach -- fields can be added but not changed later.

I jotted down some ideas about how this feature can be tackled; check it out at ReadOnlyAdmin. I will extend that wiki page with some implementation specs once I finish the project that I am working on now.

It is my intent to do any implementation work required, once I have to opportunity.

I think it should be easy to understand the behaviour from name of the attributes/list.

I'm not native english speaker but readonly doesn't give me clear view if I can fill field in create form and it's only disable for editing or also creating is disabled. And then I miss the feature of hidden field.

Proposals in ReadOnlyAdmin seems to me too complex and combination with permissions makes it even more complex. I think first behaviour should be straightforward. Then if we try it in admin and in future there will be some row level persmissions we could combine it.

I propose these two options in ModelAdmin? class:

• list_disable_edit = [] or disable_edit_fields = []
• list_disable_create = [] or disable_create_fields = []

list_disable_edit for fields I don't want to make them editable but I should fill it once in create form and then see only value in edit form.

list_disable_create for eg. automatically filled fields by imports scripts or own save() methods. In create form you could see some text from help_text like: "This is automatically filled field." or so on. If you don't also set that field in disable_edit_fields you are able to edit it further if you want.

It's for another discussion how it would be implemented on the widget side eg.: disable="disable", readonly="readonly" or only value as a text.

Maybe I'm missing something than apologize me, I'm not contributor to django but I'm using it heavy.

I wrote a simple ReadOnlyWidget?. The code here http://www.djangosnippets.org/snippets/937/

Something to keep in mind are fields like slug and primary key fields that may be editable only for new records. This is a little different from just saying that a field is solidly read only. These fields would be read only but only for the change view.

I'm not quite sure how best to handle the difference though. Maybe display_only=True/False and display_only_change=True/False. I personally like the term 'display only' over 'read only'.

For the record, there is a pretty nice implementation here: http://bitbucket.org/stephrdev/django-readonlywidget/src/

Initial patch.

Added documentation.

Added validation (and tests for the validation), only needs tests now.

Added tests.

Fixed label tag generation to use pretty_name instead of capfirst, which now produces pretty field names when underscores are used.

This patch doesn't work with fix for this bug: http://code.djangoproject.com/ticket/8164 - readonly_fields are moved to end of form, if fields are not defined in ModelAdmin? but in ModelForm?'s Meta class.

Pretty printing

(In [11965]) Fixed #342 -- added readonly_fields to ModelAdmin?. Thanks Alex Gaynor for bootstrapping the patch.

ModelAdmin? has been given a readonly_fields that allow field and calculated values to be displayed alongside editable fields. This works on model add/change pages and inlines.

This breaks if a ManyToMany? field is specified as readonly.

This is because the contents() function that is called in the fieldset.html template tries to display the value of the field but gets a ValueError? if it is a ManyToManyField? because they can't be used: "[Model name] instance needs to have a primary key value before a many-to-many relationship can be used"

Just need to add ValueError? to the catch as seen in the patch I attached, called catch_value_error.diff.

An extra patch to catch ValueError? in case of ManyToMany? field

Please open new tickets for follow-on problems rather than re-opening a fixed ticket.