Adjusting MRO of the CBVs

2018-09-06 Thread Carlton Gibson
There's a ticket adjusting the MRO of DeleteView. 

https://code.djangoproject.com/ticket/29735

I'm closing this as `wontfix`: 

* It's nice in theory but...
* not worth the breaking change. 

I'm posting here because I'm half-inclined to a Someday/Maybe (any least): 
surely, improving the structure of the code is something we can/should do. 

I'm just not at all sure of whether it's worth it, when we could do it, and 
what a migration path would look like. (And so on.) 

If you want to have a look, that would be great. I'd be very happy for 
anyone to adjust the resolution if you can see better. 

Thanks. 

Carlton



-- 
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/f3761ffe-63a4-4336-b481-4d47bea1b23e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Passing initial data to model formsets - a suggested improvement

2018-09-06 Thread Mark Gensler
Initial data for modelformsets is treated in an odd way, which was outlined 
and discussed in the issues below

https://code.djangoproject.com/ticket/16995#comment:1
https://code.djangoproject.com/ticket/29739 (submitted by me)

In summary, if the initial data provided to BaseModelFormSet.__init__ is 
longer than the number of extra forms, the excess data won't be rendered in 
forms.

This causes problems when 
a) writing abstract code which constructs the class separately from 
initialising it, or
b) the code reuses the same class with differing initial data. 

In these cases the length of the initial data may not be known at the time 
of class construction. 

In order to minimise regressions I'd suggest that model formsets use 
max(self.extra, len(self.initial_extra)) in place of self.extra when 
calculating total_form_count().

I can't see this causing major regressions as if a user would like to limit 
the length of the forms they should already be doing so with the `max_num` 
parameter to the modelformset_factory. Othewrise, why not use the 
additional data in self.initial_extra?

Mark

-- 
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/a0b827c5-b06f-43bb-83d1-bb89e1a6e78a%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

2018-09-06 Thread 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.