Re: the design of django group permission should be optimized in django.contrib.auth.ModelBackend

[Bendegúz Csirmaz]

Hi!

I would be happy to make a contribution if a decision can be reached.

I'm in favor of making the Group model swappable with the AUTH_GROUP_MODEL 
setting, similar to the User model.

The ticket was marked as Someday/Maybe, I'm not sure why.
The customization of the Group model is necessary in any bigger project, 
and defining a secondary model doesn't always cut it (e.g. when nesting the 
Group model).

AUTH_GROUP_MODEL is consistent with the User model and addresses all 
customization concerns.

Yes, it's hard to swap the User model in production, and it will be hard to 
swap the Group model.
It's still better than hacking around Django 
(see: 
https://stackoverflow.com/questions/2181039/how-do-i-extend-the-django-group-model).

I opened a PR  to add this, it 
addresses the basic functionality.

Let me know!
On Friday 24 January 2020 at 16:57:17 UTC+8 Adam Johnson wrote:

> Exactly as you see, nothing is done in secret.
>
> On Fri, 24 Jan 2020 at 08:44, LBris  wrote:
>
>> Hi everyone.
>>
>>
>> What is the state of this discussion and its attached ticket ?
>>
>> -- 
>>
> 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-develop...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/47517107-c5d2-4986-8845-087cba05e340%40googlegroups.com
>>  
>> 
>> .
>>
>
>
> -- 
> Adam
>

-- 
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/103b9150-54b5-4cd4-b27b-1fd6db7e5f5en%40googlegroups.com.

Re: the design of django group permission should be optimized in django.contrib.auth.ModelBackend

[Adam Johnson]

Exactly as you see, nothing is done in secret.

On Fri, 24 Jan 2020 at 08:44, LBris  wrote:

> Hi everyone.
>
>
> What is the state of this discussion and its attached ticket ?
>
> --
> 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/47517107-c5d2-4986-8845-087cba05e340%40googlegroups.com
> 
> .
>


-- 
Adam

-- 
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/CAMyDDM26g9LG49K7S5gPzOA-vS%2B6rUnPipt6iQv0qwYLvgMM2A%40mail.gmail.com.

Re: the design of django group permission should be optimized in django.contrib.auth.ModelBackend

[LBris]

>
> Hi everyone.


What is the state of this discussion and its attached ticket ?

-- 
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/47517107-c5d2-4986-8845-087cba05e340%40googlegroups.com.

Re: the design of django group permission should be optimized in django.contrib.auth.ModelBackend

[Tobias Bengfort]

I also have experience with the limitations of the default permission
system. But I don't think it is necessarily a problem. There are two
options to deal with it:

- Django could add small bits of flexibility, e.g. make the group model
swappable. This adds complexity that needs to be accounted for in all
relevant libraries, e.g. django-guardian.

- Django could make it easier to write custom authentication backends.
This gives complete control to application developers, at the cost of no
longer being compatible with many libraries, e.g. django-guardian.

I personally lean to the second options as I believe it allows to have
cleaner application designs. But it think it is hard to get the right
balance.

tobias


On 05/11/2019 12:03, Tom Clark wrote:
> I'd be very interested in this. But it seems like one helluva lot of work, 
> to enable people to customise their Group model.
> 
> I think in general, there are two reasons why one want to use a swappable 
> model in this case:
> 
> - To create nested relationships with e.g. mptt.
> - To add a field or two onto the model.
> 
> Couldn't these two use cases be better solved by simply updating the 
> existing Group model:
> - Add a `meta` JSONField (now generically included in Django, not just 
> postgres anymore) so people can hang extra metadata in there if required
> - Add mptt right in there so that groups can be added to other groups?
> 
> We could carve code out from django-groups-manager to achive this 
> straightforwardly, but it introduces mptt as a dependency of a contrib app.
> 
> What do you think, @John? Is this likely to be accepted into Django?
> 
> 
> 
> 
> On Wednesday, April 3, 2019 at 12:31:59 PM UTC+1, John D'Ambrosio wrote:
>>
>> I believe this change is merited and I would be happy to help if others 
>> are interested in working this.  I have actually monkey-patched it a few 
>> times now for two reasons:
>>
>> a) I want more data fields on the group itself, or
>> b) I want to implement nested groups
>>
>> MPTT's docs suggest one approach which is gross (no offense) because it 
>> creates migrations in a contrib app!
>>
>>
>> https://django-mptt.readthedocs.io/en/latest/models.html?highlight=group#registration-of-existing-models
>>
>> The nested group concept has the added concern of the PermissionsMixin 
>> leveraging a few helper functions which are defined outside of the class 
>> and not easily swappable themselves.  Maybe if we proceed on this we tackle 
>> it in two phases.  In the first, we can align all of the pieces to make it 
>> more easily swappable.  In the second, we can introduce the swap.  We 
>> definitely will want to avoid some of the pitfalls of AbstractUser and 
>> UserManager where one is unable to import varying degrees of scaffolding 
>> without invoking the concrete pieces we are not using.
>>
>> I agree with Tim that the swappable model approach is less than ideal and 
>> not well-documented for transitions, but maybe those of us who've done it 
>> can submit some detailed guides with some concrete steps of how to swap out 
>> the table namespaces and retire the old models retroactively, as well as 
>> the usual (maybe even stronger) encouragement to pull in the models to your 
>> core app up-front?  Could even have startproject do it for you in the 
>> future... maybe recommend an "accounts" app or something?
>>
>> Anyway, happy to help.  Please let me know if there is interest in 
>> proceeding.
>>
>> On Friday, August 31, 2018 at 4:28:30 PM UTC-4, 程SN wrote:
>>>
>>> Hi everybody,
>>>
>>> the information is not enough for my company in 
>>> django.contrib.auth.models.Usre and django.contrib.auth.models.Group. So I 
>>> custom User and Team model.
>>>
>>> the auth User can be changed in the django settings by AUTH_USER_MODEL. 
>>> But the Group cannot.
>>>  
>>> Further, There are many group permissions problem presented when I use 
>>> django permissions. 
>>>
>>> Firstly, I cannot use django.contrib.auth.ModelBackend directly.
>>>
>>> in django.contrib.auth.ModelBackend,  Django currently bind group 
>>> permissions with  django.contrib.auth.models.Group
>>>
>>> def _get_group_permissions(self, user_obj):
>>> user_groups_field = get_user_model()._meta.get_field('groups')
>>> user_groups_query = 'group
>>> __%s' % user_groups_field.related_query_name()
>>> return Permission.objects.filter(**{user_groups_query: user_obj})
>>>
>>> Why the group cannot be changed in the settings like AUTH_USER_MODEL ?  
>>> Can Djano support AUTH_GROUP_MODEL in the further release?
>>>
>>> So I have to custom backend that extend django.contrib.auth.ModelBackend 
>>> and modify group to my team.
>>>
>>> But I find the other problem  in my further developing.  The bad design 
>>>  limit the other app design.
>>>
>>> Many app about django permission , only  support group permission based 
>>> on django.contrib.auth.models.Group, like django-guardian
>>>
>>> It's too bad.  Please support AUTH_GROUP_MODEL

Re: the design of django group permission should be optimized in django.contrib.auth.ModelBackend

[Tom Clark]

I'd be very interested in this. But it seems like one helluva lot of work, 
to enable people to customise their Group model.

I think in general, there are two reasons why one want to use a swappable 
model in this case:

- To create nested relationships with e.g. mptt.
- To add a field or two onto the model.

Couldn't these two use cases be better solved by simply updating the 
existing Group model:
- Add a `meta` JSONField (now generically included in Django, not just 
postgres anymore) so people can hang extra metadata in there if required
- Add mptt right in there so that groups can be added to other groups?

We could carve code out from django-groups-manager to achive this 
straightforwardly, but it introduces mptt as a dependency of a contrib app.

What do you think, @John? Is this likely to be accepted into Django?




On Wednesday, April 3, 2019 at 12:31:59 PM UTC+1, John D'Ambrosio wrote:
>
> I believe this change is merited and I would be happy to help if others 
> are interested in working this.  I have actually monkey-patched it a few 
> times now for two reasons:
>
> a) I want more data fields on the group itself, or
> b) I want to implement nested groups
>
> MPTT's docs suggest one approach which is gross (no offense) because it 
> creates migrations in a contrib app!
>
>
> https://django-mptt.readthedocs.io/en/latest/models.html?highlight=group#registration-of-existing-models
>
> The nested group concept has the added concern of the PermissionsMixin 
> leveraging a few helper functions which are defined outside of the class 
> and not easily swappable themselves.  Maybe if we proceed on this we tackle 
> it in two phases.  In the first, we can align all of the pieces to make it 
> more easily swappable.  In the second, we can introduce the swap.  We 
> definitely will want to avoid some of the pitfalls of AbstractUser and 
> UserManager where one is unable to import varying degrees of scaffolding 
> without invoking the concrete pieces we are not using.
>
> I agree with Tim that the swappable model approach is less than ideal and 
> not well-documented for transitions, but maybe those of us who've done it 
> can submit some detailed guides with some concrete steps of how to swap out 
> the table namespaces and retire the old models retroactively, as well as 
> the usual (maybe even stronger) encouragement to pull in the models to your 
> core app up-front?  Could even have startproject do it for you in the 
> future... maybe recommend an "accounts" app or something?
>
> Anyway, happy to help.  Please let me know if there is interest in 
> proceeding.
>
> On Friday, August 31, 2018 at 4:28:30 PM UTC-4, 程SN wrote:
>>
>> Hi everybody,
>>
>> the information is not enough for my company in 
>> django.contrib.auth.models.Usre and django.contrib.auth.models.Group. So I 
>> custom User and Team model.
>>
>> the auth User can be changed in the django settings by AUTH_USER_MODEL. 
>> But the Group cannot.
>>  
>> Further, There are many group permissions problem presented when I use 
>> django permissions. 
>>
>> Firstly, I cannot use django.contrib.auth.ModelBackend directly.
>>
>> in django.contrib.auth.ModelBackend,  Django currently bind group 
>> permissions with  django.contrib.auth.models.Group
>>
>> def _get_group_permissions(self, user_obj):
>> user_groups_field = get_user_model()._meta.get_field('groups')
>> user_groups_query = 'group
>> __%s' % user_groups_field.related_query_name()
>> return Permission.objects.filter(**{user_groups_query: user_obj})
>>
>> Why the group cannot be changed in the settings like AUTH_USER_MODEL ?  
>> Can Djano support AUTH_GROUP_MODEL in the further release?
>>
>> So I have to custom backend that extend django.contrib.auth.ModelBackend 
>> and modify group to my team.
>>
>> But I find the other problem  in my further developing.  The bad design 
>>  limit the other app design.
>>
>> Many app about django permission , only  support group permission based 
>> on django.contrib.auth.models.Group, like django-guardian
>>
>> It's too bad.  Please support AUTH_GROUP_MODEL
>>  
>> --
>> Regards,
>>
>> damoncheng
>>
>

-- 
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/f308b198-28a5-423c-a7ae-cf6da87b9c74%40googlegroups.com.

Re: the design of django group permission should be optimized in django.contrib.auth.ModelBackend

[John D'Ambrosio]

I believe this change is merited and I would be happy to help if others are 
interested in working this.  I have actually monkey-patched it a few times 
now for two reasons:

a) I want more data fields on the group itself, or
b) I want to implement nested groups

MPTT's docs suggest one approach which is gross (no offense) because it 
creates migrations in a contrib app!

https://django-mptt.readthedocs.io/en/latest/models.html?highlight=group#registration-of-existing-models

The nested group concept has the added concern of the PermissionsMixin 
leveraging a few helper functions which are defined outside of the class 
and not easily swappable themselves.  Maybe if we proceed on this we tackle 
it in two phases.  In the first, we can align all of the pieces to make it 
more easily swappable.  In the second, we can introduce the swap.  We 
definitely will want to avoid some of the pitfalls of AbstractUser and 
UserManager where one is unable to import varying degrees of scaffolding 
without invoking the concrete pieces we are not using.

I agree with Tim that the swappable model approach is less than ideal and 
not well-documented for transitions, but maybe those of us who've done it 
can submit some detailed guides with some concrete steps of how to swap out 
the table namespaces and retire the old models retroactively, as well as 
the usual (maybe even stronger) encouragement to pull in the models to your 
core app up-front?  Could even have startproject do it for you in the 
future... maybe recommend an "accounts" app or something?

Anyway, happy to help.  Please let me know if there is interest in 
proceeding.

On Friday, August 31, 2018 at 4:28:30 PM UTC-4, 程SN wrote:
>
> Hi everybody,
>
> the information is not enough for my company in 
> django.contrib.auth.models.Usre and django.contrib.auth.models.Group. So I 
> custom User and Team model.
>
> the auth User can be changed in the django settings by AUTH_USER_MODEL. 
> But the Group cannot.
>  
> Further, There are many group permissions problem presented when I use 
> django permissions. 
>
> Firstly, I cannot use django.contrib.auth.ModelBackend directly.
>
> in django.contrib.auth.ModelBackend,  Django currently bind group 
> permissions with  django.contrib.auth.models.Group
>
> def _get_group_permissions(self, user_obj):
> user_groups_field = get_user_model()._meta.get_field('groups')
> user_groups_query = 'group
> __%s' % user_groups_field.related_query_name()
> return Permission.objects.filter(**{user_groups_query: user_obj})
>
> Why the group cannot be changed in the settings like AUTH_USER_MODEL ?  
> Can Djano support AUTH_GROUP_MODEL in the further release?
>
> So I have to custom backend that extend django.contrib.auth.ModelBackend 
> and modify group to my team.
>
> But I find the other problem  in my further developing.  The bad design 
>  limit the other app design.
>
> Many app about django permission , only  support group permission based 
> on django.contrib.auth.models.Group, like django-guardian
>
> It's too bad.  Please support AUTH_GROUP_MODEL
>  
> --
> Regards,
>
> damoncheng
>

-- 
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/f520ef96-e1c0-4f11-9026-be3d2b50b901%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: the design of django group permission should be optimized in django.contrib.auth.ModelBackend

[snhellogg]

It's a headache thing that replace `groups in auth.models.PermissionsMixin` 
to `auth.Group`. because of the backward compatibility. I can not adjust 
some code position. I have been written some patches. But they are not 
enough well. I am working on it.

在 2018年9月11日星期二 UTC+8上午1:49:33，charettes写道：
>
> Something I would add is that while some third-party apps leverage 
> swappable models it is not clear how relationships between swappable models 
> should be dealt with.
>
> This is something we'd have to figure out if `auth.Group` is made 
> swappable as the default model user model would depend on it.
>
> Simon
>
>
> Le lundi 10 septembre 2018 11:12:52 UTC-4, Tim Graham a écrit :
>>
>> I'm not sure. Swappable models still have some rough edges. In 
>> particular, switching to a swappable model after beginning a project is 
>> difficult and undocumented (https://code.djangoproject.com/ticket/25313). 
>> To overcome this, the documentation recommends starting with a custom user 
>> model (https://code.djangoproject.com/ticket/24370) -- I'm not sure if 
>> we would want to make the same recommendation for the group model as I 
>> suspect it wouldn't be swapped as often.
>>
>> I see you created a ticket to add an AUTH_GROUP_MODEL setting.
>> https://code.djangoproject.com/ticket/29748
>>
>> On Thursday, September 6, 2018 at 4:13:03 PM UTC-4, snhe...@gmail.com 
>> wrote:
>>>
>>> Hi Adam,
>>>
>>> After you reply, I make team OneToOneField to Group.  Though it can 
>>> sovle the basic problem.  it have some problem in my scene. 
>>>
>>> My project is a cloud item.  it use SCIM to manage user and team 
>>> identities in cloud.  it transfer resource from sender to many receiver. 
>>>
>>> Before I use OneToOneField,   I only transfer user and team from sender 
>>> to receiver.   It spend 2 hour.
>>>
>>> After  I use OneToOneField.  I  need transfer user and team from sender 
>>> to receiver, then create group and make team OneToOneField to Group in the 
>>> receiver. It spend 6 hour.
>>>
>>> it degrade the transform perform. So I decide to accept your suggestion 
>>> and contribution to django , support AUTH_GROUP_MODEL.
>>>
>>> I am first to contribute to django. I am getting familar with django 
>>> ticket now.
>>>
>>> 在 2018年9月2日星期日 UTC+8上午4:41:11，Adam Johnson写道：

 Hi damoncheng,

 Previous to swappable User model, the best practice was to define a 
 secondary model with OneToOneField to User for storing auxiliary 
 information. You could do this for Group to solve your use case now.

 As for the feature request, I wouldn't be against it, though I'm not 
 really in favour of it either. I'd estimate it to be a medium-sized Django 
 ticket. Would you be able to make the contribution? Or are you just 
 requesting that "someone" do it? Features don't tend to get added to 
 Django 
 except by motivated individuals who'd like to see them there :)

 Thanks,

 Adam

 On Fri, 31 Aug 2018 at 23:22, 程SN  wrote:

> Hi everybody,
>
> the information is not enough for my company in 
> django.contrib.auth.models.Usre and django.contrib.auth.models.Group. So 
> I 
> custom User and Team model.
>
> the auth User can be changed in the django settings by AUTH_USER_MODEL. 
> But the Group cannot.
>  
> Further, There are many group permissions problem presented when I 
> use django permissions. 
>
> Firstly, I cannot use django.contrib.auth.ModelBackend directly.
>
> in django.contrib.auth.ModelBackend,  Django currently bind group 
> permissions with  django.contrib.auth.models.Group
>
> def _get_group_permissions(self, user_obj):
> user_groups_field = get_user_model()._meta.get_field('groups')
> user_groups_query = 'group
> __%s' % user_groups_field.related_query_name()
>
> return Permission.objects.filter(**{user_groups_query: user_obj})
>
> Why the group cannot be changed in the settings like AUTH_USER_MODEL 
> ?  Can Djano support AUTH_GROUP_MODEL in the further release?
>
> So I have to custom backend that extend 
> django.contrib.auth.ModelBackend and modify group to my team.
>
> But I find the other problem  in my further developing.  The bad 
> design  limit the other app design.
>
> Many app about django permission , only  support group permission 
> based on django.contrib.auth.models.Group, like django-guardian
>
> It's too bad.  Please support AUTH_GROUP_MODEL
>  
> --
> Regards,
>
> damoncheng
>
> -- 
> 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-develop...@googlegroups.com.
> To post to this group, 

Re: the design of django group permission should be optimized in django.contrib.auth.ModelBackend

[snhellogg]

Hi Tim:

  The english is not my first language.  so please excuse me that my 
some statement maybe isn't accurate. But I will do my best to make my 
expression clear.
  
   Maybe the default group model can satisfy the most scene by the 
project developer complicated design. But  it is not mean that it wouldn't 
be swapped as often. Now it is that it can't be swapped all the time.  the 
design should give choose to developer.  I suspect that if the project 
developer can custom their group model. they will often choose the 
easier and basic way. 

Regards,

damoncheng

在 2018年9月10日星期一 UTC+8下午11:12:52，Tim Graham写道：
>
> I'm not sure. Swappable models still have some rough edges. In particular, 
> switching to a swappable model after beginning a project is difficult and 
> undocumented (https://code.djangoproject.com/ticket/25313). To overcome 
> this, the documentation recommends starting with a custom user model (
> https://code.djangoproject.com/ticket/24370) -- I'm not sure if we would 
> want to make the same recommendation for the group model as I suspect it 
> wouldn't be swapped as often.
>
> I see you created a ticket to add an AUTH_GROUP_MODEL setting.
> https://code.djangoproject.com/ticket/29748
>
> On Thursday, September 6, 2018 at 4:13:03 PM UTC-4, snhe...@gmail.com 
> wrote:
>>
>> Hi Adam,
>>
>> After you reply, I make team OneToOneField to Group.  Though it can sovle 
>> the basic problem.  it have some problem in my scene. 
>>
>> My project is a cloud item.  it use SCIM to manage user and team 
>> identities in cloud.  it transfer resource from sender to many receiver. 
>>
>> Before I use OneToOneField,   I only transfer user and team from sender 
>> to receiver.   It spend 2 hour.
>>
>> After  I use OneToOneField.  I  need transfer user and team from sender 
>> to receiver, then create group and make team OneToOneField to Group in the 
>> receiver. It spend 6 hour.
>>
>> it degrade the transform perform. So I decide to accept your suggestion 
>> and contribution to django , support AUTH_GROUP_MODEL.
>>
>> I am first to contribute to django. I am getting familar with django 
>> ticket now.
>>
>> 在 2018年9月2日星期日 UTC+8上午4:41:11，Adam Johnson写道：
>>>
>>> Hi damoncheng,
>>>
>>> Previous to swappable User model, the best practice was to define a 
>>> secondary model with OneToOneField to User for storing auxiliary 
>>> information. You could do this for Group to solve your use case now.
>>>
>>> As for the feature request, I wouldn't be against it, though I'm not 
>>> really in favour of it either. I'd estimate it to be a medium-sized Django 
>>> ticket. Would you be able to make the contribution? Or are you just 
>>> requesting that "someone" do it? Features don't tend to get added to Django 
>>> except by motivated individuals who'd like to see them there :)
>>>
>>> Thanks,
>>>
>>> Adam
>>>
>>> On Fri, 31 Aug 2018 at 23:22, 程SN  wrote:
>>>
 Hi everybody,

 the information is not enough for my company in 
 django.contrib.auth.models.Usre and django.contrib.auth.models.Group. So I 
 custom User and Team model.

 the auth User can be changed in the django settings by AUTH_USER_MODEL. 
 But the Group cannot.
  
 Further, There are many group permissions problem presented when I use 
 django permissions. 

 Firstly, I cannot use django.contrib.auth.ModelBackend directly.

 in django.contrib.auth.ModelBackend,  Django currently bind group 
 permissions with  django.contrib.auth.models.Group

 def _get_group_permissions(self, user_obj):
 user_groups_field = get_user_model()._meta.get_field('groups')
 user_groups_query = 'group
 __%s' % user_groups_field.related_query_name()

 return Permission.objects.filter(**{user_groups_query: user_obj})

 Why the group cannot be changed in the settings like AUTH_USER_MODEL ?  
 Can Djano support AUTH_GROUP_MODEL in the further release?

 So I have to custom backend that extend 
 django.contrib.auth.ModelBackend and modify group to my team.

 But I find the other problem  in my further developing.  The bad design 
  limit the other app design.

 Many app about django permission , only  support group permission 
 based on django.contrib.auth.models.Group, like django-guardian

 It's too bad.  Please support AUTH_GROUP_MODEL
  
 --
 Regards,

 damoncheng

 -- 
 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-develop...@googlegroups.com.
 To post to this group, send email to django-d...@googlegroups.com.
 Visit this group at https://groups.google.com/group/django-developers.
 To view this discussion on the web visit 
 

Re: the design of django group permission should be optimized in django.contrib.auth.ModelBackend

[charettes]

Something I would add is that while some third-party apps leverage 
swappable models it is not clear how relationships between swappable models 
should be dealt with.

This is something we'd have to figure out if `auth.Group` is made swappable 
as the default model user model would depend on it.

Simon


Le lundi 10 septembre 2018 11:12:52 UTC-4, Tim Graham a écrit :
>
> I'm not sure. Swappable models still have some rough edges. In particular, 
> switching to a swappable model after beginning a project is difficult and 
> undocumented (https://code.djangoproject.com/ticket/25313). To overcome 
> this, the documentation recommends starting with a custom user model (
> https://code.djangoproject.com/ticket/24370) -- I'm not sure if we would 
> want to make the same recommendation for the group model as I suspect it 
> wouldn't be swapped as often.
>
> I see you created a ticket to add an AUTH_GROUP_MODEL setting.
> https://code.djangoproject.com/ticket/29748
>
> On Thursday, September 6, 2018 at 4:13:03 PM UTC-4, snhe...@gmail.com 
> wrote:
>>
>> Hi Adam,
>>
>> After you reply, I make team OneToOneField to Group.  Though it can sovle 
>> the basic problem.  it have some problem in my scene. 
>>
>> My project is a cloud item.  it use SCIM to manage user and team 
>> identities in cloud.  it transfer resource from sender to many receiver. 
>>
>> Before I use OneToOneField,   I only transfer user and team from sender 
>> to receiver.   It spend 2 hour.
>>
>> After  I use OneToOneField.  I  need transfer user and team from sender 
>> to receiver, then create group and make team OneToOneField to Group in the 
>> receiver. It spend 6 hour.
>>
>> it degrade the transform perform. So I decide to accept your suggestion 
>> and contribution to django , support AUTH_GROUP_MODEL.
>>
>> I am first to contribute to django. I am getting familar with django 
>> ticket now.
>>
>> 在 2018年9月2日星期日 UTC+8上午4:41:11，Adam Johnson写道：
>>>
>>> Hi damoncheng,
>>>
>>> Previous to swappable User model, the best practice was to define a 
>>> secondary model with OneToOneField to User for storing auxiliary 
>>> information. You could do this for Group to solve your use case now.
>>>
>>> As for the feature request, I wouldn't be against it, though I'm not 
>>> really in favour of it either. I'd estimate it to be a medium-sized Django 
>>> ticket. Would you be able to make the contribution? Or are you just 
>>> requesting that "someone" do it? Features don't tend to get added to Django 
>>> except by motivated individuals who'd like to see them there :)
>>>
>>> Thanks,
>>>
>>> Adam
>>>
>>> On Fri, 31 Aug 2018 at 23:22, 程SN  wrote:
>>>
 Hi everybody,

 the information is not enough for my company in 
 django.contrib.auth.models.Usre and django.contrib.auth.models.Group. So I 
 custom User and Team model.

 the auth User can be changed in the django settings by AUTH_USER_MODEL. 
 But the Group cannot.
  
 Further, There are many group permissions problem presented when I use 
 django permissions. 

 Firstly, I cannot use django.contrib.auth.ModelBackend directly.

 in django.contrib.auth.ModelBackend,  Django currently bind group 
 permissions with  django.contrib.auth.models.Group

 def _get_group_permissions(self, user_obj):
 user_groups_field = get_user_model()._meta.get_field('groups')
 user_groups_query = 'group
 __%s' % user_groups_field.related_query_name()

 return Permission.objects.filter(**{user_groups_query: user_obj})

 Why the group cannot be changed in the settings like AUTH_USER_MODEL ?  
 Can Djano support AUTH_GROUP_MODEL in the further release?

 So I have to custom backend that extend 
 django.contrib.auth.ModelBackend and modify group to my team.

 But I find the other problem  in my further developing.  The bad design 
  limit the other app design.

 Many app about django permission , only  support group permission 
 based on django.contrib.auth.models.Group, like django-guardian

 It's too bad.  Please support AUTH_GROUP_MODEL
  
 --
 Regards,

 damoncheng

 -- 
 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-develop...@googlegroups.com.
 To post to this group, send email to django-d...@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/CABeySRubsPtBiNmH1tt8hnZTPvTz-ZqXLEZ-azBK-jodV98-HQ%40mail.gmail.com
  
 

Re: the design of django group permission should be optimized in django.contrib.auth.ModelBackend

[Tim Graham]

I'm not sure. Swappable models still have some rough edges. In particular, 
switching to a swappable model after beginning a project is difficult and 
undocumented (https://code.djangoproject.com/ticket/25313). To overcome 
this, the documentation recommends starting with a custom user model 
(https://code.djangoproject.com/ticket/24370) -- I'm not sure if we would 
want to make the same recommendation for the group model as I suspect it 
wouldn't be swapped as often.

I see you created a ticket to add an AUTH_GROUP_MODEL setting.
https://code.djangoproject.com/ticket/29748

On Thursday, September 6, 2018 at 4:13:03 PM UTC-4, snhe...@gmail.com wrote:
>
> Hi Adam,
>
> After you reply, I make team OneToOneField to Group.  Though it can sovle 
> the basic problem.  it have some problem in my scene. 
>
> My project is a cloud item.  it use SCIM to manage user and team 
> identities in cloud.  it transfer resource from sender to many receiver. 
>
> Before I use OneToOneField,   I only transfer user and team from sender to 
> receiver.   It spend 2 hour.
>
> After  I use OneToOneField.  I  need transfer user and team from sender to 
> receiver, then create group and make team OneToOneField to Group in the 
> receiver. It spend 6 hour.
>
> it degrade the transform perform. So I decide to accept your suggestion 
> and contribution to django , support AUTH_GROUP_MODEL.
>
> I am first to contribute to django. I am getting familar with django 
> ticket now.
>
> 在 2018年9月2日星期日 UTC+8上午4:41:11，Adam Johnson写道：
>>
>> Hi damoncheng,
>>
>> Previous to swappable User model, the best practice was to define a 
>> secondary model with OneToOneField to User for storing auxiliary 
>> information. You could do this for Group to solve your use case now.
>>
>> As for the feature request, I wouldn't be against it, though I'm not 
>> really in favour of it either. I'd estimate it to be a medium-sized Django 
>> ticket. Would you be able to make the contribution? Or are you just 
>> requesting that "someone" do it? Features don't tend to get added to Django 
>> except by motivated individuals who'd like to see them there :)
>>
>> Thanks,
>>
>> Adam
>>
>> On Fri, 31 Aug 2018 at 23:22, 程SN  wrote:
>>
>>> Hi everybody,
>>>
>>> the information is not enough for my company in 
>>> django.contrib.auth.models.Usre and django.contrib.auth.models.Group. So I 
>>> custom User and Team model.
>>>
>>> the auth User can be changed in the django settings by AUTH_USER_MODEL. 
>>> But the Group cannot.
>>>  
>>> Further, There are many group permissions problem presented when I use 
>>> django permissions. 
>>>
>>> Firstly, I cannot use django.contrib.auth.ModelBackend directly.
>>>
>>> in django.contrib.auth.ModelBackend,  Django currently bind group 
>>> permissions with  django.contrib.auth.models.Group
>>>
>>> def _get_group_permissions(self, user_obj):
>>> user_groups_field = get_user_model()._meta.get_field('groups')
>>> user_groups_query = 'group
>>> __%s' % user_groups_field.related_query_name()
>>> return Permission.objects.filter(**{user_groups_query: user_obj})
>>>
>>> Why the group cannot be changed in the settings like AUTH_USER_MODEL ?  
>>> Can Djano support AUTH_GROUP_MODEL in the further release?
>>>
>>> So I have to custom backend that extend django.contrib.auth.ModelBackend 
>>> and modify group to my team.
>>>
>>> But I find the other problem  in my further developing.  The bad design 
>>>  limit the other app design.
>>>
>>> Many app about django permission , only  support group permission based 
>>> on django.contrib.auth.models.Group, like django-guardian
>>>
>>> It's too bad.  Please support AUTH_GROUP_MODEL
>>>  
>>> --
>>> Regards,
>>>
>>> damoncheng
>>>
>>> -- 
>>> 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-develop...@googlegroups.com.
>>> To post to this group, send email to django-d...@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/CABeySRubsPtBiNmH1tt8hnZTPvTz-ZqXLEZ-azBK-jodV98-HQ%40mail.gmail.com
>>>  
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>> -- 
>> Adam
>>
>

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

Re: the design of django group permission should be optimized in django.contrib.auth.ModelBackend

[snhellogg]

Hi Adam,

After you reply, I make team OneToOneField to Group.  Though it can sovle 
the basic problem.  it have some problem in my scene. 

My project is a cloud item.  it use SCIM to manage user and team identities 
in cloud.  it transfer resource from sender to many receiver. 

Before I use OneToOneField,   I only transfer user and team from sender to 
receiver.   It spend 2 hour.

After  I use OneToOneField.  I  need transfer user and team from sender to 
receiver, then create group and make team OneToOneField to Group in the 
receiver. It spend 6 hour.

it degrade the transform perform. So I decide to accept your suggestion and 
contribution to django , support AUTH_GROUP_MODEL.

I am first to contribute to django. I am getting familar with django ticket 
now.

在 2018年9月2日星期日 UTC+8上午4:41:11，Adam Johnson写道：
>
> Hi damoncheng,
>
> Previous to swappable User model, the best practice was to define a 
> secondary model with OneToOneField to User for storing auxiliary 
> information. You could do this for Group to solve your use case now.
>
> As for the feature request, I wouldn't be against it, though I'm not 
> really in favour of it either. I'd estimate it to be a medium-sized Django 
> ticket. Would you be able to make the contribution? Or are you just 
> requesting that "someone" do it? Features don't tend to get added to Django 
> except by motivated individuals who'd like to see them there :)
>
> Thanks,
>
> Adam
>
> On Fri, 31 Aug 2018 at 23:22, 程SN > wrote:
>
>> Hi everybody,
>>
>> the information is not enough for my company in 
>> django.contrib.auth.models.Usre and django.contrib.auth.models.Group. So I 
>> custom User and Team model.
>>
>> the auth User can be changed in the django settings by AUTH_USER_MODEL. 
>> But the Group cannot.
>>  
>> Further, There are many group permissions problem presented when I use 
>> django permissions. 
>>
>> Firstly, I cannot use django.contrib.auth.ModelBackend directly.
>>
>> in django.contrib.auth.ModelBackend,  Django currently bind group 
>> permissions with  django.contrib.auth.models.Group
>>
>> def _get_group_permissions(self, user_obj):
>> user_groups_field = get_user_model()._meta.get_field('groups')
>> user_groups_query = 'group
>> __%s' % user_groups_field.related_query_name()
>> return Permission.objects.filter(**{user_groups_query: user_obj})
>>
>> Why the group cannot be changed in the settings like AUTH_USER_MODEL ?  
>> Can Djano support AUTH_GROUP_MODEL in the further release?
>>
>> So I have to custom backend that extend django.contrib.auth.ModelBackend 
>> and modify group to my team.
>>
>> But I find the other problem  in my further developing.  The bad design 
>>  limit the other app design.
>>
>> Many app about django permission , only  support group permission based 
>> on django.contrib.auth.models.Group, like django-guardian
>>
>> It's too bad.  Please support AUTH_GROUP_MODEL
>>  
>> --
>> Regards,
>>
>> damoncheng
>>
>> -- 
>> 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-develop...@googlegroups.com .
>> To post to this group, send email to django-d...@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/CABeySRubsPtBiNmH1tt8hnZTPvTz-ZqXLEZ-azBK-jodV98-HQ%40mail.gmail.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> -- 
> Adam
>

-- 
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/95b381ab-3425-4350-a101-0e3dd9453925%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: the design of django group permission should be optimized in django.contrib.auth.ModelBackend

[Adam Johnson]

Hi damoncheng,

Previous to swappable User model, the best practice was to define a
secondary model with OneToOneField to User for storing auxiliary
information. You could do this for Group to solve your use case now.

As for the feature request, I wouldn't be against it, though I'm not really
in favour of it either. I'd estimate it to be a medium-sized Django ticket.
Would you be able to make the contribution? Or are you just requesting that
"someone" do it? Features don't tend to get added to Django except by
motivated individuals who'd like to see them there :)

Thanks,

Adam

On Fri, 31 Aug 2018 at 23:22, 程SN  wrote:

> Hi everybody,
>
> the information is not enough for my company in
> django.contrib.auth.models.Usre and django.contrib.auth.models.Group. So I
> custom User and Team model.
>
> the auth User can be changed in the django settings by AUTH_USER_MODEL.
> But the Group cannot.
>
> Further, There are many group permissions problem presented when I use
> django permissions.
>
> Firstly, I cannot use django.contrib.auth.ModelBackend directly.
>
> in django.contrib.auth.ModelBackend,  Django currently bind group
> permissions with  django.contrib.auth.models.Group
>
> def _get_group_permissions(self, user_obj):
> user_groups_field = get_user_model()._meta.get_field('groups')
> user_groups_query = 'group
> __%s' % user_groups_field.related_query_name()
> return Permission.objects.filter(**{user_groups_query: user_obj})
>
> Why the group cannot be changed in the settings like AUTH_USER_MODEL ?
> Can Djano support AUTH_GROUP_MODEL in the further release?
>
> So I have to custom backend that extend django.contrib.auth.ModelBackend
> and modify group to my team.
>
> But I find the other problem  in my further developing.  The bad design
>  limit the other app design.
>
> Many app about django permission , only  support group permission based
> on django.contrib.auth.models.Group, like django-guardian
>
> It's too bad.  Please support AUTH_GROUP_MODEL
>
> --
> Regards,
>
> damoncheng
>
> --
> 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/CABeySRubsPtBiNmH1tt8hnZTPvTz-ZqXLEZ-azBK-jodV98-HQ%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Adam

-- 
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/CAMyDDM3H%3DkTv3QTtkHTq8ZX-5yCOu5_m11YDhHtk2dkO5Erj4A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

the design of django group permission should be optimized in django.contrib.auth.ModelBackend

[程SN]

Hi everybody,

the information is not enough for my company in
django.contrib.auth.models.Usre and django.contrib.auth.models.Group. So I
custom User and Team model.

the auth User can be changed in the django settings by AUTH_USER_MODEL. But
the Group cannot.

Further, There are many group permissions problem presented when I use
django permissions.

Firstly, I cannot use django.contrib.auth.ModelBackend directly.

in django.contrib.auth.ModelBackend,  Django currently bind group
permissions with  django.contrib.auth.models.Group

def _get_group_permissions(self, user_obj):
user_groups_field = get_user_model()._meta.get_field('groups')
user_groups_query = 'group
__%s' % user_groups_field.related_query_name()
return Permission.objects.filter(**{user_groups_query: user_obj})

Why the group cannot be changed in the settings like AUTH_USER_MODEL ?  Can
Djano support AUTH_GROUP_MODEL in the further release?

So I have to custom backend that extend django.contrib.auth.ModelBackend
and modify group to my team.

But I find the other problem  in my further developing.  The bad design
 limit the other app design.

Many app about django permission , only  support group permission based on
django.contrib.auth.models.Group, like django-guardian

It's too bad.  Please support AUTH_GROUP_MODEL

--
Regards,

damoncheng

-- 
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/CABeySRubsPtBiNmH1tt8hnZTPvTz-ZqXLEZ-azBK-jodV98-HQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.