[Django] #29700: Provide an "autocomplete_ordering" value in ModelAdmin, to decouple autocomplete ordering from admin ordering
Django
autocomplete ordering from admin ordering
------------------------------------------+------------------------
Reporter: David W. Lloyd | Owner: nobody
Type: New feature | Status: new
Component: contrib.admin | Version: 2.1
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
------------------------------------------+------------------------
Reference: https://code.djangoproject.com/ticket/29010#comment:7
The new autocomplete view uses whatever ordering the ModelAdmin specifies,
but most of the time you'd want autocomplete to be alphabetized so that
typeahead suggestions make more sense and can be scanned visually. My
particular use case is that I want certain admins to default to showing
the most recently edited objects, but this sort order makes no sense for
autocomplete views in lookups from related object change forms.
This seems like a common enough use case to warrant built-in decoupling of
sort order for autocomplete view from ModelAdmin's standard "ordering"
field.
Proposed improvement/feature would be an "autocomplete_ordering" field and
corresponding "get_autocomplete_ordering" method which default to using
the "ordering" but can be easily overridden, readily providing decoupling
when needed.
--
Ticket URL: <https://code.djangoproject.com/ticket/29700>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
autocomplete ordering from admin ordering
Reporter: David W. Lloyd | Owner: nobody
Type: New feature | Status: new
Component: contrib.admin | Version: 2.1
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Carlton Gibson):
* cc: Johannes Hoppe (added)
Comment:
The use-case here seems reasonable enough, but I'm (initially) sceptical
about adding yet more API to ModelAdmin.
If that weren't an option, what would I do?
Well, I'd look to customise the autocomplete view:
{{{
def autocomplete_view(self, request):
return AutocompleteJsonView.as_view(model_admin=self)(request)
}}}
Is there any reason I can't just override
[https://github.com/django/django/blob/233c70f0479beb3bff9027e6cff680882978fd4d/django/contrib/admin/views/autocomplete.py#L42-L48
`AutocompleteJsonView.get_queryset()`] to apply whatever ordering I need?
(It doesn't look like there is...)
`autocomplete_view()`/`AutocompleteJsonView`/&co are not documented, so
this ticket would amount to needing to add that (and maybe we make small
adjustments to the ModelAPI) but (for me, initially) this would help to
modularise the autocomplete options and be preferable to more top-level
ModelAdmin options.
Thoughts?
--
Ticket URL: <https://code.djangoproject.com/ticket/29700#comment:1>
Django
autocomplete ordering from admin ordering
Reporter: David W. Lloyd | Owner: nobody
Type: New feature | Status: new
Component: contrib.admin | Version: 2.1
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Johannes Hoppe):
Replying to [comment:1 Carlton Gibson]:
> The use case here seems reasonable enough, but I'm (initially) skeptical
about adding yet more API to ModelAdmin.
That is a reasonable concern. The `ModelAdmin` is practically exploding.
However that should not keep us from making changes, but only from blindly
adding features.
Maybe there is a better way though as you suggest later.
> If that weren't an option, what would I do?
>
> Well, I'd look to customise the autocomplete view:
>
> {{{
> def autocomplete_view(self, request):
> return AutocompleteJsonView.as_view(model_admin=self)(request)
> }}}
>
>
[https://github.com/django/django/blob/233c70f0479beb3bff9027e6cff680882978fd4d/django/contrib/admin/options.py#L1638-L1639
source]
>
> Is there any reason I can't just override
[https://github.com/django/django/blob/233c70f0479beb3bff9027e6cff680882978fd4d/django/contrib/admin/views/autocomplete.py#L42-L48
`AutocompleteJsonView.get_queryset()`] to apply whatever ordering I need?
(It doesn't look like there is...)
>
> `autocomplete_view()`/`AutocompleteJsonView`/&co are not documented, so
this ticket would amount to needing to add that (and maybe we make small
adjustments to the ModelAPI) but (for me, initially) this would help to
modularise the autocomplete options and be preferable to more top-level
ModelAdmin options.
>
> Thoughts?
That is not a bad way, this is how I would go about it myself too.
Actually this way you can add all sorts of extra functionality.
--
Ticket URL: <https://code.djangoproject.com/ticket/29700#comment:2>
Django
autocomplete ordering from admin ordering
Reporter: David W. Lloyd | Owner: nobody
Type: New feature | Status: new
Component: contrib.admin | Version: 2.1
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by David W. Lloyd):
Replying to [comment:2 Johannes Hoppe]:
> Replying to [comment:1 Carlton Gibson]:
> >
> > Thoughts?
>
> That is not a bad way, this is how I would go about it myself too.
Actually this way you can add all sorts of extra functionality.
I agree, that's a fine way to achieve the functionality, and if
AutocompleteJsonView gets a bit more documentation, I guess that would be
the default approach?
But my thinking is as follows: you can make the same exact argument about
the *existing* "ordering" field - why have it, when you can do the same
thing by modifying the queryset?
I personally believe the answer is: "Because it's a common enough use case
that having a dedicated field makes it easier, more intuitive, and more
explicit" - all of which are good things, and I think they apply to the
autocomplete sorting the same as they do the ModelAdmin sorting.
Yes, that comes at the cost of adding another field to the API, but that's
going to be the case with anything you want to make more
explicit/intuitive. If there was an interest in conserving fields, it
could be a dict? like:
{{{
autocomplete_view_options = {'ordering': 'name,
'other_useful_parameter_to_be_added_in_future': 'maybe?'}
}}}
...either way, while I see how to achieve the functionality in question
myself and will have no problem whatsoever doing so, I still believe that
the explicit decoupling would make sense, either via a single
"autocomplete_ordering" field or a dict of extensible options including,
initially, ordering.
--
Ticket URL: <https://code.djangoproject.com/ticket/29700#comment:3>
Django
customisation point).
--------------------------------------+------------------------------------
Reporter: David W. Lloyd | Owner: nobody
Component: Documentation | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Carlton Gibson):
* component: contrib.admin => Documentation
* version: 2.1 => master
* type: New feature => Cleanup/optimization
* stage: Unreviewed => Accepted
Comment:
> ...you can make the same exact argument about the *existing* "ordering"
field - why have it, when you can do the same thing by modifying the
queryset?
I think in the history of ModelAdmin itself, we've learnt that it's
possible to have ''too much of a good thing'' when it comes to these
declarative options.
`ordering` has been there forever, and there's no realistic way we can
take it out. **But** I don't think it's likely we'd add it again today.
Instead I think we'd point to overriding `get_queryset()`, and just using
a `orderBy`.
{{{
def get_queryset(self):
return self.model.objects.orderBy('-name')
}}}
(... or such ...)
That would do. It's roughly the same, or sometime less, code than
specifying `ordering` & co.
It's less magic. Less to remember. And less to have to go searching for
when things behave unexpectedly.
''Mutatis mutandis'', I think in this case we should document
`ModelAdmin.autocomplete_view()` and `AutocompleteJsonView` as the
customisation point for the behaviour here.
(If there are one or two key configuration options then **possibly**
`AutocompleteJsonView` could take init kwargs to `as_view()` to avoid
subclassing in every case, but any such addition would need assessing
separately, and probably afterwards.)
--
Ticket URL: <https://code.djangoproject.com/ticket/29700#comment:4>
Django
customisation point).
Reporter: David W. Lloyd | Owner: Alexandru
Type: | Balan
Cleanup/optimization | Status: assigned
Component: Documentation | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Alexandru Balan):
* owner: nobody => Alexandru Balan
* status: new => assigned
--
Ticket URL: <https://code.djangoproject.com/ticket/29700#comment:5>
Django
customisation point).
-------------------------------------+-------------------------------------
Reporter: David W. Lloyd | Owner: Alexandru
Type: | Balan
Cleanup/optimization | Status: assigned
Component: Documentation | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Tim Graham):
* has_patch: 0 => 1
Comment:
[https://github.com/django/django/pull/11045 PR]
--
Ticket URL: <https://code.djangoproject.com/ticket/29700#comment:6>
Django
customisation point).
-------------------------------------+-------------------------------------
Reporter: David W. Lloyd | Owner: Alexandru
Type: | Balan
Cleanup/optimization | Status: assigned
Component: Documentation | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
Changes (by Tim Graham):
* needs_better_patch: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/29700#comment:7>
Django
customisation point).
-------------------------------------+-------------------------------------
Reporter: David W. Lloyd | Owner: Alexandru
Type: | Balan
Cleanup/optimization | Status: assigned
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
Comment (by Denis Cornehl):
Since `ModelAdmin.autocomplete_view` [is gone since Django 3.2, and this
commit](https://github.com/django/django/commit/3071660acfbdf4b5c59457c8e9dc345d5e8894c5),
we can actually close this ticket, right?
[https://github.com/django/django/commit/3071660acfbdf4b5c59457c8e9dc345d5e8894c5]
--
Ticket URL: <https://code.djangoproject.com/ticket/29700#comment:8>
Django
customisation point).
-------------------------------------+-------------------------------------
Reporter: David W. Lloyd | Owner: Alexandru
Type: | Balan
Component: Documentation | Version: dev
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage:
| Someday/Maybe
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Johannes Maron):
* status: assigned => closed
* needs_better_patch: 1 => 0
* has_patch: 1 => 0
* resolution: => wontfix
* stage: Accepted => Someday/Maybe
Comment:
I must agree, the view does not exist anymore, or rather has been moved.
It also has become a lot more complex and doesn't seem suited for user
extension.
If anyone feels strongly about adding docs for the new implementation,
feel free to reopen the issue for review.
--
Ticket URL: <https://code.djangoproject.com/ticket/29700#comment:9>
Django
customisation point).
-------------------------------------+-------------------------------------
Reporter: David W. Lloyd | Owner: Alexandru
Type: | Balan
Component: Documentation | Version: dev
Severity: Normal | Resolution:
| Someday/Maybe
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by rossettistone):
* status: closed => new
* resolution: wontfix =>
Comment:
From what I can tell, removing `ModelAdmin.autocomplete_view` closed a
pretty clean (if undocumented) option for modifying the label of items
returned in the autocomplete Admin form. This Stack Overflow post
illustrates: https://stackoverflow.com/questions/55629887/change-django-
autocomplete-fields-label
After some exploration, I haven't found another way to accomplish the same
thing, i.e. providing a custom label for the admin autocomplete view
without just overriding the `__str__` method on the model itself (which is
rather heavy-handed).
I don't know enough to write docs on this issue myself, but I think that
documentation of the new pattern (or another way to edit autocomplete form
labels) would be very helpful.
--
Ticket URL: <https://code.djangoproject.com/ticket/29700#comment:10>
Django
customisation point).
-------------------------------------+-------------------------------------
Reporter: David W. Lloyd | Owner: Alexandru
Type: | Balan
Component: Documentation | Version: dev
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage:
| Someday/Maybe
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Mariusz Felisiak):
* status: new => closed
* resolution: => wontfix
Comment:
I appreciate you'd like to reopen the ticket, but please
[https://docs.djangoproject.com/en/stable/internals/contributing/triaging-
tickets/#closing-tickets follow the triaging guidelines with regards to
wontfix tickets] and take this to DevelopersMailingList.
--
Ticket URL: <https://code.djangoproject.com/ticket/29700#comment:11>
Django
customisation point).
-------------------------------------+-------------------------------------
Reporter: David W. Lloyd | Owner: Alexandru
Type: | Balan
Cleanup/optimization | Status: closed
Component: Documentation | Version: dev
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage:
| Someday/Maybe
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by rossettistone):
Thanks, Mariusz. Was reopening (rather than filing a new ticket) based on
the above request from Johannes Maron.
I'll follow the links that you posted and proceed from there.
--
Ticket URL: <https://code.djangoproject.com/ticket/29700#comment:12>