#8060: Admin Inlines do not respect user permissions
-------------------------------------+-------------------------------------
Reporter: | Owner: sjaensch
p.patruno@… | Status: assigned
Type: Bug | Component: contrib.admin
Milestone: | Severity: Normal
Version: SVN | Keywords: inlines User
Resolution: | authentication
Triage Stage: Accepted | Has patch: 1
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 1 | Easy pickings: 0
UI/UX: 0 |
-------------------------------------+-------------------------------------
Comment (by carljm):
Replying to [comment:21 sjaensch]:
> 1. This is a very good point. I was not sure about how I should split
them up. Should I create multiple methods on TestInline or should I go and
create a separate TestCase class for it?
You could go either way; it'll be enough related test methods that I'd
probably make a new `TestCase`.
> 3. Good point! I Hadn't thought about that. I'll post a patch tomorrow
with the changed behavior. One point to consider though: We then cannot
restrict adding additional relationships (or disallow the editing of
existing relationships) for auto-created intermediate m2m models. I think
treating the through relationship as if it were the destination model
might be better semantics. The through model is hidden from the user (as
well as the programmer) anyway, that's why there are no permissions for
it. But that's just my personal opinion, I'll gladly defer to your
judgment. Or should we ask on django-developers what the others prefer?
I'm pretty sure treating the through model as if it were the destination
model is not the right semantic. Consider the M2M relationship between,
say, `FlatPage` and `Site` (if it used inlines, which it doesn't by
default). If someone is forbidden from deleting `Site` objects, there's no
reason that should imply they can't remove a given `FlatPage` from a
particular site. Removing a `FlatPage` relationship is, if anything, a
change to a `Site` - it certainly isn't equivalent to deleting a `Site`.
I know this means we wouldn't be able to have granular permissions on an
auto-created through model, but really that's just the consequence of
auto-created through models not having their own permissions. Tying it
directly to the permissions of the destination model doesn't help, it just
moves the problem (and IMO makes it more clearly incorrect): I'd have no
way to prevent someone from deleting Sites without also preventing them
from removing a `FlatPage` from a site.
If you still aren't convinced, you're welcome to raise it on django-
developers and see what other opinions you get!
--
Ticket URL: <https://code.djangoproject.com/ticket/8060#comment:22>
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 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.
