Re: [Django] #28027: UTF-8 in help_text in models.ManyToManyField doesn't work anymore

[Django]

#28027: UTF-8 in help_text in models.ManyToManyField doesn't work anymore
---+--
 Reporter:  Thomas Kähn|Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  Version:  1.11
 Severity:  Normal |   Resolution:  invalid
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by Thomas Kähn):

 Hi,

 thank you very much for the hints and link to the commit. I can also
 confirm that the problem is gone when using Unicode strings.

 Best regards
 Thomas

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

Re: [Django] #28029: Removal of ability to reverse by dotted path found to be very non-DRY

[Django]

#28029: Removal of ability to reverse by dotted path found to be very non-DRY
--+--
 Reporter:  Henrik Levkowetz  |Owner:  nobody
 Type:  Uncategorized |   Status:  closed
Component:  Core (URLs)   |  Version:  1.10
 Severity:  Normal|   Resolution:  invalid
 Keywords:| Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--

Comment (by Henrik Levkowetz):

 I'm sorry if I tried to point out what I feel is a mistake in the wrong
 place, by opening a ticket and referring back to the earlier ticket.  I
 had considered posting to the dev list, but when one of the core
 developers with whom I talked at DjangoCon Europe (happening right now)
 suggested I open a ticket about the matter, I did so.

 I have read the [https://groups.google.com/d/topic/django-
 developers/zTGP3Bs6uKE/discussion thread you pointed out], and I don't
 find a rationale for removing the reversal by dotted path there.  What I
 find is a conflation of the two different issues mentioned in #22384.
 Everything seems to hinge on Marc Tamlyn's statements in his final post on
 that short thread, where he says "Firstly, it relies on automatic imports
 via strings, ..." , which seems to associate the dotted-path-reversal
 change with the ability to naming view functions by strings in `url()`.

 However, removing automatic import via strings is orthogonal to the
 ability to support reversal by dotted, path, as evidenced by the ability
 to write a custom `url()` function the way I did, and the way originally
 suggested by you (Tim).

 My immediate problem is solved, but the harm I feel is done to Django by
 the removal of the ability to do reversal by the dotted path of the view
 function is not.  Forcing people to re-invent new names for something that
 already has a clear and definitive name is '''not''' supporting DRY, quite
 the opposite.

 So, what now?  Is your (Tim) advice to take this up on the dev mailing
 list trumping the earlier advice from a core developer to submit a ticket?
 How can I open a discussion of this issue which will receive
 consideration?

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

Re: [Django] #28031: Documentation for uwsgi deployment mentions buggy uwsgi packages in some distros but not when they were fixed

[Django]

#28031: Documentation for uwsgi deployment mentions buggy uwsgi packages in some
distros but not when they were fixed
-+
 Reporter:  Richard Barrell  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Documentation|  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 Richard Barrell):

 I agree with you that removing the note entirely is a good course of
 action too.

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

Re: [Django] #28027: UTF-8 in help_text in models.ManyToManyField doesn't work anymore

[Django]

#28027: UTF-8 in help_text in models.ManyToManyField doesn't work anymore
---+--
 Reporter:  Thomas Kähn|Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  Version:  1.11
 Severity:  Normal |   Resolution:  invalid
 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 Tim Graham):

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


Comment:

 Confirmed that a UTF=8 encoded bytestring is needed to reproduce the
 crash.

 For the record, the commit that introduced the change is
 2315114090815aed72be2b9bc936d7b6374f12fc.

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

Re: [Django] #28019: Django django.db.models.Model.save() logic bit illogical?

[Django]

#28019: Django django.db.models.Model.save() logic bit illogical?
-+-
 Reporter:  Jacek Kałucki|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  needsinfo
 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 Tim Graham):

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


Comment:

 I also cannot reproduce a crash using the provided code. I think we would
 like you to provide a tested patch to prove that your suggested approach
 is viable and passes existing tests. It's a bit difficult to assess that
 by reading a description of the changes. Please reopen the ticket if you
 can do that. Thanks. (Retitling the ticket's summary would also be useful
 as it's difficult to get an idea of the proposal based on the current
 wording.)

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

Re: [Django] #28031: Documentation for uwsgi deployment mentions buggy uwsgi packages in some distros but not when they were fixed

[Django]

#28031: Documentation for uwsgi deployment mentions buggy uwsgi packages in some
distros but not when they were fixed
-+
 Reporter:  Richard Barrell  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Documentation|  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):

 * has_patch:  0 => 1
 * stage:  Unreviewed => Accepted


Comment:

 As mentioned on the pull request, I think this note could be removed since
 it refers to old, end-of-life or near end-of-life versions.

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

Re: [Django] #27846: refresh_from_db() doesn't clear reverse OneToOneFields

[Django]

#27846: refresh_from_db() doesn't clear reverse OneToOneFields
-+-
 Reporter:  Keith Hostetler  |Owner:  Matvey
 |  Kukuy
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  refresh_from_db  | Triage Stage:  Accepted
  OneToOneField  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Matvey Kukuy):

 * owner:  nobody => Matvey Kukuy
 * 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/067.5583469d0ab1e7f81ea9faf2bc3cd640%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28029: Removal of ability to reverse by dotted path found to be very non-DRY

[Django]

#28029: Removal of ability to reverse by dotted path found to be very non-DRY
--+--
 Reporter:  Henrik Levkowetz  |Owner:  nobody
 Type:  Uncategorized |   Status:  closed
Component:  Core (URLs)   |  Version:  1.10
 Severity:  Normal|   Resolution:  invalid
 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 Tim Graham):

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


Comment:

 The rationale is explained in more detail on the
 [https://groups.google.com/d/topic/django-
 developers/zTGP3Bs6uKE/discussion developers mailing list].  You may
 continue the conversation there, but the ticket tracker isn't the place to
 raise inactionable feedback like this. If the conversation on the mailing
 list reveals a consensus to make some change, we would open a ticket at
 that point.

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

Re: [Django] #27985: Converting `Foo.objects.filter(bar=None)` to an `IsNull` too early.

[Django]

#27985: Converting `Foo.objects.filter(bar=None)` to an `IsNull` too early.
-+-
 Reporter:  Jarek Glowacki   |Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  sql None NULL| Triage Stage:  Accepted
  transform  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Jarek Glowacki):

 * owner:  Jarek Glowacki => (none)
 * status:  assigned => new


Comment:

 Yeahh, nope.
 The current workflow is too convoluted to just slot in a patch for this.

 I couldn't find a way to untangle the ordering such that it'd cover this
 use case without breaking multiple other use cases.
 I'd suggest taking this ticket under consideration when someone comes
 round to refactor this file.

 Specifically, the functions `build_filter` and `prepare_lookup_value` need
 to be broken down into more managable bits. It's evident they've had extra
 conditional steps shoehorned in over time, which has made them very
 difficult to work with.


 For anyone who comes across this in the future, all we need to address
 this case is ensure that this snippet of code from `prepare_lookup_value`:
 {{{
 # Interpret '__exact=None' as the sql 'is NULL'; otherwise, reject
 all
 # uses of None as a query value.
 if value is None:
 if lookups[-1] not in ('exact', 'iexact'):
 raise ValueError("Cannot use None as a query value")
 return True, ['isnull'], used_joins
 }}}
 is evaluated AFTER the field's `get_prep_value` has processed the value.
 Here are the failing tests again:
 [https://github.com/django/django/compare/master...jarekwg:ticket_27985
 Failing tests]

 And here's a bandaid workaround that hacks two lookups and the form field
 to get around the problem.
 {{{
 class NulledCharField(models.CharField):
 """
 This is required when we want uniqueness on a CharField whilst also
 allowing it to be empty.
 In the DB, '' == '', but NULL != NULL. So we store emptystring as NULL
 in the db, but treat it
 as emptystring in the code.
 """
 description = _("CharField that stores emptystring as NULL but returns
 ''.")

 def from_db_value(self, value, expression, connection, context):
 if value is None:
 return ''
 else:
 return value

 def to_python(self, value):
 if isinstance(value, models.CharField):
 return value
 if value is None:
 return ''
 return value

 def get_prep_value(self, value):
 if value is '':
 return None
 else:
 return value

 class NulledCharField(forms.CharField):
 """ A form field for the encompassing model field. """
 def clean(self, value):
 if value == '':
 return None
 return value

 def formfield(self, form_class=None, **kwargs):
 return
 super().formfield(form_class=self.__class__.NulledCharField, **kwargs)


 @NulledCharField.register_lookup
 class NulledCharExactLookup(Exact):
 """ Generate ISNULL in the `exact` lookup, because Django won't use
 the `isnull` lookup correctly. """
 lookup_name = 'exact'

 def as_sql(self, compiler, connection):
 sql, params = compiler.compile(self.lhs)
 if self.rhs in ('', None):
 return "%s IS NULL" % sql, params
 else:
 return super().as_sql(compiler, connection)


 @NulledCharField.register_lookup
 class NulledCharIsNullLookup(IsNull):
 """
 Doing something like Foo.objects.exclude(bar='') has django trying to
 shove
 an extra isnull check where it doesn't need one. We solve this by just
 crippling
 this lookup altogether. We don't need it as all ISNULL checks that we
 actually
 do want, we generate in the `exact` lookup. :(
 """
 lookup_name = 'isnull'
 prepare_rhs = False

 def as_sql(self, compiler, connection):
 sql, params = compiler.compile(self.lhs)
 return "TRUE", params
 }}}

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

Re: [Django] #28030: queryset.union count() method throws TypeError

[Django]

#28030: queryset.union count() method throws TypeError
-+-
 Reporter:  David Binetti|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  duplicate
 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 Simon Charette):

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


Comment:

 Duplicate of #27995.

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

Re: [Django] #28031: Documentation for uwsgi deployment mentions buggy uwsgi packages in some distros but not when they were fixed

[Django]

#28031: Documentation for uwsgi deployment mentions buggy uwsgi packages in some
distros but not when they were fixed
-+--
 Reporter:  Richard Barrell  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Documentation|  Version:  master
 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
-+--

Comment (by Richard Barrell):

 I've filed a pull request at https://github.com/django/django/pull/8301

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

[Django] #28031: Documentation for uwsgi deployment mentions buggy uwsgi packages in some distros but not when they were fixed

[Django]

#28031: Documentation for uwsgi deployment mentions buggy uwsgi packages in some
distros but not when they were fixed
---+
   Reporter:  Richard Barrell  |  Owner:  nobody
   Type:  Bug  | Status:  new
  Component:  Documentation|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|
---+
 In `docs/howto/deployment/wsgi/uwsgi.txt` there is a warning about Debian
 and Ubuntu shipping outdated versions of uwsgi, prior to uwsgi version
 `1.2.6`. However, current Debian and Ubuntu versions already ship newer
 uwsgi packages than `1.2.6`.

 I'm concerned someone who is using an up-to-date version of Debian or
 Ubuntu might see this note and decide that this means they need to compile
 uwsgi from source themselves. Then they wouldn't be able to get security
 patches for their uwsgi binary via `apt-get` any more.

 Debian 8 (jessie) ships version `2.0.7`, according to
 https://packages.debian.org/jessie/uwsgi
 (Debian 7 was shipping `1.2.3`.)

 Ubuntu 14.04 (trusty) ships version `1.9.17` according to
 http://packages.ubuntu.com/trusty/uwsgi
 (Ubuntu 12.04 was shipping `1.0.3`.)

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

[Django] #28030: queryset.union count() method throws TypeError

[Django]

#28030: queryset.union count() method throws TypeError
-+-
   Reporter:  David  |  Owner:  nobody
  Binetti|
   Type:  Bug| Status:  new
  Component:  Database   |Version:  1.11
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 I'm not entirely certain how to create a test case, but here is the full
 description:

 {{{
 # models.py

 class Entity(models.Model):
"""Self-joined Model"""
 

 parent = models.ForeignKey(
 'self',
 null=True,
 blank=True,
 related_name='children',
 db_index=True,
 on_delete=models.SET_NULL,
 )


 class Award(models.Model):

 ...

 entity = models.ForeignKey(
 'Entity',
 related_name='awards',
 on_delete=models.CASCADE,
 )
 }}}


 With that, I'm using the new `union` method  of 1.11 to create a queryset
 combining all the  all the  `award` objects that relate to a particular
 `entity` *and* the `award` objects of that `entity`'s children.

 Thus, the queryset is:


 {{{
 e = Entity.objects.first()

 qs = Award.objects.filter(entity=e).union(
 Award.objects.filter(entity__parent=e)
 )
 }}}

 This works, BTW, and produces the correct queryset results.  However, when
 I try to call count() I get...

 {{{
 >>>qs.count()

 TypeError: int() argument must be a string, a bytes-like object or a
 number, not 'datetime.datetime'
 }}}

 with the following stack trace:

 {{{
 In [5]: qs.count()
 ---
 TypeError Traceback (most recent call
 last)
  in ()
 > 1 qs.count()

 /Users/dbinetti/.virtualenvs/barberscore-django/lib/python3.6/site-
 packages/django/db/models/query.py in count(self)
 361 return len(self._result_cache)
 362
 --> 363 return self.query.get_count(using=self.db)
 364
 365 def get(self, *args, **kwargs):

 /Users/dbinetti/.virtualenvs/barberscore-django/lib/python3.6/site-
 packages/django/db/models/sql/query.py in get_count(self, using)
 496 obj = self.clone()
 497 obj.add_annotation(Count('*'), alias='__count',
 is_summary=True)
 --> 498 number = obj.get_aggregation(using,
 ['__count'])['__count']
 499 if number is None:
 500 number = 0

 /Users/dbinetti/.virtualenvs/barberscore-django/lib/python3.6/site-
 packages/django/db/models/sql/query.py in get_aggregation(self, using,
 added_aggregate_names)
 482
 483 converters =
 compiler.get_converters(outer_query.annotation_select.values())
 --> 484 result = compiler.apply_converters(result, converters)
 485
 486 return {

 /Users/dbinetti/.virtualenvs/barberscore-django/lib/python3.6/site-
 packages/django/db/models/sql/compiler.py in apply_converters(self, row,
 converters)
 817 value = row[pos]
 818 for converter in convs:
 --> 819 value = converter(value, expression,
 self.connection, self.query.context)
 820 row[pos] = value
 821 return tuple(row)

 /Users/dbinetti/.virtualenvs/barberscore-django/lib/python3.6/site-
 packages/django/db/models/aggregates.py in convert_value(self, value,
 expression, connection, context)
  79 if value is None:
  80 return 0
 ---> 81 return int(value)
  82
  83

 TypeError: int() argument must be a string, a bytes-like object or a
 number, not 'datetime.datetime'
 }}}


 OK, I hope that's enough to go on.  Can answer questions if necessary

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

[Django] #28029: Removal of ability to reverse by dotted path found to be very non-DRY

[Django]

#28029: Removal of ability to reverse by dotted path found to be very non-DRY
+
   Reporter:  Henrik Levkowetz  |  Owner:  nobody
   Type:  Uncategorized | Status:  new
  Component:  Core (URLs)   |Version:  1.10
   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 |
+
 I've been using django for the site `datatracker.ietf.org` for about 10
 years now, updating to new Django releases along the way.  I've almost
 always appreciated the features of each new release, but release 1.10
 brought this feature removal:
  * The ability to reverse() URLs using a dotted Python path is removed.
(https://docs.djangoproject.com/en/1.10/releases/1.10/#features-
 removed-in-1-10)

 The site (datatracker.ietf.org) has about 750 distinct URL patterns, and
 we've been very good at referencing URLs using `{% url %}` in our
 templates, and using `django.url.reverse()` in code.  Given that the
 dotted url names previously provided gave a consistent DRY way of
 referring to the URL belonging to a given view function, we used it
 extensively.

 This means that in order to upgrade to 1.10 I was suddenly faced with the
 task of manually naming ~750 URL patterns with unique and meaningful
 names, and potentially updating many thousands of places using reverse URL
 lookup in code and templates, for no apparent benefit.

 The ticket which removed reversal by dotted path, #22384, also removed the
 ability to refer to view functions by strings in `url()`.  To be clear:
 This ticket is not about that change.  I found that a bit inconvenient,
 and it seems to me that it increases the risk of import loops, but that
 change is '''not''' what I'm contesting here; it's only the removal of the
 built-in ability to reverse by dotted path that I find very non-DRY.

 In the end I replaced `django.conf.urls.url()` with a wrapper that
 generated a dotted-url-path name based on the view function, which mostly
 restored the pre-1.10 functionality; but having to do that seems to me to
 be very contrary to the batteries-included approach we're proud of.

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

Re: [Django] #24030: default id field not migrated correctly

[Django]

#24030: default id field not migrated correctly
+--
 Reporter:  Brian May   |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  1.8
 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
+--

Comment (by Tim Graham):

 Is it different from #22997? Please give explicit step by step
 instructions (including code) to reproduce the issue.

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

Re: [Django] #28015: Add makemessages --add-location=full|file|never option (was: New argument for makemessages: --add-location=full|file|never)

[Django]

#28015: Add makemessages --add-location=full|file|never option
-+-
 Reporter:  Ling-Xiao Yang   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Core (Management |  Version:  master
  commands)  |
 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):

 * component:  Uncategorized => Core (Management commands)
 * stage:  Unreviewed => Accepted


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

Re: [Django] #6989: Inability to define DNS_NAME in django.core.mail results in e-mail messages being rejected or marked as spam

[Django]

#6989: Inability to define DNS_NAME in django.core.mail results in e-mail 
messages
being rejected or marked as spam
-+-
 Reporter:  Franklin |Owner:  heathervm
 Type:  Bug  |   Status:  assigned
Component:  Core (Mail)  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  local_hostname,  | Triage Stage:  Accepted
  DNS_NAME, CachedDnsName, smtplib,  |
  SMTPConnection |
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by heathervm):

 * owner:  nobody => heathervm
 * 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/066.2528b9613e28dd4bd65ef3b820a636d8%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #7452: Settings for HTML4 or XHTML output

[Django]

#7452: Settings for HTML4 or XHTML output
-+-
 Reporter:  Marc Fargas  |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Core (Other) |  Version:  master
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:  Design
 |  decision needed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by matsaman):

 "The web framework for perfectionists with deadlines." Maybe not everyone
 is using the same definition of perfection. =)

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

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:
 |  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Adam (Chainz) Johnson):

 * cc: me@… (added)


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

Re: [Django] #28024: GEOSCoordSeq performance could be improved significantly by avoiding superfluous checks

[Django]

#28024: GEOSCoordSeq performance could be improved significantly by avoiding
superfluous checks
-+-
 Reporter:  Sergey Fedoseev  |Owner:  Sergey
 Type:   |  Fedoseev
  Cleanup/optimization   |   Status:  assigned
Component:  GIS  |  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 Sergey Fedoseev):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/8300 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/068.075b6d7a1fa63b30792c03285496b4e1%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28023: Wrong method in SQL query log

[Django]

#28023: Wrong method in SQL query log
-+-
 Reporter:  erkib|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 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 Simon Charette):

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


Comment:

 This is caused by a combination of two things:

 1. You have a `pre_delete`/`post_delete` signal registered for your
 `MyModel` or foreign keys pointing to it so Django doesn't perform a
 `DELETE FROM` right away and collects objects matching your `filter()` in
 memory to simulate `ON DELETE`.
 2. No `MyModel` match your filter no the collection routine stops right
 away and doesn't both performing a `DELETE FROM`.

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

Re: [Django] #28023: Wrong method in SQL query log

[Django]

#28023: Wrong method in SQL query log
-+-
 Reporter:  erkib|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 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
-+-

Comment (by kapil garg):

 I don't see this. Here is the model i used and query i performed


 {{{
 class Test(models.Model):
 name = models.CharField(max_length=100, blank=True)

 #shell
 >>> Test.objects.filter(name__startswith='test').delete()
 (0.000) BEGIN; args=None
 (0.001) DELETE FROM "bug_test" WHERE "bug_test"."name" LIKE 'test%' ESCAPE
 '\'; args=('test%',)
 (1, {'bug.Test': 1})
 }}}

 Is this bug related to some particular backend or does this bug also
 result in failure of the `delete()` method ?
 Does your object get deleted or not ?

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

Re: [Django] #28027: UTF-8 in help_text in models.ManyToManyField doesn't work anymore

[Django]

#28027: UTF-8 in help_text in models.ManyToManyField doesn't work anymore
---+--
 Reporter:  Thomas Kähn|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  1.11
 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
---+--

Comment (by Claude Paroz):

 Is your UTF-8 content inside a Unicode string, or is it a bytestring?
 If you put UTF-8 encoded content as a bytestring, I would call that a
 programming error on your side. If it worked before, it was purely by
 accident.

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

Re: [Django] #27895: Test Client fails to decode json response with unicode characters

[Django]

#27895: Test Client fails to decode json response with unicode characters
-+-
 Reporter:  Aniruddha Maru   |Owner:  Aniruddha
 |  Maru
 Type:  Bug  |   Status:  closed
Component:  Testing framework|  Version:  1.10
 Severity:  Normal   |   Resolution:  fixed
 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):

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


Comment:

 Reclosing. A pull request was never provided for 1.11.

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

Re: [Django] #27730: Document that template tags with "as" variable assignment don't propogate variables across blocks

[Django]

#27730: Document that template tags with "as" variable assignment don't 
propogate
variables across blocks
-+-
 Reporter:  Peter Bittner|Owner:  kapil
 Type:   |  garg
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  1.10
 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 kapil garg):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/8299 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/065.7240849b346b10c48c43ba5858e8922d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24030: default id field not migrated correctly

[Django]

#24030: default id field not migrated correctly
+--
 Reporter:  Brian May   |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  1.8
 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 Anupam):

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


Comment:

 Did a new ticket ever get opened for this one? I am seeing the same
 behaviour on Django 1.10.2.

 I used a custom primary key and later decided to go back to Django's
 default primary key (by not specifying any). On running makemigrations, it
 asked for default value for auto-generated ID field (because of the issue
 discussed in #22997). Providing a default ID also doesn't help because on
 running the migration, it gives the error 'Multiple default values
 specified for column “modelname_id"' ' which is expected since its an
 auto-increment field. To get around that, it seems the only solution is as
 mentioned here [http://stackoverflow.com/a/37356512/1526703] where the
 default is actually supplied at the prompt and then manually deleted from
 the migration created. After using the above workaround, the issue talked
 about in this ticket gets revealed (i.e the id field no longer auto-
 increments). Dropping the db and removing all migrations was the only
 thing that worked for me to get the default "id" field to auto-increment
 (otherwise keep getting the error 'null value in column "id" violates not-
 null constraint' on any insert).

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

Re: [Django] #28028: Support HTTP_HOST header: 'xxx.xxx.xxx.xxx, xxx.xxx.xxx.xxx, ...'

[Django]

#28028: Support HTTP_HOST header: 'xxx.xxx.xxx.xxx,xxx.xxx.xxx.xxx,...'
-+-
 Reporter:  Rafael Herrero   |Owner:  Rafael
  Solís  |  Herrero Solís
 Type:  Bug  |   Status:  assigned
Component:  HTTP handling|  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:  Multiple Host| Triage Stage:
  Headers|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Rafael Herrero Solís):

 * status:  new => assigned
 * owner:  nobody => Rafael Herrero Solís


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

Re: [Django] #28028: Support HTTP_HOST header: 'xxx.xxx.xxx.xxx, xxx.xxx.xxx.xxx, ...'

[Django]

#28028: Support HTTP_HOST header: 'xxx.xxx.xxx.xxx,xxx.xxx.xxx.xxx,...'
-+-
 Reporter:  Rafael Herrero   |Owner:  nobody
  Solís  |
 Type:  Bug  |   Status:  new
Component:  HTTP handling|  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:  Multiple Host| Triage Stage:
  Headers|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Aymeric Augustin):

 Does the HTTP RFC specify that the Host header may have this format?

 If not, I don't think Django should make a change.

 You should use a different, non-standard header.

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

Re: [Django] #28014: "manage.py makemigrations --check" exits with 0 in case of exception

[Django]

#28014: "manage.py makemigrations --check" exits with 0 in case of exception
-+-
 Reporter:  Daniel Hahler|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (Management |  Version:  master
  commands)  |   Resolution:
 Severity:  Normal   |  worksforme
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Daniel Hahler):

 Yes, it seems to work as expected.

 I guess I got confused because I used the deprecated `--exit` before,
 which would exit with 1 in case of no changes.
 Replaced it with `--check` now.

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

[Django] #28028: Support HTTP_HOST header: 'xxx.xxx.xxx.xxx, xxx.xxx.xxx.xxx, ...'

[Django]

#28028: Support HTTP_HOST header: 'xxx.xxx.xxx.xxx,xxx.xxx.xxx.xxx,...'
-+-
   Reporter:  Rafael |  Owner:  nobody
  Herrero Solís  |
   Type:  Bug| Status:  new
  Component:  HTTP   |Version:  1.10
  handling   |   Keywords:  Multiple Host
   Severity:  Normal |  Headers
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+-
 Using Nginx/Gunicorn to serve Django website without domain (ip) I
 detected that when i use
 {{{
 proxy_set_header Host $host;
 include proxy_params;
 }}}
 ' the resulting header become a comma separated list like so:
 'xxx.xxx.xxx.xxx,xxx.xxx.xxx.xxx' giving the following error:\\
 2017-04-05 14:15:49,517 ERROR [exception] Invalid HTTP_HOST
 header:'xxx.xxx.xxx.xxx,xxx.xxx.xxx.xxx'. The domain name provided is not
 valid according to RFC 1034/1035. /home/cpc/Virtualenvs/env/lib/python2.7
 /site-packages/django/core/handlers/exception.py 73

 Removing the  include proxy_params; directive may fix this, but it
 wouldn't be hard to modify 'django.http.request.validate_host' to split
 the hosts and check if all of them are in allowed hosts.

 I could do it my self if you consider this host header should be accepted
 in case all the hosts at the host header are allowed hosts, maybe even
 expect a settings.MULTIPLE_HOST_HEADER == True

 Here is an example of the nginx site.conf that would trigger it:

 {{{
 server {
 listen 80;
 server_name xxx.xxx.xxx.xxx;

 location = /favicon.ico {
 access_log off; log_not_found off;
 alias /var/www/site/static/favicon.ico;
 }

 # Static root settigns
 location /static/ {
 root /var/www/static/;
 }

 # WebSocket settings
 location /notifications/ {
 rewrite  ^/(.*)  /$1 break;

 proxy_pass http://127.0.0.1:8005;
 proxy_redirect off;

 proxy_set_header X-Real-IP $remote_addr;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

 proxy_http_version 1.1;
 proxy_set_header Upgrade $http_upgrade;
 proxy_set_header Connection "upgrade";
 proxy_read_timeout 600;
 }

 # Gunicorn proxy settings
 location / {
 proxy_set_header Host $host;
 include proxy_params;
 }

 error_page 500 502 503 504 /custom_50x.html;

 location = /custom_50x.html {
 root /usr/share/nginx/html;
 internal;
 }
 }
 }}}

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

Re: [Django] #28014: "manage.py makemigrations --check" exits with 0 in case of exception

[Django]

#28014: "manage.py makemigrations --check" exits with 0 in case of exception
-+-
 Reporter:  Daniel Hahler|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (Management |  Version:  master
  commands)  |   Resolution:
 Severity:  Normal   |  worksforme
 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 Tim Graham):

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


Comment:

 I also can't reproduce:
 {{{
 $ python manage.py makemigrations --check
 Traceback (most recent call last):
 ...
   File "/home/tim/code/mysite/polls/migrations/0001_initial.py", line 37
 raise Exception()
 Exception
 $ echo $?
 1
 }}}

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

[Django] #28027: UTF-8 in help_text in models.ManyToManyField doesn't work anymore

[Django]

#28027: UTF-8 in help_text in models.ManyToManyField doesn't work anymore
-+
   Reporter:  tkaehn |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  contrib.admin  |Version:  1.11
   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  |
-+
 Hi,

 since Django 1.11 UTF-8 text in help_text in models.ManyToManyField
 results in UnicodeDecodeError:

 'ascii' codec can't decode byte 0xc3 in position 33: ordinal not in
 range(128)

 Error during template rendering

 In template [...]/python2.7/site-
 packages/django/contrib/admin/templates/admin/includes/fieldset.html,
 error at line 7

 In Django 1.10 UTF-8 in help_texts worked fine. In other fields in Django
 1.11 it is possible to use UTF-8 in help_texts.

 I am using Python 2.7.

 Best regards
 Thomas

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

Re: [Django] #28026: Pillow version > 4.0.0 not recognized

[Django]

#28026: Pillow version > 4.0.0 not recognized
---+--
 Reporter:  voodoo-burger  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Uncategorized  |  Version:  1.11
 Severity:  Normal |   Resolution:  duplicate
 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 Tim Graham):

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


Comment:

 Duplicate of #28022. Please provide details about how to reproduce it as I
 haven't been able to do so.

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

Re: [Django] #28020: make GEOSGeometry.json use OGRGeometry.json again (for performance reasons)

[Django]

#28020: make GEOSGeometry.json use OGRGeometry.json again (for performance 
reasons)
-+-
 Reporter:  Sergey Fedoseev  |Owner:  Sergey
 Type:   |  Fedoseev
  Cleanup/optimization   |   Status:  closed
Component:  GIS  |  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 Tim Graham ):

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


Comment:

 In [changeset:"12d0567aa5e82322543f0c0c126ba18c91a1e439" 12d0567a]:
 {{{
 #!CommitTicketReference repository=""
 revision="12d0567aa5e82322543f0c0c126ba18c91a1e439"
 Fixed #28020 -- Made GEOSGeometry.json use OGRGeometry.json for better
 performance.
 }}}

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

[Django] #28026: Pillow version > 4.0.0 not recognized

[Django]

#28026: Pillow version > 4.0.0 not recognized
-+
   Reporter:  voodoo-burger  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Uncategorized  |Version:  1.11
   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  |
-+
 I upgraded to Django 1.11 today and also upgraded Pillow from 4.0.0 to
 4.1.0 . Now Django won't start when you have any models with an ImageField
 saying you can't use ImageField without installing Pillow. It seems Django
 doesn't recognize Pillow > 4.0.0. Downgrading Pillow to 4.0.0 fixes this.

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

Re: [Django] #28013: admin/inlines.js has different functionality from admin/inlines.min.js

[Django]

#28013: admin/inlines.js has different functionality from admin/inlines.min.js
+--
 Reporter:  Joseph Solomon  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  contrib.admin   |  Version:  1.10
 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
+--

Comment (by Tim Graham):

 Joseph, ideally the sample project wouldn't involve any third-party
 JavaScript to rule out some issue there.

 If there's some behavior difference in the minified JavaScript, then it
 might be a bug for
 [https://docs.djangoproject.com/en/dev/internals/contributing/writing-
 code/javascript/#compressing-javascript the closure compiler] that Django
 uses to generate that code.

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

Re: [Django] #28022: pillow not being recognised

[Django]

#28022: pillow not being recognised
-+-
 Reporter:  fboerman |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (System |  Version:  1.11
  checks)|
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 Confirming that resolution, I see no problem when testing
 [https://github.com/django/djangoproject.com/ djangoproject.com] (which
 uses `ImageField`) with Django 1.11 and Pillow 4.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/066.3d1c8d0fa09783d017a4ca3927213a58%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28021: Add active_login_required decorator

[Django]

#28021: Add active_login_required decorator
--+--
 Reporter:  Wim Feijen|Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  contrib.auth  |  Version:  1.10
 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 Tim Graham):

 * easy:  1 => 0


Old description:

> Hi,
>
> Documentation recommends setting a user's is_active flag to False in
> stead of deleting a user:
>
> https://docs.djangoproject.com/en/1.10/ref/contrib/auth/#django.contrib.auth.models.User.is_active
> "Boolean. Designates whether this user account should be considered
> active. We recommend that you set this flag to False instead of deleting
> accounts; that way, if your applications have any foreign keys to users,
> the foreign keys won’t break."
>
> However, the recommended login_required decorator does not check whether
> is_active is True or False, meaning inactive users may still access that
> view.
>
> To maintain backwards compatibility, it was decided not to change the
> behaviour of login_required, see:
> https://code.djangoproject.com/ticket/13125
> "is_active is a hook for custom auth sources and custom auth logic; the
> built-in stuff doesn't check it. Yes it's a bit counter-intuitive, but
> changing it is going to break a number of expectations in users' code, so
> it's going to need to stay as is."
>
> As a solution, I'd like to add an active_login_required decorator, which
> does check for is_active = True. That way we maintain backwards
> compatibility and in addition we can have a decorator that behaves
> intuively.

New description:

 Hi,

 Documentation recommends setting a user's is_active flag to False in stead
 of deleting a user:

 
https://docs.djangoproject.com/en/1.10/ref/contrib/auth/#django.contrib.auth.models.User.is_active
 "Boolean. Designates whether this user account should be considered
 active. We recommend that you set this flag to False instead of deleting
 accounts; that way, if your applications have any foreign keys to users,
 the foreign keys won’t break."

 However, the recommended login_required decorator does not check whether
 is_active is True or False, meaning inactive users may still access that
 view.

 To maintain backwards compatibility, it was decided not to change the
 behaviour of login_required, see:
 https://code.djangoproject.com/ticket/13125
 "is_active is a hook for custom auth sources and custom auth logic; the
 built-in stuff doesn't check it. Yes it's a bit counter-intuitive, but
 changing it is going to break a number of expectations in users' code, so
 it's going to need to stay as is."

 As a solution, I'd like to add an active_login_required decorator, which
 does check for is_active = True. That way we maintain backwards
 compatibility and in addition we can have a decorator that behaves
 intuitively.

--

Comment:

 I'm not sure if this has much value considering that `ModelBackend` and
 `RemoteUserBackend` reject inactive users (as of Django 1.10, see #25232).
 Would this decorator change behavior in any way?

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

Re: [Django] #28024: GEOSCoordSeq performance could be improved significantly by avoiding superfluous checks

[Django]

#28024: GEOSCoordSeq performance could be improved significantly by avoiding
superfluous checks
-+-
 Reporter:  Sergey Fedoseev  |Owner:  Sergey
 Type:   |  Fedoseev
  Cleanup/optimization   |   Status:  assigned
Component:  GIS  |  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):

 * stage:  Unreviewed => Accepted


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

Re: [Django] #28018: OneToOneField not working with inlineadmin

[Django]

#28018: OneToOneField not working with inlineadmin
---+--
 Reporter:  alex   |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  Version:  1.10
 Severity:  Normal |   Resolution:  invalid
 Keywords: | Triage Stage:  Unreviewed
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 class hierarchy doesn't work with inlineadmin:
>
> class hierarchy:
>
> models.py:
> class d:
>   pass
> class a:
>   d = models.OneToOneField(d, on_delete=models.CASCADE,
> related_name="host")
> class b:
>   pass
> class dInlineAdmin(admin.TabularInline):
> model = d
>
> # admin.py
> @admin.register(b)
> class bSpecializedAdmin(admin.ModelAdmin):
> inlines = [
> dInlineAdmin,
> ]
>
> Error message:
> : (admin.E202) 'x.Requirement'
> has no field named 'host'.
>
> 'host' is the related_name

New description:

 This class hierarchy doesn't work with inlineadmin:

 class hierarchy:

 models.py:
 {{{
 class d:
   pass
 class a:
   d = models.OneToOneField(d, on_delete=models.CASCADE,
 related_name="host")
 class b:
   pass
 }}}
 admin.py
 {{{
 class dInlineAdmin(admin.TabularInline):
 model = d

 @admin.register(b)
 class bSpecializedAdmin(admin.ModelAdmin):
 inlines = [
 dInlineAdmin,
 ]
 }}}
 Error message:
 `: (admin.E202) 'x.Requirement'
 has no field named 'host'.`

 'host' is the related_name

--

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

Re: [Django] #28019: Django django.db.models.Model.save() logic bit illogical?

[Django]

#28019: Django django.db.models.Model.save() logic bit illogical?
-+-
 Reporter:  Jacek Kałucki|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 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
-+-

Comment (by kapil garg):

 I am unable to reproduce the bug on sqlite3 with dev version and 1.10
 version. Is there anything else needed to reproduce the 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/067.5f23c30ff4429ae3f018fc5de482f39d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28018: OneToOneField not working with inlineadmin

[Django]

#28018: OneToOneField not working with inlineadmin
---+--
 Reporter:  alex   |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  Version:  1.10
 Severity:  Normal |   Resolution:  invalid
 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 kapil garg):

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


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

Re: [Django] #28018: OneToOneField not working with inlineadmin

[Django]

#28018: OneToOneField not working with inlineadmin
---+--
 Reporter:  alex   |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  1.10
 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 kapil garg):

 * type:  Uncategorized => Bug
 * component:  Uncategorized => contrib.admin


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

Re: [Django] #28018: OneToOneField not working with inlineadmin

[Django]

#28018: OneToOneField not working with inlineadmin
---+--
 Reporter:  alex   |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  1.10
 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
---+--

Comment (by kapil garg):

 I think, InlineModelAdmin works for models which have related objects. In
 your example,


 {{{
 # admin.py
 class dInlineAdmin(admin.TabularInline):
 model = d

 @admin.register(b)
 class bSpecializedAdmin(admin.ModelAdmin):
 inlines = [
 dInlineAdmin,
 ]
 }}}

 model "b" is not related to model "d" and thus causing the exception. The
 following code will work

 {{{
 # admin.py
 class aInlineAdmin(admin.TabularInline):
 model = a

 @admin.register(d)
 class bSpecializedAdmin(admin.ModelAdmin):
 inlines = [
 aInlineAdmin,
 ]
 }}}

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

Re: [Django] #28020: make GEOSGeometry.json use OGRGeometry.json again (for performance reasons)

[Django]

#28020: make GEOSGeometry.json use OGRGeometry.json again (for performance 
reasons)
-+-
 Reporter:  Sergey Fedoseev  |Owner:  Sergey
 Type:   |  Fedoseev
  Cleanup/optimization   |   Status:  assigned
Component:  GIS  |  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 Claude Paroz):

 * 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.4ca70f9d6a06916b370f66dc805314ee%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28022: pillow not being recognised

[Django]

#28022: pillow not being recognised
-+-
 Reporter:  fboerman |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (System |  Version:  1.11
  checks)|
 Severity:  Normal   |   Resolution:  needsinfo
 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 Claude Paroz):

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


Comment:

 AFAIR, nothing changed from Django 1.8 in this regard. In
 `django/db/models/fields/files.py` Django is doing `from PIL import Image`
 to detect pillow installs. I would suggest searching for help in Django
 support channels to find out if Django is at fault or not.

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

Re: [Django] #28025: Typo in the documentation of 1.11 release

[Django]

#28025: Typo in the documentation of 1.11 release
-+-
 Reporter:  Sudhanshu Mishra |Owner:  Sudhanshu
 |  Mishra
 Type:  Uncategorized|   Status:  closed
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  docs, typo   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"44bf3c6812a42360bd22741a5943145527ce4acf" 44bf3c68]:
 {{{
 #!CommitTicketReference repository=""
 revision="44bf3c6812a42360bd22741a5943145527ce4acf"
 [1.11.x] Fixed #28025 -- Fixed typo in docs/ref/models/querysets.txt.

 Backport of 9f0c82971dff1e40bad63879b5f6fee42dd64953 from master
 }}}

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

Re: [Django] #28025: Typo in the documentation of 1.11 release

[Django]

#28025: Typo in the documentation of 1.11 release
-+-
 Reporter:  Sudhanshu Mishra |Owner:  Sudhanshu
 |  Mishra
 Type:  Uncategorized|   Status:  closed
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  docs, typo   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"9f0c82971dff1e40bad63879b5f6fee42dd64953" 9f0c8297]:
 {{{
 #!CommitTicketReference repository=""
 revision="9f0c82971dff1e40bad63879b5f6fee42dd64953"
 Fixed #28025 -- Fixed typo in docs/ref/models/querysets.txt.
 }}}

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

Re: [Django] #28025: Typo in the documentation of 1.11 release

[Django]

#28025: Typo in the documentation of 1.11 release
-+-
 Reporter:  Sudhanshu Mishra |Owner:  Sudhanshu
 |  Mishra
 Type:  Uncategorized|   Status:  assigned
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  docs, typo   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Sudhanshu Mishra):

 * has_patch:  0 => 1


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

Re: [Django] #28025: Typo in the documentation of 1.11 release

[Django]

#28025: Typo in the documentation of 1.11 release
-+-
 Reporter:  Sudhanshu Mishra |Owner:  Sudhanshu
 |  Mishra
 Type:  Uncategorized|   Status:  assigned
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  docs, typo   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Sudhanshu Mishra):

 I've already created a PR for this ticket.

 https://github.com/django/django/pull/8298

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

Re: [Django] #28025: Typo in the documentation of 1.11 release

[Django]

#28025: Typo in the documentation of 1.11 release
-+-
 Reporter:  Sudhanshu Mishra |Owner:  Sudhanshu
 |  Mishra
 Type:  Uncategorized|   Status:  assigned
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  docs, typo   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Sudhanshu Mishra):

 * owner:  nobody => Sudhanshu Mishra


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

[Django] #28025: Typo in the documentation of 1.11 release

[Django]

#28025: Typo in the documentation of 1.11 release
+
   Reporter:  Sudhanshu Mishra  |  Owner:  nobody
   Type:  Uncategorized | Status:  assigned
  Component:  Documentation |Version:  master
   Severity:  Normal|   Keywords:  docs, typo
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  1
  UI/UX:  0 |
+
 Here
 
https://github.com/django/django/blob/b427f0d674362d22c063852754914d9315cbc2fa/docs/ref/models/querysets.txt#L840

 It should say

 `>>> qs1.intersection(qs2, qs3)`

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

Re: [Django] #28024: GEOSCoordSeq performance could be improved significantly by avoiding superfluous checks

[Django]

#28024: GEOSCoordSeq performance could be improved significantly by avoiding
superfluous checks
-+-
 Reporter:  Sergey Fedoseev  |Owner:  Sergey
 Type:   |  Fedoseev
  Cleanup/optimization   |   Status:  assigned
Component:  GIS  |  Version:  master
 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):

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


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

[Django] #28024: GEOSCoordSeq performance could be improved significantly by avoiding superfluous checks

[Django]

#28024: GEOSCoordSeq performance could be improved significantly by avoiding
superfluous checks
+
   Reporter:  Sergey Fedoseev   |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  GIS   |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 |
+
 For proof of concept I added reworked `tuple` version as `tuple_fast`
 property.

 {{{
 In [14]: ls = LineString([(x, x) for x in range(1000)])

 In [15]: %timeit ls.tuple
 10 loops, best of 3: 43.5 ms per loop

 In [16]: %timeit ls.tuple_fast
 10 loops, best of 3: 16.8 ms per loop
 }}}

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

Re: [Django] #27917: Allow ModelAdmin.radio_fields to work with NullBooleanField

[Django]

#27917: Allow ModelAdmin.radio_fields to work with NullBooleanField
--+
 Reporter:  Jerome Leclanche  |Owner:  Musen
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  contrib.admin |  Version:  1.10
 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 Musen):

 * owner:  nobody => Musen
 * 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/062.e91f94cc1f5a4f583a9daf57c386f511%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #28023: Wrong method in SQL query log

[Django]

#28023: Wrong method in SQL query log
-+-
   Reporter:  erkib  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Database   |Version:  1.11
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 When SQL query logging is enabled and you run a following:


 {{{
 n = now() - timedelta(days=30)
 MyModel.objects.filter(my_date__lt=n).delete()
 }}}


 Query being logged is:

 2017-04-05 11:41:22,192  DEBUG(0.019) QUERY = 'SELECT "MY_MODEL"."ID",
 "MY_MODEL"."MY_DATE" FROM "MY_MODEL" WHERE "MY_MODEL"."MY_DATE" < :arg0' -
 PARAMS = (Oracle_datetime(2017, 3, 6, 8, 41, 21, 913366),);
 args=(Oracle_datetime(2017, 3, 6, 8, 41, 21, 913366),)

 The same behaviour happens with 1.10.* version of Django as well.

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

Re: [Django] #28020: make GEOSGeometry.json use OGRGeometry.json again (for performance reasons)

[Django]

#28020: make GEOSGeometry.json use OGRGeometry.json again (for performance 
reasons)
-+-
 Reporter:  Sergey Fedoseev  |Owner:  Sergey
 Type:   |  Fedoseev
  Cleanup/optimization   |   Status:  assigned
Component:  GIS  |  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 Sergey Fedoseev):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/8297 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/068.6643f84a689e871976bdda6da727b55c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #28022: pillow not being recognised

[Django]

#28022: pillow not being recognised
+
   Reporter:  fboerman  |  Owner:  nobody
   Type:  Bug   | Status:  new
  Component:  Core (System checks)  |Version:  1.11
   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 |
+
 Hi,

 I have updated my django to version 1.11 with pip and now django does not
 recognise that I have pillow installed. I get the {{{Cannot user
 ImageField because Pillow is not installed}}}. However pillow is installed
 as {{{pip install -U pillow}}} tells me and I can also do {{{import PIL}}}
 with no problems.
 This problem also did not occur before I upgraded from 1.10 to 1.11. Are
 there people who can reproduce this and maybe know how to fix it?

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

Re: [Django] #28020: make GEOSGeometry.json use OGRGeometry.json again (for performance reasons)

[Django]

#28020: make GEOSGeometry.json use OGRGeometry.json again (for performance 
reasons)
-+-
 Reporter:  Sergey Fedoseev  |Owner:  Sergey
 Type:   |  Fedoseev
  Cleanup/optimization   |   Status:  assigned
Component:  GIS  |  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 Claude Paroz):

 * stage:  Unreviewed => Accepted


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

Re: [Django] #28017: Add option to specify a different secret to PasswordResetTokenGenerator

[Django]

#28017: Add option to specify a different secret to PasswordResetTokenGenerator
--+--
 Reporter:  Jann Haber|Owner:  Jann Haber
 Type:  New feature   |   Status:  assigned
Component:  contrib.auth  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+--
Changes (by Claude Paroz):

 * stage:  Unreviewed => Accepted


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

[Django] #28021: Add active_login_required decorator

[Django]

#28021: Add active_login_required decorator
+
   Reporter:  Wim Feijen|  Owner:  nobody
   Type:  New feature   | Status:  new
  Component:  contrib.auth  |Version:  1.10
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  1
  UI/UX:  0 |
+
 Hi,

 Documentation recommends setting a user's is_active flag to False in stead
 of deleting a user:

 
https://docs.djangoproject.com/en/1.10/ref/contrib/auth/#django.contrib.auth.models.User.is_active
 "Boolean. Designates whether this user account should be considered
 active. We recommend that you set this flag to False instead of deleting
 accounts; that way, if your applications have any foreign keys to users,
 the foreign keys won’t break."

 However, the recommended login_required decorator does not check whether
 is_active is True or False, meaning inactive users may still access that
 view.

 To maintain backwards compatibility, it was decided not to change the
 behaviour of login_required, see:
 https://code.djangoproject.com/ticket/13125
 "is_active is a hook for custom auth sources and custom auth logic; the
 built-in stuff doesn't check it. Yes it's a bit counter-intuitive, but
 changing it is going to break a number of expectations in users' code, so
 it's going to need to stay as is."

 As a solution, I'd like to add an active_login_required decorator, which
 does check for is_active = True. That way we maintain backwards
 compatibility and in addition we can have a decorator that behaves
 intuively.

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

Re: [Django] #28020: make GEOSGeometry.json use OGRGeometry.json again (for performance reasons)

[Django]

#28020: make GEOSGeometry.json use OGRGeometry.json again (for performance 
reasons)
-+-
 Reporter:  Sergey Fedoseev  |Owner:  Sergey
 Type:   |  Fedoseev
  Cleanup/optimization   |   Status:  assigned
Component:  GIS  |  Version:  master
 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
-+-
Description changed by Sergey Fedoseev:

Old description:

> `GEOSGeometry.json` was using `OGRGeometry.json` prior to 1.9. That was
> changed in #25141. Now GDAL is required (#26753) and I believe we should
> restore previous `GEOSGeometry.json` implementation for performance
> reasons:
>
> {{{
> In [67]: ls = LineString([(x, x) for x in range(1000)])
>
> In [68]: %timeit a = ls.json
> 10 loops, best of 3: 42.6 ms per loop
>
> In [69]: %timeit a = ls.ogr.json
> 100 loops, best of 3: 3.75 ms per loop
> }}}

New description:

 `GEOSGeometry.json` was using `OGRGeometry.json` prior to 1.9. That was
 changed in #25141. Now GDAL is required (#26753) and I believe we should
 restore previous `GEOSGeometry.json` implementation for performance
 reasons:

 {{{
 In [67]: ls = LineString([(x, x) for x in range(1000)])

 In [68]: %timeit ls.json
 10 loops, best of 3: 42.6 ms per loop

 In [69]: %timeit ls.ogr.json
 100 loops, best of 3: 3.75 ms per loop
 }}}

--

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

[Django] #28020: make GEOSGeometry.json use OGRGeometry.json again (for performance reasons)

[Django]

#28020: make GEOSGeometry.json use OGRGeometry.json again (for performance 
reasons)
+
   Reporter:  Sergey Fedoseev   |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  GIS   |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 |
+
 `GEOSGeometry.json` was using `OGRGeometry.json` prior to 1.9. That was
 changed in #25141. Now GDAL is required (#26753) and I believe we should
 restore previous `GEOSGeometry.json` implementation for performance
 reasons:

 {{{
 In [67]: ls = LineString([(x, x) for x in range(1000)])

 In [68]: %timeit a = ls.json
 10 loops, best of 3: 42.6 ms per loop

 In [69]: %timeit a = ls.ogr.json
 100 loops, best of 3: 3.75 ms per loop
 }}}

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

Re: [Django] #28020: make GEOSGeometry.json use OGRGeometry.json again (for performance reasons)

[Django]

#28020: make GEOSGeometry.json use OGRGeometry.json again (for performance 
reasons)
-+-
 Reporter:  Sergey Fedoseev  |Owner:  Sergey
 Type:   |  Fedoseev
  Cleanup/optimization   |   Status:  assigned
Component:  GIS  |  Version:  master
 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):

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


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

Re: [Django] #27998: LogEntry messages do not list m2m fields that were changed when an object is changed via ModelAdmin

[Django]

#27998: LogEntry messages do not list m2m fields that were changed when an 
object
is changed via ModelAdmin
---+
 Reporter:  ljsjl  |Owner:  ljsjl
 Type:  Bug|   Status:  assigned
Component:  contrib.admin  |  Version:  1.10
 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 ljsjl):

 * owner:  nobody => ljsjl
 * status:  new => assigned


Comment:

 https://github.com/ljsjl/django/tree/ticket_27998

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

[Django] #28019: Django django.db.models.Model.save() logic bit illogical?

[Django]

#28019: Django django.db.models.Model.save() logic bit illogical?
-+-
   Reporter:  Jacek  |  Owner:  nobody
  Kałucki|
   Type:  Bug| Status:  new
  Component:  Database   |Version:  1.10
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 In code below, calling “Foo(name='Foo Bar').save()” method raises
 ValueError “Cannot force an update in save() with no primary key” - let’s
 check what goes wrong here:
 1) I didn’t pass any parameters so why logic mentions about “force” and
 “update” since I’m not forcing nor updating but inserting new data row?
 I’ve figured out that logic adds fields to “update_fields” parameters
 itself and in this case it’s a “name” which is class Foo property name.
 It won’t happened if there is no class inheritance scenario. Why? But it
 leads us to the next point.
 2) Let’s check when the “not pk_set and (force_update or update_fields)”
 condition is fulfilled.
 IMHO if “pk_set” is false there is no need to check “update_fields”
 because it’s never used in this scenario, it may be used only in case of
 “pk_set” equals true but these states are mutually exclusive.

 My proposal is to revise “get_deferred_fields()” method to handle class
 attributes correctly in case of inheritance and remove redundant
 “update_fields” checking on inserts.

 {{{
 #!div style="font-size: 80%"
 Code highlighting:
   {{{#!python
 class Bar(models.Model):

 name = models.CharField(max_length=100, blank=True)


 class Foo(Bar):

 first_name = models.CharField(max_length=50, blank=True)
 last_name = models.CharField(max_length=50, blank=True)

 def __init__(self, *args, **kwargs):
 name = kwargs.get('name')
 if name:
 (first_name, last_name) = name.split()
 kwargs['first_name'] = first_name
 kwargs['last_name'] = last_name
 super(Foo, self).__init__(*args, **kwargs)

 @property
 def name(self):
 names = (self.first_name, self.last_name)
 return " ".join(x for x in names if x)

 @name.setter
 def name(self, value):
 (self.first_name, self.last_name) = value.split()
   }}}
 }}}

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