Opened 19 years ago

Closed 15 years ago

Last modified 13 years ago

#342 closed enhancement (fixed)

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

Reported by: Bless Owned by: Brian Rosner
Component: contrib.admin Version: newforms-admin
Severity: normal Keywords: djangocon
Cc: josh@…, dan.fairs@…, Florian Apolloner, taavi@…, chromano@…, cg@…, rlaager@…, listuser@…, russryba@…, reinis.veips@…, francois@… Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: yes Patch needs improvement: yes
Easy pickings: no UI/UX: no

Description

When editable=False option is used then that field isn't showed in the form.

But it should be an option for show a field without can to editing it.

Attachments (8)

readonly-admin.diff (14.6 KB ) - added by Alex Gaynor 15 years ago.
Initial patch.
readonly-admin.2.diff (16.2 KB ) - added by Alex Gaynor 15 years ago.
Added documentation.
readonly-admin.3.diff (18.5 KB ) - added by Alex Gaynor 15 years ago.
Added validation (and tests for the validation), only needs tests now.
readonly-admin.4.diff (21.9 KB ) - added by Alex Gaynor 15 years ago.
Added tests.
readonly-admin.5.diff (21.4 KB ) - added by fest 15 years ago.
Fixed label tag generation to use pretty_name instead of capfirst, which now produces pretty field names when underscores are used.
readonly-admin.6.diff (22.1 KB ) - added by Alex Gaynor 15 years ago.
readonly-admin.7.diff (24.9 KB ) - added by Alex Gaynor 15 years ago.
Pretty printing
catch_value_error.diff (609 bytes ) - added by hejsan 15 years ago.
An extra patch to catch ValueError in case of ManyToMany field

Download all attachments as: .zip

Change History (51)

comment:1 by Adrian Holovaty, 19 years ago

Summary: editable option - suggestionAdd a way for fields to be displayed in the admin without being editable

comment:2 by Chris Beaven, 18 years ago

Triage Stage: UnreviewedDesign decision needed

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

What's the word from the men upstairs?

comment:3 by Malcolm Tredinnick, 18 years ago

Triage Stage: Design decision neededAccepted

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.

comment:5 by James Bennett, 17 years ago

Resolution: wontfix
Status: newclosed

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.

comment:6 by anonymous, 16 years ago

Resolution: wontfix
Status: closedreopened
Version: 1.0newforms-admin

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.

comment:7 by James Bennett, 16 years ago

Resolution: wontfix
Status: reopenedclosed

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.

comment:8 by simon, 16 years ago

Keywords: djangocon added
Resolution: wontfix
Status: closedreopened

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).

comment:9 by simon, 16 years ago

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.

comment:10 by simon, 16 years ago

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.

comment:11 by jcroft, 16 years ago

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

comment:12 by bkroeze, 16 years ago

+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.

comment:13 by Dan Fairs, 16 years ago

Cc: dan.fairs@… added

comment:14 by Viktor, 16 years ago

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.

comment:15 by cainmatt@…, 16 years ago

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

comment:16 by legutierr, 16 years ago

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.

comment:17 by mrts, 16 years ago

milestone: 1.2

Re-targeting for 1.2.

comment:18 by mrts, 16 years ago

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

comment:19 by legutierr, 16 years ago

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.

comment:20 by Florian Apolloner, 16 years ago

Cc: Florian Apolloner added

comment:21 by anonymous, 15 years ago

Cc: taavi@… added

comment:22 by Henrique Romano, 15 years ago

Cc: chromano@… added

comment:23 by veena, 15 years ago

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.

comment:24 by Thomas Güttler, 15 years ago

Cc: hv@… added

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

comment:25 by anonymous, 15 years ago

Cc: cg@… added; dan.fairs@… Florian Apolloner taavi@… chromano@… hv@… removed

comment:26 by anonymous, 15 years ago

Cc: dan.fairs@… Florian Apolloner taavi@… chromano@… hv@… added

comment:27 by anonymous, 15 years ago

Cc: rlaager@… added

comment:28 by joshuajonah, 15 years ago

Cc: josh@… added

comment:29 by nix, 15 years ago

Cc: listuser@… added

comment:30 by anonymous, 15 years ago

Cc: russryba@… added

comment:31 by Joshua Russo, 15 years ago

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'.

comment:32 by Jannis Leidel, 15 years ago

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

by Alex Gaynor, 15 years ago

Attachment: readonly-admin.diff added

Initial patch.

comment:33 by Alex Gaynor, 15 years ago

Has patch: set
Needs documentation: set
Needs tests: set
Owner: changed from nobody to Alex Gaynor
Status: reopenednew

by Alex Gaynor, 15 years ago

Attachment: readonly-admin.2.diff added

Added documentation.

comment:34 by Alex Gaynor, 15 years ago

Needs documentation: unset

by Alex Gaynor, 15 years ago

Attachment: readonly-admin.3.diff added

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

by Alex Gaynor, 15 years ago

Attachment: readonly-admin.4.diff added

Added tests.

by fest, 15 years ago

Attachment: readonly-admin.5.diff added

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

comment:35 by fest, 15 years ago

Cc: reinis.veips@… added

comment:36 by frans, 15 years ago

Cc: francois@… added

comment:37 by yed@…, 15 years ago

Patch needs improvement: set

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.

by Alex Gaynor, 15 years ago

Attachment: readonly-admin.6.diff added

by Alex Gaynor, 15 years ago

Attachment: readonly-admin.7.diff added

Pretty printing

comment:38 by Brian Rosner, 15 years ago

Owner: changed from Alex Gaynor to Brian Rosner
Status: newassigned

comment:39 by Brian Rosner, 15 years ago

Resolution: fixed
Status: assignedclosed

(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.

comment:40 by hejsan, 15 years ago

Resolution: fixed
Status: closedreopened

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.

by hejsan, 15 years ago

Attachment: catch_value_error.diff added

An extra patch to catch ValueError in case of ManyToMany field

comment:41 by Karen Tracey, 15 years ago

Resolution: fixed
Status: reopenedclosed

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

comment:42 by Thomas Güttler, 13 years ago

Cc: hv@… removed
Easy pickings: unset
UI/UX: unset

comment:43 by Jacob, 13 years ago

milestone: 1.2

Milestone 1.2 deleted

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