#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)
Change History (51)
comment:1 by , 19 years ago
Summary: | editable option - suggestion → Add a way for fields to be displayed in the admin without being editable |
---|
comment:2 by , 18 years ago
Triage Stage: | Unreviewed → Design decision needed |
---|
comment:3 by , 18 years ago
Triage Stage: | Design decision needed → Accepted |
---|
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:4 by , 18 years ago
related issue discussed at:
http://groups.google.com/group/django-developers/browse_thread/thread/1d7d8cb0662181c6
comment:5 by , 17 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
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 , 16 years ago
Resolution: | wontfix |
---|---|
Status: | closed → reopened |
Version: | 1.0 → newforms-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 , 16 years ago
Resolution: | → wontfix |
---|---|
Status: | reopened → closed |
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 , 16 years ago
Keywords: | djangocon added |
---|---|
Resolution: | wontfix |
Status: | closed → reopened |
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 , 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 , 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 , 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 , 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 , 16 years ago
Cc: | added |
---|
comment:14 by , 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 , 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 , 16 years ago
comment:18 by , 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 , 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 , 16 years ago
Cc: | added |
---|
comment:21 by , 15 years ago
Cc: | added |
---|
comment:22 by , 15 years ago
Cc: | added |
---|
comment:23 by , 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 = []
ordisable_edit_fields = []
list_disable_create = []
ordisable_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 , 15 years ago
Cc: | added |
---|
I wrote a simple ReadOnlyWidget. The code here http://www.djangosnippets.org/snippets/937/
comment:25 by , 15 years ago
Cc: | added; removed |
---|
comment:26 by , 15 years ago
Cc: | added |
---|
comment:27 by , 15 years ago
Cc: | added |
---|
comment:28 by , 15 years ago
Cc: | added |
---|
comment:29 by , 15 years ago
Cc: | added |
---|
comment:30 by , 15 years ago
Cc: | added |
---|
comment:31 by , 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 , 15 years ago
For the record, there is a pretty nice implementation here: http://bitbucket.org/stephrdev/django-readonlywidget/src/
comment:33 by , 15 years ago
Has patch: | set |
---|---|
Needs documentation: | set |
Needs tests: | set |
Owner: | changed from | to
Status: | reopened → new |
comment:34 by , 15 years ago
Needs documentation: | unset |
---|
by , 15 years ago
Attachment: | readonly-admin.3.diff added |
---|
Added validation (and tests for the validation), only needs tests now.
by , 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 , 15 years ago
Cc: | added |
---|
comment:36 by , 15 years ago
Cc: | added |
---|
comment:37 by , 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 , 15 years ago
Attachment: | readonly-admin.6.diff added |
---|
comment:38 by , 15 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:39 by , 15 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
comment:40 by , 15 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
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 , 15 years ago
Attachment: | catch_value_error.diff added |
---|
An extra patch to catch ValueError in case of ManyToMany field
comment:41 by , 15 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
Please open new tickets for follow-on problems rather than re-opening a fixed ticket.
comment:42 by , 13 years ago
Cc: | removed |
---|---|
Easy pickings: | unset |
UI/UX: | unset |
Personally, I think it's a good idea too (something like
readonly=True
).What's the word from the men upstairs?