Re: Deprecate is_superuser, is_staff and is_active

2017-03-29 Thread guettli 
Thank you for the inspiring conversation.

Am Dienstag, 28. März 2017 14:31:33 UTC+2 schrieb Melvyn Sopacua:
>
>
>   
>
> From an object perspective, you need to send the invoice to the group 
> "Approvers". Again, best solved at the group level.
>
> And it's questionable if superusers should be in there. They are the 
> equivalent of the Posix 'root' user, which has the power to lock/unlock 
> everything in and about the system. Data privilege and system privilege are 
> always in fight and in this case it's questionable if superusers should 
> automatically be Approvers and while they still could do it, the UI 
> shouldn't present them.
>
>

My favorite search engine did not reveal much to the topic "Data privilege 
vs system privilege". Do you have any further readings about this topic?



 

>  
>
> As said, a good group structure solves a lot of your problems -
>
>  
>


Yes, groups exist as container/list data type for users.

On the other hand just because groups exist, I think there are other ways 
to specify a list of users. Example: All people with a particular OCEAN 
Vector 

> in fact you wouldn't need a user selection to begin with, as the mail can 
simply be sent to all members of the Approvers group.

A mail to everyone is like a mail to no one (not always, but often).

Again  system vs data privs ... sounds interesting.

Regards,
  Thomas Güttler

-- 
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/12b2c209-3e24-4cc9-b7e2-40df744d92c2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Deprecate is_superuser, is_staff and is_active

2017-03-28 Thread Melvyn Sopacua 
On Tuesday 28 March 2017 03:52:59 guettli wrote:
> Am Montag, 27. März 2017 16:11:06 UTC+2 schrieb Melvyn Sopacua:
> > On Friday 24 March 2017 04:31:32 guettli wrote:
> > > I know this is a crazy idea, and it will get the "won't fix" tag
> > > very
> > > 
> > > soon.
> > > 
> > > 
> > > 
> > > Nevertheless I want to speak it out.
> > > 
> > > 
> > > 
> > > My use case: Get a queryset of users who have a given permission.
> > 
> > I'm still thinking about this use case.
> > 
> > Cause it's not for normal use - you don't normally use permissions
> > as
> > data, you use permissions to deny / allow access to data.
> > 
> > So, you're already in the "specialized" corner.
> 
> I can use more words, to make this use case more colorful.
> 
> Imagine a approval workflow: Only some users are allowed to do the
> approval.
> 
> An invoice instance needs to be forwarded to someone with the matching
> permissions.

>From an object perspective, you need to send the invoice to the group 
>"Approvers". 
Again, best solved at the group level.
And it's questionable if superusers should be in there. They are the equivalent 
of the 
Posix 'root' user, which has the power to lock/unlock everything in and about 
the 
system. Data privilege and system privilege are always in fight and in this 
case it's 
questionable if superusers should automatically be Approvers and while they 
still could 
do it, the UI shouldn't present them.

As said, a good group structure solves a lot of your problems -  in fact you 
wouldn't 
need a user selection to begin with, as the mail can simply be sent to all 
members of 
the Approvers group.

-- 
Melvyn Sopacua

-- 
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/1596191.7V5LMPvmps%40devstation.
For more options, visit https://groups.google.com/d/optout.

Re: Deprecate is_superuser, is_staff and is_active

2017-03-28 Thread Anssi Kääriäinen 
If you want to query for each user with given permission, then the query 
seems to be this (unfortunately not tested as I don't have a nice database 
to test this against):

users = User.objects.filter(
Q(is_superuser=True) |

Q(pk__in=Group.objects.filter(permissions=permission).values('user__pk')) |

Q(pk__in=Permission.objects.filter(id=permission.pk).values('user__pk')))

I can't see how removing the is_superuser attribute would make this query 
more efficient. And, it's likely the query you were using is slow because 
it doesn't use subqueries. It would be nice to make Django use subqueries 
automatically, but for queryset API reasons that's hard to do.

 - Anssi

On Tuesday, March 28, 2017 at 1:53:00 PM UTC+3, guettli wrote:
>
>
>
> Am Montag, 27. März 2017 16:11:06 UTC+2 schrieb Melvyn Sopacua:
>>
>> On Friday 24 March 2017 04:31:32 guettli wrote:
>>
>> > I know this is a crazy idea, and it will get the "won't fix" tag very
>>
>> > soon.
>>
>> > 
>>
>> > Nevertheless I want to speak it out.
>>
>> > 
>>
>> > My use case: Get a queryset of users who have a given permission.
>>
>>  
>>
>> I'm still thinking about this use case.
>>
>> Cause it's not for normal use - you don't normally use permissions as 
>> data, you use permissions to deny / allow access to data.
>>
>> So, you're already in the "specialized" corner.
>>
>>  
>>
>
>
> I can use more words, to make this use case more colorful.
>
> Imagine a approval workflow: Only some users are allowed to do the 
> approval.
>
> An invoice instance needs to be forwarded to someone with the matching 
> permissions.
>
> This way I want to provide a html form where the current user can choose 
> the user with the matching
> permissions.
>
>
>
>
>  
>
>> > At the moment this query is complex and results in performance issues,
>>
>>  
>>
>> For a small install this works fine. When performance becomes an issue 
>> because there's a large number of users and groups, my first instinct is to 
>> regroup users so that no permission exceptions exist anymore at the user 
>> level.
>>
>> I'd add all superusers to the "wheel" group ("root", "superuser", 
>> whatever floats your boat).
>>
>> Now the query to get this info no longer requires the user model for 
>> conditions and you can simply query the group manager.
>>
>> It is what groups are for and it'll be always faster get all the matching 
>> groups as one set and combine it with all the users that have the 
>> permission assigned directly.
>>
>> The "one query" requirement conflicts with your performance requirement.
>>
>>
>
> Unfortunately the current sql query has several outer joins and takes 
> several seconds even with only very few data in the database.
>
> We have a work-around this. The basic part is published here: 
> https://code.djangoproject.com/ticket/27260#comment:10
>
>
>
>  
>
>>  
>>
>> -- 
>>
>> Melvyn Sopacua
>>
>

-- 
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/f38eb15f-4e5f-45b8-8fa9-be4e749bc86c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Deprecate is_superuser, is_staff and is_active

2017-03-28 Thread guettli 


Am Montag, 27. März 2017 16:11:06 UTC+2 schrieb Melvyn Sopacua:
>
> On Friday 24 March 2017 04:31:32 guettli wrote:
>
> > I know this is a crazy idea, and it will get the "won't fix" tag very
>
> > soon.
>
> > 
>
> > Nevertheless I want to speak it out.
>
> > 
>
> > My use case: Get a queryset of users who have a given permission.
>
>  
>
> I'm still thinking about this use case.
>
> Cause it's not for normal use - you don't normally use permissions as 
> data, you use permissions to deny / allow access to data.
>
> So, you're already in the "specialized" corner.
>
>  
>


I can use more words, to make this use case more colorful.

Imagine a approval workflow: Only some users are allowed to do the approval.

An invoice instance needs to be forwarded to someone with the matching 
permissions.

This way I want to provide a html form where the current user can choose 
the user with the matching
permissions.




 

> > At the moment this query is complex and results in performance issues,
>
>  
>
> For a small install this works fine. When performance becomes an issue 
> because there's a large number of users and groups, my first instinct is to 
> regroup users so that no permission exceptions exist anymore at the user 
> level.
>
> I'd add all superusers to the "wheel" group ("root", "superuser", whatever 
> floats your boat).
>
> Now the query to get this info no longer requires the user model for 
> conditions and you can simply query the group manager.
>
> It is what groups are for and it'll be always faster get all the matching 
> groups as one set and combine it with all the users that have the 
> permission assigned directly.
>
> The "one query" requirement conflicts with your performance requirement.
>
>

Unfortunately the current sql query has several outer joins and takes 
several seconds even with only very few data in the database.

We have a work-around this. The basic part is published here: 
https://code.djangoproject.com/ticket/27260#comment:10



 

>  
>
> -- 
>
> Melvyn Sopacua
>

-- 
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/8803a089-4497-47a8-bfcd-3fe31e0d9ffb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Deprecate is_superuser, is_staff and is_active

2017-03-27 Thread Melvyn Sopacua 
On Friday 24 March 2017 04:31:32 guettli wrote:
> I know this is a crazy idea, and it will get the "won't fix" tag very
> soon.
> 
> Nevertheless I want to speak it out.
> 
> My use case: Get a queryset of users who have a given permission.

I'm still thinking about this use case.
Cause it's not for normal use - you don't normally use permissions as data, you 
use 
permissions to deny / allow access to data.
So, you're already in the "specialized" corner.

> At the moment this query is complex and results in performance issues,

For a small install this works fine. When performance becomes an issue because 
there's a large number of users and groups, my first instinct is to regroup 
users so 
that no permission exceptions exist anymore at the user level.
I'd add all superusers to the "wheel" group ("root", "superuser", whatever 
floats your 
boat).
Now the query to get this info no longer requires the user model for conditions 
and 
you can simply query the group manager.
It is what groups are for and it'll be always faster get all the matching 
groups as one 
set and combine it with all the users that have  the permission assigned 
directly.
The "one query" requirement conflicts with your performance requirement.

-- 
Melvyn Sopacua

-- 
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/198.MnPFgKG1jH%40devstation.
For more options, visit https://groups.google.com/d/optout.

Re: Deprecate is_superuser, is_staff and is_active

2017-03-27 Thread guettli 


Am Freitag, 24. März 2017 14:12:44 UTC+1 schrieb Collin Anderson:
>
> Hi Thomas,
>
> "If the user should have all permissions, then why not give him all these 
> permissions at database level?" - I have some use cases where there are 
> only 3-5 people that need to log into the admin. I don't really need to set 
> different levels of access for different people. I also don't want to have 
> to go through and add new permissions to every person every time I add a 
> model. So, I just mark them all as is_superuser and don't use permissions 
> at all. It keeps things simple.
>
> Something like this might handle your situation:
> class MyUser:
> # etc
> is_superuser = False
> is_staff = property(lambda u: u.has_perm('admin'))
>
>
Yes, configuring permission each time you add a model makes no fun. I have 
to think about this again.

Regards,
  Thomas Güttler

-- 
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/abd56b3b-a0af-4fd8-847e-1ea7d06dd9b6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Deprecate is_superuser, is_staff and is_active

2017-03-24 Thread Collin Anderson 
Hi Thomas,

"If the user should have all permissions, then why not give him all these
permissions at database level?" - I have some use cases where there are
only 3-5 people that need to log into the admin. I don't really need to set
different levels of access for different people. I also don't want to have
to go through and add new permissions to every person every time I add a
model. So, I just mark them all as is_superuser and don't use permissions
at all. It keeps things simple.

Something like this might handle your situation:
class MyUser:
# etc
is_superuser = False
is_staff = property(lambda u: u.has_perm('admin'))

Collin

On Fri, Mar 24, 2017 at 8:55 AM, guettli 
wrote:

>
>
> Am Freitag, 24. März 2017 12:42:03 UTC+1 schrieb Andrew Ingram:
>>
>> I've always felt that `is_staff` should be changed to a permission such
>> as `can_access_admin` provided by the Admin app itself.
>>
>
>
>
>> However, `is_superuser` is slightly different, in that it's not a
>> permission, but rather a flag that says "this user has EVERY permission".
>> It's also potentially nonsensical from a functional perspective, you could
>> have two permissions that are intended to be mutually exclusive, but a
>> superuser would nonetheless have both of them - potentially resulting in a
>> broken/nonsense UI.
>>
>
> Thank you for this easy to understand use case. I ask myself if "this user
> has EVERY permission" is needed at all. If the user should have all
> permissions, then why not give
> him all these permissions at database level? It's like a very special 1:N
> relation which is: 1:∞  :-)
>
>
>
>
>
>> This is the main reason why almost nobody should be a superuser (yet
>> nearly every Django project i've inherited has nearly every member of staff
>> marked as superusers).
>>
>>
> Unfortunately we detected this "best practice" too late. We need to switch
> now, but this not related to django-dev, this needs to be solved in our
> company.
>
>
>
>> `is_active` is intended to be used a little differently isn't it? It's
>> not saying "user has no permissions", it's saying "user is disabled". It's
>> not access-control, it's data.
>>
>>
> Let's look at our use case: I want a queryset of all users which have a
> given permission. Do I want to be
> inactive users in this queryset?  I am unsure. But I am sure: I want this
> queryset to be simple at SQL level.
>
>
>
>> I think that most of it could do with a rethink, but `is_staff` is
>> probably the biggest wart.
>>
>> Andy
>>
>>
>>
>
> Thanky you Andy
>
> Regards,
>   Thomas
>
> --
> 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/66dc2010-eca4-409f-9dea-
> f1a4f5aa8217%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/CAFO84S5fJaGgDZpXQLpKd2B9jZCfxBvEqKbjnqWceOf0w1q5hQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Deprecate is_superuser, is_staff and is_active

2017-03-24 Thread guettli 


Am Freitag, 24. März 2017 13:41:10 UTC+1 schrieb Tim Graham:
>
> I don't think the current fields are so bad or nonsensical that it 
> warrants a change. Also, consider that every Django user would have to 
> learn how to use a new permissions setup.
>
> If you don't like the default permissions structure, use a custom user 
> model.
>
>

Yes, I guess we will go this way.

Are there established third party solutions? . I could not find any 
with my favorite search engine ...

Thank you Tim

Regards,
  Thomas
 

-- 
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/945701ea-37d5-4c48-a115-d172edc61ad4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Deprecate is_superuser, is_staff and is_active

2017-03-24 Thread guettli 


Am Freitag, 24. März 2017 12:42:03 UTC+1 schrieb Andrew Ingram:
>
> I've always felt that `is_staff` should be changed to a permission such as 
> `can_access_admin` provided by the Admin app itself. 
>

 

> However, `is_superuser` is slightly different, in that it's not a 
> permission, but rather a flag that says "this user has EVERY permission". 
> It's also potentially nonsensical from a functional perspective, you could 
> have two permissions that are intended to be mutually exclusive, but a 
> superuser would nonetheless have both of them - potentially resulting in a 
> broken/nonsense UI.
>

Thank you for this easy to understand use case. I ask myself if "this user 
has EVERY permission" is needed at all. If the user should have all 
permissions, then why not give
him all these permissions at database level? It's like a very special 1:N 
relation which is: 1:∞  :-)



 

> This is the main reason why almost nobody should be a superuser (yet 
> nearly every Django project i've inherited has nearly every member of staff 
> marked as superusers).
>
>
Unfortunately we detected this "best practice" too late. We need to switch 
now, but this not related to django-dev, this needs to be solved in our 
company.

 

> `is_active` is intended to be used a little differently isn't it? It's not 
> saying "user has no permissions", it's saying "user is disabled". It's not 
> access-control, it's data.
>
>
Let's look at our use case: I want a queryset of all users which have a 
given permission. Do I want to be
inactive users in this queryset?  I am unsure. But I am sure: I want this 
queryset to be simple at SQL level.

 

> I think that most of it could do with a rethink, but `is_staff` is 
> probably the biggest wart.
>
> Andy
>
>
>

Thanky you Andy

Regards,
  Thomas 

-- 
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/66dc2010-eca4-409f-9dea-f1a4f5aa8217%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Deprecate is_superuser, is_staff and is_active

2017-03-24 Thread Tim Graham 
I don't think the current fields are so bad or nonsensical that it warrants 
a change. Also, consider that every Django user would have to learn how to 
use a new permissions setup.

If you don't like the default permissions structure, use a custom user 
model.

On Friday, March 24, 2017 at 7:31:32 AM UTC-4, guettli wrote:
>
> I know this is a crazy idea, and it will get the "won't fix" tag very soon.
>
> Nevertheless I want to speak it out.
>
> My use case: Get a queryset of users who have a given permission.
>
> I would like to get this with a simple SQL statement.
>
> At the moment this query is complex and results in performance issues, 
> since
> several outer joins get created. See: 
> https://groups.google.com/forum/#!topic/django-users/lUGkZybXllM
>
> is_superuser and is_staff could be changed to permissions easily.
>
> It's different with is_active. But again: a simple SQL to get all users 
> which have a given permission is my goal.
>
> I personally could live without is_active: Just remove all permissions for 
> this user.
>
> If you don't like dropping all perms to make a user inactive since you 
> want to switch back and forward between active and inactive   ...
> then this a different (bigger) problem: switching back and forward between 
> states. Why not solve
> this for all models (not just User instances)? But this is a different 
> topic :-)
>
> I know the road to deprecate these three friends would be hard since a lot 
> of code uses them.
>
> What do you think?
>
>
>
>
>
>
>

-- 
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/083e3eb0-d76c-4fb7-9f26-ce60ee5f9ef5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Deprecate is_superuser, is_staff and is_active

2017-03-24 Thread Andrew Ingram 
I've always felt that `is_staff` should be changed to a permission such as
`can_access_admin` provided by the Admin app itself. However,
`is_superuser` is slightly different, in that it's not a permission, but
rather a flag that says "this user has EVERY permission". It's also
potentially nonsensical from a functional perspective, you could have two
permissions that are intended to be mutually exclusive, but a superuser
would nonetheless have both of them - potentially resulting in a
broken/nonsense UI. This is the main reason why almost nobody should be a
superuser (yet nearly every Django project i've inherited has nearly every
member of staff marked as superusers).

`is_active` is intended to be used a little differently isn't it? It's not
saying "user has no permissions", it's saying "user is disabled". It's not
access-control, it's data.

I think that most of it could do with a rethink, but `is_staff` is probably
the biggest wart.

Andy

On Fri, 24 Mar 2017 at 11:31 guettli 
wrote:

> I know this is a crazy idea, and it will get the "won't fix" tag very soon.
>
> Nevertheless I want to speak it out.
>
> My use case: Get a queryset of users who have a given permission.
>
> I would like to get this with a simple SQL statement.
>
> At the moment this query is complex and results in performance issues,
> since
> several outer joins get created. See:
> https://groups.google.com/forum/#!topic/django-users/lUGkZybXllM
>
> is_superuser and is_staff could be changed to permissions easily.
>
> It's different with is_active. But again: a simple SQL to get all users
> which have a given permission is my goal.
>
> I personally could live without is_active: Just remove all permissions for
> this user.
>
> If you don't like dropping all perms to make a user inactive since you
> want to switch back and forward between active and inactive   ...
> then this a different (bigger) problem: switching back and forward between
> states. Why not solve
> this for all models (not just User instances)? But this is a different
> topic :-)
>
> I know the road to deprecate these three friends would be hard since a lot
> of code uses them.
>
> What do you think?
>
>
>
>
>
>
> --
> 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/961fd91c-3954-4c7f-a05e-807f2863dc5e%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/CAOA51CV4KTQHREgQ046nCF2You7kZB407c3jKjgn%3D-%2B0ObREvw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.