Re: [Django] #29182: SQLite 3.26 breaks database migration ForeignKey constraint, leaving __old in db schema

2018-12-06 Thread Django
#29182: SQLite 3.26 breaks database migration ForeignKey constraint, leaving
__old in db schema
--+
 Reporter:  ezaquarii |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Migrations|  Version:  2.1
 Severity:  Release blocker   |   Resolution:
 Keywords:  sqlite migration  | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Simon Charette):

 * has_patch:  0 => 1


Comment:

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

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


Re: [Django] #29182: SQLite 3.26 breaks database migration ForeignKey constraint, leaving __old in db schema

2018-12-06 Thread Django
#29182: SQLite 3.26 breaks database migration ForeignKey constraint, leaving
__old in db schema
--+
 Reporter:  ezaquarii |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Migrations|  Version:  2.1
 Severity:  Release blocker   |   Resolution:
 Keywords:  sqlite migration  | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Muflone):

 * cc: Muflone (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/067.745b849785684f17fca7be542c986949%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #28766: Add route information to ResolverMatch

2018-12-06 Thread Django
#28766: Add route information to ResolverMatch
-+-
 Reporter:  Benjamin Wohlwend|Owner:  Melvyn
 |  Sopacua
 Type:  New feature  |   Status:  closed
Component:  Core (URLs)  |  Version:  master
 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:  assigned => closed
 * resolution:   => fixed


Comment:

 In [changeset:"79c196cfb287893aadc6b0e74603ffde1512170e" 79c196cf]:
 {{{
 #!CommitTicketReference repository=""
 revision="79c196cfb287893aadc6b0e74603ffde1512170e"
 Fixed #28766 -- Added ResolverMatch.route.

 Co-Authored-By: Xavier Fernandez 
 }}}

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


Re: [Django] #29182: SQLite 3.26 breaks database migration ForeignKey constraint, leaving __old in db schema

2018-12-06 Thread Django
#29182: SQLite 3.26 breaks database migration ForeignKey constraint, leaving
__old in db schema
--+
 Reporter:  ezaquarii |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Migrations|  Version:  2.1
 Severity:  Release blocker   |   Resolution:
 Keywords:  sqlite migration  | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Simon Charette):

 Awesome, thanks for confirming Florian. I'll turn it into a PR with a
 release note for the next 2.1 release later today.

 I feel like we'll want to stick to this solution until we drop support for
 < 3.26 as the logic involved, as you've come to notice yourself, is
 already quite convoluted and adding some version branching in there would
 make it even worst. We've got a solution that allows us to keep atomic
 migrations enabled on SQLite so I suggest we stick to 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/067.b9cbdae1b08c5ef23baca2304302093f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #29182: SQLite 3.26 breaks database migration ForeignKey constraint, leaving __old in db schema

2018-12-06 Thread Django
#29182: SQLite 3.26 breaks database migration ForeignKey constraint, leaving
__old in db schema
--+
 Reporter:  ezaquarii |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Migrations|  Version:  2.1
 Severity:  Release blocker   |   Resolution:
 Keywords:  sqlite migration  | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Florian Apolloner):

 Hrmpf, I must have forgot to hit send before. Yes your pragma patch fixes
 it (with my testcase 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/067.50a821ee3a52bd0eac0b6a0811f54c89%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #29182: SQLite 3.26 breaks database migration ForeignKey constraint, leaving __old in db schema

2018-12-06 Thread Django
#29182: SQLite 3.26 breaks database migration ForeignKey constraint, leaving
__old in db schema
--+
 Reporter:  ezaquarii |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Migrations|  Version:  2.1
 Severity:  Release blocker   |   Resolution:
 Keywords:  sqlite migration  | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Simon Charette):

 Florian or Chris,

 Could you give a try at running the suite with the following patch and
 report if it helps

 https://github.com/django/django/compare/master...charettes:ticket-29182-pragma

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


Re: [Django] #29182: SQLite 3.26 breaks database migration ForeignKey constraint, leaving __old in db schema

2018-12-06 Thread Django
#29182: SQLite 3.26 breaks database migration ForeignKey constraint, leaving
__old in db schema
--+
 Reporter:  ezaquarii |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Migrations|  Version:  2.1
 Severity:  Release blocker   |   Resolution:
 Keywords:  sqlite migration  | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Chris Lamb):

 This is being tracked upstream in sqlite3 here:
 https://www.sqlite.org/src/info/f44bc7a8b3fac82a (hat-tip László
 Böszörményi in https://bugs.debian.org/915626#27).

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


Re: [Django] #29895: Adjust atomic DDL documentation to avoid ambiguity with MySQL 8+ notion of atomic DDL.

2018-12-06 Thread Django
#29895: Adjust atomic DDL documentation to avoid ambiguity with MySQL 8+ notion 
of
atomic DDL.
--+
 Reporter:  Nathan Klug   |Owner:  Rodrigo
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Documentation |  Version:  2.1
 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
--+

Comment (by Tim Graham ):

 In [changeset:"4c506730b5a8dae2ab9a16712db2f39c21d4385a" 4c50673]:
 {{{
 #!CommitTicketReference repository=""
 revision="4c506730b5a8dae2ab9a16712db2f39c21d4385a"
 [2.1.x] Fixed #29895 -- Doc'd why MySQL's atomic DDL statements don't work
 for atomic migrations.

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


Re: [Django] #29895: Adjust atomic DDL documentation to avoid ambiguity with MySQL 8+ notion of atomic DDL.

2018-12-06 Thread Django
#29895: Adjust atomic DDL documentation to avoid ambiguity with MySQL 8+ notion 
of
atomic DDL.
--+
 Reporter:  Nathan Klug   |Owner:  Rodrigo
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Documentation |  Version:  2.1
 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:  assigned => closed
 * resolution:   => fixed


Comment:

 In [changeset:"ad191d9e011f37d79a7f2df3da881b06539aaaea" ad191d9]:
 {{{
 #!CommitTicketReference repository=""
 revision="ad191d9e011f37d79a7f2df3da881b06539aaaea"
 Fixed #29895 -- Doc'd why MySQL's atomic DDL statements don't work for
 atomic migrations.
 }}}

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


Re: [Django] #29214: Invalid SQL generated when annotating a subquery with an outerref to an annotated field. (was: Invalid SQL when updating after annotating using subquery)

2018-12-06 Thread Django
#29214: Invalid SQL generated when annotating a subquery with an outerref to an
annotated field.
-+-
 Reporter:  Oskar Persson|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  queryset | Triage Stage:  Accepted
  annotations|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette):

 #30009 was a duplicate that wasn't relying on `update()`.

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


Re: [Django] #30009: Invalid SQL query when using Subquery, caused by table alias quoting.

2018-12-06 Thread Django
#30009: Invalid SQL query when using Subquery, caused by table alias quoting.
-+-
 Reporter:  Davit Mikava |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  queryset subquery| Triage Stage:  Accepted
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


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


Re: [Django] #30009: Invalid SQL query when using Subquery, caused by table alias quoting.

2018-12-06 Thread Django
#30009: Invalid SQL query when using Subquery, caused by table alias quoting.
-+-
 Reporter:  Davit Mikava |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  queryset subquery| Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette):

 I think you are right Felix, both use a subquery with an outer ref to an
 annotate field.

 I'll close this one as a duplicate of #29214 and reword its summary.

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


Re: [Django] #29932: QuerySet.difference() after intersection() returns incorrect results on SQLite and Oracle

2018-12-06 Thread Django
#29932: QuerySet.difference() after intersection() returns incorrect results on
SQLite and Oracle
-+-
 Reporter:  michaeldel   |Owner:  felixxm
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  queryset sqlite  | Triage Stage:  Accepted
  difference intersection|
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:"f9a33e3c3f4cfbff60522cd54455e78c96a9d2a4" f9a33e3c]:
 {{{
 #!CommitTicketReference repository=""
 revision="f9a33e3c3f4cfbff60522cd54455e78c96a9d2a4"
 Fixed #29932 -- Fixed combining compound queries with sub-compound queries
 on SQLite and Oracle.
 }}}

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


Re: [Django] #29986: ngettext_lazy result doesn't support `.format`

2018-12-06 Thread Django
#29986: ngettext_lazy result doesn't support `.format`
-+-
 Reporter:  patrick  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:   |  Version:  2.1
  Internationalization   |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  translations | 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:  new => closed
 * resolution:   => fixed


Comment:

 In [changeset:"ae180fa4b7f927a4aeae772975927c9888bb0cb0" ae180fa4]:
 {{{
 #!CommitTicketReference repository=""
 revision="ae180fa4b7f927a4aeae772975927c9888bb0cb0"
 Fixed #29986 -- Added .format() support to ngettext_lazy strings.
 }}}

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


Re: [Django] #30011: Count with filter annotation bug on filter

2018-12-06 Thread Django
#30011: Count with filter annotation bug on filter
-+-
 Reporter:  Taqi Abbas   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  Annotation, Count,   | Triage Stage:  Ready for
  Filter |  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:  new => closed
 * resolution:   => fixed


Comment:

 In [changeset:"53269bcaaf1fc2ce4db797d7d8935d98a53494df" 53269bca]:
 {{{
 #!CommitTicketReference repository=""
 revision="53269bcaaf1fc2ce4db797d7d8935d98a53494df"
 Fixed #30011 -- Fixed queries that reuse filtered aggregates.

 Thanks Taqi Abbas and Raphael Kimmig 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 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.34fc5c546ae6696f3b2e044749439c0b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #30005: Example in documentation of transaction.atomic uses both decorator and context manager

2018-12-06 Thread Django
#30005: Example in documentation of transaction.atomic uses both decorator and
context manager
---+--
 Reporter:  Peter Hull |Owner:  Peter Hull
 Type:  Bug|   Status:  closed
Component:  Documentation  |  Version:  2.1
 Severity:  Normal |   Resolution:  invalid
 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 Tim Graham):

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


[Django] #30017: Django should assume port 443 for https in django.utils.http.is_same_domain()

2018-12-06 Thread Django
#30017: Django should assume port 443 for https in
django.utils.http.is_same_domain()
-+
   Reporter:  Tagar  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  HTTP handling  |Version:  2.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  |
-+
 More complete explanation posted here -
 https://stackoverflow.com/questions/53658795/django-how-to-disable-
 referer-check

 the issue is probably in Django code here:
 
https://github.com/django/django/blob/22e8ab02863819093832de9f771bf40a62a6bd4a/django/middleware/csrf.py#L280

 referer variable there is a urlparse object (see
 https://docs.python.org/3/library/urllib.parse.html ) which contains
 "netloc" property with a port.

 Notice the error again - netlocs don't match because one has a port (443)
 and another doesn't have it (443 port is default for https):

 Referer checking failed -

 https://hue-dev.discover.abc.com/hue/accounts/login/?next=/
 does not match
 https://hue-dev.discover.abc.com:443/.

 so I guess it should be some sort of Referer field transformation made in
 nginx config to cut out 443 port explicitly (or add it).

 Referer check is failing because django.utils.http.is_same_domain() takes
 into account port
 (in referer.netloc ).

 Django should assume that port 443 is default for httpS, and not fail
 Referer check in this case.

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


Re: [Django] #30011: Count with filter annotation bug on filter

2018-12-06 Thread Django
#30011: Count with filter annotation bug on filter
-+-
 Reporter:  Taqi Abbas   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  Annotation, Count,   | Triage Stage:  Ready for
  Filter |  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 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.f40d4a095f299e1d9f0a6d05d745af25%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #30011: Count with filter annotation bug on filter

2018-12-06 Thread Django
#30011: Count with filter annotation bug on filter
-+-
 Reporter:  Taqi Abbas   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  Annotation, Count,   | Triage Stage:  Accepted
  Filter |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * stage:  Ready for checkin => 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/065.544d57e4e73eac9a1719221b60a8bc3d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #30011: Count with filter annotation bug on filter

2018-12-06 Thread Django
#30011: Count with filter annotation bug on filter
-+-
 Reporter:  Taqi Abbas   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  Annotation, Count,   | Triage Stage:  Ready for
  Filter |  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 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.3e3165fe6cec9474986ee82d4f85a9bd%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #30003: Manage.py entry point

2018-12-06 Thread Django
#30003: Manage.py entry point
-+-
 Reporter:  James Pic|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Core (Management |  Version:  2.1
  commands)  |
 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:  new => closed
 * resolution:   => fixed


Comment:

 In [changeset:"9453bc77f4968dc3a8167eadbf9775953812" 9453bc7]:
 {{{
 #!CommitTicketReference repository=""
 revision="9453bc77f4968dc3a8167eadbf9775953812"
 Fixed #30003 -- Added usable entry point in default manage.py.
 }}}

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


Re: [Django] #30014: Initialising disabled ModelChoiceField yields 'Select a valid choice'-error despite initialised option being valid

2018-12-06 Thread Django
#30014: Initialising disabled ModelChoiceField yields 'Select a valid 
choice'-error
despite initialised option being valid
-+-
 Reporter:  thoha|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:  forms, disabled  | Triage Stage:
  field, error, to_field_name|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 Can you please include code to reproduce the issue? (or ideally, a test
 for Django's test suite). Also, you should verify the issue against Django
 2.1 or master, if possible.

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


Re: [Django] #30009: Invalid SQL query when using Subquery, caused by table alias quoting.

2018-12-06 Thread Django
#30009: Invalid SQL query when using Subquery, caused by table alias quoting.
-+-
 Reporter:  Davit Mikava |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  queryset subquery| Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

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


Re: [Django] #30009: Invalid SQL query when using Subquery, caused by table alias quoting.

2018-12-06 Thread Django
#30009: Invalid SQL query when using Subquery, caused by table alias quoting.
-+-
 Reporter:  Davit Mikava |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  queryset subquery| 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):

 I think it is a duplicate of #29214.

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


Re: [Django] #29182: SQLite 3.26 breaks database migration ForeignKey constraint, leaving __old in db schema

2018-12-06 Thread Django
#29182: SQLite 3.26 breaks database migration ForeignKey constraint, leaving
__old in db schema
--+
 Reporter:  ezaquarii |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Migrations|  Version:  2.1
 Severity:  Release blocker   |   Resolution:
 Keywords:  sqlite migration  | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Florian Apolloner):

 Replying to [comment:25 Simon Charette]:
 > > We cannot safely alter a SQLite database inside a transaction from the
 looks of it...
 >
 > It has been working just fine on SQLite < 3.26 and the tests prove it.

 Yes, I was speaking with my 3.26 hat on (That is if we want to fix it
 without the PRAGMA for the rename). The existing code in master absolutely
 works fine and is stable for anything but the newest SQLite.

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


Re: [Django] #29182: SQLite 3.26 breaks database migration ForeignKey constraint, leaving __old in db schema

2018-12-06 Thread Django
#29182: SQLite 3.26 breaks database migration ForeignKey constraint, leaving
__old in db schema
--+
 Reporter:  ezaquarii |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Migrations|  Version:  2.1
 Severity:  Release blocker   |   Resolution:
 Keywords:  sqlite migration  | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Simon Charette):

 > We cannot safely alter a SQLite database inside a transaction from the
 looks of it...

 It has been working just fine on SQLite < 3.26 and the tests prove it.

 The current issue with 3.26 is that it changes the assumptions related to
 foreign key repointing on table rename when constraint checks are
 disabled. On SQLite < 3.26 renaming a table like we do in table remake
 because of unsupported `ALTER table` doesn't automatically repoint the
 foreign key constraints (e.g from `table_name` to `table_name__old`) but
 it does on SQLite 3.26.

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


Re: [Django] #29182: SQLite 3.26 breaks database migration ForeignKey constraint, leaving __old in db schema

2018-12-06 Thread Django
#29182: SQLite 3.26 breaks database migration ForeignKey constraint, leaving
__old in db schema
--+
 Reporter:  ezaquarii |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Migrations|  Version:  2.1
 Severity:  Release blocker   |   Resolution:
 Keywords:  sqlite migration  | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Florian Apolloner):

 Replying to [comment:22 Chris Lamb]:
 > However, the patch in
 https://code.djangoproject.com/ticket/29182#comment:12 does not work for
 me:

 As said this is just a starting point and we might come around to make
 this actually the expected behavior. We cannot safely alter a SQLite
 database inside a transaction from the looks of it (If you look at the
 patch we rewrite internal tables and then need to issues a VACUUM -- not
 sure if we can do that safely in transactions).

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


Re: [Django] #29182: SQLite 3.26 breaks database migration ForeignKey constraint, leaving __old in db schema

2018-12-06 Thread Django
#29182: SQLite 3.26 breaks database migration ForeignKey constraint, leaving
__old in db schema
--+
 Reporter:  ezaquarii |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Migrations|  Version:  2.1
 Severity:  Release blocker   |   Resolution:
 Keywords:  sqlite migration  | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Simon Charette):

 Hello Chris,

 I don't think the approach of the patch
 https://code.djangoproject.com/ticket/29182#comment:12 will work.

 Could you give
 https://github.com/django/django/compare/master...charettes:ticket-29182-pragma
 a run against the test suite on SQLite 3.26.

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


Re: [Django] #29182: SQLite 3.26 breaks database migration ForeignKey constraint, leaving __old in db schema

2018-12-06 Thread Django
#29182: SQLite 3.26 breaks database migration ForeignKey constraint, leaving
__old in db schema
--+
 Reporter:  ezaquarii |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Migrations|  Version:  2.1
 Severity:  Release blocker   |   Resolution:
 Keywords:  sqlite migration  | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Chris Lamb):

 * Apologies for the dupe. I filed #30016after not reading the most-recent
 entries here more carefully...

 * I can reproduce with sqlite3 `3.26.0` (but not with `3.25.3`)

 However, the patch in
 https://code.djangoproject.com/ticket/29182#comment:12 does not work for
 me:

 {{{
 test_testcase_ordering
 (test_runner.test_discover_runner.DiscoverRunnerTest) ... ok
 test_transaction_support (test_runner.tests.Sqlite3InMemoryTestDbs)
 Ticket #16329: sqlite3 in-memory test databases ... ERROR

 ==
 ERROR: test_transaction_support (test_runner.tests.Sqlite3InMemoryTestDbs)
 Ticket #16329: sqlite3 in-memory test databases
 --
 Traceback (most recent call last):
   File "/home/lamby/git/debian/python-team/modules/python-
 django/tests/test_runner/tests.py", line 226, in test_transaction_support
 DiscoverRunner(verbosity=0).setup_databases()
   File "/home/lamby/git/debian/python-team/modules/python-
 django/django/test/runner.py", line 551, in setup_databases
 self.parallel, **kwargs
   File "/home/lamby/git/debian/python-team/modules/python-
 django/django/test/utils.py", line 174, in setup_databases
 serialize=connection.settings_dict.get('TEST', {}).get('SERIALIZE',
 True),
   File "/home/lamby/git/debian/python-team/modules/python-
 django/django/db/backends/base/creation.py", line 68, in create_test_db
 run_syncdb=True,
   File "/home/lamby/git/debian/python-team/modules/python-
 django/django/core/management/__init__.py", line 148, in call_command
 return command.execute(*args, **defaults)
   File "/home/lamby/git/debian/python-team/modules/python-
 django/django/core/management/base.py", line 353, in execute
 output = self.handle(*args, **options)
   File "/home/lamby/git/debian/python-team/modules/python-
 django/django/core/management/base.py", line 83, in wrapped
 res = handle_func(*args, **kwargs)
   File "/home/lamby/git/debian/python-team/modules/python-
 django/django/core/management/commands/migrate.py", line 172, in handle
 self.sync_apps(connection, executor.loader.unmigrated_apps)
   File "/home/lamby/git/debian/python-team/modules/python-
 django/django/core/management/commands/migrate.py", line 306, in sync_apps
 editor.create_model(model)
   File "/home/lamby/git/debian/python-team/modules/python-
 django/django/db/backends/base/schema.py", line 312, in create_model
 self.execute(sql, params or None)
   File "/home/lamby/git/debian/python-team/modules/python-
 django/django/db/backends/base/schema.py", line 118, in execute
 "Executing DDL statements while in a transaction on databases "
 django.db.transaction.TransactionManagementError: Executing DDL statements
 while in a transaction on databases that can't perform a rollback is
 prohibited.

 --
 Ran 5020 tests in 138.176s

 FAILED (errors=1, skipped=657, expected failures=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/067.41052a35cc4f14a12c1095589ef3565b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #29182: SQLite 3.26 breaks database migration ForeignKey constraint, leaving __old in db schema (was: SQLite database migration breaks ForeignKey constraint, leaving

2018-12-06 Thread Django
#29182: SQLite 3.26 breaks database migration ForeignKey constraint, leaving
__old in db schema
--+
 Reporter:  ezaquarii |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Migrations|  Version:  2.1
 Severity:  Release blocker   |   Resolution:
 Keywords:  sqlite migration  | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Simon Charette):

 Changed ticket name to give it more exposure as there have been a few
 duplicates so far (e.g. #30016).

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


Re: [Django] #30016: Test regressions with sqlite3 3.26.0 (vs 3.25.3)

2018-12-06 Thread Django
#30016: Test regressions with sqlite3 3.26.0 (vs 3.25.3)
-+-
 Reporter:  Chris Lamb   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  sqlite3 tests| 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 #29182.

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


Re: [Django] #30015: HTTP server doesn't clear previous request data in keep-alive connection.

2018-12-06 Thread Django
#30015: HTTP server doesn't clear previous request data in keep-alive 
connection.
+
 Reporter:  kalekseev   |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  HTTP handling   |  Version:  2.1
 Severity:  Release blocker |   Resolution:
 Keywords:  keep-alive, server  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+
Changes (by Simon Charette):

 * cc: Florian Apolloner (added)
 * type:  Uncategorized => Bug
 * component:  Core (Other) => HTTP handling
 * severity:  Normal => Release blocker
 * 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/067.01007bc6445698b32d74c26e73ab89f0%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #28699: Document middleware ordering requirements following CSRF change in Django 1.11.6

2018-12-06 Thread Django
#28699: Document middleware ordering requirements following CSRF change in 
Django
1.11.6
---+
 Reporter:  stephanm   |Owner:  Rodrigo
 Type:  Bug|   Status:  assigned
Component:  Documentation  |  Version:  1.11
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+
Changes (by Carlton Gibson):

 * needs_better_patch:  0 => 1


Comment:

 Okay. Thank you for following up Florian. I will dig dipper given your
 confirmation of my first reading.

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


[Django] #30016: Test regressions with sqlite3 3.26.0 (vs 3.25.3)

2018-12-06 Thread Django
#30016: Test regressions with sqlite3 3.26.0 (vs 3.25.3)
-+-
   Reporter:  Chris  |  Owner:  nobody
  Lamb   |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  2.1
  layer (models, ORM)|
   Severity:  Normal |   Keywords:  sqlite3 tests
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Hi,

 In Debian, I am seeing the following test failure since upgrading
 `libsqlite3-0` from `3.25.3` (currently in buster) to `3.26.0`.

 With `libsqlite3-0 (3.26.0-1)`:

 {{{
   $ cd tests
   $ PYTHONPATH=.. python3 ./runtests.py --parallel=1 --failfast
   […]
   Testing against Django installed in '/home/lamby/git/debian/python-
 team/modules/python-django/django'
   Creating test database for alias 'default'...
   Creating test database for alias 'other'...
   System check identified no issues (14 silenced).
 
.sss..ssss..s..s..sss.sE
   ==
   ERROR: test_dumpdata_with_excludes (fixtures.tests.FixtureLoadingTests)
   --
   Traceback (most recent call last):
 File "/home/lamby/git/debian/python-team/modules/python-
 django/django/db/backends/utils.py", line 85, in _execute
   return self.cursor.execute(sql, params)
 File "/home/lamby/git/debian/python-team/modules/python-
 django/django/db/backends/sqlite3/base.py", line 296, in execute
   return Database.Cursor.execute(self, query, params)
   sqlite3.OperationalError: no such table: main.django_site__old

   The above exception was the direct cause of the following exception:

   Traceback (most recent call last):
 File "/home/lamby/git/debian/python-team/modules/python-
 django/tests/fixtures/tests.py", line 330, in test_dumpdata_with_excludes
   Site.objects.all().delete()
 File "/home/lamby/git/debian/python-team/modules/python-
 django/django/db/models/query.py", line 663, in delete
   deleted, _rows_count = collector.delete()
 File "/home/lamby/git/debian/python-team/modules/python-
 django/django/db/models/deletion.py", line 282, in delete
   count = qs._raw_delete(using=self.using)
 File "/home/lamby/git/debian/python-team/modules/python-
 django/django/db/models/query.py", line 677, in _raw_delete
   return sql.DeleteQuery(self.model).delete_qs(self, using)
 File "/home/lamby/git/debian/python-team/modules/python-
 django/django/db/models/sql/subqueries.py", line 75, in delete_qs
   cursor = self.get_compiler(using).execute_sql(CURSOR)
 File "/home/lamby/git/debian/python-team/modules/python-
 django/django/db/models/sql/compiler.py", line 1065, in execute_sql
   cursor.execute(sql, params)
 File "/home/lamby/git/debian/python-team/modules/python-
 django/django/db/backends/utils.py", line 68, in execute
   return self._execute_with_wrappers(sql, params, many=False,
 executor=self._execute)
 File "/home/lamby/git/debian/python-team/modules/python-
 django/django/db/backends/utils.py", line 77, in _execute_with_wrappers
   return executor(sql, params, many, context)
 File "/home/lamby/git/debian/python-team/modules/python-
 django/django/db/backends/utils.py", line 85, in _execute
   return self.cursor.execute(sql, params)
 File "/home/lamby/git/debian/python-team/modules/python-
 django/django/db/utils.py", line 89, in __exit__
   raise dj_exc_value.with_traceback(traceback) from exc_value
 File "/home/lamby/git/debian/python-team/modules/python-
 django/django/db/backends/utils.py", line 85, in _execute
   return self.cursor.execute(sql, params)
 File "/home/lamby/git/debian/python-team/modules/python-
 django/django/db/backends/sqlite3/base.py", line 296, in execute
   return Database.Cursor.execute(self, query, params)
   django.db.utils.OperationalError: no such table: main.django_site__old

   --
   Ran 572 tests 

Re: [Django] #28699: Document middleware ordering requirements following CSRF change in Django 1.11.6

2018-12-06 Thread Django
#28699: Document middleware ordering requirements following CSRF change in 
Django
1.11.6
---+
 Reporter:  stephanm   |Owner:  Rodrigo
 Type:  Bug|   Status:  assigned
Component:  Documentation  |  Version:  1.11
 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 Florian Apolloner):

 Replying to [comment:16 Carlton Gibson]:
 > Unless I missed something, this is **negating the `rotate_token()`
 call**. Is that correct, or have I misread it? Given the docstring in
 `rotate_token()` isn't this a no-no? If so, we can't recommend this.

 Yes, this seems correct

 > On the other hand, if `CsrfViewMiddleware` is first then the
 `rotate_token()` call will replace whatever `CSRF_COOKIE` was previously
 set, and so the actual CSRF check in `process_view()` will necessarily
 fail. (As we must be seeing here.)

 Also correct. I wonder if my patch in #28488 actually made the situation
 worse (speaks for the complexity of the middleware :/)

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


[Django] #30015: HTTP server doesn't clear previous request data in keep-alive connection.

2018-12-06 Thread Django
#30015: HTTP server doesn't clear previous request data in keep-alive 
connection.
-+-
   Reporter:  kalekseev  |  Owner:  nobody
   Type: | Status:  new
  Uncategorized  |
  Component:  Core   |Version:  2.1
  (Other)|
   Severity:  Normal |   Keywords:  keep-alive, server
   Triage Stage: |  Has patch:  1
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Django 2.1.4 affected.
 Commit that enabled keep-alive connections
 
https://github.com/django/django/commit/934acf1126995f6e6ccba5947ec8f7561633c27f
 Bug: if you make two requests in one keep-alive connection and first
 request posted data that wasn't read in the view
 then on second request that data will be read alongside with first line of
 the new request.
 As a result request.method will contain "..data from previous
 request...POST"

 Pull request with test and possible fix
 https://github.com/django/django/pull/10732

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


Re: [Django] #30011: Count with filter annotation bug on filter

2018-12-06 Thread Django
#30011: Count with filter annotation bug on filter
-+-
 Reporter:  Taqi Abbas   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  Annotation, Count,   | Triage Stage:  Accepted
  Filter |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Simon Charette):

 * has_patch:  0 => 1
 * type:  Uncategorized => Bug
 * stage:  Unreviewed => Accepted


Comment:

 Thanks for confirming as well Raphael!

 With both your reports I managed to come up with a patch. We happened to
 alter `Aggregate.source_expressions` on `get_expressions` when a `filter`
 was specified.

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

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


Re: [Django] #29027: file_move_safe() PermissionError with SELinux (was: file_move_safe error with SELinux)

2018-12-06 Thread Django
#29027: file_move_safe() PermissionError with SELinux
--+
 Reporter:  bhargu|Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  File uploads/storage  |  Version:  1.11
 Severity:  Normal|   Resolution:
 Keywords:  selinux   | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  1 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Tim Graham):

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


Comment:

 I closed the issue because there wasn't a response to comment 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/064.e9a83d7ea4882f24d9530d31ff18f12a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #30010: Add support for running the test suite through docker with docker-compose

2018-12-06 Thread Django
#30010: Add support for running the test suite through docker with 
docker-compose
---+
 Reporter:  Tom Forbes |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Testing framework  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  1
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by Tom Forbes):

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


Re: [Django] #29027: file_move_safe error with SELinux

2018-12-06 Thread Django
#29027: file_move_safe error with SELinux
-+-
 Reporter:  bhargu   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  File |  Version:  1.11
  uploads/storage|
 Severity:  Normal   |   Resolution:
 Keywords:  selinux  | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Paolo Donadeo):

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


Comment:

 I have a question: why the ticket has been closed? I can confirm the issue
 reported by bhargu still present in Django 2.1.3 and I can confirm that
 the proposed patch:
 
https://github.com/agrimgt/django/commit/f9b48086d083b1eee800ea752f2c3fd60a8cc448
 works.

 This is a show stopper for us: Django simply don't work on a RHEL7 or
 CentOS7 with SELinux enabled. To deploy Django 2.x I'm forced to fork.

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


Re: [Django] #30014: Initialising disabled ModelChoiceField yields 'Select a valid choice'-error despite initialised option being valid

2018-12-06 Thread Django
#30014: Initialising disabled ModelChoiceField yields 'Select a valid 
choice'-error
despite initialised option being valid
-+-
 Reporter:  thoha|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:  forms, disabled  | Triage Stage:
  field, error, to_field_name|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by thoha):

 * keywords:  forms, disabled field, error => forms, disabled field, error,
 to_field_name


Old description:

> I have a form with a ModelChoiceField that gets initialised to a specific
> value using get_initial in that form's View. This value is a valid choice
> for that Model. I don't want the user to be able to change the option on
> the form, but it needs to be displayed nonetheless.
>
> When I set disabled=True on that field in forms.py, submitting the form
> yields the following error:
>
> fieldnameSelect a
> valid choice. That choice is not one of the available
> choices..
>
> Firstly, I would like to comment on the general quality of the error
> message, as it is not very useful: It does not return ''which'' choice it
> considers invalid. Including this information would make the message much
> more informative, and would avoid sending people on a wild goose chase to
> discover what the message could possibly mean.
>
> Secondly, if a field is disabled but does contain a valid choice,
> validating the form should work and not trigger an error.
>
> This is probably related to the bugfix for this bug:
> https://code.djangoproject.com/ticket/28387

New description:

 I have a form with a ModelChoiceField that gets initialised to a specific
 value using get_initial in that form's View. This value is a valid choice
 for that Model. I don't want the user to be able to change the option on
 the form, but it needs to be displayed nonetheless.

 When I set disabled=True on that field in forms.py, submitting the form
 yields the following error:

 fieldnameSelect a
 valid choice. That choice is not one of the available
 choices..

 Firstly, I would like to comment on the general quality of the error
 message, as it is not very useful: It does not return ''which'' choice it
 considers invalid. Including this information would make the message much
 more informative, and would avoid sending people on a wild goose chase to
 discover what the message could possibly mean.

 Secondly, if a field is disabled but does contain a valid choice,
 validating the form should work and not trigger an error.

 Edit: Adding the **to_field_name** option to the form field fixes the
 problem. However, when disabled=True is not present, this is not required.

 This is probably related to the bugfix for this bug:
 https://code.djangoproject.com/ticket/28387

--

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


Re: [Django] #30000: QuerySet constructed with .union() should raise an exception on unsupported filter() attempt.

2018-12-06 Thread Django
#3: QuerySet constructed with .union() should raise an exception on 
unsupported
filter() attempt.
-+-
 Reporter:  thoha|Owner:  Hasan
 |  Ramezani
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  queryset union   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by thoha):

 Replying to [comment:7 Hasan Ramezani]:
 > should we raise an exception for all `filter()` attempts? or just for
 unsupported one?
 > if we should we raise an exception just for unsupported, is there any
 way to find them?

 Unsupported ones, I'd think. For my original problem, a simple check would
 be to do a count on the number of selections made in the form and
 comparing that to the number of records returned - normally they should
 match.

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


[Django] #30014: Initialising disabled ModelChoiceField yields 'Select a valid choice'-error despite initialised option being valid

2018-12-06 Thread Django
#30014: Initialising disabled ModelChoiceField yields 'Select a valid 
choice'-error
despite initialised option being valid
-+-
   Reporter:  thoha  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Forms  |Version:  1.11
   Severity:  Normal |   Keywords:  forms, disabled
   Triage Stage: |  field, error
  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 I have a form with a ModelChoiceField that gets initialised to a specific
 value using get_initial in that form's View. This value is a valid choice
 for that Model. I don't want the user to be able to change the option on
 the form, but it needs to be displayed nonetheless.

 When I set disabled=True on that field in forms.py, submitting the form
 yields the following error:

 fieldnameSelect a
 valid choice. That choice is not one of the available
 choices..

 Firstly, I would like to comment on the general quality of the error
 message, as it is not very useful: It does not return ''which'' choice it
 considers invalid. Including this information would make the message much
 more informative, and would avoid sending people on a wild goose chase to
 discover what the message could possibly mean.

 Secondly, if a field is disabled but does contain a valid choice,
 validating the form should work and not trigger an error.

 This is probably related to the bugfix for this bug:
 https://code.djangoproject.com/ticket/28387

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


Re: [Django] #30011: Count with filter annotation bug on filter

2018-12-06 Thread Django
#30011: Count with filter annotation bug on filter
-+-
 Reporter:  Taqi Abbas   |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Database layer   |  Version:  2.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  Annotation, Count,   | Triage Stage:
  Filter |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Raphael Kimmig):

 I've got a somewhat smaller repro here, the bug seems to require both a
 filtered annotation and a nested filter.

 {{{
 from django.db.models import Count, Q
 from django.test import TestCase
 from django.db import models, OperationalError


 class Thing(models.Model):
 pass


 class RelatedThing(models.Model):
 thing = models.ForeignKey(
 Thing, on_delete=models.CASCADE,
 )


 class TestCountExtraArg(TestCase):
 def setUp(self):
 t = Thing.objects.create()
 t.relatedthing_set.create()

 def test_issue_not_triggered_without_filter_in_(self):
 queryset = Thing.objects.annotate(
 related_count=Count("relatedthing")
 )
 result = queryset.filter(id__in=queryset.values("id"))

 self.assertEqual(result[0].related_count, 1, result)

 def test_issue_not_triggered_without_nested_query(self):
 queryset = Thing.objects.annotate(
 related_count=Count("relatedthing", filter=Q(id__gt=0))
 )
 result = queryset.filter(id__in=list(queryset.values_list("id",
 flat=True)))
 self.assertEqual(result[0].related_count, 1, result)

 def test_triggering_issue(self):
 queryset = Thing.objects.annotate(
 related_count=Count("relatedthing", filter=Q(id__gt=0))
 )
 result = queryset.filter(id__in=queryset.values("id"))

 with self.assertRaises(OperationalError):
 self.assertEqual(result[0].related_count, 1, result)
 }}}

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