#15103: Django 1.2.4 breaks limit_choices_to for raw_id_fields
-------------------------------------------+--------------------------------
Reporter: natrius | Owner: nobody
Status: new | Milestone: 1.3
Component: django.contrib.admin | Version: 1.2
Resolution: | Keywords: blocker regression
send_mail email
Stage: Accepted | Has_patch: 0
Needs_docs: 0 | Needs_tests: 0
Needs_better_patch: 0 |
-------------------------------------------+--------------------------------
Comment (by lukeplant):
Russell,
I'd argue that with `limit_choices_to` we need to err on the side of
caution, for the following reasons:
* `list_filter` etc is an '''explicit''' control enabling filtering in
the admin, while `limit_choices_to` is at best implicit.
* `limit_choices_to` is actually a model/database level constraint, not
application level, and would be useful if the admin didn't exist, so it is
not obvious that its behaviour affects the filtering available in the
admin changelist at all - and in fact only needs to do so because of raw
id fields, which are not the default.
* `list_filter` etc are defined in the `ModelAdmin` for the model in
question, whereas `limit_choices_to` is defined in (any number of)
completely separate models.
So, suppose I am allowing `MyModel` to be viewed in the admin changelist
by some users, and supposed I then add `some_other_app.SomeModel` to my
project, which doesn't even have an admin interface, but has a foreign key
to `MyModel`, with `limit_choices_to` set. It really isn't obvious that
this addition could change the behaviour of the admin for `MyModel` '''at
all''', since that isn't necessary, and it could be argued that any change
would be a bug. It also isn't likely to be the kind of hole that anyone
will catch, because it's unlikely that anyone will have sufficient
overview of all the models to spot the potential information leaks. I
therefore think we need to be as conservative as possible in what we allow
here.
Also, I think the example I have above was better than the example in the
test. In the example above, if the Tour changelist showed the leader's
name, then allowing filtering of `Holiday` on any `leader__status` would
easily allow you to find the status of any leader that was associated with
at least one Tour. Now, although the interface is fairly obviously
exposing all those leaders who are `Expert` and those who are not, and
that is difficult to avoid, you might not want the other distinctions to
be visible.
In fact, consider the case where one person can access the admin to
view/edit `Tour` objects, but that is all. With my proposed patch, we
already have the problem that they can find out which leaders have
status=2. For some applications, this might be bad enough in itself, and I
don't think we should open this up more than it has to be opened.
--
Ticket URL: <http://code.djangoproject.com/ticket/15103#comment:7>
Django <http://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 post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en.
