I agree that the current behaviour is confusing and needs change in order to be DRY[1] and consistent[2].
[1] https://docs.djangoproject.com/en/dev/misc/design-philosophies/#don-t-repeat-yourself-dry [2] https://docs.djangoproject.com/en/dev/misc/design-philosophies/#consistency This is how I currently work around this issue. models.py class Question(models.Model): text = models.CharField(max_length=200) pub_date = models.DateTimeField('date published') class Choice(models.Model): question = models.ForeignKey(Question) choice_text = models.CharField(max_length=200) votes = models.IntegerField(default=0) admin.py class ChoiceAdmin(admin.ModelAdmin): def question__text(self, obj): return obj.question.text list_display = ('pk', 'question__text', 'choice_text', 'votes') admin.site.register(Choice, ChoiceAdmin) On Tuesday, February 25, 2014 3:48:40 PM UTC-8, Wim Feijen wrote: > > Hello, > > Right now I have a School model containing a OneToOne-relation to User. > > In the admin, in search_fields, I can use double underscores to search in > related fields, for example: > search_fields = ('place__name', 'school__name') > > But in list_display, I can't. For example, > list_display = ['school', 'school__user', 'place', ] > gives an error. > > I find this totally confusing. More people do. > > A ticket has been made six years ago and was eventually closed as won't > fix. Currently, the proposed solution is to write a custom method or > callable. I'd like to raise a discussion to reopen that ticket. > > For reference, see: > https://code.djangoproject.com/ticket/5863 > https://groups.google.com/forum/#!topic/django-developers/eQSEv74bQh8 > > My arguments to allow such a syntax are: > > 1. allowing 'school__user' in list_display is consistent with the > behaviour of search_fields, list_filter in the admin, and get() and > filter() query syntax in general. > 2. it saves many people duplicating two to four lines of custom code, and > in my opinion, allows for a more concise yet extremely easy to understand > notation. > 3. ideally, a solution would use select_related in order to save database > queries and thus be longer than two to four lines of code. > 4. the need is common, and in onetoonefields specifically. Many people > have expressed their interest in this feature, and a core developer > initially accepted it. > 5. a long time has passed since then and our policy of accepting tickets > has changed. > > Thanks for reading! I'd love to hear your response. > > Regards, Wim > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/764cf67d-2107-4bdd-88bd-004a043a162f%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
