Re: adding permission_required decorator for class based view

2022-02-09 Thread 'Adam Johnson' via Django developers (Contributions to Django itself) 
Additionally, it's always possible to apply decorators to CBV's like this:

class MyView(...):
...

my_view = some_decorator(MyView.as_view())

Then use my_view in your urls.py. This works because as_view() returns the
"real view" function.

...and you can use method_decorator like this:

@method_decorator(some_decorator, name='dispatch')
class MyView(...):
...

I think you then don't have to define a local dispatch in this case - the
super version will be copied and wrapped.

On Wed, Feb 9, 2022 at 7:30 PM Albert  wrote:

> Hi,
>
> For class based views there are mixins, LoginRequiredMixin,
> PermissionRequiredMixin which give the same functionality.
>
> https://docs.djangoproject.com/en/4.0/topics/auth/default/#the-loginrequired-mixin
>
> https://docs.djangoproject.com/en/4.0/topics/auth/default/#the-permissionrequiredmixin-mixin
>
>
> Why don't use them? Decorators are for function based views not for class
> based views.
>
> Regards,
> Albert
>
> Hi,
>
> as of today, adding a permission_required and / or a login_required
> decorator on a class based view is a bit ugly, as you have to decorate the
> dispatch method, which you then have to write down in your class.
> On top of that, you can't directly use the decorator itself, as you have
> to wrap it in the method_decorator decorator so it can be applied to a
> class method instead of a free running function.
>
> The problem is that none of those things you have to do in order to use
> the permission_required and / or login_required decorator are linked to
> permission / login logic. It's needed only because there's not a proper
> place to put those decorator, and you can't use them as class decorator.
>
> Another problem is that some people might find it a bit weird, and only
> apply those decorator to a specific method, like get or post, which, if it
> works, isn't covering other method and might become an issue. It's also not
> consistent with the function based decorator which cover any http methods
> at once.
>
> In our team, we refactored it a little bit so we could use a class
> decorator instead. It is much more consistent with the function based view
> logic, and requires much less code to implement.
>
> for the permission_required, it looks like that:
> ```
> from django.contrib.auth.decorators import permission_required as pr
> from django.utils.decorators import method_decorator
>
>
> def method_permission_decorator(permission, login_url):
> return method_decorator(pr(permission, login_url=login_url))
>
> def permission_required(permission, login_url="/admin/login"):
> # build the specific permissions to use
> specific_permissions = method_permission_decorator(permission,
> login_url)
> def wrapper(cls):
> # decorate the dispatch method with the specific permissions we set
> cls.dispatch = specific_permissions(cls.dispatch)
> return cls
> return wrapper
> ```
>
> This is specific to our needs of course, but I think it's easy to make
> more generic, and would add value other teams could benefit from.
>
> What it allows is to replace :
>
> ```
> class MyView(View):
> # my code here
> @method_decorator(permission_required(perm))
> def dispatch(self, *args, **kwargs):
> return super().dispatch(*args, **kwargs)
> ```
>
> by this
>
> ```
> @permission_required(perm)
> class MyView(View):
> # my code here
>
> ```
>
> Now, idk if it would make more sense to have another decorator
> class_permission_required or to have the permission_required decorator
> tweaked to work with class too, but no matter what's best on that regard, i
> think it would be a valuable change.
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/9529f8c7-e6b4-48e0-8941-efb0123cd5d2n%40googlegroups.com
> 
> .
>
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/ppgmuepmxqoefbmikovf%40eywg
> 
> .
>

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

adding permission_required decorator for class based view

2022-02-09 Thread Albert 
Hi,For class based views there are mixins, LoginRequiredMixin, 
PermissionRequiredMixin which give the same 
functionality.https://docs.djangoproject.com/en/4.0/topics/auth/default/#the-loginrequired-mixinhttps://docs.djangoproject.com/en/4.0/topics/auth/default/#the-permissionrequiredmixin-mixinWhy
 don't use them? Decorators are for function based views not for class based 
views.Regards,AlbertHi,as of today, adding a permission_required and / or a 
login_required decorator on a class based view is a bit ugly, as you have to 
decorate the dispatch method, which you then have to write down in your 
class.On top of that, you can't directly use the decorator itself, as you have 
to wrap it in the method_decorator decorator so it can be applied to a class 
method instead of a free running function.The problem is that none of those 
things you have to do in order to use the permission_required and / or 
login_required decorator are linked to permission / login logic. It's needed 
only because there's not a proper place to put those decorator, and you can't 
use them as class decorator.Another problem is that some people might find it a 
bit weird, and only apply those decorator to a specific method, like get or 
post, which, if it works, isn't covering other method and might become an 
issue. It's also not consistent with the function based decorator which cover 
any http methods at once.In our team, we refactored it a little bit so we could 
use a class decorator instead. It is much more consistent with the function 
based view logic, and requires much less code to implement.for the 
permission_required, it looks like that:```from django.contrib.auth.decorators 
import permission_required as prfrom django.utils.decorators import 
method_decoratordef method_permission_decorator(permission, login_url):  
  return method_decorator(pr(permission, login_url=login_url))def 
permission_required(permission, login_url="/admin/login"):    # build 
the specific permissions to use    specific_permissions = 
method_permission_decorator(permission, login_url)    def 
wrapper(cls):        # decorate the dispatch method with 
the specific permissions we set        cls.dispatch = 
specific_permissions(cls.dispatch)        return cls  
  return wrapper```This is specific to our needs of course, but I think 
it's easy to make more generic, and would add value other teams could benefit 
from.What it allows is to replace :```class MyView(View):    # my 
code here    @method_decorator(permission_required(perm))  
  def dispatch(self, *args, **kwargs):        return 
super().dispatch(*args, **kwargs)```by this```@permission_required(perm)class 
MyView(View):    # my code here```Now, idk if it would make more 
sense to have another decorator class_permission_required or to have the 
permission_required decorator tweaked to work with class too, but no matter 
what's best on that regard, i think it would be a valuable change.



-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/9529f8c7-e6b4-48e0-8941-efb0123cd5d2n%40googlegroups.com.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ppgmuepmxqoefbmikovf%40eywg.

adding permission_required decorator for class based view

2022-02-09 Thread Martin Milon 
Hi,

as of today, adding a permission_required and / or a login_required 
decorator on a class based view is a bit ugly, as you have to decorate the 
dispatch method, which you then have to write down in your class.
On top of that, you can't directly use the decorator itself, as you have to 
wrap it in the method_decorator decorator so it can be applied to a class 
method instead of a free running function.

The problem is that none of those things you have to do in order to use the 
permission_required and / or login_required decorator are linked to 
permission / login logic. It's needed only because there's not a proper 
place to put those decorator, and you can't use them as class decorator.

Another problem is that some people might find it a bit weird, and only 
apply those decorator to a specific method, like get or post, which, if it 
works, isn't covering other method and might become an issue. It's also not 
consistent with the function based decorator which cover any http methods 
at once.

In our team, we refactored it a little bit so we could use a class 
decorator instead. It is much more consistent with the function based view 
logic, and requires much less code to implement.

for the permission_required, it looks like that:
```
from django.contrib.auth.decorators import permission_required as pr
from django.utils.decorators import method_decorator


def method_permission_decorator(permission, login_url):
return method_decorator(pr(permission, login_url=login_url))

def permission_required(permission, login_url="/admin/login"):
# build the specific permissions to use
specific_permissions = method_permission_decorator(permission, 
login_url)
def wrapper(cls):
# decorate the dispatch method with the specific permissions we set
cls.dispatch = specific_permissions(cls.dispatch)
return cls
return wrapper
```

This is specific to our needs of course, but I think it's easy to make more 
generic, and would add value other teams could benefit from.

What it allows is to replace :

```
class MyView(View):
# my code here
@method_decorator(permission_required(perm))
def dispatch(self, *args, **kwargs):
return super().dispatch(*args, **kwargs)
```

by this

```
@permission_required(perm)
class MyView(View):
# my code here

```

Now, idk if it would make more sense to have another decorator 
class_permission_required or to have the permission_required decorator 
tweaked to work with class too, but no matter what's best on that regard, i 
think it would be a valuable change.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/9529f8c7-e6b4-48e0-8941-efb0123cd5d2n%40googlegroups.com.

Re: TypeError: __init__() got an unexpected keyword argument 'name'

2022-02-09 Thread 'Adam Johnson' via Django developers (Contributions to Django itself) 
Hi!

I think you've found the wrong mailing list for this post. This mailing
list is for discussing the development of Django itself, not for support
using Django. This means the discussions of bugs and features in Django
itself, rather than in your code using it. People on this list are unlikely
to answer your support query with their limited time and energy.

For support, please follow the "Getting Help" page:
https://docs.djangoproject.com/en/stable/faq/help/ . This will help you
find people who are willing to support you, and to ask your question in a
way that makes it easy for them to answer.

Thanks for your understanding and all the best,

Adam

On Tue, Feb 8, 2022 at 7:23 PM Meerim  wrote:

>  File
> "/home/meerim/sushi-drf2/venv/lib/python3.8/site-packages/django_filters/filters.py",
> line 137, in field
> self._field = self.field_class(label=self.label, **field_kwargs)
>   File
> "/home/meerim/sushi-drf2/venv/lib/python3.8/site-packages/django/forms/fields.py",
> line 332, in __init__
> super().__init__(max_value=max_value, min_value=min_value, **kwargs)
>   File
> "/home/meerim/sushi-drf2/venv/lib/python3.8/site-packages/django/forms/fields.py",
> line 256, in __init__
> super().__init__(**kwargs)
> TypeError: __init__() got an unexpected keyword argument 'name'
> [08/Feb/2022 19:17:51] "GET /coupon HTTP/1.1" 500 134802
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/524463f8-8a8c-444b-8c40-7b122998eb7cn%40googlegroups.com
> 
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM376Mb%2BWOkfuthQ24BoMc7194QapNGgp4WX1FscSK63vw%40mail.gmail.com.