Re: [Django] #23557: annotate gives different results on postgresql and mysql

2014-09-26 Thread Django
#23557: annotate gives different results on postgresql and mysql
-+-
 Reporter:  brian|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by shaib):

 It should be noted that "full" group-by causes significant performance
 degradations on mysql; this is related to #17144.

 In other respects, @jarshwah's comments are mostly correct -- except for
 one point, and that is that the SQL spec is retarded, and an ORM ''can''
 know when it's safe to group by a subset of the retrieved fields (which
 are unique for the group).

 I suspect the only way to resolve this without breaking stuff is to close
 this ticket as "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 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.a1093d7bcbd646678ba0fe4e9893de18%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #23557: annotate gives different results on postgresql and mysql

2014-09-26 Thread Django
#23557: annotate gives different results on postgresql and mysql
-+-
 Reporter:  brian|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by jarshwah):

 Additionally, it may be worth talking about removing the non-standard
 behaviour from mysql in django by setting the session to
 "ONLY_FULL_GROUP_BY": http://dev.mysql.com/doc/refman/5.0/en/sql-
 mode.html#sqlmode_only_full_group_by but that may be backwards
 incompatible.

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


Re: [Django] #23557: annotate gives different results on postgresql and mysql

2014-09-26 Thread Django
#23557: annotate gives different results on postgresql and mysql
-+-
 Reporter:  brian|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by jarshwah):

 * stage:  Unreviewed => Accepted


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

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


Re: [Django] #23557: annotate gives different results on postgresql and mysql

2014-09-26 Thread Django
#23557: annotate gives different results on postgresql and mysql
-+-
 Reporter:  brian|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by jarshwah):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 The behaviour you're seeing with Postgres is correct, and documented:
 https://docs.djangoproject.com/en/dev/topics/db/aggregation/#interaction-
 with-default-ordering-or-order-by

 Columns in the ORDER BY clause must be added to the GROUP BY clause on
 Postgres, and any RDBMS that conforms to the spec. MySQL and sqlite allow
 columns in the select list that aren't also in the GROUP BY. Django should
 be consistent though - it's weird that different results are returned
 based on the underlying engine.

 I would propose that the MySQL backend should add the order by columns
 into the group by list.

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


Re: [Django] #22738: Schema migration: test_add_field_temp_default_boolean

2014-09-26 Thread Django
#22738: Schema migration: test_add_field_temp_default_boolean
-+-
 Reporter:  maxi |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  Migrations   |   Resolution:
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by shaib):

 ...so, let's see what Jenkins thinks of
 https://github.com/django/django/pull/3283

 If I read the earlier failures right -- this will fail as well, because,
 apparently, the buggy behavior only kicks in if the column is added by
 `ALTER TABLE`, not if it is already present in the `CREATE TABLE`. If that
 turns out to be the case, I'll add another argument to the
 `DatabaseFeatures` method.

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


Re: [Django] #6707: Another implementation for ReverseManyRelatedObjectsDescriptor.__set__ method

2014-09-26 Thread Django
#6707: Another implementation for ReverseManyRelatedObjectsDescriptor.__set__
method
-+-
 Reporter:  favo |Owner:  loic
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by loic):

 * owner:  loic84 => loic
 * needs_docs:  1 => 0
 * needs_tests:  1 => 0


Comment:

 Resuming work on this issue, I brought the branch up-to-date and drafted
 some documentation. It'd be very helpful if some of those affected by this
 issue could give it a try.

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


Re: [Django] #22738: Schema migration: test_add_field_temp_default_boolean

2014-09-26 Thread Django
#22738: Schema migration: test_add_field_temp_default_boolean
-+-
 Reporter:  maxi |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  Migrations   |   Resolution:
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by shaib):

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


Comment:

 The new patch is, indeed, a significant improvement compared to the
 previous approach, except for one small thing -- it fails on Oracle :).

 I'll fix it.

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

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


Re: [Django] #22738: Schema migration: test_add_field_temp_default_boolean

2014-09-26 Thread Django
#22738: Schema migration: test_add_field_temp_default_boolean
-+-
 Reporter:  maxi |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  master
Component:  Migrations   |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Claude Paroz ):

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


Comment:

 In [changeset:"dbdae3a75512bddbf0b75ea6354fb3fc4bdb53cf"]:
 {{{
 #!CommitTicketReference repository=""
 revision="dbdae3a75512bddbf0b75ea6354fb3fc4bdb53cf"
 Fixed #22738 -- Abstracted boolean field type introspection

 Thanks maxi for the report, Shai Berger for his help with the patch
 and Tim Graham for the review.
 }}}

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


[django/django] dbdae3: Fixed #22738 -- Abstracted boolean field type intr...

2014-09-26 Thread GitHub
  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: dbdae3a75512bddbf0b75ea6354fb3fc4bdb53cf
  
https://github.com/django/django/commit/dbdae3a75512bddbf0b75ea6354fb3fc4bdb53cf
  Author: Claude Paroz 
  Date:   2014-09-26 (Fri, 26 Sep 2014)

  Changed paths:
M django/db/backends/__init__.py
M django/db/backends/mysql/base.py
M django/db/backends/oracle/base.py
M tests/inspectdb/tests.py
M tests/schema/tests.py

  Log Message:
  ---
  Fixed #22738 -- Abstracted boolean field type introspection

Thanks maxi for the report, Shai Berger for his help with the patch
and Tim Graham for the review.


-- 
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/5425ab37b9584_51b83fbaee55d2bc3469a%40hookshot-fe4-cp1-prd.iad.github.net.mail.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #23543: Documentation how to test custom management command missing

2014-09-26 Thread Django
#23543: Documentation how to test custom management command missing
--+
 Reporter:  wittwerch |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.7
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by claudep):

 I think an example wouldn't hurt, and show how you can catch the command
 output with `six.StringIO` (see `tests/user_commands/tests.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/067.8af4bf3ceebaae7ec35c5696879cbd37%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


[django/django] 458409: Silenced some deprecation warnings in contrib.site...

2014-09-26 Thread GitHub
  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 45840927d3516770be2654422e752357d5c063a5
  
https://github.com/django/django/commit/45840927d3516770be2654422e752357d5c063a5
  Author: Loic Bistuer 
  Date:   2014-09-27 (Sat, 27 Sep 2014)

  Changed paths:
M django/contrib/sitemaps/tests/test_http.py
M django/contrib/sitemaps/tests/test_https.py
M django/contrib/sitemaps/tests/urls/http.py
M django/contrib/sitemaps/tests/urls/https.py

  Log Message:
  ---
  Silenced some deprecation warnings in contrib.sitemaps; refs #22384.


-- 
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/5425a6225aa38_59113fdbe09ff2bc33967%40hookshot-fe4-cp1-prd.iad.github.net.mail.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #22384: Deprecate the ability to reverse by dotted path

2014-09-26 Thread Django
#22384: Deprecate the ability to reverse by dotted path
-+-
 Reporter:  timo |Owner:  timo
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  master
Component:  Core (URLs)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Loic Bistuer ):

 In [changeset:"45840927d3516770be2654422e752357d5c063a5"]:
 {{{
 #!CommitTicketReference repository=""
 revision="45840927d3516770be2654422e752357d5c063a5"
 Silenced some deprecation warnings in contrib.sitemaps; refs #22384.
 }}}

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


Re: [Django] #22738: Schema migration: test_add_field_temp_default_boolean

2014-09-26 Thread Django
#22738: Schema migration: test_add_field_temp_default_boolean
-+-
 Reporter:  maxi |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  Migrations   |   Resolution:
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

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


[django/django] 735588: [1.7.x] Fixed #23560 -- Fixed MigrationWrite to ha...

2014-09-26 Thread GitHub
  Branch: refs/heads/stable/1.7.x
  Home:   https://github.com/django/django
  Commit: 7355885ef504cc34f447311741511018f777667f
  
https://github.com/django/django/commit/7355885ef504cc34f447311741511018f777667f
  Author: Loic Bistuer 
  Date:   2014-09-27 (Sat, 27 Sep 2014)

  Changed paths:
M django/db/migrations/writer.py
M docs/releases/1.7.1.txt
M tests/migrations/test_writer.py

  Log Message:
  ---
  [1.7.x] Fixed #23560 -- Fixed MigrationWrite to handle builtin types without 
imports.

Thanks Tim Graham for the review.

Backport of b23d47412c from master


-- 
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/5425a555d325f_cb23f88e169329c2313b%40hookshot-fe2-cp1-prd.iad.github.net.mail.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #23560: MigrationWriter prefixes builtin types with __builtins__.

2014-09-26 Thread Django
#23560: MigrationWriter prefixes builtin types with __builtins__.
+-
 Reporter:  loic|Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  Migrations  |  Version:  1.7
 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 Loic Bistuer ):

 In [changeset:"7355885ef504cc34f447311741511018f777667f"]:
 {{{
 #!CommitTicketReference repository=""
 revision="7355885ef504cc34f447311741511018f777667f"
 [1.7.x] Fixed #23560 -- Fixed MigrationWrite to handle builtin types
 without imports.

 Thanks Tim Graham for the review.

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


[django/django] b23d47: Fixed #23560 -- Fixed MigrationWrite to handle bui...

2014-09-26 Thread GitHub
  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: b23d47412c12352ba2e2133b05a15ccd09e81af3
  
https://github.com/django/django/commit/b23d47412c12352ba2e2133b05a15ccd09e81af3
  Author: Loic Bistuer 
  Date:   2014-09-27 (Sat, 27 Sep 2014)

  Changed paths:
M django/db/migrations/writer.py
M docs/releases/1.7.1.txt
M tests/migrations/test_writer.py

  Log Message:
  ---
  Fixed #23560 -- Fixed MigrationWrite to handle builtin types without imports.

Thanks Tim Graham for the review.


-- 
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/5425a4eb4a38b_7b1f3fd02f6bd2a010208a%40hookshot-fe3-cp1-prd.iad.github.net.mail.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #23560: MigrationWriter prefixes builtin types with __builtins__.

2014-09-26 Thread Django
#23560: MigrationWriter prefixes builtin types with __builtins__.
+-
 Reporter:  loic|Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  Migrations  |  Version:  1.7
 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 Loic Bistuer ):

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


Comment:

 In [changeset:"b23d47412c12352ba2e2133b05a15ccd09e81af3"]:
 {{{
 #!CommitTicketReference repository=""
 revision="b23d47412c12352ba2e2133b05a15ccd09e81af3"
 Fixed #23560 -- Fixed MigrationWrite to handle builtin types without
 imports.

 Thanks Tim Graham for the review.
 }}}

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


[django/django]

2014-09-26 Thread GitHub
  Branch: refs/heads/ticket23560
  Home:   https://github.com/django/django

-- 
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/5425a49c5a419_5de73fbc0a0412c08732d%40hookshot-fe4-cp1-prd.iad.github.net.mail.
For more options, visit https://groups.google.com/d/optout.


[django/django] b23d47: Fixed #23560 -- Fixed MigrationWrite to handle bui...

2014-09-26 Thread GitHub
  Branch: refs/heads/ticket23560
  Home:   https://github.com/django/django
  Commit: b23d47412c12352ba2e2133b05a15ccd09e81af3
  
https://github.com/django/django/commit/b23d47412c12352ba2e2133b05a15ccd09e81af3
  Author: Loic Bistuer 
  Date:   2014-09-27 (Sat, 27 Sep 2014)

  Changed paths:
M django/db/migrations/writer.py
M docs/releases/1.7.1.txt
M tests/migrations/test_writer.py

  Log Message:
  ---
  Fixed #23560 -- Fixed MigrationWrite to handle builtin types without imports.

Thanks Tim Graham for the review.


-- 
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/5425a48513921_162a3fefd380129c2647d%40hookshot-fe2-cp1-prd.iad.github.net.mail.
For more options, visit https://groups.google.com/d/optout.


[django/django] 091289: [1.7.X] How many is two?

2014-09-26 Thread GitHub
  Branch: refs/heads/stable/1.7.x
  Home:   https://github.com/django/django
  Commit: 091289d95039cfaa4a94cd40ac5055915f72971e
  
https://github.com/django/django/commit/091289d95039cfaa4a94cd40ac5055915f72971e
  Author: Carl Meyer 
  Date:   2014-09-26 (Fri, 26 Sep 2014)

  Changed paths:
M docs/topics/migrations.txt

  Log Message:
  ---
  [1.7.X] How many is two?


-- 
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/5425a147d42c5_51b53f99bb0d129c6584f%40hookshot-fe4-cp1-prd.iad.github.net.mail.
For more options, visit https://groups.google.com/d/optout.


[django/django] f5c932: How many is two?

2014-09-26 Thread GitHub
  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: f5c932ddec8605df82319850d0f0e2f4dad1de11
  
https://github.com/django/django/commit/f5c932ddec8605df82319850d0f0e2f4dad1de11
  Author: Carl Meyer 
  Date:   2014-09-26 (Fri, 26 Sep 2014)

  Changed paths:
M docs/topics/migrations.txt

  Log Message:
  ---
  How many is two?


-- 
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/5425a1409e211_4ee13fa468af92bc2624c%40hookshot-fe4-cp1-prd.iad.github.net.mail.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #23561: Can unauthorized JS execution happen in quoted & escaped HTML class name?

2014-09-26 Thread Django
#23561: Can unauthorized JS execution happen in quoted & escaped HTML class 
name?
---+
 Reporter:  djbug  |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Documentation  |  Version:  1.7
 Severity:  Normal |   Resolution:  fixed
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by Carl Meyer ):

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


Comment:

 In [changeset:"d16bc7f0e46785bcf422310c41d20b25c0112051"]:
 {{{
 #!CommitTicketReference repository=""
 revision="d16bc7f0e46785bcf422310c41d20b25c0112051"
 Fixed #23561 -- Corrected a security doc example that requires an unquoted
 HTML attribute.

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


[django/django] d7bc30: [1.7.X] Fixed #23561 -- Corrected a security doc e...

2014-09-26 Thread GitHub
  Branch: refs/heads/stable/1.7.x
  Home:   https://github.com/django/django
  Commit: d7bc30ffd26ebbe6d98fcd08d9120f44702d2a62
  
https://github.com/django/django/commit/d7bc30ffd26ebbe6d98fcd08d9120f44702d2a62
  Author: Carl Meyer 
  Date:   2014-09-26 (Fri, 26 Sep 2014)

  Changed paths:
M docs/topics/security.txt

  Log Message:
  ---
  [1.7.X] Fixed #23561 -- Corrected a security doc example that requires an 
unquoted HTML attribute.

Thanks "djbug" for the report.


-- 
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/54259d98992b4_cb23f88e169329c211bc%40hookshot-fe2-cp1-prd.iad.github.net.mail.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #23561: Can unauthorized JS execution happen in quoted & escaped HTML class name?

2014-09-26 Thread Django
#23561: Can unauthorized JS execution happen in quoted & escaped HTML class 
name?
---+
 Reporter:  djbug  |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Documentation  |  Version:  1.7
 Severity:  Normal |   Resolution:  fixed
 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 Carl Meyer ):

 In [changeset:"d7bc30ffd26ebbe6d98fcd08d9120f44702d2a62"]:
 {{{
 #!CommitTicketReference repository=""
 revision="d7bc30ffd26ebbe6d98fcd08d9120f44702d2a62"
 [1.7.X] Fixed #23561 -- Corrected a security doc example that requires an
 unquoted HTML attribute.

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


[django/django] d16bc7: Fixed #23561 -- Corrected a security doc example t...

2014-09-26 Thread GitHub
  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: d16bc7f0e46785bcf422310c41d20b25c0112051
  
https://github.com/django/django/commit/d16bc7f0e46785bcf422310c41d20b25c0112051
  Author: Carl Meyer 
  Date:   2014-09-26 (Fri, 26 Sep 2014)

  Changed paths:
M docs/topics/security.txt

  Log Message:
  ---
  Fixed #23561 -- Corrected a security doc example that requires an unquoted 
HTML attribute.

Thanks "djbug" for the report.


-- 
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/54259d8be0e06_685e3f83b45cb29c1076f1%40hookshot-fe3-cp1-prd.iad.github.net.mail.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #23460: Allow a literal `%s` to be passed through extra select

2014-09-26 Thread Django
#23460: Allow a literal `%s` to be passed through extra select
-+-
 Reporter:  mattrobenolt |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  queryset |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"ef5f9b6ae8c873927aa6047f5f9d1d902a0c2177"]:
 {{{
 #!CommitTicketReference repository=""
 revision="ef5f9b6ae8c873927aa6047f5f9d1d902a0c2177"
 Fixed #23460 -- Added literal `%s` support to extra() QuerySets.
 }}}

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


[django/django] ef5f9b: Fixed #23460 -- Added literal `%s` support to extr...

2014-09-26 Thread GitHub
  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: ef5f9b6ae8c873927aa6047f5f9d1d902a0c2177
  
https://github.com/django/django/commit/ef5f9b6ae8c873927aa6047f5f9d1d902a0c2177
  Author: Matt Robenolt 
  Date:   2014-09-26 (Fri, 26 Sep 2014)

  Changed paths:
M django/db/models/sql/query.py
M docs/ref/models/querysets.txt
M docs/releases/1.8.txt
M tests/queries/tests.py

  Log Message:
  ---
  Fixed #23460 -- Added literal `%s` support to extra() QuerySets.


-- 
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/54259c41c15b9_5b483fc2e211729c2847%40hookshot-fe4-cp1-prd.iad.github.net.mail.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #23561: Can unauthorized JS execution happen in quoted & escaped HTML class name?

2014-09-26 Thread Django
#23561: Can unauthorized JS execution happen in quoted & escaped HTML class 
name?
---+
 Reporter:  djbug  |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Documentation  |  Version:  1.7
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by carljm):

 * component:  Uncategorized => Documentation
 * stage:  Unreviewed => Accepted


Comment:

 It looks to me like those quotes were added in 9432f1, probably without
 consideration that adding them changed that particular example
 significantly.

 I'm not aware of a browser vulnerability that would make the shown code
 (with quoted attributes and autoescaping on) vulnerable.

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


Re: [Django] #23561: Can unauthorized JS execution happen in quoted & escaped HTML class name?

2014-09-26 Thread Django
#23561: Can unauthorized JS execution happen in quoted & escaped HTML class 
name?
---+--
 Reporter:  djbug  |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  1.7
 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 djbug:

Old description:

> According to https://docs.djangoproject.com/en/1.7/topics/security/
>
> ...
>
> If var is set to 'class1 onmouseover=javascript:func()', this can result
> in unauthorized JavaScript execution, depending on how the browser
> renders imperfect HTML.
>
> If `var` is escaped and the class attribute is in quotes, how can JS
> execution happen?
>
> The previous version of docs i.e.
> https://docs.djangoproject.com/en/1.6/topics/security/ & before didn't
> have quotes around `{{var}}` and that made sense as you switch out of the
> attribute context with many characters. Is this a typo in the docs for
> 1.7 or is it implied that the invalid characters in class name *may*
> cause a security exception in some obscure browser that might close the
> class context. Is this a known security issue in any browser?

New description:

 According to https://docs.djangoproject.com/en/1.7/topics/security/

 ...

 If var is set to 'class1 onmouseover=javascript:func()', this can result
 in unauthorized JavaScript execution, depending on how the browser renders
 imperfect HTML.

 If `var` is escaped and the class attribute is in quotes, how can JS
 execution happen?

 The previous version of docs i.e.
 https://docs.djangoproject.com/en/1.6/topics/security/ & before didn't
 have quotes around `{{var}}` and that made sense (i.e. unquoted attributes
 are unsafe). However in v 1.7, is this a typo in the or is it implied that
 the invalid characters in class name *may* cause a security exception in
 some obscure browser that might close the class context. Is this a known
 security issue in any browser?

--

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


Re: [Django] #23561: Can unauthorized JS execution happen in quoted & escaped HTML class name?

2014-09-26 Thread Django
#23561: Can unauthorized JS execution happen in quoted & escaped HTML class 
name?
---+--
 Reporter:  djbug  |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  1.7
 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 djbug):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


Old description:

> According to https://docs.djangoproject.com/en/1.7/topics/security/
>
> ...
>
> If var is set to 'class1 onmouseover=javascript:func()', this can result
> in unauthorized JavaScript execution, depending on how the browser
> renders imperfect HTML.
>
> If `var` is escaped and the class attribute is in quotes, how can JS
> execution happen?
>
> The previous version of docs i.e.
> https://docs.djangoproject.com/en/1.6/topics/security/ & before didn't
> have quotes around `{{var}}` and that made sense as you switch out of the
> attribute context with many characters. Is this a typo in the docs for
> 1.7 ?

New description:

 According to https://docs.djangoproject.com/en/1.7/topics/security/

 ...

 If var is set to 'class1 onmouseover=javascript:func()', this can result
 in unauthorized JavaScript execution, depending on how the browser renders
 imperfect HTML.

 If `var` is escaped and the class attribute is in quotes, how can JS
 execution happen?

 The previous version of docs i.e.
 https://docs.djangoproject.com/en/1.6/topics/security/ & before didn't
 have quotes around `{{var}}` and that made sense as you switch out of the
 attribute context with many characters. Is this a typo in the docs for 1.7
 or is it implied that the invalid characters in class name *may* cause a
 security exception in some obscure browser that might close the class
 context. Is this a known security issue in any browser?

--

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


[Django] #23561: Can unauthorized JS execution happen in quoted & escaped HTML class name?

2014-09-26 Thread Django
#23561: Can unauthorized JS execution happen in quoted & escaped HTML class 
name?
---+
 Reporter:  djbug  |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  1.7
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 According to https://docs.djangoproject.com/en/1.7/topics/security/

 ...

 If var is set to 'class1 onmouseover=javascript:func()', this can result
 in unauthorized JavaScript execution, depending on how the browser renders
 imperfect HTML.

 If `var` is escaped and the class attribute is in quotes, how can JS
 execution happen?

 The previous version of docs i.e.
 https://docs.djangoproject.com/en/1.6/topics/security/ & before didn't
 have quotes around `{{var}}` and that made sense as you switch out of the
 attribute context with many characters. Is this a typo in the docs for 1.7
 ?

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


[django/django]

2014-09-26 Thread GitHub
  Branch: refs/heads/ticket23560
  Home:   https://github.com/django/django

-- 
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/5425969a760a_61fa3fb67a4732c0192c4%40hookshot-fe4-cp1-prd.iad.github.net.mail.
For more options, visit https://groups.google.com/d/optout.


[django/django] ff40c4: Fixed #23560 -- Fixed MigrationWrite to handle bui...

2014-09-26 Thread GitHub
  Branch: refs/heads/ticket23560
  Home:   https://github.com/django/django
  Commit: ff40c4f36b6d4056dbf85a4b31fb275943aff4bb
  
https://github.com/django/django/commit/ff40c4f36b6d4056dbf85a4b31fb275943aff4bb
  Author: Loic Bistuer 
  Date:   2014-09-26 (Fri, 26 Sep 2014)

  Changed paths:
M django/db/migrations/writer.py
M docs/releases/1.7.1.txt
M tests/migrations/test_writer.py

  Log Message:
  ---
  Fixed #23560 -- Fixed MigrationWrite to handle builtin types without imports.

Thanks Tim Graham for the review.


-- 
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/5425960798cbd_59113fdbe09ff2bc30742%40hookshot-fe4-cp1-prd.iad.github.net.mail.
For more options, visit https://groups.google.com/d/optout.


[django/django] 17557d: Fixed #8408 -- Added ModelAdmin.show_full_result_c...

2014-09-26 Thread GitHub
  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 17557d068c43bd61cdc6c18caf250ffa469414a1
  
https://github.com/django/django/commit/17557d068c43bd61cdc6c18caf250ffa469414a1
  Author: Thomas Chaumeny 
  Date:   2014-09-26 (Fri, 26 Sep 2014)

  Changed paths:
M django/contrib/admin/options.py
M django/contrib/admin/templates/admin/change_list.html
M django/contrib/admin/templates/admin/search_form.html
M django/contrib/admin/views/main.py
M docs/ref/contrib/admin/index.txt
M docs/releases/1.8.txt
M tests/admin_views/admin.py
M tests/admin_views/tests.py

  Log Message:
  ---
  Fixed #8408 -- Added ModelAdmin.show_full_result_count to avoid COUNT() query.

Thanks lidaobing for the suggestion.


-- 
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/5425909cf1a36_528c3fcda359f2bc5099c%40hookshot-fe4-cp1-prd.iad.github.net.mail.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #8408: Add a new meta option: don't do count(*) in admin

2014-09-26 Thread Django
#8408: Add a new meta option: don't do count(*) in admin
---+-
 Reporter:  lidaobing  |Owner:  tchaumeny
 Type:  New feature|   Status:  closed
Component:  contrib.admin  |  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:"17557d068c43bd61cdc6c18caf250ffa469414a1"]:
 {{{
 #!CommitTicketReference repository=""
 revision="17557d068c43bd61cdc6c18caf250ffa469414a1"
 Fixed #8408 -- Added ModelAdmin.show_full_result_count to avoid COUNT()
 query.

 Thanks lidaobing for the suggestion.
 }}}

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


Re: [Django] #23559: Staff (not superusers) should not manage perms of Users

2014-09-26 Thread Django
#23559: Staff (not superusers) should not manage perms of Users
---+
 Reporter:  Tuttle |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Documentation  |  Version:
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  1
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+

Comment (by Tuttle):

 It was only a sketch from me, but thanks for the security audit. :-)
 That's something not immediately apparent.

 In my project I also add this to prevent staff user to edit other users
 who possibly have any permission:

 {{{#!python
 def has_change_permission(self, request, obj=None):
 has = super(MyUserAdmin, self).has_change_permission(request, obj)
 if obj and not request.user.is_superuser:
 if obj != request.user:
 if obj.is_superuser or obj.groups.exists() or
 obj.user_permissions.exists():
 has = False

 return has
 }}}

 Indeed, while this depends on how particular project manages users and
 their perms, I still humbly think there's an idea in it worth spreading.

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


Re: [Django] #23426: migrations.RunSQL's function signature implies it won't do any parameter substitution

2014-09-26 Thread Django
#23426: migrations.RunSQL's function signature implies it won't do any parameter
substitution
-+-
 Reporter:  ris  |Owner:
 Type:   |  Markush2010
  Cleanup/optimization   |   Status:  closed
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  migrations sql   | Triage Stage:  Accepted
  runsql params escape   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by Markush2010):

 Thanks for the comment. I removed the 1-tuple support. Waiting for Jenkins
 to test.

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


Re: [Django] #23543: Documentation how to test custom management command missing

2014-09-26 Thread Django
#23543: Documentation how to test custom management command missing
--+
 Reporter:  wittwerch |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.7
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Lagovas):

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


Re: [Django] #23543: Documentation how to test custom management command missing

2014-09-26 Thread Django
#23543: Documentation how to test custom management command missing
--+
 Reporter:  wittwerch |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.7
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Lagovas):

 You can test commands like any other function. Just


 {{{
 from django.core.management import call_command
 class SomeTest(TestCase):
 def test_command(self):
 call_command('your_command', *args, **kwargs)
 self.assertTrue(somethingDone())
 }}}


 and test result or behavior of your command. I think no sense for writing
 how to test all functions or methods from docs.

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


Re: [Django] #23560: MigrationWriter prefixes builtin types with __builtins__.

2014-09-26 Thread Django
#23560: MigrationWriter prefixes builtin types with __builtins__.
+-
 Reporter:  loic|Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  1.7
 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 timgraham):

 * version:  master => 1.7
 * stage:  Unreviewed => 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/062.0cfd8d4c7f26c58d39c2e0e99bc40fb0%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #23560: MigrationWriter prefixes builtin types with __builtins__.

2014-09-26 Thread Django
#23560: MigrationWriter prefixes builtin types with __builtins__.
+--
 Reporter:  loic|Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  master
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Changes (by loic):

 * has_patch:  0 => 1


Comment:

 PR https://github.com/django/django/pull/3281.

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


Re: [Django] #23460: Allow a literal `%s` to be passed through extra select

2014-09-26 Thread Django
#23460: Allow a literal `%s` to be passed through extra select
-+-
 Reporter:  mattrobenolt |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  queryset |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by timgraham):

 * needs_better_patch:  1 => 0


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

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


[Django] #23560: MigrationWriter prefixes builtin types with __builtins__.

2014-09-26 Thread Django
#23560: MigrationWriter prefixes builtin types with __builtins__.
--+
   Reporter:  loic|  Owner:  nobody
   Type:  Bug | Status:  new
  Component:  Migrations  |Version:  master
   Severity:  Normal  |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+
 When MigrationWriter finds a builtin type (i.e. not a builtin type
 instance) it serializes as follows:

 {{{
 import __builtin__
 __builtin__.dict
 }}}

 `__builtin__` isn't needed nor pretty, but worse it was renamed `builtins`
 in PY3 so migrations written in PY2 wouldn't work in PY3 and vice versa.

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


Re: [Django] #23555: QuerySet.first suppresses internal IndexError exceptions

2014-09-26 Thread Django
#23555: QuerySet.first suppresses internal IndexError exceptions
-+-
 Reporter:  artemrizhov  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:  QuerySet first   |  Unreviewed
  IndexError |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by artemrizhov):

 Sorry for my English, my explanation is probably not too clear. But if you
 see the pull request and the test that I've added to the branch, you
 probably will understand the problem. There is also a lot of comments on
 the test case code.

 Let me try to explain one more time.

 '''You are right.''' There is no reason why `__getitem__` shouldn't raise
 an `IndexError`. This is correct and normal behaviour. I'm talking about
 another case.

 '''`IndexError` from `QuerySet.__getitem__` is not always what you think,
 because it may be produced by nested calls, not by this method itself.'''

 Let's remember that QuerySet is a lazy request to DB. So when you write
 `qs[i]`, it makes actual query to the DB, retrieves a list of items and
 returns i-th element. `IndexError` maybe raised by some another method
 that is called from `__getitem__`, especially by `__iter__` and any nested
 call. For example by the iterator implementation, or by database adaptor.
 For example if internal list of db connections is empty, but the adaptor
 tries to get one from the list. Such abnormal situation should not be
 treated as "no such element in the queryset". `IndexError` in nested calls
 may mean anything, but probably not what you mean. If any nested call
 produces `IndexError`, the caller (`_getitem__`, `__iter__` and another
 nested methods) is responsible to handle this right way, because it is
 aware of the source of error. Your outer code can't handle such error just
 because it's not aware of the source.

 Hope this is clear now. If you are in doubt, please review the test in the
 pull request.

 So what is the problem?

 You can use try/except if you access i-th element of a list. Because you
 are sure `IndexError` means "no such element" in this certain list. But
 you should not rely on try/except for `IndexError` when accessing i-th
 element of QuerySet. You should not. But the current implementation of
 `first()` method does this. It uses "standard" try/except in the case
 where it is not safe:

 
https://github.com/django/django/blob/e9103402c0fa873aea58a6a11dba510cd308cb84/django/db/models/query.py#L515
 {{{
 try:
 return qs[0]
 except IndexError:
 return None
 }}}

 This would work if `qs` as plain `list`. But `qs` is `QuerySet` with all
 it's magic. It's `__getitem__` is not simple and rely on successful
 execution of a lot of nested calls. If any of those calls produces
 unexpected exception (either `IndexError` or another one), this should not
 be treated as "empty query set", and should not be suppressed. The outer
 code should receive this exception as a singal that something goes wrong.
 But `first()` method suppresses such errors.

 Hope you understand the problem now. If no then please review the pull
 request, especially my tests, and the comments on the PR.

 Thanks for the attention.

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

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


Re: [Django] #23559: Staff (not superusers) should not manage perms of Users

2014-09-26 Thread Django
#23559: Staff (not superusers) should not manage perms of Users
---+
 Reporter:  Tuttle |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Documentation  |  Version:
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  1
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+
Changes (by loic):

 * needs_better_patch:   => 0
 * component:  contrib.admin => Documentation
 * needs_tests:   => 0
 * easy:  0 => 1
 * needs_docs:   => 1
 * stage:  Unreviewed => Accepted


Comment:

 What about `password` and `email` both of which could be used to gain
 access to a superuser account; in my opinion this use-case is better
 served by a custom `UserAdmin` in your project where you whitelist the few
 fields that should be editable.

 I tentatively accept this as a documentation issue, we could warn about
 the consequences of giving edit permissions to the user model.

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


Re: [Django] #23556: Allow migrations to depend on a migration only part of a squashed migration

2014-09-26 Thread Django
#23556: Allow migrations to depend on a migration only part of a squashed 
migration
-+-
 Reporter:  Markush2010  |Owner:
 Type:   |  Markush2010
  Cleanup/optimization   |   Status:  new
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Markush2010):

 I updated my tests and slightly changed the behavior of the migration
 loader to check for if a migration could have potentially be replaced by a
 squash migration, but which wasn't used due e.g. partially be applied.
 E.g. if 3, 4 and 5 are squashed into 3_5 and a database has 3 applied, but
 not 4 and 5, 3_5 cannot be used. In this case removing 3 or 4 from the
 file system is not possible until 5 is applied on every instance.

 Pull request: https://github.com/django/django/pull/3280

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

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


[Django] #23559: Staff (not superusers) should not manage perms of Users

2014-09-26 Thread Django
#23559: Staff (not superusers) should not manage perms of Users
---+
 Reporter:  Tuttle |  Owner:  nobody
 Type:  New feature| Status:  new
Component:  contrib.admin  |Version:
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 In our project we want to let some colleagues to see and modify several
 tables including the Users table. Nevertheless I don't want the colleague
 to be able to elevate his or anybody else's privileges.

 May I submit little change of {{{UserAdmin}}} similar to the following for
 consideration?

 {{{#!python
 def get_readonly_fields(self, request, obj=None):
 rof = super(UserAdmin, self).get_readonly_fields(request, obj)
 if not request.user.is_superuser:
 rof += ('is_staff', 'is_superuser', 'groups', 'user_permissions')
 return rof
 }}}

 I rather doubt there is a use-case for current behaviour: Once the access
 to Users table is given, one can do anything.

 In case the behavior change will get rejected, how about to add it as a
 tip in the doc?

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

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


Re: [Django] #23555: QuerySet.first suppresses internal IndexError exceptions

2014-09-26 Thread Django
#23555: QuerySet.first suppresses internal IndexError exceptions
-+-
 Reporter:  artemrizhov  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:  QuerySet first   |  Unreviewed
  IndexError |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by tchaumeny):

 I don't think there is a problem with the current implementation. There is
 no reason why `QuerySet.__getitem__()` shouldn't raise an `IndexError` as
 it aims to provide a similar interface to a list.

 Note that this is a common thing in Python to raise such an IndexError in
 similar situation, see those examples in cPython itself :
 
https://github.com/python/cpython/blob/c7688b44387d116522ff53c0927169db45969f0e/Lib/xml/dom/pulldom.py#L219
 
https://github.com/python/cpython/blob/c7688b44387d116522ff53c0927169db45969f0e/Lib/ipaddress.py#L666

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

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


Re: [Django] #23556: Allow migrations to depend on a migration only part of a squashed migration

2014-09-26 Thread Django
#23556: Allow migrations to depend on a migration only part of a squashed 
migration
-+-
 Reporter:  Markush2010  |Owner:
 Type:   |  Markush2010
  Cleanup/optimization   |   Status:  new
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Markush2010):

 * type:  Bug => Cleanup/optimization


Comment:

 I looked into the issue a bit deeper and found my tests to be faulty. I'm
 working on a patch to make the error message more useful, though.

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

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


[django/django] d1ca70: Factorized schema_editor() at BaseDatabaseWrapper ...

2014-09-26 Thread GitHub
  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: d1ca70110f49f0be90206c8da516ac16aebc8c75
  
https://github.com/django/django/commit/d1ca70110f49f0be90206c8da516ac16aebc8c75
  Author: Claude Paroz 
  Date:   2014-09-26 (Fri, 26 Sep 2014)

  Changed paths:
M django/contrib/gis/db/backends/mysql/base.py
M django/contrib/gis/db/backends/oracle/base.py
M django/contrib/gis/db/backends/postgis/base.py
M django/contrib/gis/db/backends/spatialite/base.py
M django/db/backends/__init__.py
M django/db/backends/mysql/base.py
M django/db/backends/oracle/base.py
M django/db/backends/postgresql_psycopg2/base.py
M django/db/backends/sqlite3/base.py

  Log Message:
  ---
  Factorized schema_editor() at BaseDatabaseWrapper level


-- 
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/54250cf5b0b69_11b03fa4058d52a075633%40hookshot-fe3-cp1-prd.iad.github.net.mail.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #22738: Schema migration: test_add_field_temp_default_boolean

2014-09-26 Thread Django
#22738: Schema migration: test_add_field_temp_default_boolean
--+
 Reporter:  maxi  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Migrations|  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by claudep):

 Shai, I'll try to outperform your expectations :-)
 https://github.com/django/django/pull/3278

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