#30149: Empty value selected check in Admin Filter prevents subclassing
--------------------------------------+------------------------------------
Reporter: Sardorbek Imomaliev | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: contrib.admin | Version: master
Severity: Normal | Resolution:
Keywords: admin | 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):
* version: 2.1 => master
* type: Uncategorized => Cleanup/optimization
* stage: Unreviewed => Accepted
Comment:
Hmmm. Not sure...
* Given that you **can** currently set any value at all in the query
string to have `Empty` filtering working, it's guaranteed that people
**will** be doing just that. So if we start comparing against the string
`'True'` we'll be breaking someone's site.
We might argue, "well they shouldn't do that" but I look at this, which is
what we're doing (in e.g. `RelatedFieldListFilter.__init__()`):
{{{
self.lookup_val_isnull = request.GET.get(self.lookup_kwarg_isnull)
}}}
...and I think we **should** be using a form to process the raw `GET`,
validate it and extract the value **as a boolean**.
(I know we trust users in the admin but it's raw user input...)
So there's various **shoulds** floating around. I'm not clear that one
trumps the other at this point in time.
So questions:
* what does the subclass look like overriding `__init__()` to use a form
to process the GET parameter as boolean?
If it's not too bad, we might still say `wontfix`. However...
* Does anything break in the test suite if we make that change in the
existing filters?
If not, we could probably make the change.
If there are BC issues, we could maybe use a widget that accepted
''Obviously False'' values as `False` (e.g. `'False'`, `'0'` el al) with
everything else as `True`.
> Would it be ok if I provide fix?
Yep. Always. 🙂
I'll `Accept` this now, on the basis that you want to work on it, and that
the implementation doesn't raise any issues. (It may be we have to decline
in the end, but it should be OK, at first glance.)
Thanks!
--
Ticket URL: <https://code.djangoproject.com/ticket/30149#comment:5>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" 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].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/067.6e1c8ff8aabd459588c309255042f65e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
