[Django Code] #5863: list_display does not allow functions of references objects

[Django Code]

#5863: list_display does not allow functions of references objects
---------------------------------------------+------------------------------
Reporter: Beat Bolli <me+d...@drbeat.li> | Owner: nobody
Status: new | Component: Admin interface
Version: SVN | Keywords: list_display
Stage: Unreviewed | Has_patch: 0
---------------------------------------------+------------------------------
It is possible to include a model member function in the list_display
Admin property. The same thing is not possible for ForeignKey models; at
least not with any of the variations I have tried: foreign.method,
foreign_method and foreign__method.

--
Ticket URL: <http://code.djangoproject.com/ticket/5863>
Django Code <http://code.djangoproject.com/>
The web framework for perfectionists with deadlines

[Django Code]

#5863: list_display does not allow functions of referenced objects
------------------------------------------------+---------------------------

Reporter: Beat Bolli <me+d...@drbeat.li> | Owner: nobody
Status: new | Component: Admin interface

Version: SVN | Resolution:
Keywords: list_display | Stage: Unreviewed
Has_patch: 0 | Needs_docs: 0
Needs_tests: 0 | Needs_better_patch: 0
------------------------------------------------+---------------------------
Changes (by Beat Bolli <me+d...@drbeat.li>):

* needs_better_patch: => 0
* summary: list_display does not allow functions of references objects
=> list_display does not allow functions of
referenced objects
* needs_tests: => 0
* needs_docs: => 0

--
Ticket URL: <http://code.djangoproject.com/ticket/5863#comment:1>

[Django Code]

#5863: list_display does not allow functions of referenced objects
------------------------------------------------+---------------------------

Reporter: Beat Bolli <me+d...@drbeat.li> | Owner: nobody
Status: new | Component: Admin interface

Version: SVN | Resolution:
Keywords: list_display | Stage: Unreviewed

Has_patch: 0 | Needs_docs: 0
Needs_tests: 0 | Needs_better_patch: 0
------------------------------------------------+---------------------------

Comment (by Beat Bolli <me+d...@drbeat.li>):

Sorry; the third example should have two underline characters between
"foreign" and "method".

--
Ticket URL: <http://code.djangoproject.com/ticket/5863#comment:2>

[Django Code]

#5863: list_display does not allow functions of referenced objects
------------------------------------------------+---------------------------

Reporter: Beat Bolli <me+d...@drbeat.li> | Owner: nobody

Status: closed | Component: Admin interface
Version: SVN | Resolution: invalid
Keywords: list_display | Stage: Unreviewed

Has_patch: 0 | Needs_docs: 0
Needs_tests: 0 | Needs_better_patch: 0
------------------------------------------------+---------------------------

Changes (by brosner):

* status: new => closed
* resolution: => invalid

Comment:

There is no need to support functions on ```ForeignKey``` models. You can
encapsulate that in a function on the model.

--
Ticket URL: <http://code.djangoproject.com/ticket/5863#comment:3>

[Django Code]

#5863: list_display does not allow functions of referenced objects
------------------------------------------------+---------------------------

Reporter: Beat Bolli <me+d...@drbeat.li> | Owner: nobody

Status: reopened | Component: Admin interface
Version: SVN | Resolution:
Keywords: list_display | Stage: Unreviewed

Has_patch: 0 | Needs_docs: 0
Needs_tests: 0 | Needs_better_patch: 0
------------------------------------------------+---------------------------

Changes (by me+d...@drbeat.li):

* status: closed => reopened
* resolution: invalid =>

Comment:

Thanks for the quick reply, which I have implemented for now.

Still, your proposal violates DRY: I have to define the same function on
each model that references the foreign model.

--
Ticket URL: <http://code.djangoproject.com/ticket/5863#comment:4>

[Django Code]

#5863: list_display does not allow functions of referenced objects
------------------------------------------------+---------------------------

Reporter: Beat Bolli <me+d...@drbeat.li> | Owner: nobody

Status: reopened | Component: Admin interface
Version: SVN | Resolution:
Keywords: list_display | Stage: Accepted

Has_patch: 0 | Needs_docs: 0
Needs_tests: 0 | Needs_better_patch: 0
------------------------------------------------+---------------------------

Changes (by gwilson):

* stage: Unreviewed => Accepted

Old description:

> It is possible to include a model member function in the list_display
> Admin property. The same thing is not possible for ForeignKey models; at
> least not with any of the variations I have tried: foreign.method,
> foreign_method and foreign__method.

New description:

It is possible to include a model member function in the `list_display`
Admin property. The same thing is not possible for ForeignKey models; at

least not with any of the variations I have tried: `foreign.method`,
`foreign_method` and `foreign__method`.

Comment:

Seems like a reasonable addition to me. Do we even allow doing this for
actual fields of a related model? This feature probably needs to be part
of newforms-admin or wait until that branch is merged though. It would be
helpful if you could attach a simple example, or even try your hand at
creating a patch.

--
Ticket URL: <http://code.djangoproject.com/ticket/5863#comment:5>

[Django Code]

#5863: list_display does not allow functions of referenced objects
-------------------------------------------------------+--------------------

Reporter: Beat Bolli <me+d...@drbeat.li> | Owner: nobody

Status: reopened | Milestone:

Component: Admin interface | Version: SVN

Resolution: | Keywords: list_display
Stage: Accepted | Has_patch: 0
Needs_docs: 0 | Needs_tests: 0
Needs_better_patch: 0 |

-------------------------------------------------------+--------------------
Comment (by zobbo):

I just wanted to raise this again. I'm using the new forms admin branch
and it's odd that in the following
{{{
class BlueEDIJobFileAdmin(admin.ModelAdmin):
search_fields=('blueedijob__client__code',)
list_display = ('id','blueedijob__client__code',)
}}}

The search_fields option is valid, but the list_display option is not.

--
Ticket URL: <http://code.djangoproject.com/ticket/5863#comment:6>

[Django Code]

#5863: list_display does not allow functions of referenced objects
-------------------------------------------------------+--------------------

Reporter: Beat Bolli <me+d...@drbeat.li> | Owner: nobody

Status: reopened | Milestone:

Component: Admin interface | Version: SVN

Resolution: | Keywords: list_display
Stage: Accepted | Has_patch: 0
Needs_docs: 0 | Needs_tests: 0
Needs_better_patch: 0 |
-------------------------------------------------------+--------------------

Comment (by cripple...@gmail.com):

I want to raise it once again since newforms-admin is now in...

--
Ticket URL: <http://code.djangoproject.com/ticket/5863#comment:7>

[Django]

#5863: list_display does not allow functions of referenced objects
-------------------------------------------------------+--------------------

Reporter: Beat Bolli <me+d...@drbeat.li> | Owner: nobody

Status: reopened | Milestone:
Component: django.contrib.admin | Version: SVN

Resolution: | Keywords: list_display
Stage: Accepted | Has_patch: 0
Needs_docs: 0 | Needs_tests: 0
Needs_better_patch: 0 |
-------------------------------------------------------+--------------------

Comment (by gra...@grahamcarlyle.com):

The patch uploaded shows the related objects field values in the same way
as the object field values are shown (a boolean as an tick icon etc.)
rather than as a string as a custom method would.

However the header of the field still shows the related object's verbose
name. Ideally it would show something like (section -> title) to indicate
its a related objects field, but I haven't worked out how to do that yet
:)

--
Ticket URL: <http://code.djangoproject.com/ticket/5863#comment:8>
Django <http://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

[Django]

#5863: list_display does not allow functions of referenced objects
-------------------------------------------------------+--------------------

Reporter: Beat Bolli <me+d...@drbeat.li> | Owner: nobody

Status: reopened | Milestone:
Component: django.contrib.admin | Version: SVN
Resolution: | Keywords: list_display
Stage: Accepted | Has_patch: 0
Needs_docs: 0 | Needs_tests: 0
Needs_better_patch: 0 |
-------------------------------------------------------+--------------------

Comment (by pihentagy):

What is the next step to see this patch in django?

thanks

--
Ticket URL: <http://code.djangoproject.com/ticket/5863#comment:9>

[Django]

#5863: list_display does not allow functions of referenced objects
-------------------------------------------------------+--------------------

Reporter: Beat Bolli <me+d...@drbeat.li> | Owner: nobody

Status: reopened | Milestone:
Component: django.contrib.admin | Version: SVN
Resolution: | Keywords: list_display

Stage: Design decision needed | Has_patch: 1
Needs_docs: 1 | Needs_tests: 0
Needs_better_patch: 1 |
-------------------------------------------------------+--------------------
Changes (by kmtracey):

* needs_better_patch: 0 => 1
* has_patch: 0 => 1
* stage: Accepted => Design decision needed
* needs_docs: 0 => 1

Comment:

Replying to [comment:9 pihentagy]:

> What is the next step to see this patch in django?
>

Since this ticket was raised callables were added to the list of things
allowed, in list_display, as were methods on !ModelAdmin, in [8352]. Do
we need yet another way to specify something in list_display? Can this
case not be covered by callables?

I was going to experiment to see, but I can't. First, the patch doesn't
apply cleanly to existing trunk. The actual apply failures are on the
tests, not the code, so I thought I could experiment with the code, but I
can't get that to work either. If I add something with the double
underscore syntax to the list_display for one of the models in my app, I
get an !ImproperlyConfigured exception thrown during admin validation:

{{{
Traceback:
File "/home/kmt/django/trunk/django/core/handlers/base.py" in get_response
77. request.path_info)
File "/home/kmt/django/trunk/django/core/urlresolvers.py" in resolve
179. for pattern in self.urlconf_module.urlpatterns:
File "/home/kmt/django/trunk/django/core/urlresolvers.py" in
_get_urlconf_module
198. self._urlconf_module = __import__(self.urlconf_name,
{}, {}, [''])
File "/home/kmt/software/web/xword/../xword/urls.py" in <module>
9. admin.autodiscover()
File "/home/kmt/django/trunk/django/contrib/admin/__init__.py" in
autodiscover
40. __import__("%s.admin" % app)
File "/home/kmt/software/web/xword/../xword/crossword/admin.py" in
<module>
61. admin.site.register(Puzzles, PuzzlesAdmin)
File "/home/kmt/django/trunk/django/contrib/admin/sites.py" in register
76. validate(admin_class, model)
File "/home/kmt/django/trunk/django/contrib/admin/validation.py" in
validate
38. % (cls.__name__, idx, field,
cls.__name__, model._meta.object_name))

Exception Type: ImproperlyConfigured at /admin/crossword/authors/
Exception Value: PuzzlesAdmin.list_display[4], 'AuthorID__Notes' is not a
callable or an attribute of 'PuzzlesAdmin' or found in the model
'Puzzles'.
}}}

This may be validation code added since the patch was originally created,
I don['t know -- I think I specified the new thing correctly but I'm not
entirely sure because there are no docs for the new supported thing in
list_display. The existing docs spell out pretty clearly what's allowed:
http://docs.djangoproject.com/en/dev/ref/contrib/admin/#list-display and
they would also need to be updated if it's decided this addition is still
worthwhile.

So a working patch with docs that applies cleanly to trunk (and doesn't
have the same problem with sorting that [8352] introduced, see [9212]),
plus something that addresses graham's last remark about the title for the
column being non-intuitive, are all missing for this to get in...but even
before that please answer the first question I had: what does this provide
that isn't already possible given the expanded options of things you can
now specify in list_display?

--
Ticket URL: <http://code.djangoproject.com/ticket/5863#comment:10>

[Django]

#5863: list_display does not allow functions of referenced objects
-------------------------------------------------------+--------------------

Reporter: Beat Bolli <me+d...@drbeat.li> | Owner: nobody

Status: reopened | Milestone:
Component: django.contrib.admin | Version: SVN
Resolution: | Keywords: list_display
Stage: Design decision needed | Has_patch: 1
Needs_docs: 1 | Needs_tests: 0
Needs_better_patch: 1 |
-------------------------------------------------------+--------------------

Comment (by pihentagy):

Replying to [comment:10 kmtracey]:

> but even before that please answer the first question I had: what does
this provide that isn't already possible given the expanded options of
things you can now specify in list_display?

Consistency and DRY: so you shouldn't write boilerplate code. You
shouldn't specify column name django alredy knows.

--
Ticket URL: <http://code.djangoproject.com/ticket/5863#comment:11>

[Django]

#5863: list_display does not allow functions of referenced objects
-------------------------------------------------------+--------------------

Reporter: Beat Bolli <me+d...@drbeat.li> | Owner: nobody

Status: reopened | Milestone:
Component: django.contrib.admin | Version: SVN
Resolution: | Keywords: list_display
Stage: Design decision needed | Has_patch: 1
Needs_docs: 1 | Needs_tests: 0
Needs_better_patch: 1 |
-------------------------------------------------------+--------------------

Comment (by kmtracey):

Replying to [comment:11 pihentagy]:

> Consistency and DRY: so you shouldn't write boilerplate code. You
shouldn't specify column name django alredy knows.

I understand wanting to avoid boilerplate code but I'm missing how this is
a common enough case to warrant inclusion and balance the additional
complexity (both for users -- the list of things you can put in
list_display is getting a bit long -- and code maintainers). What's the
common situation where user's would really like to see the value of a
field in a related model instead of just the text representation of the
related model? I'm just not seeing that as a very common need, meaning
when you need it if you have to write a little extra code it's no big
deal. It's not boilerplate if you only have to do it in rare situations.
I'm looking for something a little more concrete as motivation than mom
and apple pie goodness.

--
Ticket URL: <http://code.djangoproject.com/ticket/5863#comment:12>

[Django]

#5863: list_display does not allow functions of referenced objects
-------------------------------------------------------+--------------------

Reporter: Beat Bolli <me+d...@drbeat.li> | Owner: nobody

Status: reopened | Milestone:
Component: django.contrib.admin | Version: SVN
Resolution: | Keywords: list_display
Stage: Design decision needed | Has_patch: 1
Needs_docs: 1 | Needs_tests: 0
Needs_better_patch: 1 |
-------------------------------------------------------+--------------------

Comment (by pihentagy):

Replying to [comment:12 kmtracey]:

> Replying to [comment:11 pihentagy]:
> > Consistency and DRY: so you shouldn't write boilerplate code. You
shouldn't specify column name django alredy knows.
>
> I understand wanting to avoid boilerplate code but I'm missing how this
is a common enough case to warrant inclusion and balance the additional
complexity (both for users -- the list of things you can put in
list_display is getting a bit long -- and code maintainers). What's the
common situation where user's would really like to see the value of a
field in a related model instead of just the text representation of the
related model? I'm just not seeing that as a very common need, meaning
when you need it if you have to write a little extra code it's no big
deal. It's not boilerplate if you only have to do it in rare situations.
I'm looking for something a little more concrete as motivation than mom
and apple pie goodness.

If you have just 1 or 2 foreign keys, you have a lot of place, so it seems
logical to display more interesting fields from a foreignkey. The unicode
representation is ok, but it is just 1 column, you will find things
quickly, if you have 2 or 3 fields from a foreign tabble (not to mention,
you will be able to sort on that field for free!)

For example m2m tables with additional fields doesn't contain interesting
information on their own. Maybe you want to display more columns from one
FK and sort on them...

--
Ticket URL: <http://code.djangoproject.com/ticket/5863#comment:13>

[Django]

#5863: list_display does not allow functions of referenced objects
-------------------------------------------------------+--------------------

Reporter: Beat Bolli <me+d...@drbeat.li> | Owner: nobody

Status: reopened | Milestone:
Component: django.contrib.admin | Version: SVN
Resolution: | Keywords: list_display
Stage: Design decision needed | Has_patch: 1
Needs_docs: 1 | Needs_tests: 0
Needs_better_patch: 1 |
-------------------------------------------------------+--------------------

Comment (by danros):

Replying to [comment:13 pihentagy]:

> What's the common situation where user's would really like to see the
value of a field in a related model instead of just the text
representation of the related model? I'm just not seeing that as a very
common need, meaning when you need it if you have to write a little extra
code it's no big deal. It's not boilerplate if you only have to do it in
rare situations. I'm looking for something a little more concrete as
motivation than mom and apple pie goodness.

Can I add that I would very much like this functionality for my project.
In fact the lack of this functionality led me to give up on the admin
interface and create my own thing that did do that!

Being able to mix-in related model fields is very useful for creating a
'dashboard' style admin page which I would think is a very common
requirement.

--
Ticket URL: <http://code.djangoproject.com/ticket/5863#comment:14>

[Django]

#5863: list_display does not allow functions of referenced objects
-------------------------------------------------------+--------------------

Reporter: Beat Bolli <me+d...@drbeat.li> | Owner: nobody

Status: reopened | Milestone:
Component: django.contrib.admin | Version: SVN
Resolution: | Keywords: list_display
Stage: Design decision needed | Has_patch: 1
Needs_docs: 1 | Needs_tests: 0
Needs_better_patch: 1 |
-------------------------------------------------------+--------------------

Comment (by kmtracey):

Replying to [comment:14 danros]:

>
> Can I add that I would very much like this functionality for my project.
In fact the lack of this functionality led me to give up on the admin
interface and create my own thing that did do that!

It was easier to write your own admin than write some trivial !ModelAdmin
methods that returned the information you were interested in?

--
Ticket URL: <http://code.djangoproject.com/ticket/5863#comment:15>

[Django]

#5863: list_display does not allow functions of referenced objects
-------------------------------------------------------+--------------------

Reporter: Beat Bolli <me+d...@drbeat.li> | Owner: nobody

Status: reopened | Milestone:
Component: django.contrib.admin | Version: SVN
Resolution: | Keywords: list_display
Stage: Design decision needed | Has_patch: 1
Needs_docs: 1 | Needs_tests: 0
Needs_better_patch: 1 |
-------------------------------------------------------+--------------------

Comment (by pihentagy):

Khm, sorry for the noise guys, I think I misread this ticket.

All I want to do is:

{{{
list_display = ('foreign_key__related_fieldname1',
'foreign_key__related_fieldname2')
}}}

so displaying related fields.
Should I open a ticket for that, or is there one for it?

--
Ticket URL: <http://code.djangoproject.com/ticket/5863#comment:16>

[Django]

#5863: list_display does not allow functions of referenced objects
-------------------------------------------------------+--------------------

Reporter: Beat Bolli <me+d...@drbeat.li> | Owner: nobody

Status: reopened | Milestone:
Component: django.contrib.admin | Version: SVN
Resolution: | Keywords: list_display
Stage: Design decision needed | Has_patch: 1
Needs_docs: 1 | Needs_tests: 0
Needs_better_patch: 1 |
-------------------------------------------------------+--------------------

Comment (by kmtracey):

Replying to [comment:16 pihentagy]:

> Should I open a ticket for that, or is there one for it?

I believe that is what this ticket is asking for, so no need for another
ticket. In the absence of a working patch for this ticket, you can
achieve what you want by adding !ModelAdmin methods (or callables) that
return the information you are looking for, and specifying these methods
in your `list_display`. It is not particularly difficult and not a lot of
code. Doc is here: http://docs.djangoproject.com/en/dev/ref/contrib/admin
/#list-display

--
Ticket URL: <http://code.djangoproject.com/ticket/5863#comment:17>

[Django]

#5863: list_display does not allow functions of referenced objects
-------------------------------------------------------+--------------------

Reporter: Beat Bolli <me+d...@drbeat.li> | Owner: nobody

Status: reopened | Milestone:
Component: django.contrib.admin | Version: SVN
Resolution: | Keywords: list_display
Stage: Design decision needed | Has_patch: 1
Needs_docs: 1 | Needs_tests: 0
Needs_better_patch: 1 |
-------------------------------------------------------+--------------------

Comment (by ramiro):

I'd say this ticket can be closed (I found it when looking for material
related to #10230).

Using callables (bare functions for example, i.e. no model methods nor
`ModelAdmin` subclasses methods) make the "It violates DRY: I have to

define the same function on each model that references the foreign model"

argument moot.

Also, when it comes to the HTML table headers:

1. Seeing a bare 'Code' header (using the
[http://code.djangoproject.com/ticket/5863#comment:6 comment 6] example)
that refers to a `code` field of a `Client` model that is located one or
more FK-hops away isn't necessarily a good idea, it can be confusing
because the user could assume it refers about a (non-existent) `code`
field local to the model being displayed.
2. In the case of more that one level of indirection, having an
automatically-generated `'Hop1 Model > ... > HopN Model > Field'` header
wouldn´t be practical/scalable.

It's more practical in that case that the developer sets explicitely an
appropiate, unambiguous header literal using the `.short_description`
facility.

In other words, I'd say current functionality plus a bit of work satisfy
the needs expressed in this ticket discussion for this arguably rare
scenario.

--
Ticket URL: <http://code.djangoproject.com/ticket/5863#comment:18>

[Django]

#5863: list_display does not allow functions of referenced objects
-------------------------------------------------------+--------------------

Reporter: Beat Bolli <me+d...@drbeat.li> | Owner: nobody

Status: reopened | Milestone:
Component: django.contrib.admin | Version: SVN
Resolution: | Keywords: list_display
Stage: Design decision needed | Has_patch: 1
Needs_docs: 1 | Needs_tests: 0
Needs_better_patch: 1 |
-------------------------------------------------------+--------------------

Comment (by galund):

Reasons not to close this ticket:
- consistency between search_fields, list_display, and list_filter: it
seems reasonable to want them all to work the same way. At the basic
level, they are all a list of fields, after that, the limitations seem
arbitrary (i.e. it seems at first glance as if the more advanced features
of each could be available but just haven't been programmed yet).

- this need isn't really so rare, particularly if you have models that
relate one-to-one, where you naturally do want to include fields from
across several tables.

--
Ticket URL: <http://code.djangoproject.com/ticket/5863#comment:19>

[Django]

#5863: list_display does not allow functions of referenced objects
-------------------------------------------------------+--------------------

Reporter: Beat Bolli <me+d...@drbeat.li> | Owner: nobody

Status: reopened | Milestone:
Component: django.contrib.admin | Version: SVN
Resolution: | Keywords: list_display

Stage: Design decision needed | Has_patch: 0
Needs_docs: 1 | Needs_tests: 1
Needs_better_patch: 1 |
-------------------------------------------------------+--------------------
Changes (by codekoala):

* has_patch: 1 => 0
* needs_tests: 0 => 1

Comment:

Would someone like to review the snippet I've come up with as a "work
around" of sorts? It would definitely need some work before it could be
used in Django if it's deemed worthy, but I hope it's an option at
least... I'm not sure I feel comfortable posting it as a patch because of
the issues involved with my approach, but I still think it's worth looking
at.

You can find it here, along with some details about the issues involved:
http://www.codekoala.com/blog/2009/feb/27/model-relationships-and-
list_display/

Thanks!

--
Ticket URL: <http://code.djangoproject.com/ticket/5863#comment:20>

[Django]

#5863: list_display does not allow functions of referenced objects
-------------------------------------------------------+--------------------

Reporter: Beat Bolli <me+d...@drbeat.li> | Owner: nobody

Status: reopened | Milestone:
Component: django.contrib.admin | Version: SVN
Resolution: | Keywords: list_display

Stage: Design decision needed | Has_patch: 1
Needs_docs: 1 | Needs_tests: 0

Needs_better_patch: 1 |
-------------------------------------------------------+--------------------
Changes (by codekoala):

* has_patch: 0 => 1
* needs_tests: 1 => 0

Comment:

oops... didn't mean to adjust the ticket properties like that.

--
Ticket URL: <http://code.djangoproject.com/ticket/5863#comment:21>

[Django]

#5863: list_display does not allow functions of referenced objects
-------------------------------------------------------+--------------------

Reporter: Beat Bolli <me+d...@drbeat.li> | Owner: nobody

Status: reopened | Milestone:
Component: django.contrib.admin | Version: SVN
Resolution: | Keywords: list_display
Stage: Design decision needed | Has_patch: 1
Needs_docs: 1 | Needs_tests: 0
Needs_better_patch: 1 |
-------------------------------------------------------+--------------------

Comment (by haffi67):

One thing that I think no one has pointed out yet; if it were possible to
set {{{table__field}}} in list_display, you could order the list by that
field in the interface, which you can't do with callables.

--
Ticket URL: <http://code.djangoproject.com/ticket/5863#comment:22>

[Django]

#5863: list_display does not allow functions of referenced objects
-------------------------------------------------------+--------------------

Reporter: Beat Bolli <me+d...@drbeat.li> | Owner: nobody

Status: reopened | Milestone:
Component: django.contrib.admin | Version: SVN
Resolution: | Keywords: list_display
Stage: Design decision needed | Has_patch: 1
Needs_docs: 1 | Needs_tests: 0
Needs_better_patch: 1 |
-------------------------------------------------------+--------------------

Comment (by kmtracey):

Replying to [comment:22 haffi67]:

> One thing that I think no one has pointed out yet; if it were possible
to set {{{table__field}}} in list_display, you could order the list by
that field in the interface, which you can't do with callables.

You can set admin_order_field on a callable to specify ordering; doc on
that is the last bullet under
http://docs.djangoproject.com/en/dev/ref/contrib/admin/#django.contrib.admin.ModelAdmin.list_display.
If that doesn't currently support the double-underscore syntax to
reference a ordering by a field in a related object, then I doubt it would
'just work' for things specified that way in list_display.

--
Ticket URL: <http://code.djangoproject.com/ticket/5863#comment:23>

[Django]

#5863: list_display does not allow functions of referenced objects
-------------------------------------------------------+--------------------

Reporter: Beat Bolli <me+d...@drbeat.li> | Owner: nobody

Status: reopened | Milestone:
Component: django.contrib.admin | Version: SVN
Resolution: | Keywords: list_display
Stage: Design decision needed | Has_patch: 1
Needs_docs: 1 | Needs_tests: 0
Needs_better_patch: 1 |
-------------------------------------------------------+--------------------

Comment (by subsume):

Seems like discussion of this has petered out. Too bad, especially when
more and more people are looking to subclass parts of admin for their own
use.

This is so simple in many other ways in admin. I realize it leads to
situations where what you get back isn't a field, but another queryset,
but the developer gets what they deserve in that case. Its not hard (or
even out of precedent) to simply ignore relations which are nonsense. Just
take a look at the behavior of select_related! Having to create a custom
method each time is tedious and this limitation prevents extensibility in
situations where you've put those fields on the model yourself manually
using extra() and other methods.

--
Ticket URL: <http://code.djangoproject.com/ticket/5863#comment:24>

[Django]

#5863: list_display does not allow functions of referenced objects
-------------------------------------------------------+--------------------

Reporter: Beat Bolli <me+d...@drbeat.li> | Owner: nobody

Status: reopened | Milestone:
Component: django.contrib.admin | Version: SVN
Resolution: | Keywords: list_display
Stage: Design decision needed | Has_patch: 1
Needs_docs: 1 | Needs_tests: 0
Needs_better_patch: 1 |
-------------------------------------------------------+--------------------

Changes (by andybak):

* cc: an...@andybak.net (added)

--
Ticket URL: <http://code.djangoproject.com/ticket/5863#comment:25>

[Django]

#5863: list_display does not allow functions of referenced objects
-------------------------------------------------------+--------------------
Reporter: Beat Bolli <me+d...@drbeat.li> | Owner: nobody
Status: reopened | Milestone:
Component: django.contrib.admin | Version: SVN
Resolution: | Keywords: list_display
Stage: Design decision needed | Has_patch: 1
Needs_docs: 1 | Needs_tests: 0
Needs_better_patch: 1 |
-------------------------------------------------------+--------------------

Changes (by mikexstudios):

* cc: mike.huy...@gmail.com (added)

--
Ticket URL: <http://code.djangoproject.com/ticket/5863#comment:26>

[Django]

#5863: list_display does not allow functions of referenced objects

------------------------------------------------------------+---------------
Reporter: Beat Bolli <me+django@…> | Owner: nobody

Status: reopened | Milestone:
Component: django.contrib.admin | Version: SVN
Resolution: | Keywords: list_display

Triage Stage: Design decision needed | Has patch: 1
Needs documentation: 1 | Needs tests: 0
Patch needs improvement: 1 |
------------------------------------------------------------+---------------

Comment (by Herman S):

This needs attention.

I have the following models:
* Applicant
* Application, which has a field "applicant =
models.ForeignKey(Applicant)"

In ApplicationAdmin I'm trying to request the applicants name, phone,
email etc. with:[[BR]]
list_display = ['status', 'interview' ... 'applicant__name',
'applicant__email']

As the parent/child relationship is reversed from what Django's
ModelAdmin.inlines expect, there seems to not be a solution for my
problem.

--
Ticket URL: <http://code.djangoproject.com/ticket/5863#comment:27>

[Django]

#5863: list_display does not allow functions of referenced objects
------------------------------------------------------------+---------------
Reporter: Beat Bolli <me+django@…> | Owner: nobody

Status: closed | Milestone:
Component: django.contrib.admin | Version: SVN
Resolution: wontfix | Keywords: list_display

Triage Stage: Design decision needed | Has patch: 1
Needs documentation: 1 | Needs tests: 0
Patch needs improvement: 1 |
------------------------------------------------------------+---------------

Changes (by kmtracey):

* status: reopened => closed
* resolution: => wontfix

Comment:

Replying to [comment:27 Herman S]:

>
> As the parent/child relationship is reversed from what Django's
ModelAdmin.inlines expect, there seems to not be a solution for my
problem.

There's a trivially-easy solution you can code: methods on your model or
model admin that return the information you desire, listed in your
list_display.

I'm closing this wontfix; having it be open seems to be confusing people
into thinking the requested function of allowing a specific field from a
related model to be shown in list_display is not possible. It is possible,
quite easily, with a feature (callables in list_display) added since this
ticket was originally opened. That feature is more powerful than simply
allowing traversal to a related model's field, so the syntax of how to do
it is not exactly the same as it would be if just that one piece was
implemented. But given the more powerful thing has been implemented, I
don't believe the addition of another way of doing the same thing is
necessary or worth the implementation/maintenance effort.

--
Ticket URL: <http://code.djangoproject.com/ticket/5863#comment:28>

[Django]

#5863: list_display does not allow functions of referenced objects
------------------------------------------------------------+---------------
Reporter: Beat Bolli <me+django@…> | Owner: nobody
Status: closed | Milestone:
Component: django.contrib.admin | Version: SVN
Resolution: wontfix | Keywords: list_display
Triage Stage: Design decision needed | Has patch: 1
Needs documentation: 1 | Needs tests: 0
Patch needs improvement: 1 |
------------------------------------------------------------+---------------

Comment (by pihentagy):

And what about sorting?

--
Ticket URL: <http://code.djangoproject.com/ticket/5863#comment:29>

[Django]

#5863: list_display does not allow functions of referenced objects
------------------------------------------------------------+---------------
Reporter: Beat Bolli <me+django@…> | Owner: nobody
Status: closed | Milestone:
Component: django.contrib.admin | Version: SVN
Resolution: wontfix | Keywords: list_display
Triage Stage: Design decision needed | Has patch: 1
Needs documentation: 1 | Needs tests: 0
Patch needs improvement: 1 |
------------------------------------------------------------+---------------

Comment (by kmtracey):

Replying to [comment:29 pihentagy]:
> And what about sorting?

Sorting is supported for callables in in list_display, as noted in
http://code.djangoproject.com/ticket/5863#comment:23

--
Ticket URL: <http://code.djangoproject.com/ticket/5863#comment:30>

[Django]

#5863: list_display does not allow functions of referenced objects

-------------------------------------+-------------------------------------
Reporter: Beat | Owner: nobody
Bolli <me+django@…> | Status: closed
Type: | Component: contrib.admin
Uncategorized | Severity: Normal
Milestone: | Keywords: list_display
Version: SVN | Has patch: 1
Resolution: wontfix | Needs tests: 0

Triage Stage: Design |
decision needed |

Needs documentation: 1 |
Patch needs improvement: 1 |
-------------------------------------+-------------------------------------
Changes (by brillgen):

* cc: brillgen (added)
* type: => Uncategorized
* severity: => Normal

Comment:

@kmtracey:
We would have to use over a 100 extra boilerplate functions at last
estimate since callables is being stated as the only supported means of
getting direct fields from foreign keys...some of them are simply a text
field that needs to be displayed as such..I have 2 questions for the
community:
1. Isn't there a performance impact of using a callable (select_related)
benefit loss which could happen in case of simple FK fields required?
If there is no impact, its irrelevant because the boiler plate code is not
thaat much trouble
However, if there is (and I believe there would be),
2. Would the django admin accept a patch as long as it met the
requirements of test cases, documentation etc etc.
I ask because there would be nothing more frustrating than developing a
fully featured patch against trunk just to hear that it'll never get
accepted due to contrary design ideas :(

--
Ticket URL: <http://code.djangoproject.com/ticket/5863#comment:31>

[Django]

#5863: list_display does not allow functions of referenced objects
-------------------------------------+-------------------------------------
Reporter: Beat | Owner: nobody
Bolli <me+django@…> | Status: closed
Type: | Component: contrib.admin
Uncategorized | Severity: Normal
Milestone: | Keywords: list_display
Version: SVN | Has patch: 1
Resolution: wontfix | Needs tests: 0
Triage Stage: Design |
decision needed |
Needs documentation: 1 |
Patch needs improvement: 1 |
-------------------------------------+-------------------------------------

Comment (by lukeplant):

@brillgen:

It's difficult to believe there would be much difference between the two
methods if you are using 'select_related' correctly (and we don't want to
complicate the logic for select_related any further).

Also, note that you could easily write a function that would eliminate the
boilerplate, if it is really boilerplate that conforms to a common
pattern. Untested code:

{{{
#!python

def foreign_field(field_name):
def accessor(obj):
val = obj
for part in field_name.split('__'):
val = getattr(val, part)
return val
accessor.__name__ = field_name
return accessor

ff = foreign_field

class MyAdmin(ModelAdmin):

list_display = [ff('foreign_key__related_fieldname1'),
ff('foreign_key__related_fieldname2')]
}}}

--
Ticket URL: <http://code.djangoproject.com/ticket/5863#comment:32>

[Django]

#5863: list_display does not allow functions of referenced objects
-------------------------------------+-------------------------------------
Reporter: Beat | Owner: nobody
Bolli <me+django@…> | Status: closed
Type: | Component: contrib.admin
Uncategorized | Severity: Normal
Milestone: | Keywords: list_display
Version: SVN | Has patch: 1
Resolution: wontfix | Needs tests: 0

Triage Stage: Design | Easy pickings: 0

decision needed |
Needs documentation: 1 |
Patch needs improvement: 1 |
-------------------------------------+-------------------------------------

Changes (by brillgen):

* easy: => 0

Comment:

@lukeplant: In the absence of any other solution your function is a
lifesaver. I guess I'm not pythonic enough yet to have thought of it on my
own...
Still it does have a few problems that can't be fixed...For instance, how
to assign the short_description attribute to be the same as what has
already been defined for the field? It can't be done the way I see it,
without explicitly passing the model involved or the short description
(which will have to be repeated here)

--
Ticket URL: <http://code.djangoproject.com/ticket/5863#comment:33>

[Django]

#5863: list_display does not allow functions of referenced objects
-------------------------------------+-------------------------------------
Reporter: Beat | Owner: nobody
Bolli <me+django@…> | Status: closed
Type: | Component: contrib.admin
Uncategorized | Severity: Normal
Milestone: | Keywords: list_display
Version: SVN | Has patch: 1
Resolution: wontfix | Needs tests: 0
Triage Stage: Design | Easy pickings: 0
decision needed |
Needs documentation: 1 |
Patch needs improvement: 1 |
-------------------------------------+-------------------------------------

Comment (by andybak):

I agree with @brillgen here.

It would be clearer and much more consistant to support the parent__child
syntax for accessing related models wherever feasible.

I believe it's already been added for admin list_filter.

--
Ticket URL: <http://code.djangoproject.com/ticket/5863#comment:34>