>> * 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. IMHO the UX improvements in [3] are worth getting on board ASAP. Simon [1] http://code.djangoproject.com/ticket/1035 [2] http://code.djangoproject.com/ticket/8060 [3] http://code.djangoproject.com/attachment/ticket/13163/combined_13163_13165.diff -- 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.
