Re: Permission hooks in class-based views

[fordprefect]

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

Re: Permission hooks in class-based views

[Russell Keith-Magee]

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.