> > 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.