Code

Opened 6 years ago

Closed 6 years ago

Last modified 3 years ago

#8220 closed Uncategorized (wontfix)

ForeignKey dropdown sorting in Admin

Reported by: robvdl Owned by: nobody
Component: contrib.admin Version: master
Severity: Normal Keywords: ForeignKey sort ordering
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

I have a model with a unique ForeignKey field called "user" to the django.contrib.auth User model. When I edit the model in admin, the dropdown list shows users in the order they are in the database, not sorted.

I would like to be able to sort the users in the dropdown list alphabetically, but cannot see a way how I can do this currently.

Considering the User model already has an ordering field in the UserAdmin class (django.contrib.auth.admin), would it be possible to also use this field for sorting the data in a ForeignKey dropdown box?

Attachments (0)

Change History (8)

comment:1 Changed 6 years ago by jacob

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Resolution set to wontfix
  • Status changed from new to closed

The object is sorted according to its ordering option.

comment:2 follow-up: Changed 6 years ago by eriks5

  • Resolution wontfix deleted
  • Status changed from closed to reopened

Setting the ordering option is not possible in this case since the User model is not under our control. In r7806 the default ordering of the User model was removed causing all select boxes in the admin interface for the User model to be sorted in database order instead of username order.

In my application there are thousands of users. It is impossible to find a user if the select box is not sorted by username.

In http://groups.google.com/group/django-users/browse_thread/thread/8526e0c37293d196 a solution to this problem is given, but this is really just a hack. In my application I have a dozen models with a ForeignKey on the User model and had to add that solution to each model. This is not the DRY principle as we're used with in Django.

comment:3 Changed 6 years ago by mtredinnick

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

The change in [7806] was made for good reasons (sorting thousands of entries every time, whether or not it is wanted is a big performance hit).

Saying that if you want custom admin behaviour you should modify the admin to customise it is "a hack" is a matter of opinion and not necessarily one that everybody agrees with.

In any case, reopening a ticket that has been closed as wontfix by a core developer is not the way things work (otherwise we end up with endless open-close-reopen cycles). If you are unhappy with the resolution, the next step is documented in the ticket lifecycle section of the contributing documentation. You may well have some genuinely new input that hasn't been considered, but at least follow the process so things work smoothly.

comment:4 in reply to: ↑ 2 Changed 6 years ago by julianb

Replying to eriks5:

In my application there are thousands of users. It is impossible to find a user if the select box is not sorted by username.

You really need to start using the raw_id_fields admin option.

comment:5 Changed 6 years ago by anonymous

  • milestone 1.0 maybe deleted

Milestone 1.0 maybe deleted

comment:6 Changed 6 years ago by SebastienWacquiez

It's not because [7806] was a good patch that this ticket don't deserve any thinking.

It's right that for medium userbase the lost of defaut ordering *without* any "usable" way to restore the functionnality is a pain.

So if one of the "core developer" can take some time to think about it, and eventualy find/propose a clean way to restore what have been removed, I'm quite sure that I won't be the only one to be happy :)

comment:7 Changed 4 years ago by sggottlieb

If anyone else was running into this, there is a fairly painless work around.

First, you want to create your own ModelForm that sorts the users how you want. Here is an example:

class EventRegistrationForm(ModelForm):
    def __init__(self, *args, **kwargs):
        super(EventRegistrationForm, self).__init__(*args, **kwargs)
        if self.instance:
            self.fields['user'].queryset = \
                User.objects.all().order_by('username')
    
    class Meta:
        model = EventRegistration

Then, you can wire in your admin to use that form rather than the default:

class RegistrantInline(admin.TabularInline):
	model = EventRegistration
	form = EventRegistrationForm

comment:8 Changed 3 years ago by atkinsonr@…

  • Easy pickings unset
  • Severity set to Normal
  • Type set to Uncategorized
  • UI/UX unset

Another workaround for people finding this on google is ModelAdmin.foreign_key_for_field [1] introduced on Django 1.1.

[1] https://docs.djangoproject.com/en/1.1/ref/contrib/admin/#django.contrib.admin.ModelAdmin.formfield_for_foreignkey

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.