date:20160907

Re: [Django] #27193: ORDER BY clause not included in subqueries using select_for_update()

2016-09-07 Thread Django

#27193: ORDER BY clause not included in subqueries using select_for_update()
-+-
 Reporter:  sqwishy  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 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 shaib):

 * cc: shaib (added)
 * component:  Uncategorized => Database layer (models, ORM)
 * type:  Uncategorized => New feature
 * stage:  Unreviewed => Accepted


Comment:

 That said, 1.9 and even 1.10 are past the phase where this can be put in
 them. Accepting tentatively, assuming it can be reproduced in master (I
 don't have time to check right now)

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

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

Re: [Django] #27193: ORDER BY clause not included in subqueries using select_for_update()

2016-09-07 Thread Django

#27193: ORDER BY clause not included in subqueries using select_for_update()
---+--
 Reporter:  sqwishy|Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  1.9
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by shaib):

 Well, I don't quite see it in the doc you linked, but it's mentioned in
 [https://www.postgresql.org/message-
 id/freemail.20070030161126.43...@fm10.freemail.hu this thread] and your
 code example is convincing. I stand corrected.

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

Re: [Django] #27195: Avoid unnecessary DROP DEFAULT when adding a NULLable column.

2016-09-07 Thread Django

#27195: Avoid unnecessary DROP DEFAULT when adding a NULLable column.
-+-
 Reporter:  charettes|Owner:  charettes
 Type:   |   Status:  new
  Cleanup/optimization   |
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 charettes):

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

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

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

[Django] #27195: Avoid unnecessary DROP DEFAULT when adding a NULLable column.

2016-09-07 Thread Django

#27195: Avoid unnecessary DROP DEFAULT when adding a NULLable column.
-+-
   Reporter:  charettes  |  Owner:  charettes
   Type: | Status:  new
  Cleanup/optimization   |
  Component: |Version:  master
  Migrations |
   Severity:  Normal |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 The schema editor shouldn't issue an `ALTER TABLE foo ALTER COLUMN bar
 DROP DEFAULT` query if a `NULL` able column is 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/052.1730a139b237a61d225ea97b95326f08%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26956: Allow additional safe hosts for "next" parameter during login

2016-09-07 Thread Django

#26956: Allow additional safe hosts for "next" parameter during login
-+-
 Reporter:  jdufresne|Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  contrib.auth |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Jon Dufresne ):

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


Comment:

 In [changeset:"66e1ebbffc2742deb9b2051c6de89c0ac58fcc89" 66e1ebbf]:
 {{{
 #!CommitTicketReference repository=""
 revision="66e1ebbffc2742deb9b2051c6de89c0ac58fcc89"
 Fixed #26956 -- Added success_url_allowed_hosts to LoginView and
 LogoutView.

 Allows specifying additional hosts to redirect after login and log out.
 }}}

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

Re: [Django] #26956: Allow additional safe hosts for "next" parameter during login

2016-09-07 Thread Django

#26956: Allow additional safe hosts for "next" parameter during login
-+-
 Reporter:  jdufresne|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  contrib.auth |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Jon Dufresne ):

 In [changeset:"f227b8d15d9d0e0c50eb6459cf4556bccc3fae53" f227b8d]:
 {{{
 #!CommitTicketReference repository=""
 revision="f227b8d15d9d0e0c50eb6459cf4556bccc3fae53"
 Refs #26956 -- Allowed is_safe_url() to validate against multiple hosts
 }}}

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

Re: [Django] #27193: ORDER BY clause not included in subqueries using select_for_update()

2016-09-07 Thread Django

#27193: ORDER BY clause not included in subqueries using select_for_update()
---+--
 Reporter:  sqwishy|Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  1.9
 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 sqwishy):

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


Comment:

 The documentation at the following link may suggest that rows are locked
 while a query is running rather than all at once atomically; see
 particularly the second paragraph under "13.2.1. Read Committed Isolation
 Level" https://www.postgresql.org/docs/current/static/transaction-iso.html
 #XACT-READ-COMMITTED

 This is a bit of code where adding the order by seems to prevent
 deadlocks.

 {{{#!python
 from django.db import transaction
 from django.contrib.auth.models import Group
 from django.db.models import F

 def setup():
 for i in range(20):
 Group.objects.get_or_create(name='test_27193_%i' % i)

 def test():
 for _ in range(20):
 with transaction.atomic():
 Group.objects.filter(
 id__in=Group.objects.filter(name__startswith='test_27193').select_for_update()
 ).update(name=F('name'))
 #Group.objects.filter(
 #
 
id__in=Group.objects.filter(name__startswith='test_27193').select_for_update().order_by('id')[1:]
 #).update(name=F('name'))

 setup()
 test()
 }}}

 I have that saved to a file aptly named `script.py` and run it 20 times at
 once (I'm sure there is a less ugly way to do this):

 {{{
 seq 20 | parallel --ungroup -j 20 "echo {}; ./manage.py shell --plain <
 script.py"
 }}}

 Doing this with the script as shown, exceptions are raised in python about
 deadlocks and PostgreSQL logs about it. If you comment out that first
 query and uncomment the second one everything runs fine. The slice there
 is just to convince django not to reset the order-by value in the
 queryset.

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

Re: [Django] #27194: Cannot access admin page by following tutorial

2016-09-07 Thread Django

#27194: Cannot access admin page by following tutorial
---+--
 Reporter:  keksbaecker|Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Uncategorized  |  Version:  1.10
 Severity:  Normal |   Resolution:  invalid
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by timgraham):

 * status:  new => closed
 * needs_better_patch:   => 0
 * resolution:   => invalid
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 I guess you might have created your project with Django 1.10 but are using
 Django 1.9 or earlier. Please see TicketClosingReasons/UseSupportChannels
 for ways to get help.

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

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

[Django] #27194: Cannot access admin page by following tutorial

2016-09-07 Thread Django

#27194: Cannot access admin page by following tutorial
---+
 Reporter:  keksbaecker|  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Uncategorized  |Version:  1.10
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 If you follow the tutorial up to the
 [https://docs.djangoproject.com/en/1.10/intro/tutorial02/ second part] and
 try to access the admin panel, then django raises an AttributeError
 because //'WSGIRequest' object has no attribute 'user'//.

 I have not made any changes to the order of MIDDLEWARE or anything else
 that wasn't mentioned in the tutorial in the settings.py and changing the
 name from MIDDLEWARE to MIDDLEWARE_CLASSES solves the problem.

 It seems like the default installation is somehow broken.

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

Re: [Django] #27193: ORDER BY clause not included in subqueries using select_for_update()

2016-09-07 Thread Django

#27193: ORDER BY clause not included in subqueries using select_for_update()
---+--
Reporter: sqwishy|Owner: nobody
Type: Uncategorized | Status: closed
Component: Uncategorized | Version: 1.9
Severity: Normal | Resolution: needsinfo
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 |UI/UX: 0
---+--
Changes (by shaib):

* status: new => closed
* needs_better_patch: => 0
* resolution: => needsinfo
* needs_tests: => 0
* needs_docs: => 0

Comment:

Hi,

You said:

> My use case is to lock rows in a particular order with the goal of
preventing deadlocks.

Can you please point to some documentation, or example code with
execution, that shows this idea may work? As far as I know, the locking is
atomic -- it is done for all rows matching the criteria together, and thus
the order-by clause on the inner select is indeed meaningless and can be
dropped.

If and when you show this, please re-open the ticket.

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

Re: [Django] #27143: SearchQuery is not combinable using more than one `&` or `|` operators

2016-09-07 Thread Django

#27143: SearchQuery is not combinable using more than one `&` or `|` operators
-+-
 Reporter:  hixi |Owner:  Tim
 |  Graham 
 Type:  Bug  |   Status:  closed
Component:  contrib.postgres |  Version:  1.10
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  Search   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"1f3c66fe9fd8c8e980ecda0a9917319f35ad6676" 1f3c66fe]:
 {{{
 #!CommitTicketReference repository=""
 revision="1f3c66fe9fd8c8e980ecda0a9917319f35ad6676"
 [1.10.x] Fixed #27143 -- Allowed combining SearchQuery with more than one
 & or | operators.

 Backport of 978a00e39fee25cfa99065285b0de88366710fad 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.51d0576186071e3344f9b08ca80d3f6b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26170: ModelAdmin add/change/delete views always run transaction on default database

2016-09-07 Thread Django

#26170: ModelAdmin add/change/delete views always run transaction on default
database
--+
 Reporter:  juntatalor|Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.admin |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  admin multi database  | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  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/068.cb3ae5e185febc0c949053b60b8a8b83%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27143: SearchQuery is not combinable using more than one `&` or `|` operators

2016-09-07 Thread Django

#27143: SearchQuery is not combinable using more than one `&` or `|` operators
-+-
 Reporter:  hixi |Owner:  Tim
 |  Graham 
 Type:  Bug  |   Status:  closed
Component:  contrib.postgres |  Version:  1.10
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  Search   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

 * owner:   => Tim Graham 
 * status:  new => closed
 * resolution:   => fixed


Comment:

 In [changeset:"978a00e39fee25cfa99065285b0de88366710fad" 978a00e]:
 {{{
 #!CommitTicketReference repository=""
 revision="978a00e39fee25cfa99065285b0de88366710fad"
 Fixed #27143 -- Allowed combining SearchQuery with more than one & or |
 operators.
 }}}

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

Re: [Django] #27174: Explain where 'polls.apps.PollsConfig' comes from in tutorial 2

2016-09-07 Thread Django

#27174: Explain where 'polls.apps.PollsConfig' comes from in tutorial 2
-+-
 Reporter:  hckrtst  |Owner:  ankur0493
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  1.10
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  docs | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by timgraham):

 We don't update older versions of the docs except for critical mistakes.

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

[Django] #27193: ORDER BY clause not included in subqueries using select_for_update()

2016-09-07 Thread Django

#27193: ORDER BY clause not included in subqueries using select_for_update()
---+
 Reporter:  sqwishy|  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  1.9
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 This was tested using Django 1.9.5. I believe the code below fails to
 generate the correct SQL. I explicitly set an ordering in the subquery but
 it is not expressed in the generated SQL. This alters the behaviour of the
 SELECT statement when the FOR UPDATE clause is used. My use case is to
 lock rows in a particular order with the goal of preventing deadlocks.

 Example code:
 {{{
 with transaction.atomic():
 
print(User.objects.filter(id__in=User.objects.order_by('id').select_for_update()))
 }}}

 PostgreSQL logs:
 {{{
 2016-09-08 02:59:43 ACWST [30398-20] testsystem@testsystem LOG:
 statement: BEGIN
 2016-09-08 02:59:43 ACWST [30398-21] testsystem@testsystem LOG:
 statement: SELECT "testapp_user"."id", "testapp_user"."password", ... FROM
 "testapp_user" WHERE "testapp_user"."id" IN (SELECT "testapp_user"."id"
 FROM "testapp_user" FOR UPDATE) LIMIT 21
 2016-09-08 02:59:43 ACWST [30398-22] testsystem@testsystem LOG:
 statement: COMMIT
 }}}

 It looks like the order_by is being cleared on the queryset object here
 
https://github.com/django/django/blob/master/django/db/models/sql/compiler.py#L476

 I can verify this as it looks like ORDER BY does show up when I include
 distinct() in the subquery - which isn't a suitable workaround as DISTINCT
 is not compatible with FOR UPDATE - and by slicing the subquery as to set
 an offset or a limit.

 For now, an acceptable workaround seems to make the SELECT FOR UPDATE in a
 separate query instead of a subquery. That at least seems to accomplish
 the goal I am trying to achieve.

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

Re: [Django] #27174: Explain where 'polls.apps.PollsConfig' comes from in tutorial 2

2016-09-07 Thread Django

#27174: Explain where 'polls.apps.PollsConfig' comes from in tutorial 2
-+-
 Reporter:  hckrtst  |Owner:  ankur0493
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  1.10
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  docs | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by ankur0493):

 Hi Tim,

 This also needs to be backported for 1.9.x

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

Re: [Django] #27179: Bug: error when trying to filter using regex/iregex on a key in a django.contrib.postgres.fields.JSONField

2016-09-07 Thread Django

#27179: Bug: error when trying to filter using regex/iregex on a key in a
django.contrib.postgres.fields.JSONField
--+-
 Reporter:  jrhouston |Owner:
 Type:  Bug   |   Status:  closed
Component:  contrib.postgres  |  Version:  1.10
 Severity:  Normal|   Resolution:  duplicate
 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 charettes):

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


Comment:

 I think we can close as duplicate is this case. The proposed tests don't
 add much value to the suite.

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

Re: [Django] #27174: Explain where 'polls.apps.PollsConfig' comes from in tutorial 2

2016-09-07 Thread Django

#27174: Explain where 'polls.apps.PollsConfig' comes from in tutorial 2
-+-
 Reporter:  hckrtst  |Owner:  ankur0493
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  1.10
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  docs | 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:   => fixed


Comment:

 In [changeset:"40d501147176352b694ec8b67b09127b20193ad2" 40d50114]:
 {{{
 #!CommitTicketReference repository=""
 revision="40d501147176352b694ec8b67b09127b20193ad2"
 Fixed #27174 -- Explained where PollsConfig comes from in tutorial 2.
 }}}

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

Re: [Django] #27174: Explain where 'polls.apps.PollsConfig' comes from in tutorial 2

2016-09-07 Thread Django

#27174: Explain where 'polls.apps.PollsConfig' comes from in tutorial 2
-+-
 Reporter:  hckrtst  |Owner:  ankur0493
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  1.10
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  docs | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"9a03d30d94a6924ffdcdcc58dce267485ca393a2" 9a03d30d]:
 {{{
 #!CommitTicketReference repository=""
 revision="9a03d30d94a6924ffdcdcc58dce267485ca393a2"
 [1.10.x] Fixed #27174 -- Explained where PollsConfig comes from in
 tutorial 2.

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

Re: [Django] #27191: Generation of error reports fails if request.GET, POST, FILES or COOKIES contains key 'items'

2016-09-07 Thread Django

#27191: Generation of error reports fails if request.GET, POST, FILES or COOKIES
contains key 'items'
-+
 Reporter:  anatolyrr|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Error reporting  |  Version:  1.10
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"7b6dccc82fa5b03cf431742c0655e5ac954e228e" 7b6dccc8]:
 {{{
 #!CommitTicketReference repository=""
 revision="7b6dccc82fa5b03cf431742c0655e5ac954e228e"
 Fixed #27191 -- Fixed debug view crash for requests with 'items' in
 GET/POST/COOKIES/FILES.
 }}}

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

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

Re: [Django] #26908: jsonfieldkeyisnull lookup crashes on PostgreSQL 9.4

2016-09-07 Thread Django

#26908: jsonfield__key__isnull lookup crashes on PostgreSQL 9.4
--+
 Reporter:  sigfrido  |Owner:  PREM1980
 Type:  Bug   |   Status:  closed
Component:  contrib.postgres  |  Version:  1.9
 Severity:  Normal|   Resolution:  fixed
 Keywords:  jsonb,postgresql  | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by GitHub ):

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


Comment:

 In [changeset:"2eb7d6e6d41480f21305fc6abe2f1a443491ddec" 2eb7d6e6]:
 {{{
 #!CommitTicketReference repository=""
 revision="2eb7d6e6d41480f21305fc6abe2f1a443491ddec"
 Fixed #26908 -- Fixed crash with jsonfield__key__isnull lookup.
 }}}

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

Re: [Django] #27170: Make database backend init() methods friendlier to subclassing

2016-09-07 Thread Django

#27170: Make database backend __init__() methods friendlier to subclassing
-+-
 Reporter:  cjerdonek|Owner:  cjerdonek
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by 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/067.e801dfe27ec9081c1fd1e502b9c089fa%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26956: Allow additional safe hosts for "next" parameter during login

2016-09-07 Thread Django

#26956: Allow additional safe hosts for "next" parameter during login
-+-
 Reporter:  jdufresne|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  contrib.auth |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by 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/067.8a117ad948b695897b4036b76f78b135%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27179: Bug: error when trying to filter using regex/iregex on a key in a django.contrib.postgres.fields.JSONField

2016-09-07 Thread Django

#27179: Bug: error when trying to filter using regex/iregex on a key in a
django.contrib.postgres.fields.JSONField
--+
 Reporter:  jrhouston |Owner:
 Type:  Bug   |   Status:  new
Component:  contrib.postgres  |  Version:  1.10
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+

Comment (by timgraham):

 A related ticket is #26908. My [https://github.com/django/django/pull/6929
 PR] for that ticket also adds the parentheses.

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

Re: [Django] #27180: Check for sql_mode fails during migration with special database connections

2016-09-07 Thread Django

#27180: Check for sql_mode fails during migration with special database 
connections
-+-
 Reporter:  gerricom |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Release blocker  |   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 Tim Graham ):

 In [changeset:"baa1790b4ddd5e7836170743aa058c834b7b2040" baa1790b]:
 {{{
 #!CommitTicketReference repository=""
 revision="baa1790b4ddd5e7836170743aa058c834b7b2040"
 [1.10.x] Fixed #27180 -- Fixed a crash in MySQL checks where SELECT
 @@sql_mode doesn't return a result.

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

Re: [Django] #27180: Check for sql_mode fails during migration with special database connections

2016-09-07 Thread Django

#27180: Check for sql_mode fails during migration with special database 
connections
-+-
 Reporter:  gerricom |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Release blocker  |   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 Tim Graham ):

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


Comment:

 In [changeset:"2b64ff68cc375b5688174b4087bf44be9edd2558" 2b64ff68]:
 {{{
 #!CommitTicketReference repository=""
 revision="2b64ff68cc375b5688174b4087bf44be9edd2558"
 Fixed #27180 -- Fixed a crash in MySQL checks where SELECT @@sql_mode
 doesn't return a 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/066.165d3b0b2068e3ae87143284b9c3d545%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27178: ImageField when default provided in model, it's impossible to change the value.

2016-09-07 Thread Django

#27178: ImageField when default provided in model, it's impossible to change the
value.
-+-
 Reporter:  phonkee  |Owner:  timgraham
 Type:  Bug  |   Status:  assigned
Component:  Forms|  Version:  1.10
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * has_patch:  0 => 1


Comment:

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

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

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

Re: [Django] #27186: Cannot change DateTimeField with default via Admin since Django 1.10.1

2016-09-07 Thread Django

#27186: Cannot change DateTimeField with default via Admin since Django 1.10.1
-+-
 Reporter:  michael-k|Owner:  timgraham
 Type:  Bug  |   Status:  assigned
Component:  Forms|  Version:  1.10
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * has_patch:  0 => 1


Comment:

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

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

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

Re: [Django] #27192: Allow pluralizing admin URLs

2016-09-07 Thread Django

#27192: Allow pluralizing admin URLs
---+--
 Reporter:  AlJohri|Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  contrib.admin  |  Version:  1.10
 Severity:  Normal |   Resolution:  wontfix
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by aaugustin):

 I'm not convinced it's worth breaking every admin URL — lots of people
 bookmark these — just for this reason.

 Also using the singular for the changelist view means that if you're on
 the changeform view, you can chop off the number and get to the changelist
 view. Some people do that.

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

Re: [Django] #27192: Allow pluralizing admin URLs (was: [Feature Request] Pluralize Admin Urls)

2016-09-07 Thread Django

#27192: Allow pluralizing admin URLs
---+--
 Reporter:  AlJohri|Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  contrib.admin  |  Version:  1.10
 Severity:  Normal |   Resolution:  wontfix
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by timgraham):

 * status:  new => closed
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0
 * resolution:   => wontfix


Comment:

 I don't see much advantage to the additional complexity. The admin doesn't
 need perfect URLs, in my opinion. Feel free to raise the idea on the
 DevelopersMailingList to get other opinions. You could also
 [http://stackoverflow.com/questions/5680405/override-django-admin-urls-
 for-specific-model customize these URLs] in your own `AdminSite`.

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

Re: [Django] #27191: Generation of error reports fails if request.GET, POST, FILES or COOKIES contains key 'items'

2016-09-07 Thread Django

#27191: Generation of error reports fails if request.GET, POST, FILES or COOKIES
contains key 'items'
-+
 Reporter:  anatolyrr|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Error reporting  |  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by timgraham):

 * has_patch:  0 => 1
 * component:  Uncategorized => Error reporting
 * 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.ba0ae60536dfc1f00db6c8fe74c1abfb%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27183: JSONField improperly escaped in admin interface during normal usage

2016-09-07 Thread Django

#27183: JSONField improperly escaped in admin interface during normal usage
--+--
 Reporter:  sjuxax|Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  contrib.postgres  |  Version:  1.10
 Severity:  Normal|   Resolution:  needsinfo
 Keywords:| Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by timgraham):

 * status:  new => closed
 * resolution:   => needsinfo
 * component:  Uncategorized => contrib.postgres
 * type:  Uncategorized => Bug


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

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

Re: [Django] #27190: Internet explorer 9 fails to load Roboto-Regular.woff font

2016-09-07 Thread Django

#27190: Internet explorer 9 fails to load Roboto-Regular.woff font
-+-
 Reporter:  pcompassion  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  contrib.admin|  Version:  1.10
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * status:  new => closed
 * resolution:   => wontfix
 * component:  Uncategorized => contrib.admin
 * needs_tests:   => 0
 * needs_better_patch:   => 0
 * needs_docs:   => 0
 * type:  Uncategorized => Cleanup/optimization


Comment:

 I don't think there's much value in fixing this since a fix wouldn't ship
 until Django 1.11 in April 2017. According to
 [https://support.microsoft.com/en-us/lifecycle?forceorigin=esmc#gp
 /Microsoft-Internet-Explorer Microsoft Support Lifecycle], support for
 Windows Vista (the only desktop version to support IE9) ends in April 11,
 2017.

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

Re: [Django] #27180: Check for sql_mode fails during migration with special database connections

2016-09-07 Thread Django

#27180: Check for sql_mode fails during migration with special database 
connections
-+-
 Reporter:  gerricom |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by gerricom):

 [https://github.com/django/django/pull/7216 Done]

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

[Django] #27192: [Feature Request] Pluralize Admin Urls

2016-09-07 Thread Django

#27192: [Feature Request] Pluralize Admin Urls
---+
Reporter: AlJohri| Owner: nobody
Type: New feature| Status: new
Component: contrib.admin |Version: 1.10
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
---+
It seems like some of the official documentation suggests using plural
model names in the url as a convention such as `/articles/1/` but the
admin uses singular model names and this option is not configurable. It
seems like its been this way since for a very long time browsing through
the commit history (pre-2008).

I propose allowing the user to use the model's `default_related_name`
(plural of the model name) as opposed to the `model._meta.model_name` that
is being used now in a configurable option.

This is the line that currently sets the url in the admin:

https://github.com/django/django/blob/255fb992845e987ef36e3d721a77747a0b2df620/django/contrib/admin/sites.py#L251

This doesn't seem like a difficult change and allows for more consistent
urls.

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

Re: [Django] #27191: Generation of error reports fails if request.GET, POST, FILES or COOKIES contains key 'items'

2016-09-07 Thread Django

#27191: Generation of error reports fails if request.GET, POST, FILES or COOKIES
contains key 'items'
---+--
 Reporter:  anatolyrr  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Uncategorized  |  Version:  1.10
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by anatolyrr):

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


Comment:

 [https://github.com/django/django/pull/7215 PR] with tests and the fix.

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

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

2016-09-07 Thread Django

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

Old description:

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

New description:

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

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

Re: [Django] #4304: a second dev. web server does not report an err if bound to the same port

2016-09-07 Thread Django

#4304: a second dev. web server does not report an err if bound to the same port
-+-
 Reporter:  rogerpack2005@…  |Owner:  adrian
 Type:  Uncategorized|   Status:  closed
Component:  Core (Other) |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by claudep):

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


Comment:

 Please do not reopen such old bug reports. Create a new one (where you can
 mention this one).

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

Re: [Django] #27172: Close cursor in custom SQL example

2016-09-07 Thread Django

#27172: Close cursor in custom SQL example
-+-
 Reporter:  cjerdonek|Owner:  cjerdonek
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Claude Paroz ):

 In [changeset:"d923733234afd20304db763913020170709ef088" d923733]:
 {{{
 #!CommitTicketReference repository=""
 revision="d923733234afd20304db763913020170709ef088"
 [1.10.x] Fixed #27172 -- Closed database cursor explicitly in two doc
 examples

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

Re: [Django] #27172: Close cursor in custom SQL example

2016-09-07 Thread Django

#27172: Close cursor in custom SQL example
-+-
 Reporter:  cjerdonek|Owner:  cjerdonek
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Claude Paroz ):

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


Comment:

 In [changeset:"ccf7adb064a70eb1b1ec5857f1dd54988f5c983c" ccf7adb]:
 {{{
 #!CommitTicketReference repository=""
 revision="ccf7adb064a70eb1b1ec5857f1dd54988f5c983c"
 Fixed #27172 -- Closed database cursor explicitly in two doc examples
 }}}

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

Re: [Django] #27180: Check for sql_mode fails during migration with special database connections

2016-09-07 Thread Django

#27180: Check for sql_mode fails during migration with special database 
connections
-+-
 Reporter:  gerricom |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by claudep):

 @gerricom: thanks for the patch, could you provide it as a pull request on
 Github?

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

[Django] #27191: Generation of error reports fails if request.GET, POST, FILES or COOKIES contains key 'items'

2016-09-07 Thread Django

#27191: Generation of error reports fails if request.GET, POST, FILES or COOKIES
contains key 'items'
---+
 Reporter:  anatolyrr  |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Uncategorized  |Version:  1.10
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 When `DEBUG` is True, if the `request.GET` or another QueryDict contains
 key named `'items'` and a view raises an exception, the generation of
 error report fails. Due to a difference in
 `django.views.debug.TECHNICAL_500_TEMPLATE` and
 `TECHNICAL_500_TEXT_TEMPLATE`, the actual behaviour varies.

  Normal requests 

 For normal requests the output ''is'' produced, but the query variables
 are dumped in a wrong way. For example, for request 'GET
 /test/?items=Oops' the dump will contain a table:

 ** GET **
 || Variable || Value ||
 || O || `''` ||
 || o || `''` ||
 || p || `''` ||
 || s || `''` ||

 This is because `TECHNICAL_500_TEMPLATE` iterates QueryDict this way:

 {{{
 {% for var in filtered_POST.items %} ... {{ var.0 }} ... {{ var.1 }} ...
 }}}


  Ajax requests 

 For ajax requests the plain text error report generation itself raises an
 exception:

 {{{
 ValueError: Need 2 values to unpack in for loop; got 1.
 }}}

 The console gets flooded with the tracedumps and the upstream eventually
 receives a `502 Bad Gateway`.

 This is because `TECHNICAL_500_TEXT_TEMPLATE` iterates QueryDict this way:

 {{{
 {% for k, v in request.GET.items %} ... {{ k }} ... {{ v }} ...
 }}}

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

[Django] #27190: Internet explorer 9 fails to load Roboto-Regular.woff font

2016-09-07 Thread Django

#27190: Internet explorer 9 fails to load Roboto-Regular.woff font
---+
 Reporter:  pcompassion|  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  1.10
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 Django admin uses Roboto fonts.
 and it fails to load in IE9.

 http://stackoverflow.com/questions/16710972/css-font-face-not-working-in-
 ie9

 django/contrib/admin/static/admin/css/fonts.css has the following lines

 {{{

  @font-face {
  font-family: 'Roboto';
  src: url('../fonts/Roboto-Regular-webfont.woff');
  font-weight: 400;
  font-style: normal;
  }

 }}}

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

Re: [Django] #22657: Can't disconnect signal if connected using @receiver tag

2016-09-07 Thread Django

#22657: Can't disconnect signal if connected using @receiver tag
-+-
 Reporter:  michalsicker@…   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.6
  (models, ORM)  |   Resolution:
 Severity:  Normal   |  worksforme
 Keywords:  @receiver signal | Triage Stage:
  disconnect |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by aldnav):

 Replying to [comment:3 anonymous]:
 Might be good to shed some light in this 2 year old issue.

 @Mike
   result:
   test fails from different reasons.

 One of the possible causes this signal-handler-dependent test fails is
 that the '''TestCase''' that issued __''disconnect''__ did not
 re__''connect''__ the muted signal handler and TestCases that follow fail.
 There are a couple of things that you can do to justify/correct other
 independent test cases: (cleaner/recommended) __reconnect__ on
 __tearDown__; or (works but may have side effects to other tests)
 __reload__ the signal handler from the other test cases; or __import__ the
 signal handler from the other test case.

 Say we have too models '''Foo''' and '''Bar'''. We hook '''pre_save'''
 signal with sender '''Foo''' to create a '''Bar''' instance.
 {{{#!python
 from django.db.models.signals import pre_save
 from django.dispatch import receiver

 from bug22657.models import Foo, Bar


 @receiver(pre_save, sender=Foo)
 def callback(sender, **kwargs):
 Bar.objects.create()
 print 'Hello!'

 }}}

 Then, we have two tests: ''test_model'' and ''test_signal''.
 {{{#!python
 ###  test_model.py ###
 from django.test import TestCase

 from bug22657.models import Foo, Bar
 # a safe re-import/reload of the signal handler
 # in expense of an unused import
 from bug22657.signals import handlers


 class FooModelTestCase(TestCase):

 def test_create_model(self):
 Foo.objects.create()
 self.assertEquals(Foo.objects.count(), 1)
 self.assertEquals(Bar.objects.count(), 1)

 ###  test_signal.py ###
 from django.db.models.signals import pre_save
 from django.test import TestCase

 from bug22657.models import Foo, Bar
 from bug22657.signals.handlers import callback


 class FooSignalTestCase(TestCase):

 def setUp(self):
 pre_save.disconnect(callback, sender=Foo)

 def test_create_signal_off(self):
 Foo.objects.create()
 self.assertEquals(Foo.objects.count(), 1)
 self.assertEquals(Bar.objects.count(), 0)

 #  comment this tearDown and other tests may fail
 def tearDown(self):
 pre_save.connect(callback, sender=Foo)
 }}}

 For the benefit of it, if you have not noticed the code comments, running
 the test suite will be successful. However, commenting
 ''test_signal.FooSignalTestCase.tearDown'' will fail the other following
 test cases, in this particular example the ''test_model'' will fail on its
 second assertion or no Bar object is created.

 To avoid further failures that relates to signals, temporary disabling of
 signals must be use with caution if you have other test cases that depends
 upon the signal mechanism.

 > Replying to [comment:2 bmispelon]:
 >
 > Hi,
 >
 > I just reproduced the issue. It's related to parameter sender, when I
 don't provide that parameter, receiver is not disconnected. I know it
 works for you but maybe something else influence my results, i.e. it
 occurs in test case. Also the function is imported from different app. But
 now I'm 100% sure, i'll paste my results.
 >
 > code part:
 > pre_save.disconnect(calculate_current_equity)
 > for s in Subscription.objects.all():
 > # simulate real world behaviour - closing transactions one
 by one in correct order
 > for st in
 s.subscription_transactions.order_by('mt_close_time'):
 > st.mt_open_price =
 QuoteGenerator.get_symbol_sl_value(st.symbol.name, st.type)
 > st.mt_close_price =
 QuoteGenerator.get_symbol_sl_value(st.symbol.name, st.type)
 > st.mt_profit = Decimal(randint(1000, 10) / 100)
 > st.save()
 > result:
 >  File "[...]/webapp/signals/models.py", line 149, in
 '''calculate_current_equity'''
 > raise CustomRuntimeError("Closed transaction saved again, although
 calculations already done.")
 > CustomRuntimeError: Closed transaction saved again, although
 calculations already done.
 >
 >
 > pre_save.disconnect(calculate_current_equity,
 SubscriptionTransaction)
 > for s in Subscription.object

44 matches

Mail list logo