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 [email protected]. To post to this group, send email to [email protected]. 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.
