Ticket #34646 Ordering a Django admin column based on multiple model fields

[Mubarak Alrashidi]

Hello,

I posted this StackOverflow question, and @Willem Van Onsem tried to help by opening a ticket numbered #34646, and creating a patch for supporting the order by multiple fields in admin.display decorator.

But it got closed as a duplicate of #31975 which was reported about 3 years ago, and it got closed as wontfix by @Mariusz Felisiak because he said: "We don't want to add unnecessary complexity to the API.".

And I agree with what @Petr Dlouhý says: "it is small modification of Django code and small increase in API complexity (which is consistent with the logic of other order fields, BTW).".

The inconsistency is when somewhere we're able to order by multiple fields, and somewhere else we can't.

If we can order by multiple fields in the modelAdmin classes, why can't we do so in the admin.display decorator?

So, I do hope to reconsider implementing the patch that @Willem Van Onsem created.

Thanks

[Mubarak Alrashidi]

Can we at least know what the developers think about it?

[David Sanders]

Mariusz is a developer, so that's at least 1 developer's opinion :)

Unless anybody else pipes up to counter this I'd consider it to be a nice solution.

[Mark Niehues]

I also lately stumbled across this and was a little surprised that it could not handle multiple fields, as it is the case in other places.

So +1 for fixing this from me :)

[David Sanders]

Sorry to clarify I intended to respond with "niche solution" not "nice solution" lol. I didn't realise the phone's autocomplete had done that.

[Mubarak Alrashidi]

I really hope the developers implement the patch.

[Mubarak Alrashidi]

Could you re-consider it please?
it is really important, and we need it.
I have started another project where I need to create a computed column (used_invitations / max_invitations)

Best regards

[Fran Hrženjak]

The proposed patch adds very little extra API surface. Django admin in fact already support this, but for this arbitrary restriction in `get_ordering_field`. The patch just makes it possible to pass a list down to `get_queryset` method.

I would argue that this patch removes a special case in the API. Everywhere else (I think, pls correct me) devs can specify multiple fields for ordering. Except here. From a certain point of view, removing special cases means reducing API surface (:

The patch could be even simpler, IMHO: just keep the name `get_ordering_field`, for compatibility with existing code. It is easier to document that the method "now also takes a list", especially since in most cases it is still going to be given a single string.

Can power that be take another look at this issue? 🙏 

+1 with an extra "cmon" from me!

-- 

Fran