#17985 closed New feature (fixed)
Document ModelAdmin.lookup_allowed()
Reported by: | 3point2 | Owned by: | Simon Meers |
---|---|---|---|
Component: | Documentation | Version: | 1.4 |
Severity: | Normal | Keywords: | |
Cc: | lemaire.adrien@…, zborboa@… | Triage Stage: | Accepted |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
Right now, as a result of the security fix introduced in r15031, the only way to allow querystring lookups across relationships in the admin is to whitelist them by including them in list_filter.
However, in my application the lookup that needs to be whitelisted generates a huge filter widget as it contains thousands of instances.
It would be helpful if I could whitelist the exact lookup I need to link to without having to generate the filter widget itself.
Something like
class MyModelAdmin(ModelAdmin): allow_lookup = ["fieldname__id__exact"]
would do. If the developers agree this is useful functionality, I could write a patch.
Change History (18)
comment:1 by , 13 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
comment:2 by , 13 years ago
Resolution: | wontfix |
---|---|
Status: | closed → reopened |
Sorry to re-open. I'm fine with overriding lookup_allowed, but I opened this ticket because I feel like this is a feature that is generally useful, and lookup_allowed is undocumented. I feel like this functionality should be officially supported, and overriding an undocumented method is more of a work-around. Also see http://www.hoboes.com/Mimsy/hacks/fixing-django-124s-suspiciousoperation-filtering/lookup_allowed-gets-new-parameter-value/
At the very least, documenting lookup_allowed would be helpful.
If on the other hand you feel that this functionality is not a common use case, I'm fine with closing the ticket and sticking with the work around.
comment:3 by , 13 years ago
Cc: | added |
---|---|
Easy pickings: | set |
Needs documentation: | set |
Summary: | Add additional lookup_allowed whitelist functionality to ModelAdmin → Add documentation for the lookup_allowed method |
Triage Stage: | Unreviewed → Accepted |
Renamed the ticket: Improving the documentation is a good idea.
comment:4 by , 13 years ago
Triage Stage: | Accepted → Design decision needed |
---|
I'm not sure we want to document this method yet. It has been introduced recently (in 1.2.4) to fix a security issue, and has been modified quite a bit since then, so it's quite unstable. At the very least, this needs more thought before we make it part of the official API.
comment:5 by , 12 years ago
Component: | contrib.admin → Documentation |
---|
comment:6 by , 12 years ago
Status: | reopened → new |
---|
comment:7 by , 12 years ago
Easy pickings: | unset |
---|---|
Triage Stage: | Design decision needed → Accepted |
Julien, do you think lookup_allowed can be considered stable now?
comment:8 by , 8 years ago
Cc: | added |
---|
comment:9 by , 7 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
Discussed in https://github.com/django/django/pull/8856
comment:10 by , 7 years ago
See https://github.com/django/django/pull/8904
Though I suspect I didn't actually need to create three separate pull requests for the three (dependent but distinct) commits?
comment:11 by , 7 years ago
Has patch: | set |
---|---|
Needs documentation: | unset |
comment:12 by , 7 years ago
Patch needs improvement: | set |
---|---|
Summary: | Add documentation for the lookup_allowed method → Document ModelAdmin.lookup_allowed() |
I suppose your thinking was that since ModelAdmin.lookup_allowed()
isn't documented, it's okay to make a backwards-incompatible change in adding the request
argument without a deprecation? Lately, Django has been more conservative about changing undocumented APIs without a deprecation if there's evidence that the API is at least somewhat widely used by projects. A GitHub code search reveals that's probably the case here.
If I were writing a patch, I would first document ModelAdmin.lookup_allowed()
as it is now and backport that documentation to 1.11. (A separate pull request would ease merging that incrementally). Then I'd implement a deprecation and corresponding documentation changes for adding the request
argument as part of #22569.
comment:13 by , 7 years ago
Thanks Tim, sounds like a good approach. Here is a documentation patch for the current implementation to start with: https://github.com/django/django/pull/8906
comment:14 by , 7 years ago
Patch needs improvement: | unset |
---|
comment:15 by , 7 years ago
So the deprecation would involve:
- Adding a heads-up in
internals/deprecation.txt
thatrequest
will be required in2.0
(or do we have to go further ahead --2.1
?) - Adding code to
lookup_allowed
in the current implementation that accepts both parameter formats (with/without request) and provides a deprecation warning if request is absent -- can this be in1.11
, or does that need to be in2.0
? - Then performing the change in https://github.com/django/django/pull/8904 (and removing the deprecation warning)
- Hopefully https://github.com/django/django/pull/8903 can be merged in the meanwhile to close #28496 and lay the foundation for the simpler patch for #22569?
comment:16 by , 7 years ago
The deprecation should start in Django 2.0 and request
would be required in Django 3.0 (use RemovedInDjango30Warning
). You may find the checklist for Deprecating a feature helpful.
I plan to look at the patch for #28496 tomorrow.
Thanks for the suggestion, but you can already easily achieve this by overriding the
ModelAdmin.lookup_allowed()
method. So there is no need for introducing a new class attribute.