Permission hooks in class-based views
Hi, looking at the new class-based views for 1.3, there doesn't appear to be an easy way to add row-level permission hooks to the views (as one can do in ModelAdmin). It seems a strange omission as this should be quite straightforward and is an extremely common use-case. For example, if I have a BlogPostEditView I should be able to specify a has_permission() method, e.g.: class BlogPostEditView(UpdateView): def has_permission(self, inst): return request.user.id == inst.author_id Are row-level permissions in the works for class-based views ? -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Permission hooks in class-based views
On Sat, Feb 19, 2011 at 6:28 PM, fordprefect wrote: > Hi, looking at the new class-based views for 1.3, there doesn't appear > to be an easy way to add row-level permission hooks to the views (as > one can do in ModelAdmin). It seems a strange omission as this should > be quite straightforward and is an extremely common use-case. > > For example, if I have a BlogPostEditView I should be able to specify > a has_permission() method, e.g.: > > class BlogPostEditView(UpdateView): > > def has_permission(self, inst): > return request.user.id == inst.author_id > > > Are row-level permissions in the works for class-based views ? The intention for 1.3 was to get a class-based view framework in place that could serve as a replacement for the existing function-based generic views. Since the function-based generics don't have permissions, neither does the initial iteration of class-based views. At this point in the 1.3 cycle, there aren't any new feature plans for class-based views -- we're just making sure that there aren't any glaring bugs in what is already in trunk. Once we start the 1.4 cycle, we can take a closer look at suggestions like adding permission support to CBVs. If this topic is something that you have a particular interest in, I encourage you to tinker with the code that is there and see if you can develop a concrete proposal for this feature; that way, when formal feature discussions start, you'll be in a good position to drive a discussion. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Permission hooks in class-based views
> > The intention for 1.3 was to get a class-based view framework in place > that could serve as a replacement for the existing function-based > generic views. Since the function-based generics don't have > permissions, neither does the initial iteration of class-based views. That's fair enough. > Once we start the 1.4 cycle, we can take a closer look at suggestions > like adding permission support to CBVs. If this topic is something > that you have a particular interest in, I encourage you to tinker with > the code that is there and see if you can develop a concrete proposal > for this feature; that way, when formal feature discussions start, > you'll be in a good position to drive a discussion. For most cases, using a user-specific queryset would be enough, for example: class BlogPostUpdateView(UpdateView): def get_queryset(self): return self.request.user.blogpost_set.all() Which would restrict the ability to update only one's own blog posts. For more specific requirements, a possible SecureMixin could do a post- lookup check through a has_permission() check. The problem then is how to handle non-permitted cases - probably another hook would be required, with a default behaviour being e.g. redirect to login. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
