Sent from my iPad
On 12/06/2010, at 7:15 AM, Simon Meers <drme...@gmail.com> wrote: >>> * Permissions - from my initial inspection, it isn't obvious to me >>> that you are honoring (and/or testing that you are honoring) >>> permissions. If I don't have permission to edit an object, I shouldn't >>> get an edit link. Given the addition in 1.2 of object-level >>> permissions, this means permissions need to be per-object. Have I >>> missed something in my hasty patch read? >> >> Correct; no permissions checking is performed at present. In some >> places checking would be almost impossible given the current code >> architecture, so I had hoped to avoid it if possible. This was one of >> the main points I wanted feedback on. > > Here is a more detailed explanation of why permission checking has > been omitted for now: > > * The "add-another" link (green plus) next to ForeignKey widgets is > appended to the HTML output in the render() method. This currently has > no access to the User, so cannot determine permissions. The > "add-another" link (and new "edit" link) will therefore be displayed > regardless of the current user's add/change permissions for the > related object. This should certainly be dealt with, but this ticket > does not appear to the the appropriate place to do so. Ticket #1035 > [1] addresses this issue. > > * The "edit separately" links on inlines could perform checking using > a templatetag, perhaps. Again, however, I'm not sure that this is the > place to deal with this as larger issues exist -- currently a user can > add/change inlines even if they do not possess permissions for the > inline model. Ticket #8060 [2] addresses this issue. > > So the current patch for #13163 and #13165 [3] seems to solve the > issues in a manner which fits with the rest of the admin interface as > it currently stands. Permission issues should certainly be dealt with, > but separately I believe. I think [3] could be committed as is > (pending review), and permission controls added as the other tickets > are resolved. Currently all this means is that people might see an > edit link, click on it, then get a "permission denied" message -- > though in the relatively rare cases where a related object is > registered in the same admin site but the user doesn't have permission > to change it. My perspective is the other way around. We already have permission problems, which have been exacerbated by the introduction of row-based permission hooks. IMHO, before we start adding extra entry points where permissions can be wrong, we should get our house in order. I appreciate that this is an impediment to you getting your changes into trunk, but personally, I'd rather see less bugs (especially when those bugs relate to something as important as permissions) than more features. > IMHO the UX improvements in [3] are worth getting on board ASAP. No argument from me on this - absent of other problems, they strike me as worthwhile changes. I just think we should fix the other problems first. > Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
