Re: [Django] #27580: add special field for storing content types

[Django]

#27580: add special field for storing content types
-+-
 Reporter:  Sergey Fedoseev  |Owner:  Sergey
 |  Fedoseev
 Type:  New feature  |   Status:  assigned
Component:   |  Version:  master
  contrib.contenttypes   |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Sergey Fedoseev):

 * owner:  nobody => Sergey Fedoseev
 * status:  new => assigned


--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.a06f7c017406c9ea9eaadf92a37a70af%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #17002: ManyToManyField through a model which extends some other model

[Django]

#17002: ManyToManyField through a model which extends some other model
-+-
 Reporter:  Mitar|Owner:
 |  InvalidInterrupt
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 In [changeset:"98359109eb0ed68a5821476bcd797455723aaaba" 9835910]:
 {{{
 #!CommitTicketReference repository=""
 revision="98359109eb0ed68a5821476bcd797455723aaaba"
 Fixed #17002 -- Allowed using a ManyToManyField through model that
 inherits another.
 }}}

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.93ae86e271878c076dfb4951cae33d45%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27579: Alias Python 3's assertion names on Python 2 in SimpleTestCase

[Django]

#27579: Alias Python 3's assertion names on Python 2 in SimpleTestCase
-+-
 Reporter:  Tim Graham   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by GitHub ):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 In [changeset:"b5f0b3478dfcf0335f8ac2038d59f54b4a05f2a0" b5f0b347]:
 {{{
 #!CommitTicketReference repository=""
 revision="b5f0b3478dfcf0335f8ac2038d59f54b4a05f2a0"
 Fixed #27579 -- Added aliases for Python 3's assertion names in
 SimpleTestCase.
 }}}

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.030dffd79e9be7eeca2e702a31cfd2d9%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27579: Alias Python 3's assertion names on Python 2 in SimpleTestCase

[Django]

#27579: Alias Python 3's assertion names on Python 2 in SimpleTestCase
-+-
 Reporter:  Tim Graham   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Simon Charette):

 * stage:  Accepted => Ready for checkin


--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.5f242a3b8e02831f825f942e07d669e0%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27579: Alias Python 3's assertion names on Python 2 in SimpleTestCase

[Django]

#27579: Alias Python 3's assertion names on Python 2 in SimpleTestCase
--+
 Reporter:  Tim Graham|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Testing framework |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Simon Charette):

 * stage:  Unreviewed => Accepted


Comment:

 Makes sense to me.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.72d8308179147d3ef5ec117519949c20%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27498: Filtering annotated field in SQLite returns wrong results

[Django]

#27498: Filtering annotated field in SQLite returns wrong results
-+-
 Reporter:  Tim Düllmann |Owner:  Peter
 |  Inglesby
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  sqlite,  | Triage Stage:  Accepted
  annotations, filter|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Peter Inglesby):

 * owner:  nobody => Peter Inglesby
 * status:  new => assigned


--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.75991b7a435d60a45f81add637f577aa%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27472: GEOSGeometry('POINT EMPTY').ogr crashes

[Django]

#27472: GEOSGeometry('POINT EMPTY').ogr crashes
-+-
 Reporter:  Sergey Fedoseev  |Owner:  Sergey
 |  Fedoseev
 Type:  Bug  |   Status:  assigned
Component:  GIS  |  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * stage:  Accepted => Ready for checkin


--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.42b08f497c39e12c526a02b08063289b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #16682: KeyboardInterrupt not handled properly in transaction aborting

[Django]

#16682: KeyboardInterrupt not handled properly in transaction aborting
-+-
 Reporter:  Malcolm Tredinnick   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  1.11 | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by felixxm):

 Oracle DB is in the same version in both cases (12.1.0.2.0). I also
 checked DB params and there is nothing unusual in them. I don't know where
 is the source of the problem.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/069.c5da30ef2a37d82aa3465eb2668e5e8e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25708: cannot annotate with geometry value

[Django]

#25708: cannot annotate with geometry value
-+-
 Reporter:  Sergey Fedoseev  |Owner:  Sergey
 |  Fedoseev
 Type:  Bug  |   Status:  closed
Component:  GIS  |  Version:  1.8
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 In [changeset:"f909fa84bedb51778a175aadfe4cfe7a91fe06cd" f909fa8]:
 {{{
 #!CommitTicketReference repository=""
 revision="f909fa84bedb51778a175aadfe4cfe7a91fe06cd"
 Fixed #25708 -- Fixed annotations with geometry values.
 }}}

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.352a81801e39ee650c13182650480ad6%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27560: Formset.save() crashes for model with foreign key to concrete base model

[Django]

#27560: Formset.save() crashes for model with foreign key to concrete base model
-+-
 Reporter:  Lorenzo Peña |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  1.9
 Severity:  Normal   |   Resolution:
 Keywords:  formset  | Triage Stage:
  inline_formset |  Unreviewed
  inline_formsetfactory  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Lorenzo Peña):

 I'll have to investigate, but for the record:

 1. In this view, I'm creating master and details at the same time, so I
 don't have really anything to pass because nothing exists yet.
 2. Regarding the fact that I'm omitting the link to master, do you suggest
 a hidden field?
 3. This exact pattern works in at least one more place in my codebase,
 only crashing when the abstract base is involved in the child formset.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.8c77b64b965df6578822d20704a0041e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #27580: add special field for storing content types

[Django]

#27580: add special field for storing content types
+
   Reporter:  Sergey Fedoseev   |  Owner:  nobody
   Type:  New feature   | Status:  new
  Component:  contrib.contenttypes  |Version:  master
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 `ContentType` model is quite specific, so we could add the subclass of
 ForeignKey field with some specific features.

 For example we have such model:

 {{{
 #!python
 class ModelWithContentTypeField(models.Model):
 ct = ContentTypeField(on_delete=models.CASCADE)
 }}}

 In comparison with `ForeignKey` `ContentTypeField` will have these
 features:

 1. `ModelWithContentTypeField.objects.first().ct` will use content types
 cache.

 2. `ContentTypeField` will support lookups on the model classes:
 `ModelWithContentTypeField.objects.filter(ct=FooModel)` vs
 
`ModelWithContentTypeField.objects.filter(ct=ContentType.objects.get_for_model(FooModel))`

 `ModelWithContentTypeField.objects.filter(ct__in=[FooModel, BarModel])` vs
 
`ModelWithContentTypeField.objects.filter(ct__in=[ContentType.objects.get_for_model(model)
 in [FooModel, BarModel]])`

 3. Creation using a model class as a value:
 `ModelWithContentTypeField.objects.create(ct=FooModel)`

 Here's [https://github.com/sir-sigurd/django/tree/contenttype-field-3
 rough implementation].

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/053.2275423dc28e230a3d254a2f4c2c05cc%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27560: Formset.save() crashes for model with foreign key to concrete base model

[Django]

#27560: Formset.save() crashes for model with foreign key to concrete base model
-+-
 Reporter:  Lorenzo Peña |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  1.9
 Severity:  Normal   |   Resolution:
 Keywords:  formset  | Triage Stage:
  inline_formset |  Unreviewed
  inline_formsetfactory  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 This report is awfully complicated and without spending more than a few
 minutes investigating I can't say whether or not this is a bug in Django
 or in your code. One thing to try might be:
 `DetailModelFormset(self.request.POST, instance=master_instance)`.

 It seems like excluding `master` from `DetailModelForm` may also be
 related. (How can you have an inline formset without the field linking the
 subforms to the parent?)

 It would be nice if you do more to confirm that this is actually a bug,
 such as by [wiki:TicketClosingReasons/UseSupportChannels using our support
 channels]. Putting together a sample project with a test case that someone
 could download to quickly reproduce the issue would also help.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.2a891e2d1475a645e72bf4572904eb23%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27560: Formset.save() crashes for model with foreign key to concrete base model

[Django]

#27560: Formset.save() crashes for model with foreign key to concrete base model
-+-
 Reporter:  Lorenzo Peña |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  1.9
 Severity:  Normal   |   Resolution:
 Keywords:  formset  | Triage Stage:
  inline_formset |  Unreviewed
  inline_formsetfactory  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Lorenzo Peña):

 Updated ticket to expand context so that bug may be (hopefully)
 reproduced.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.db639766d679d94ccc1b5e5fe6f76607%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27560: Formset.save() crashes for model with foreign key to concrete base model

[Django]

#27560: Formset.save() crashes for model with foreign key to concrete base model
-+-
 Reporter:  Lorenzo Peña |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  1.9
 Severity:  Normal   |   Resolution:
 Keywords:  formset  | Triage Stage:
  inline_formset |  Unreviewed
  inline_formsetfactory  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Lorenzo Peña:

Old description:

> {{{
> class A(models.Model):
>   pass
>
> class B(A):
>   pass
>
> class C(models.Model):
>   some_model = models.ForeignKey(SomeModel)
>   a_link = models.ForeignKey(A)
> }}}
>
> I'm using an inlineformset_factory where the parent model is SomeModel
> and the child model is C.
> When calling formset.save() I'm getting an error from
> django/forms/models.py (line 910)
>
> {{{
> 910:   pk_value = getattr(self.instance, self.fk.remote_field.field_name)
> 911:   setattr(obj, self.fk.get_attname(), getattr(pk_value, 'pk',
> pk_value))
> }}}
>
> The getattr call fails
>
> if I wrap both lines in: if hasattr(self.instance,
> self.fk.remote_field.field_name):
> it works good.
>
> Not sure if the condition is the way to fix the bug or it's just
> preventing the original cause from happening.

New description:

 Model hierharchy

 {{{
 class ConcreteBase(models.Model):
 ...


 class Descendant(ConcreteBase):
 ...
 }}}

 Master / Detail type models (e.g. Order and OrderDetail)

 {{{
 class MasterModel(models.Model):
 ...


 class DetailModel(models.Model):

 master = models.ForeignKey(MasterModel, ...)
 concrete_base = models.ForeignKey(ConcreteBase, ...)
 }}}

 Form definition

 {{{
 class MasterModelForm(forms.ModelForm):
 ...


 class DetailModelForm(forms.ModelForm):
 ...
 # master excluded from fields as will be manually added in view
 ...
 }}}

 Formset definition

 {{{
 DetailModelFormset = inlineformset_factory(MasterModel, DetailModel,
 form=DetailModelForm)
 }}}

 View definition

 {{{
 from django.views.generic.edit import CreateView  < the error only
 happens on create view of MasterModel

 class MasterModelAdd(CreateView):
 model = MasterModel
 form_class = MasterModelForm
 ...

 def form_valid(self, form):
 master_instance = form.save()
 detail_formset = DetailModelFormset()(self.request.POST)
 detail_instances = detail_formset.save(commit=False) ### <--
 this line raises the error
 for detail_instance in detail_instances: ### <- it never gets
 here
 detail_instance.master = master_instance
 detail_instance.save()

 }}}

 When calling formset.save() I'm getting an error from
 django/forms/models.py (line 910) regardless of the value of commit
 passed.

 {{{
 910:   pk_value = getattr(self.instance, self.fk.remote_field.field_name)
 911:   setattr(obj, self.fk.get_attname(), getattr(pk_value, 'pk',
 pk_value))
 }}}

 The getattr call fails

 if I wrap both lines in: {{{ if hasattr(self.instance,
 self.fk.remote_field.field_name): }}}
 it works good.

 Not sure if the condition is the way to fix the bug or it's just
 preventing the original cause from happening.

--

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.5e9da8251a6beeb4381a7ae0673fdec3%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #9318: "Virtual" behaviour for signal dispatcher and model inheritance

[Django]

#9318: "Virtual" behaviour for signal dispatcher and model inheritance
-+-
 Reporter:  Alexander Artemenko  |Owner:  (none)
 Type:  New feature  |   Status:  new
Component:  Core (Other) |  Version:  1.0
 Severity:  Normal   |   Resolution:
 Keywords:  model inheritance,   | Triage Stage:  Accepted
  signals, dispatch, proxy,  |
  subclass   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Aymeric Augustin):

 * type:  Bug => New feature


Comment:

 For proxy models it's a straightforward bug.

 For multi-table inheritance it's more complicated.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/070.b005edac927839da6df9d2bc48a2137a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #9318: "Virtual" behaviour for signal dispatcher and model inheritance

[Django]

#9318: "Virtual" behaviour for signal dispatcher and model inheritance
-+-
 Reporter:  Alexander Artemenko  |Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  Core (Other) |  Version:  1.0
 Severity:  Normal   |   Resolution:
 Keywords:  model inheritance,   | Triage Stage:  Accepted
  signals, dispatch, proxy,  |
  subclass   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Aymeric Augustin):

 * type:  New feature => Bug


Comment:

 I hit this bug today.

 It's really a silent data loss issue: creating a proxy model shouldn't
 disable behavior of the original model.

 I'm applying the following patch to Django until this is resolved:

 {{{
 --- a/django/db/models/base.py  2016-12-07 17:09:16.0 +0100
 +++ b/django/db/models/base.py  2016-12-07 17:13:18.0 +0100
 @@ -810,13 +810,12 @@
  using = using or router.db_for_write(self.__class__,
 instance=self)
  assert not (force_insert and (force_update or update_fields))
  assert update_fields is None or len(update_fields) > 0
 -cls = origin = self.__class__
 -# Skip proxies, but keep the origin as the proxy model.
 +cls = self.__class__
  if cls._meta.proxy:
  cls = cls._meta.concrete_model
  meta = cls._meta
  if not meta.auto_created:
 -signals.pre_save.send(sender=origin, instance=self, raw=raw,
 using=using,
 +signals.pre_save.send(sender=cls, instance=self, raw=raw,
 using=using,
update_fields=update_fields)
  with transaction.atomic(using=using, savepoint=False):
  if not raw:
 @@ -829,7 +828,7 @@

  # Signal that the save is complete
  if not meta.auto_created:
 -signals.post_save.send(sender=origin, instance=self,
 created=(not updated),
 +signals.post_save.send(sender=cls, instance=self,
 created=(not updated),
 update_fields=update_fields, raw=raw,
 using=using)

  save_base.alters_data = True
 }}}

 IMO this is the correct way to fix the issue. I understand the concern
 about backwards compatibility but I have a hard time figuring out a
 realistic scenario where developers would purposefully rely on this bug.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/070.630e023c9042a3fea04a8cbdf44a8229%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24994: Document/check that settings.SECRET_KEY should be a valid unicode string

[Django]

#24994: Document/check that settings.SECRET_KEY should be a valid unicode string
-+-
 Reporter:  Baptiste Mispelon|Owner:  MaartenPI
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Core (System |  Version:  1.8
  checks)|
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Andres Mejia):

 Cryptographic keys are suppose to be random bytes that don't necessarily
 represent a Unicode string. See also the RFC I linked in my comment.

 I think it's fair to assume devs using the SECRET_KEY know it must be used
 as bytes. Various crypto libraries will refuse to accept them otherwise.
 This is true of the hmac, cryptography, and pyOpenSSL libraries.

 As for my use case, a common practice is to use an external script or
 program to pipe secrets into processes that need them. I use something
 like this to not only setup my Django sites but to also rotate the secrets
 in them whenever necessary. The output from a subprocess.check_output()
 call is in bytes. As of now, since Django accepts the SECRET_KEY as bytes,
 I use random bytes for my SECRET_KEY and have it loaded in my Django sites
 via an external program.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.81f241811209ecc4472c44843207ce7a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24128: Admindocs doesn't account for template loaders

[Django]

#24128: Admindocs doesn't account for template loaders
---+
 Reporter:  Aymeric Augustin   |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admindocs  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by Tim Graham):

 * needs_tests:  1 => 0


--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.3fbc7813f2b7c19223ca7aec5f5ea465%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #17002: ManyToManyField through a model which extends some other model

[Django]

#17002: ManyToManyField through a model which extends some other model
-+-
 Reporter:  Mitar|Owner:
 |  InvalidInterrupt
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * stage:  Accepted => Ready for checkin


Comment:

 I've made a few cosmetic edits to the PR and plan to merge this after
 #27579 as I've used part of that patch .

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.d21a841333a65928f8df01dc00c75bfd%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #17235: Multipartparser shouldn't leave request.POST/request.FILES mutable (was: Multipartparser shouldn't leave the QueryDict mutable)

[Django]

#17235: Multipartparser shouldn't leave request.POST/request.FILES mutable
---+
 Reporter:  Florian Apolloner  |Owner:  (none)
 Type:  Bug|   Status:  new
Component:  HTTP handling  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by Tim Graham):

 * has_patch:  1 => 0


Comment:

 The ticket remains open to address `request.FILES`.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.f14a9ee9bee211d9e3337e762262ed76%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #17235: Multipartparser shouldn't leave the QueryDict mutable

[Django]

#17235: Multipartparser shouldn't leave the QueryDict mutable
---+
 Reporter:  Florian Apolloner  |Owner:  (none)
 Type:  Bug|   Status:  new
Component:  HTTP handling  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by Tim Graham ):

 In [changeset:"4a246a02bdcbc13b15480c014f51cb0682af7c1e" 4a246a0]:
 {{{
 #!CommitTicketReference repository=""
 revision="4a246a02bdcbc13b15480c014f51cb0682af7c1e"
 Refs #17235 -- Made MultiPartParser leave request.POST immutable.
 }}}

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.0327c1c8dfd7719263b5d74a991ab942%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23919: Cleanups for when we drop Python 2 compatibility

[Django]

#23919: Cleanups for when we drop Python 2 compatibility
-+-
 Reporter:  Tim Graham   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Core (Other) |  Version:
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Tim Graham:

Old description:

> This is a tracking ticket of things that we can remove when we drop
> Python 2 compatibility in Django 2.0. Please edit the description of the
> ticket as you come across new items.
>
> * `django.core.mail.message.make_msgid()` #23905
> * `django.dispatch.weakref_backports`
> * `django.http.cookie` workarounds
> * `django.utils.2to3_fixes`
> * `django.utils.decorators.ContextDecorator`
> * `django.utils.encoding`
>  * `@python_2_unicode_compatible`
>  * force/smart _unicode
>  * either force/smart _text or force/smart _str
> * `django.utils.html_parser.use_workaround`
> * `django.utils.http` functions like `urlquote_plus` -- I think the
> versions of these functions on Python 3 don't have the unicode characters
> bug we are working around.
> * `django.utils.lru_cache`
> * `django.utils.six`
> * `from __future__ import unicode_literals`
> * `str()` stuff for environment variables, e.g.
> 0bfb53866199f366ed140d49938fd185e5898156
> * Inheriting from `object` in `django.core.servers.basehttp` (and perhaps
> other places) ala 4ee06ec3fc8e94d164afbd2f9c880c60c658a9ac
> * `git grep 'long int'` (mostly docs)
> * `django.utils._os [npath,upath]`
> * In tests: `contextlib.closing(self.urlopen` (`contextlib.closing` no
> longer needed)
> * Support for pysqlite (doesn't support Python 3)
> * Replace `super(ClassName, self)` with `super()`
> * Remove `# -*- coding: utf-8 -*-` source file encoding (that's the
> default on Python 3)
> * Evaluate replacement of custom `__del__` methods by
> [https://docs.python.org/3/library/weakref.html#weakref.finalize
> weakref.finalize]
> * Remove `__ne__` from objects already defining a `__eq__`
> * Remove note about PYTHONHASHSEED (see #26243)
> * Remove Field.creation_counter (replace by metaclass `__prepare__`
> returning `OrderedDict()`,
> https://docs.python.org/3/reference/datamodel.html#preparing-the-class-
> namespace)
> * `django.test.utils.reset_warning_registry()`
> * Replace `errno` checks by `IOError` subclasses defined by
> [https://www.python.org/dev/peps/pep-3151/ PEP 3151]
> * `django.utils.glob`
> * `django.utils.cookies.SimpleCookie`
> * `django.test.mock`
> * Replace `tempfile.mkdtemp` + remove with `tempfile.TemporaryDirectory`
> context manager
> * Replace `io.open()` by a plain `open()`

New description:

 This is a tracking ticket of things that we can remove when we drop Python
 2 compatibility in Django 2.0. Please edit the description of the ticket
 as you come across new items.

 * `django.core.mail.message.make_msgid()` #23905
 * `django.dispatch.weakref_backports`
 * `django.http.cookie` workarounds
 * `django.utils.2to3_fixes`
 * `django.utils.decorators.ContextDecorator`
 * `django.utils.encoding`
  * `@python_2_unicode_compatible`
  * force/smart _unicode
  * either force/smart _text or force/smart _str
 * `django.utils.html_parser.use_workaround`
 * `django.utils.http` functions like `urlquote_plus` -- I think the
 versions of these functions on Python 3 don't have the unicode characters
 bug we are working around.
 * `django.utils.lru_cache`
 * `django.utils.six`
 * `from __future__ import unicode_literals`
 * `str()` stuff for environment variables, e.g.
 0bfb53866199f366ed140d49938fd185e5898156
 * Inheriting from `object` in `django.core.servers.basehttp` (and perhaps
 other places) ala 4ee06ec3fc8e94d164afbd2f9c880c60c658a9ac
 * `git grep 'long int'` (mostly docs)
 * `django.utils._os [npath,upath]`
 * In tests: `contextlib.closing(self.urlopen` (`contextlib.closing` no
 longer needed)
 * Support for pysqlite (doesn't support Python 3)
 * Replace `super(ClassName, self)` with `super()`
 * Remove `# -*- coding: utf-8 -*-` source file encoding (that's the
 default on Python 3)
 * Evaluate replacement of custom `__del__` methods by
 [https://docs.python.org/3/library/weakref.html#weakref.finalize
 weakref.finalize]
 * Remove `__ne__` from objects already defining a `__eq__`
 * Remove note about PYTHONHASHSEED (see #26243)
 * Remove Field.creation_counter (replace by metaclass `__prepare__`
 returning `OrderedDict()`,
 https://docs.python.org/3/reference/datamodel.htm

[Django] #27579: Alias Python 3's assertion names on Python 2 in SimpleTestCase

[Django]

#27579: Alias Python 3's assertion names on Python 2 in SimpleTestCase
+
   Reporter:  Tim Graham|  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Testing framework |Version:  master
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 To minimize the usage of `six` so there's less changes to make when
 dropping Python 2, the following Python 3 to Python 2 aliases could be
 added:
 {{{
 assertCountEqual = unittest.TestCase.assertItemsEqual
 assertNotRegex = unittest.TestCase.assertNotRegexpMatches
 assertRaisesRegex = unittest.TestCase.assertRaisesRegexp
 assertRegex = unittest.TestCase.assertRegexpMatches
 }}}

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/052.85e0fbd6af665c00461d5f319cb55c43%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27579: Alias Python 3's assertion names on Python 2 in SimpleTestCase

[Django]

#27579: Alias Python 3's assertion names on Python 2 in SimpleTestCase
-+-
 Reporter:  Tim Graham   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/7662 PR]

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.c0c4f055b83cd267e0ead898a4e3fbd6%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24994: Document/check that settings.SECRET_KEY should be a valid unicode string

[Django]

#24994: Document/check that settings.SECRET_KEY should be a valid unicode string
-+-
 Reporter:  Baptiste Mispelon|Owner:  MaartenPI
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Core (System |  Version:  1.8
  checks)|
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Aymeric Augustin):

 * status:  closed => new
 * resolution:  needsinfo =>


Comment:

 Once Django drops support for Python 2 you'll have to go out of your way
 to put bytes in the SECRET_KEY.

 Currently, since the type isn't enforced, every app that wants to do
 something with SECRET_KEY should conditionally convert it to bytes,
 typically with `force_bytes`, since it _could_ be bytes. I don't think
 this is common knowledge; it's even a pitfall.

 Enforcing the type would simplify that code and avoid errors for the
 minority who uses bytes in pluggable apps that assume text e.g. by doing
 `settings.SECRET_KEY.encode()`.

 mejiaa has spent a lot of time lobbying for making this change in the
 debug toolbar but his opinion has received little support until now and I
 disagree with them.

--
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.6cf63ded8d46ccbe02e45c01ec64425f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.