Re: Permission classes for Class Based Views

[Marc Tamlyn]

I don't feel there is any need for this feature in Django. As you mention
in the ticket, there are ways of approaching it used in DRF, there are
other ways in django-braces[0], I personally have my own taste in how to
handle it. The details will depend on the logic necessary - sometimes you
need to load objects to check permission, sometimes you don't. There is no
one size fits all approach.

[0]
http://django-braces.readthedocs.io/en/latest/access.html#permissionrequiredmixin

On 16 March 2017 at 20:10,  wrote:

> Hello, my first post here!
>
> This post is about a new feature request I'd like to propose and it's
> about permission classes (just like I've stated in topic) for CBVs. I've
> provided most of the technical information at [0], because I think that
> such information is more ticket-specific, however I'm not sure if what I
> did is a correct way, because docs say that feature requests should begin
> their lifespan at the mailing list. Well, anyway basically saying the
> reason to have it in core Django is to make managing "who can do what" in a
> simpler, faster and more expendable manner.
>
> I believe that everything that we need to discuss the matter is already at
> [0] so I'd be extremely happy if somebody would reply with some thoughts
> about it.
>
> [0] https://code.djangoproject.com/ticket/27950
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/django-developers/605eddf3-147a-4e39-a9fb-
> 4e40f055c4d6%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1ECf3cgaZxxN6D530v-cig2m%3D3KdVfDuow1rZZrTQQirQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Permission classes for Class Based Views

[piotr . szpetkowski]

Hello, my first post here!

This post is about a new feature request I'd like to propose and it's about 
permission classes (just like I've stated in topic) for CBVs. I've provided 
most of the technical information at [0], because I think that such 
information is more ticket-specific, however I'm not sure if what I did is 
a correct way, because docs say that feature requests should begin their 
lifespan at the mailing list. Well, anyway basically saying the reason to 
have it in core Django is to make managing "who can do what" in a simpler, 
faster and more expendable manner.

I believe that everything that we need to discuss the matter is already at 
[0] so I'd be extremely happy if somebody would reply with some thoughts 
about it.

[0] https://code.djangoproject.com/ticket/27950

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/605eddf3-147a-4e39-a9fb-4e40f055c4d6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

To keep or not to keep: logging of undefined template variables

[Tim Graham]

Ticket #18773 [0] added logging of undefined template variables in Django 
1.9 [1], however, I've seen several reports of users finding this logging 
more confusing than helpful. For example, admin templates log errors about 
missing is_popup variables [2] which is how the template are designed 
(is_popup is only in the contexts of pop ups) and the 
TECHNICAL_404_TEMPLATE also logs errors without any obvious solution about 
how to prevent that [3].

I'm thinking it might be better to remove this noisy, generally unhelpful 
logging. What do you think?

[0] https://code.djangoproject.com/ticket/18773
[1] 
https://github.com/django/django/commit/dc5b01ad05e50ccde688c73c2ed3334a956076b0
[2] https://groups.google.com/d/topic/django-users/6Ve9dcv23sI/discussion
[3] https://code.djangoproject.com/ticket/26886

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a428f373-ef0c-4575-8a84-69a4beda154c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.