[Django] #31962: Raise of SuspiciousOperation should use more specific SuspiciousSession class

[Django]

#31962: Raise of SuspiciousOperation should use more specific SuspiciousSession
class
+
   Reporter:  alexmv|  Owner:  nobody
   Type:  Uncategorized | Status:  new
  Component:  contrib.sessions  |Version:  master
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  1
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  1
  UI/UX:  0 |
+
 `django/contrib/sessions/middleware.py` contains the only non-test place
 where a bare `SuspiciousOperation` is raised; all other locations use one
 of its more specific subclasses.  Making this suspicious operation that
 involves a session into a `raise SuspiciousSession` would remove this
 outlier, and make the exception more specific.

 This is also notable because every SuspiciousOperation subclass gets its
 own logger, so this is the only place that is logged via the
 `django.security.SuspiciousOperation` logger.

 This should only require:

 {{{
 diff --git django/contrib/sessions/middleware.py
 django/contrib/sessions/middleware.py
 index cb8c1ff45b..f8386a21ce 100644
 --- django/contrib/sessions/middleware.py
 +++ django/contrib/sessions/middleware.py
 @@ -3,7 +3,7 @@ from importlib import import_module

  from django.conf import settings
  from django.contrib.sessions.backends.base import UpdateError
 -from django.core.exceptions import SuspiciousOperation
 +from django.contrib.sessions.exceptions import SuspiciousSession
  from django.utils.cache import patch_vary_headers
  from django.utils.deprecation import MiddlewareMixin
  from django.utils.http import http_date
 @@ -60,7 +60,7 @@ class SessionMiddleware(MiddlewareMixin):
  try:
  request.session.save()
  except UpdateError:
 -raise SuspiciousOperation(
 +raise SuspiciousSession(
  "The request's session was deleted before the
 "
  "request completed. The user may have logged
 "
  "out in a concurrent request, for example."
 }}}

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/049.93b4c2dd460959b80597624a46d75443%40djangoproject.com.

Re: [Django] #31961: forms.ChoiceField calls choices callback multiple times.

[Django]

#31961: forms.ChoiceField calls choices callback multiple times.
---+--
 Reporter:  Roy Smith  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Forms  |  Version:  2.2
 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 Roy Smith:

Old description:

> I'm running:
>
> Python 3.7
> Django 2.2
> Debian 4.9
>
> If I configure a forms ChoiceField with a callback function for choices,
> it gets called twice each time I render the form:
>

> {{{
> from unittest import TestCase
> from django import forms
>
> def callback():
> print("callback")
> return [('foo', 'bar')]
>
> class MyForm(forms.Form):
> f = forms.ChoiceField(choices=callback)
>

> class FormTest(TestCase):
> MyForm().as_p()
> }}}
>
> prints:
>
> {{{
> ./manage.py test spi.test_f
> callback
> callback
> System check identified no issues (0 silenced).
>
> --
> Ran 0 tests in 0.000s
>
> OK
> }}}
>
> This is the same sort of problem described in #26665 and/or #11390.  It's
> an obvious performance issue, but more than that, if can beak behavior if
> the callback is non-idempotent.
>
> I discovered this because I had patched my callback using unttest.mock to
> return a sequence of return values and got hard-to-diagnose test
> failures.  Specifically, my test failed because it raised StopIteration
> when it ran out of values to return.

New description:

 I'm running:

 Python 3.7
 Django 2.2
 Debian 4.9

 If I configure a forms ChoiceField with a callback function for choices,
 it gets called twice each time I render the form:


 {{{
 from unittest import TestCase
 from django import forms

 def callback():
 print("callback")
 return [('foo', 'bar')]

 class MyForm(forms.Form):
 f = forms.ChoiceField(choices=callback)


 class FormTest(TestCase):
 MyForm().as_p()
 }}}

 prints:

 {{{
 ./manage.py test spi.test_f
 callback
 callback
 System check identified no issues (0 silenced).

 --
 Ran 0 tests in 0.000s

 OK
 }}}

 This is the same sort of problem described in #26665 and/or #11390.  It's
 an obvious performance issue, but more than that, it can beak behavior if
 the callback is non-idempotent.

 I discovered this because I had patched my callback using unttest.mock to
 return a sequence of return values and got hard-to-diagnose test failures.
 Specifically, my test failed because it raised StopIteration when it ran
 out of values to return.

--

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.d8965a7f34bf78ef2400c141c0eaeb02%40djangoproject.com.

Re: [Django] #31961: forms.ChoiceField calls choices callback multiple times.

[Django]

#31961: forms.ChoiceField calls choices callback multiple times.
---+--
 Reporter:  Roy Smith  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Forms  |  Version:  2.2
 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 Roy Smith):

 fixed typo

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.221fc0c9c38523cd028f5011cb308d13%40djangoproject.com.

[Django] #31961: forms.ChoiceField calls choices callback multiple times.

[Django]

#31961: forms.ChoiceField calls choices callback multiple times.
--+
   Reporter:  Roy Smith   |  Owner:  nobody
   Type:  Bug | Status:  new
  Component:  Forms   |Version:  2.2
   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'm running:

 Python 3.7
 Django 2.2
 Debian 4.9

 If I configure a forms ChoiceField with a callback function for choices,
 it gets called twice each time I render the form:


 {{{
 from unittest import TestCase
 from django import forms

 def callback():
 print("callback")
 return [('foo', 'bar')]

 class MyForm(forms.Form):
 f = forms.ChoiceField(choices=callback)


 class FormTest(TestCase):
 MyForm().as_p()
 }}}

 prints:

 {{{
 ./manage.py test spi.test_f
 callback
 callback
 System check identified no issues (0 silenced).

 --
 Ran 0 tests in 0.000s

 OK
 }}}

 This is the same sort of problem described in #26665 and/or #11390.  It's
 an obvious performance issue, but more than that, if can beak behavior if
 the callback is non-idempotent.

 I discovered this because I had patched my callback using unttest.mock to
 return a sequence of return values and got hard-to-diagnose test failures.
 Specifically, my test failed because it raised StopIteration when it ran
 out of values to return.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/051.220c1d1f61e9b68b91d60d49a56ad28a%40djangoproject.com.

Re: [Django] #31956: QuerySet.order_by() chained with values() crashes on JSONField with a custom decoder on PostgreSQL.

[Django]

#31956: QuerySet.order_by() chained with values() crashes on JSONField with a
custom decoder on PostgreSQL.
-+-
 Reporter:  Marc DEBUREAUX   |Owner:  felixxm
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 Severity:  Release blocker  |   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 Mariusz Felisiak ):

 In [changeset:"22105391424cc56f29f153bb76d6a15246152674" 2210539]:
 {{{
 #!CommitTicketReference repository=""
 revision="22105391424cc56f29f153bb76d6a15246152674"
 Refs #31956 -- Added test for ordering by JSONField with a custom decoder.
 }}}

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.203c38068c9e5c84b46498f4bdac1527%40djangoproject.com.

Re: [Django] #31956: QuerySet.order_by() chained with values() crashes on JSONField with a custom decoder on PostgreSQL.

[Django]

#31956: QuerySet.order_by() chained with values() crashes on JSONField with a
custom decoder on PostgreSQL.
-+-
 Reporter:  Marc DEBUREAUX   |Owner:  felixxm
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 Severity:  Release blocker  |   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 Mariusz Felisiak ):

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


Comment:

 In [changeset:"0be51d2226fce030ac9ca840535a524f41e9832c" 0be51d2]:
 {{{
 #!CommitTicketReference repository=""
 revision="0be51d2226fce030ac9ca840535a524f41e9832c"
 Fixed #31956 -- Fixed crash of ordering by JSONField with a custom decoder
 on PostgreSQL.

 Thanks Marc Debureaux for the report.
 Thanks Simon Charette, Nick Pope, and Adam Johnson for reviews.
 }}}

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.aab37c849cd869061374cc7cfe93d02b%40djangoproject.com.

Re: [Django] #31956: QuerySet.order_by() chained with values() crashes on JSONField with a custom decoder on PostgreSQL.

[Django]

#31956: QuerySet.order_by() chained with values() crashes on JSONField with a
custom decoder on PostgreSQL.
-+-
 Reporter:  Marc DEBUREAUX   |Owner:  felixxm
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 Severity:  Release blocker  |   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
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"655e1ce6b1ca8df71518060ae770c3ee647b9801" 655e1ce6]:
 {{{
 #!CommitTicketReference repository=""
 revision="655e1ce6b1ca8df71518060ae770c3ee647b9801"
 [3.1.x] Fixed #31956 -- Fixed crash of ordering by JSONField with a custom
 decoder on PostgreSQL.

 Thanks Marc Debureaux for the report.
 Thanks Simon Charette, Nick Pope, and Adam Johnson for reviews.

 Backport of 0be51d2226fce030ac9ca840535a524f41e9832c 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.e682472aebd206142edc685594df16c9%40djangoproject.com.

Re: [Django] #31960: Document that Django email validator does not enforce valid emails

[Django]

#31960: Document that Django email validator does not enforce valid emails
---+--
 Reporter:  James Pic  |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Uncategorized  |  Version:  3.1
 Severity:  Normal |   Resolution:  wontfix
 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 James Pic):

 Actually I think there is nothing we can do really, even SMTP VRFY is not
 going to be reliable because some providers block it "to foil spammers":
 https://docs.python.org/3/library/smtplib.html#smtplib.SMTP.verify

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/062.de0ccf48db8e8dcb524d55b4f3745730%40djangoproject.com.

Re: [Django] #31960: Document that Django email validator does not enforce valid emails

[Django]

#31960: Document that Django email validator does not enforce valid emails
---+--
 Reporter:  James Pic  |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Uncategorized  |  Version:  3.1
 Severity:  Normal |   Resolution:  wontfix
 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 James Pic):

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


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/062.1acfab0495fabb8632eba313bfc2d599%40djangoproject.com.

Re: [Django] #31960: Document that Django email validator does not enforce valid emails

[Django]

#31960: Document that Django email validator does not enforce valid emails
---+--
 Reporter:  James Pic  |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  3.1
 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 James Pic:

Old description:

> Currently, Django makes it seem that using an EmailField / EmailValidator
> will protect projects from getting invalid emails in their database, for
> example: emails starting with a dot like ".f...@bar.com" will be invalid
> as expected.
>
> But in reality, users must not count on Django for that:
>
> - https://code.djangoproject.com/ticket/31959
> - https://code.djangoproject.com/ticket/25452
>
> This makes the following documentation statement inaccurate:
>
> > "EmailField: A CharField that checks that the value is a valid email
> address using EmailValidator."
>
> Source :
> https://docs.djangoproject.com/en/3.1/ref/models/fields/#emailfield
>
> It would be only fair to users to document that the EmailValidator will
> let invalid emails through, which will be the cause of SMTPError, and
> that people who don't want invalid emails in their EmailField must
> override and fix Django's default behaviour.

New description:

 Currently, Django makes it seem that using an EmailField / EmailValidator
 will protect projects from getting invalid emails in their database.

 But in reality, users must not count on Django for that:

 - https://code.djangoproject.com/ticket/31959
 - https://code.djangoproject.com/ticket/25452

 This makes the following documentation statement inaccurate:

 > "EmailField: A CharField that checks that the value is a valid email
 address using EmailValidator."

 Source :
 https://docs.djangoproject.com/en/3.1/ref/models/fields/#emailfield

 It would be only fair to users to document that the EmailValidator will
 let invalid emails through, which will be the cause of SMTPError, and that
 people who don't want invalid emails in their EmailField must override and
 fix Django's default behaviour.

 As to why EmailValidator would reject emails starting with a dot like
 ".f...@bar.com" but not emails starting with a hyphen "-f...@bar.com": this
 will remain a mystery.

--

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/062.8361839330dd11e91f1f0cace8790d49%40djangoproject.com.

Re: [Django] #31960: Document that Django email validator does not enforce valid emails

[Django]

#31960: Document that Django email validator does not enforce valid emails
---+--
 Reporter:  James Pic  |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  3.1
 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 James Pic:

Old description:

> Currently, Django makes it seem that using an EmailField / EmailValidator
> will protect projects from getting invalid emails in their database, for
> example: emails starting with a dot like ".f...@bar.com" will be invalid
> as expected.
>
> But in reality, Django doesn't actually care :
> https://code.djangoproject.com/ticket/31959#ticket
>
> This makes the following documentation statement inaccurate:
>
> > "EmailField: A CharField that checks that the value is a valid email
> address using EmailValidator."
>
> Source :
> https://docs.djangoproject.com/en/3.1/ref/models/fields/#emailfield
>
> It would be only fair to users to document that the EmailValidator will
> let invalid emails through, which will be the cause of SMTPError, and
> that people who don't want invalid emails in their EmailField must
> override and fix Django's default behaviour.

New description:

 Currently, Django makes it seem that using an EmailField / EmailValidator
 will protect projects from getting invalid emails in their database, for
 example: emails starting with a dot like ".f...@bar.com" will be invalid as
 expected.

 But in reality, users must not count on Django for that:

 - https://code.djangoproject.com/ticket/31959
 - https://code.djangoproject.com/ticket/25452

 This makes the following documentation statement inaccurate:

 > "EmailField: A CharField that checks that the value is a valid email
 address using EmailValidator."

 Source :
 https://docs.djangoproject.com/en/3.1/ref/models/fields/#emailfield

 It would be only fair to users to document that the EmailValidator will
 let invalid emails through, which will be the cause of SMTPError, and that
 people who don't want invalid emails in their EmailField must override and
 fix Django's default behaviour.

--

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/062.e61435f3105145b0f792b5c072f64fc0%40djangoproject.com.

Re: [Django] #31959: EmailValidator must not accept hyphen as first character

[Django]

#31959: EmailValidator must not accept hyphen as first character
-+-
 Reporter:  James Pic|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Utilities|  Version:  3.1
 Severity:  Normal   |   Resolution:  wontfix
 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 James Pic):

 Thanks to you Felix, I now know that EmailField is deliberately broken and
 untrustable.

 However, this needs to be properly documented, and inaccuracies in the
 documentation must be fixed.

 Following-up on this ticket : https://code.djangoproject.com/ticket/31960

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/062.ccfd05b6c0d629874b00dc75ceec861a%40djangoproject.com.

Re: [Django] #31960: Document that Django email validator does not enforce valid emails

[Django]

#31960: Document that Django email validator does not enforce valid emails
---+--
 Reporter:  James Pic  |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  3.1
 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 James Pic:

Old description:

> Currently, Django makes it seem that using an EmailField / EmailValidator
> will protect projects from getting invalid emails in their database, for
> example: emails starting with a dot like ".f...@bar.com" will be invalid
> as expected.
>
> But in reality, Django doesn't actually care :
> https://code.djangoproject.com/ticket/31959#ticket
>
> It would be only fair to users to document that the EmailValidator will
> let invalid emails through, which will be the cause of SMTPError, and
> that people who don't want invalid emails in their EmailField must
> override and fix Django's default behaviour.

New description:

 Currently, Django makes it seem that using an EmailField / EmailValidator
 will protect projects from getting invalid emails in their database, for
 example: emails starting with a dot like ".f...@bar.com" will be invalid as
 expected.

 But in reality, Django doesn't actually care :
 https://code.djangoproject.com/ticket/31959#ticket

 This makes the following documentation statement inaccurate:

 > "EmailField: A CharField that checks that the value is a valid email
 address using EmailValidator."

 Source :
 https://docs.djangoproject.com/en/3.1/ref/models/fields/#emailfield

 It would be only fair to users to document that the EmailValidator will
 let invalid emails through, which will be the cause of SMTPError, and that
 people who don't want invalid emails in their EmailField must override and
 fix Django's default behaviour.

--

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/062.95469ce97181348292595c4c1751ddc1%40djangoproject.com.

[Django] #31960: Document that Django email validator does not enforce valid emails

[Django]

#31960: Document that Django email validator does not enforce valid emails
-+
   Reporter:  James Pic  |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Uncategorized  |Version:  3.1
   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  |
-+
 Currently, Django makes it seem that using an EmailField / EmailValidator
 will protect projects from getting invalid emails in their database, for
 example: emails starting with a dot like ".f...@bar.com" will be invalid as
 expected.

 But in reality, Django doesn't actually care :
 https://code.djangoproject.com/ticket/31959#ticket

 It would be only fair to users to document that the EmailValidator will
 let invalid emails through, which will be the cause of SMTPError, and that
 people who don't want invalid emails in their EmailField must override and
 fix Django's default behaviour.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/047.2ca0c9363f778e6401504469eea92e86%40djangoproject.com.

Re: [Django] #30952: KeyError: '_password_reset_token' during password reset.

[Django]

#30952: KeyError: '_password_reset_token' during password reset.
--+--
 Reporter:  defigor   |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.auth  |  Version:  2.1
 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 Peter De Wachter):

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


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.1c6e9a902ca16b5f97a869879259a972%40djangoproject.com.

Re: [Django] #30952: KeyError: '_password_reset_token' during password reset.

[Django]

#30952: KeyError: '_password_reset_token' during password reset.
--+--
 Reporter:  defigor   |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  contrib.auth  |  Version:  2.1
 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 Peter De Wachter):

 We hit this bug as well, the mechanism is a bit convoluted though. Our
 project installs a post_save receiver for the User table, for logging
 purposes. This receiver accesses request.user as part of that logging (it
 uses a middleware to get at the request), and that's the cause of the
 failure.

 What happens is this:
 - The user uses a password reset link while logged in, as described by
 Andrey Shakurov above.
 - When PasswordResetConfirmView saves the user object with the new
 password, our post_save receiver runs.
 - The post_save receiver accesses request.user.
 - There's nothing in the password reset flow that used request.user at an
 earlier point, so there's no cached user object.
 - So auth.get_user() gets called. get_user() will attempt validate the
 session hash. But that will fail: even if the hash was valid before (not
 necessarily the case), it will certainly be invalid after the password
 change. So it flushes the session!
 - Our post_save code finishes and the save completes.
 - Then the view tries to delete the session field, which no longer exists,
 because the session was flushed. So we get the KeyError.

 I think the simplest solution is to explicitly log out the user when he
 accesses a password reset link.
 I've submitted a PR: https://github.com/django/django/pull/13360

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.a3ef5aafacdd110d27095c07b836be17%40djangoproject.com.

Re: [Django] #31954: MigrationOptimizer mangles operation order if app name contains uppercase letters.

[Django]

#31954: MigrationOptimizer mangles operation order if app name contains 
uppercase
letters.
-+-
 Reporter:  Koen De Wit  |Owner:  Koen De Wit
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  3.1
 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 Mariusz Felisiak ):

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


Comment:

 In [changeset:"4c0b4720b0d5b025bc0ce4149eb501b9dde8c03f" 4c0b472]:
 {{{
 #!CommitTicketReference repository=""
 revision="4c0b4720b0d5b025bc0ce4149eb501b9dde8c03f"
 Fixed #31954 -- Fixed migration optimization for MTI model creation with
 parent model with mixed case app label.
 }}}

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.0b62ab465339ee4bf96ea2e63808c387%40djangoproject.com.

Re: [Django] #31959: EmailValidator must not accept hyphen as first character (was: EmailValidator must not accept hyphen as first caracter)

[Django]

#31959: EmailValidator must not accept hyphen as first character
-+-
 Reporter:  James Pic|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Utilities|  Version:  3.1
 Severity:  Normal   |   Resolution:  wontfix
 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 felixxm):

 * status:  new => closed
 * type:  Uncategorized => Cleanup/optimization
 * resolution:   => wontfix


Comment:

 Thanks for this ticket, however we discussed a similar case in #25452 and
 the consensus on the [https://groups.google.com/d/topic/django-
 developers/ASBJ0ge2KYo/discussion mailing list] was to simplify the
 validation, not make it more comprehensive.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/062.42681a06938234b01f340b69a4cf%40djangoproject.com.

Re: [Django] #31954: MigrationOptimizer mangles operation order if app name contains uppercase letters.

[Django]

#31954: MigrationOptimizer mangles operation order if app name contains 
uppercase
letters.
-+-
 Reporter:  Koen De Wit  |Owner:  Koen De Wit
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  3.1
 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 felixxm):

 * 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.0315d2c12bd60218069d83861f786775%40djangoproject.com.

Re: [Django] #31928: Coroutine passed to the first middleware's process_response() instead of HttpResponse.

[Django]

#31928: Coroutine passed to the first middleware's process_response() instead of
HttpResponse.
-+-
 Reporter:  Kordian Kowalski |Owner:  Kevin
 |  Michel
 Type:  Bug  |   Status:  closed
Component:  HTTP handling|  Version:  3.1
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  async asgi   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"825ce75faec63ce81601e31152c757a9c28fed13" 825ce75f]:
 {{{
 #!CommitTicketReference repository=""
 revision="825ce75faec63ce81601e31152c757a9c28fed13"
 Fixed #31928 -- Fixed detecting an async get_response in various
 middlewares.

 SecurityMiddleware and the three cache middlewares were not calling
 super().__init__() during their initialization or calling the required
 MiddlewareMixin._async_check() method.

 This made the middlewares not properly present as coroutine and
 confused the middleware chain when used in a fully async context.

 Thanks Kordian Kowalski for the report.
 }}}

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/074.9adf8fca313aa8701d0448ea3bd9b0c6%40djangoproject.com.

Re: [Django] #26601: DEP5 implementation: Improved middleware

[Django]

#26601: DEP5 implementation: Improved middleware
-+-
 Reporter:  Tim Graham   |Owner:  Tim
 |  Graham
 Type:  New feature  |   Status:  closed
Component:  HTTP handling|  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
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"68d7cf4054e4d53d77270659113520540cc7cadc" 68d7cf4]:
 {{{
 #!CommitTicketReference repository=""
 revision="68d7cf4054e4d53d77270659113520540cc7cadc"
 Refs #26601 -- Added various middlewares tests for deprecation of passing
 None as get_response.
 }}}

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.8ea614729b4d58595a1b31d632b9c0b3%40djangoproject.com.

Re: [Django] #31928: Coroutine passed to the first middleware's process_response() instead of HttpResponse.

[Django]

#31928: Coroutine passed to the first middleware's process_response() instead of
HttpResponse.
-+-
 Reporter:  Kordian Kowalski |Owner:  Kevin
 |  Michel
 Type:  Bug  |   Status:  closed
Component:  HTTP handling|  Version:  3.1
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  async asgi   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"225261b70136fa90e63b6cf4ea10341e793d7341" 225261b7]:
 {{{
 #!CommitTicketReference repository=""
 revision="225261b70136fa90e63b6cf4ea10341e793d7341"
 Refs #31928 -- Added various middlewares tests for detecting when
 get_response is coroutine.
 }}}

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/074.c24cec82fbe18e92b25f0b03b95b899f%40djangoproject.com.

Re: [Django] #31928: Coroutine passed to the first middleware's process_response() instead of HttpResponse.

[Django]

#31928: Coroutine passed to the first middleware's process_response() instead of
HttpResponse.
-+-
 Reporter:  Kordian Kowalski |Owner:  Kevin
 |  Michel
 Type:  Bug  |   Status:  closed
Component:  HTTP handling|  Version:  3.1
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  async asgi   | 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 Mariusz Felisiak ):

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


Comment:

 In [changeset:"3a42c0447b6a3187bd2aaae0bba566d835c47d22" 3a42c044]:
 {{{
 #!CommitTicketReference repository=""
 revision="3a42c0447b6a3187bd2aaae0bba566d835c47d22"
 [3.1.x] Fixed #31928 -- Fixed detecting an async get_response in various
 middlewares.

 SecurityMiddleware and the three cache middlewares were not calling
 super().__init__() during their initialization or calling the required
 MiddlewareMixin._async_check() method.

 This made the middlewares not properly present as coroutine and
 confused the middleware chain when used in a fully async context.

 Thanks Kordian Kowalski for the report.

 Backport of 825ce75faec63ce81601e31152c757a9c28fed13 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/074.f189e841ce88b36ae865b4d1d05fc649%40djangoproject.com.

Re: [Django] #31928: Coroutine passed to the first middleware's process_response() instead of HttpResponse.

[Django]

#31928: Coroutine passed to the first middleware's process_response() instead of
HttpResponse.
-+-
 Reporter:  Kordian Kowalski |Owner:  Kevin
 |  Michel
 Type:  Bug  |   Status:  closed
Component:  HTTP handling|  Version:  3.1
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  async asgi   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"ea57a2834fe32d895e6e6b0f3791feb2fec71737" ea57a283]:
 {{{
 #!CommitTicketReference repository=""
 revision="ea57a2834fe32d895e6e6b0f3791feb2fec71737"
 Refs #31928 -- Made SessionMiddleware call super().__init__().
 }}}

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/074.f8022dcec2a9275d4e0020dbad12b337%40djangoproject.com.

[Django] #31959: EmailValidator must not accept hyphen as first caracter

[Django]

#31959: EmailValidator must not accept hyphen as first caracter
-+
   Reporter:  James Pic  |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Utilities  |Version:  3.1
   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  |
-+
 Getting the following exception:

 Aug 28 10:57:22 production 83a5b18c66bc[1752]:
 smtplib.SMTPRecipientsRefused: {'-redac...@laposte.net': (501, b'5.1.3 Bad
 recipient address syntax')}

 EmailValidator should not accept a hyphen as first caracter.

 Note: Component set to "Utilities" but really I believe a "Validator"
 Component should be available.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/047.289bd6cf92c490d49c94797c8d4e0fae%40djangoproject.com.

Re: [Django] #31928: Coroutine passed to the first middleware's process_response() instead of HttpResponse.

[Django]

#31928: Coroutine passed to the first middleware's process_response() instead of
HttpResponse.
-+-
 Reporter:  Kordian Kowalski |Owner:  Kevin
 |  Michel
 Type:  Bug  |   Status:  assigned
Component:  HTTP handling|  Version:  3.1
 Severity:  Release blocker  |   Resolution:
 Keywords:  async asgi   | 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 felixxm):

 * 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/074.82bd4a3e6bdadc2b8184a5c1b8eed007%40djangoproject.com.

Re: [Django] #31958: Django ORM sync_to_async error FATAL: remaining connection slots are reserved for non-replication superuser connections

[Django]

#31958: Django ORM sync_to_async error FATAL: remaining connection slots are
reserved for non-replication superuser connections
-+-
 Reporter:  Supratim Samantray   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  ORM Async| Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

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


Comment:

 This is a usage issue. Please see TicketClosingReasons/UseSupportChannels.

 I'd post the forum in the internals async channel.
 https://forum.djangoproject.com/

 Essentially you're going to need to wait for async ORM support to do this
 properly.

 Even then you'll need to consider the number of DB connections you're
 creating. You're trying to create a connection for each item in `metrics`,
 which is too many (This kind of issue is perennial...)

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.0e0a97098bc660380a4f66df1d68c3c3%40djangoproject.com.

Re: [Django] #31956: QuerySet.order_by() chained with values() crashes on JSONField with a custom decoder on PostgreSQL.

[Django]

#31956: QuerySet.order_by() chained with values() crashes on JSONField with a
custom decoder on PostgreSQL.
-+-
 Reporter:  Marc DEBUREAUX   |Owner:  felixxm
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 Severity:  Release blocker  |   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 felixxm):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/13358 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.f36d15409b2054b204827786cd7f0bc0%40djangoproject.com.

[Django] #31958: Django ORM sync_to_async error FATAL: remaining connection slots are reserved for non-replication superuser connections

[Django]

#31958: Django ORM sync_to_async error FATAL: remaining connection slots are
reserved for non-replication superuser connections
-+-
   Reporter:  super-sam  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Database   |Version:  3.1
  layer (models, ORM)|
   Severity:  Normal |   Keywords:  ORM Async
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 I am trying to implement Asynchronous
 support(https://docs.djangoproject.com/en/3.1/topics/async/) for Django
 ORM to write many records in Database(Postgres).

 I am getting the ERROR:root:**FATAL: remaining connection slots are
 reserved for non-replication superuser connections**

 ''I am creating coroutines add adding them to running the asyincio loop''
 {{{
 # Helper Class
 class ModelsHelper:
 @staticmethod
 @sync_to_async
 def __handle_resource_data(data):
   // Some calculation to create kwargs dict
   return Resource.objects.get_or_create(**kwargs)

 async def store_data(metric):
 // some calculation to get data
 return await ModelsHelper.__handle_resource_data(data)


 # Main File
 def get_event_loop():
 loop = None
 try:
 loop = asyncio.get_event_loop()
 except Exception as e:
 print(" New Event Loop ".center(50, '*'))
 loop = asyncio.new_event_loop()
 asyncio.set_event_loop(loop)
 return loop

 loop = get_event_loop()
 future = asyncio.ensure_future(
 asyncio.gather(*[ModelsHelper.store_data(metric) for metric in
 metrics]),
 loop=loop
  )
 loop.run_until_complete(future)
 }}}

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/052.fc10aa4e486fb19289580b36288e86d3%40djangoproject.com.

Re: [Django] #31956: QuerySet.order_by() chained with values() crashes on JSONField with a custom decoder on PostgreSQL.

[Django]

#31956: QuerySet.order_by() chained with values() crashes on JSONField with a
custom decoder on PostgreSQL.
-+-
 Reporter:  Marc DEBUREAUX   |Owner:  felixxm
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by felixxm):

 We cannot use proposed solution because it breaks ordering for non-text
 values.

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

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