>
> 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 [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-users?hl=en.
