Code

Opened 9 years ago

Closed 4 years ago

Last modified 3 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: brosner
Component: contrib.admin Version: newforms-admin
Severity: normal Keywords: djangocon
Cc: josh@…, dan.fairs@…, apollo13, 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 4 years ago.
Initial patch.
readonly-admin.2.diff (16.2 KB) - added by Alex 4 years ago.
Added documentation.
readonly-admin.3.diff (18.5 KB) - added by Alex 4 years ago.
Added validation (and tests for the validation), only needs tests now.
readonly-admin.4.diff (21.9 KB) - added by Alex 4 years ago.
Added tests.
readonly-admin.5.diff (21.4 KB) - added by fest 4 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 4 years ago.
readonly-admin.7.diff (24.9 KB) - added by Alex 4 years ago.
Pretty printing
catch_value_error.diff (609 bytes) - added by hejsan 4 years ago.
An extra patch to catch ValueError in case of ManyToMany field

Download all attachments as: .zip

Change History (51)

comment:1 Changed 9 years ago by adrian

  • Summary changed from editable option - suggestion to Add a way for fields to be displayed in the admin without being editable

comment:2 Changed 7 years ago by SmileyChris

  • Triage Stage changed from Unreviewed to Design 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 Changed 7 years ago by mtredinnick

  • Triage Stage changed from Design decision needed to 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:5 Changed 7 years ago by ubernostrum

  • Resolution set to wontfix
  • Status changed from new to 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 Changed 6 years ago by anonymous

  • Resolution wontfix deleted
  • Status changed from closed to reopened
  • Version changed from 1.0 to 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 Changed 6 years ago by ubernostrum

  • Resolution set to wontfix
  • Status changed from reopened to 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 Changed 6 years ago by simon

  • Keywords djangocon added
  • Resolution wontfix deleted
  • Status changed from closed to 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 Changed 6 years ago by simon

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 Changed 6 years ago by simon

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 Changed 6 years ago by jcroft

+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 Changed 6 years ago by bkroeze

+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 Changed 6 years ago by danfairs

  • Cc dan.fairs@… added

comment:14 Changed 6 years ago by nagyv

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 Changed 6 years ago by cainmatt@…

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 Changed 5 years ago by legutierr

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 Changed 5 years ago by mrts

  • milestone set to 1.2

Re-targeting for 1.2.

comment:18 Changed 5 years ago by mrts

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

comment:19 Changed 5 years ago by legutierr

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 Changed 5 years ago by apollo13

  • Cc apollo13 added

comment:21 Changed 5 years ago by anonymous

  • Cc taavi@… added

comment:22 Changed 5 years ago by chromano

  • Cc chromano@… added

comment:23 Changed 5 years ago by veena

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 Changed 5 years ago by guettli

  • Cc hv@… added

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

comment:25 Changed 5 years ago by anonymous

  • Cc cg@… added; dan.fairs@…, apollo13, taavi@…, chromano@…, hv@… removed

comment:26 Changed 5 years ago by anonymous

  • Cc dan.fairs@…, apollo13, taavi@…, chromano@…, hv@… added

comment:27 Changed 5 years ago by anonymous

  • Cc rlaager@… added

comment:28 Changed 5 years ago by joshuajonah

  • Cc josh@… added

comment:29 Changed 5 years ago by nix

  • Cc listuser@… added

comment:30 Changed 5 years ago by anonymous

  • Cc russryba@… added

comment:31 Changed 5 years ago by Rupe

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 Changed 4 years ago by jezdez

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

Changed 4 years ago by Alex

Initial patch.

comment:33 Changed 4 years ago by Alex

  • Has patch set
  • Needs documentation set
  • Needs tests set
  • Owner changed from nobody to Alex
  • Status changed from reopened to new

Changed 4 years ago by Alex

Added documentation.

comment:34 Changed 4 years ago by Alex

  • Needs documentation unset

Changed 4 years ago by Alex

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

Changed 4 years ago by Alex

Added tests.

Changed 4 years ago by fest

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

comment:35 Changed 4 years ago by fest

  • Cc reinis.veips@… added

comment:36 Changed 4 years ago by frans

  • Cc francois@… added

comment:37 Changed 4 years ago by yed@…

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

Changed 4 years ago by Alex

Changed 4 years ago by Alex

Pretty printing

comment:38 Changed 4 years ago by brosner

  • Owner changed from Alex to brosner
  • Status changed from new to assigned

comment:39 Changed 4 years ago by brosner

  • Resolution set to fixed
  • Status changed from assigned to closed

(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 Changed 4 years ago by hejsan

  • Resolution fixed deleted
  • Status changed from closed to 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.

Changed 4 years ago by hejsan

An extra patch to catch ValueError in case of ManyToMany field

comment:41 Changed 4 years ago by kmtracey

  • Resolution set to fixed
  • Status changed from reopened to closed

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

comment:42 Changed 3 years ago by guettli

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

comment:43 Changed 3 years ago by jacob

  • milestone 1.2 deleted

Milestone 1.2 deleted

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.