date:20161024

Re: [Django] #27382: Document that ugettext_lazy() result can't be used with arbitrary Python code

2016-10-24 Thread Django

#27382: Document that ugettext_lazy() result can't be used with arbitrary Python
code
---+--
 Reporter:  Mike Edmunds   |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Documentation  |  Version:  1.10
 Severity:  Normal |   Resolution:
 Keywords:  ugettext_lazy  | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Mike Edmunds):

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


Comment:

 Doc change: https://github.com/django/django/pull/7430

 (Aside: I did also explore changing ugettext_lazy() to test as an instance
 of text_type. It's not totally infeasible, but would probably cause at
 least as many problems as it would solve.
 https://github.com/medmunds/django/pull/1 if you're curious.)

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

[Django] #27382: Document that ugettext_lazy() result can't be used with arbitrary Python code

2016-10-24 Thread Django

#27382: Document that ugettext_lazy() result can't be used with arbitrary Python
code
---+---
Reporter: Mike Edmunds | Owner: nobody
Type: Bug| Status: new
Component: Documentation |Version: 1.10
Severity: Normal | Keywords: ugettext_lazy
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
---+---
The documentation
[https://docs.djangoproject.com/en/1.10/topics/i18n/translation/#working-
with-lazy-translation-objects currently states] that:

The result of a `ugettext_lazy()` call can be used wherever you would
use a unicode string (an object with type `unicode`) in Python.

However, the result of ugettext_lazy() does not pass `isinstance(lazy_obj,
unicode)`. Because instance checks are commonly used to detect text
strings, the lazy objects are incompatible with some Python standard
library code and other popular Python packages (such as requests).

Proposed doc patch clarifies that ugettext_lazy() can be used with other
Django code, but that it should generally be converted to text before
passing to arbitrary, non-Django Python code.

Discussion and examples on django-dev:
https://groups.google.com/forum/#!topic/django-developers/eFsGf1ZrG7c

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

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

Re: [Django] #27328: return `Set-Cookie` if sessionid= None value

2016-10-24 Thread Django

#27328: return `Set-Cookie` if sessionid=  None value
-+-
 Reporter:  Ramin Farajpour  |Owner:  nobody
  Cami   |
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  contrib.sessions |  Version:  1.10
 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 Ramin Farajpour Cami):

 * type:  Bug => Cleanup/optimization


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

Re: [Django] #27328: return `Set-Cookie` if sessionid= None value

2016-10-24 Thread Django

#27328: return `Set-Cookie` if sessionid=  None value
-+-
 Reporter:  Ramin Farajpour  |Owner:  nobody
  Cami   |
 Type:  Bug  |   Status:  new
Component:  contrib.sessions |  Version:  1.10
 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 Ramin Farajpour Cami):

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


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

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

Re: [Django] #26357: 'related-lookup' and 'add-another' popups don't work for admin fields added via ajax

2016-10-24 Thread Django

#26357: 'related-lookup' and 'add-another' popups don't work for admin fields 
added
via ajax
-+-
 Reporter:  Julian Andrews   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  admin javascript | Triage Stage:  Accepted
  ajax   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"adc93e85990b644194c679f528225deed9fdaa85" adc93e85]:
 {{{
 #!CommitTicketReference repository=""
 revision="adc93e85990b644194c679f528225deed9fdaa85"
 Fixed #26357 -- Allowed admin popups to work on links added after page
 load.
 }}}

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

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

Re: [Django] #27328: return `Set-Cookie` if sessionid= None value

2016-10-24 Thread Django

#27328: return `Set-Cookie` if sessionid=  None value
-+-
 Reporter:  Ramin Farajpour  |Owner:  nobody
  Cami   |
 Type:  Bug  |   Status:  closed
Component:  contrib.sessions |  Version:  1.10
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Ramin Farajpour Cami):

 question : what happen when set  `sessionid=''` ?

 status now : sessionid django when sessionid on logout set date 1970 for
 define browser this sessionid is expire sessionid store on server django

 best practice : check sessionid is empty for call extra methods `set-
 cookie` and `delete-cookie` (set-cookie and delete-cookie methods call for
 expire sessionid on browser or  `CookieJar`)

 Note : i test my real app port 8000 and show demo video of this,

 Steps :

 1 - login to django app for example on ip (127.0.0.1:8000) you have set
 sessionid OK,

 2- set `sessionid=''` from AJAX `document.cookie="sessionid="` this means
 set sessionid on cookie success  from request (this idea of me create a
 scenario for this)

 3- you see on request header Cookie : sessionid="";
 sessionid="jaksdnkjasdkasjdaskd" va ... with set document cookie on ajax
 or browser (Step 2),there isn't problem here with two sessionid= because
 django use cookie_parse , cookie parse is a `dict` accept one sessionid

 4- now logout from app

 5- again set step 2 ,

 6- you see sessionid is set on user is logout also i display on demo video
 cookie path is `/user` (`/user` this path first time i run step 2)

 7- problem is here with refresh page `sessionid=''` is not expire and call
 always extra method `set-cookie` and `delete-cookie` in every request on
 browser, with call this there is problem because path cookie on browser
 set `path:/user` is not '/' root , `sessionid=''`


 this step of my video,

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

Re: [Django] #26401: Allow auth machinery to be used without installing auth app

2016-10-24 Thread Django

#26401: Allow auth machinery to be used without installing auth app
--+-
 Reporter:  Matt Johnson  |Owner:  Andrew Konoff
 Type:  New feature   |   Status:  new
Component:  contrib.auth  |  Version:  1.9
 Severity:  Normal|   Resolution:
 Keywords:  auth 1.11 | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+-

Comment (by Tim Graham):

 It seems like you basically want an
 `apps.register.Apps.unregister_model()` method or some way of telling
 Django not to setup relations for a given model. This might not be
 trivial, so if you want to revert for now, that's fine with me.

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

Re: [Django] #27328: return `Set-Cookie` if sessionid= None value

2016-10-24 Thread Django

#27328: return `Set-Cookie` if sessionid=  None value
-+-
 Reporter:  Ramin Farajpour  |Owner:  nobody
  Cami   |
 Type:  Bug  |   Status:  closed
Component:  contrib.sessions |  Version:  1.10
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 I'm sorry but I can't make sense of that comment and I'm still missing the
 information requested in comment:23. I guess I would suggest either
 writing up explicit steps to reproduce the issue:

 1. Do this
 2. Do that
 3. ...

 Expected result: ...
 Actual result: ...

 ... or, as I feel language might be the barrier here, try to find someone
 who speaks your native language and might be able to more easily answer my
 questions so I can understand 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/065.e3b69a8fee4250c9ffb3c2bdaa60a5f6%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27328: return `Set-Cookie` if sessionid= None value

2016-10-24 Thread Django

#27328: return `Set-Cookie` if sessionid=  None value
-+-
 Reporter:  Ramin Farajpour  |Owner:  nobody
  Cami   |
 Type:  Bug  |   Status:  closed
Component:  contrib.sessions |  Version:  1.10
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Ramin Farajpour Cami):

 Yes, I show after login and manually set seseionid='' on browser you're
 right, I say first this issue when Ajax send with sessionid empty if set
 cookie in Ajax sessionid='' save this other browser for example when user
 logout sessions empty (is not expired) with every request browser send to
 server sessionid empty
 This I'd was demo,

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

Re: [Django] #27381: Add a migration operation to enable to pg_prewarm extension for Postgres

2016-10-24 Thread Django

#27381: Add a migration operation to enable to pg_prewarm extension for Postgres
--+--
 Reporter:  petedmarsh|Owner:  petedmarsh
 Type:  New feature   |   Status:  closed
Component:  contrib.postgres  |  Version:  master
 Severity:  Normal|   Resolution:  wontfix
 Keywords:| Triage Stage:  Unreviewed
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+--
Changes (by Simon Charette):

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


Comment:

 I don't think we should be shipping a `CreateExtension` subclass for every
 existing built-in Postgres extension. You can use
 `CreateExtension('pg_prewarm')` for this case as
 
[https://docs.djangoproject.com/en/1.10/ref/contrib/postgres/operations/#django.contrib.postgres.operations.CreateExtension
 documented].

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

Re: [Django] #27381: Add a migration operation to enable to pg_prewarm extension for Postgres

2016-10-24 Thread Django

#27381: Add a migration operation to enable to pg_prewarm extension for Postgres
--+--
 Reporter:  petedmarsh|Owner:  (none)
 Type:  New feature   |   Status:  assigned
Component:  contrib.postgres  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Unreviewed
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+--
Changes (by petedmarsh):

 * needs_better_patch:   => 0
 * version:  1.10 => master
 * needs_tests:   => 0
 * needs_docs:   => 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.c8bb5f4f5d65cb0c91ebdd1aed576d64%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27381: Add a migration operation to enable to pg_prewarm extension for Postgres

2016-10-24 Thread Django

#27381: Add a migration operation to enable to pg_prewarm extension for Postgres
--+--
 Reporter:  petedmarsh|Owner:  petedmarsh
 Type:  New feature   |   Status:  assigned
Component:  contrib.postgres  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Unreviewed
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+--
Changes (by petedmarsh):

 * owner:  (none) => petedmarsh


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

[Django] #27381: Add a migration operation to enable to pg_prewarm extension for Postgres

2016-10-24 Thread Django

#27381: Add a migration operation to enable to pg_prewarm extension for Postgres
--+--
 Reporter:  petedmarsh|  Owner:  (none)
 Type:  New feature   | Status:  assigned
Component:  contrib.postgres  |Version:  1.10
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  1
Easy pickings:  1 |  UI/UX:  0
--+--
 "The pg_prewarm module provides a convenient way to load relation data
 into either the operating system buffer cache or the PostgreSQL buffer
 cache." It is included with Postgres starting from 9.4.

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

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

Re: [Django] #27328: return `Set-Cookie` if sessionid= None value

2016-10-24 Thread Django

#27328: return `Set-Cookie` if sessionid=  None value
-+-
 Reporter:  Ramin Farajpour  |Owner:  nobody
  Cami   |
 Type:  Bug  |   Status:  closed
Component:  contrib.sessions |  Version:  1.10
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 One of the steps in your video involves using the browser console to set
 `document.cookie = 'sessionid='`. I don't understand what condition that's
 simulating or if this is some improvement for the case where someone
 actually does 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.08c28b958e84623688f4217a94241615%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27380: Add the 'raw' argument with the 'm2m_changed' signal

2016-10-24 Thread Django

#27380: Add the 'raw' argument with the 'm2m_changed' signal
-+-
 Reporter:  Élie Bouttier|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

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


Comment:

 This was also proposed in #17583 which was marked as a duplicate of #8399
 but I don't see an elegant solution in that ticket, so maybe it's time to
 accept this.

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

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

[Django] #27380: Add the 'raw' argument with the 'm2m_changed' signal

2016-10-24 Thread Django

#27380: Add the 'raw' argument with the 'm2m_changed' signal
--+
 Reporter:  Élie Bouttier |  Owner:  nobody
 Type:  New feature   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.10
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 The 'raw' argument is sent with pre_save and post_save signals in order to
 detect fixture loading and avoid un-needed operations in this case.
 Unfortunatly, this argument is not sent with m2m_changed signal !
 I find a work-around on stack-overflow for tests which consist in
 disconnecting the m2m_signal in the setUpClass.
 However, this is not applicable for loaddata management command.

 Please send the 'raw' argument with the m2m_changed signal, this is
 needed!

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

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

Re: [Django] #27373: Incorrect message on 404 debug page for an empty request path

2016-10-24 Thread Django

#27373: Incorrect message on 404 debug page for an empty request path
--+
 Reporter:  felixxm   |Owner:  felixxm
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Error reporting   |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by felixxm):

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

Re: [Django] #27379: Django violates RFC7230 when handling requests.

2016-10-24 Thread Django

#27379: Django violates RFC7230 when handling requests.
-+-
 Reporter:  Stavros  |Owner:  nobody
  Korokithakis   |
 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 René Fleschenberg):

 * cc: rene@… (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/071.97c5a6a233d85565f3a07e14a84658a8%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27379: Django violates RFC7230 when handling requests.

2016-10-24 Thread Django

Comment (by Florian Apolloner):

Oh, I found something interesting in (
https://tools.ietf.org/html/rfc7230#section-5.3.2 ):
{{{
To allow for transition to the absolute-form for all requests in some
future version of HTTP, a server MUST accept the absolute-form in
requests, even though HTTP/1.1 clients will only send them in
requests to proxies.
}}}
That said, now that HTTP/2 exists and is the successor of 1.1, we should
look what that spec requires. Either way, I think Django should not
concern itself to much with it, since it is not a server but just a
library rejecting an invalid request.

Arguably there is actually a bug, ie if a client sends:
{{{
GET http://valid.com/ HTTP/1.1
Host: alsovalid.com
}}}
but I cannot figure out a sane reason to do this :D

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

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

Re: [Django] #27379: Django violates RFC7230 when handling requests.

2016-10-24 Thread Django

#27379: Django violates RFC7230 when handling requests.
-+-
 Reporter:  Stavros  |Owner:  nobody
  Korokithakis   |
 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
-+-

Comment (by Florian Apolloner):

 Replying to [comment:3 Stavros Korokithakis]:
 > and I get thousands of emails. This has to be handled *somewhere*,
 otherwise I need to just completely disable invalid host reporting

 Yes, disable it in your LOGGING config, can you confirm that this does not
 happen with the default Django Logging config? Ie set logging to {}

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

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

Re: [Django] #27379: Django violates RFC7230 when handling requests.

2016-10-24 Thread Django

#27379: Django violates RFC7230 when handling requests.
-+-
 Reporter:  Stavros  |Owner:  nobody
  Korokithakis   |
 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
-+-

Comment (by Stavros Korokithakis):

 I would be fine with that, especially given the rationale, except for the
 fact that nginx does pass the request through, and I get thousands of
 emails. This has to be handled *somewhere*, otherwise I need to just
 completely disable invalid host reporting, and people in #nginx seemed to
 think that nginx is handling this compliantly.

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

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

Re: [Django] #27379: Django violates RFC7230 when handling requests.

2016-10-24 Thread Django

* cc: Florian Apolloner (added)

Comment:

I think this depends on how you configured Nginx. If Nginx works as a
proxy for your application, this applies (
https://tools.ietf.org/html/rfc7230#section-5.4 ):
{{{
When a proxy receives a request with an absolute-form of
request-target, the proxy MUST ignore the received Host header field
(if any) and instead replace it with the host information of the
request-target. A proxy that forwards such a request MUST generate a
new Host field-value based on the received request-target rather than
forward the received Host field-value.
}}}
If Nginx does not work as a proxy, it should reject requests which are not
compliant to the RFC ( https://tools.ietf.org/html/rfc7230#section-5.3 ):
{{{
When making a request directly to an origin server, other than a
CONNECT or server-wide OPTIONS request (as detailed below), a client
MUST send only the absolute path and query components of the target
URI as the request-target. If the target URI's path component is
empty, the client MUST send "/" as the path within the origin-form of
request-target. A Host header field is also sent, as defined in
Section 5.4.
}}}
In this case it is imo questionable if Nginx should pass an invalid
request on at all, or answer with 400 already as per (
https://tools.ietf.org/html/rfc7230#section-5.4 ):
{{{
A server MUST respond with a 400 (Bad Request) status code to any
HTTP/1.1 request message that lacks a Host header field and to any
request message that contains more than one Host header field or a
Host header field with an invalid field-value.
}}}
It is questionable on whether an invalid request makes the Host header in
this case invalid, but well.

Either way, I cannot see any reason for Django to consider such a request
not as an attack, and therefore the last paragraph of (
https://tools.ietf.org/html/rfc7230#section-5.5 ) applies:
{{{
Once the effective request URI has been constructed, an origin server
needs to decide whether or not to provide service for that URI via
the connection in which the request was received. For example, the
request might have been misdirected, deliberately or accidentally,
such that the information within a received request-target or Host
header field differs from the host or port upon which the connection
has been made. If the connection is from a trusted gateway, that
inconsistency might be expected; otherwise, it might indicate an
attempt to bypass security filters, trick the server into delivering
non-public content, or poison a cache. See Section 9 for security
considerations regarding message routing.
}}}

Django chooses not to honour this request cause the host-header is not
configured as it expects it too. This is a valid reason to reject the
request, cause after all a valid client MUST send a valid host-header and
technically is not allowed to send a full request URI. So unless there is
any evidence that this has legitimate use cases, I suggest we leave it as
is to keep the code simple. Another interesting sidenote: How is the
server supposed to know if `http://example.com` is a full URI or actually
a path named `http://example.com`?

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

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

Re: [Django] #27379: Django violates RFC7230 when handling requests.

2016-10-24 Thread Django

#27379: Django violates RFC7230 when handling requests.
-+-
 Reporter:  Stavros  |Owner:  nobody
  Korokithakis   |
 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 Stavros Korokithakis):

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


Old description:

> For a request coming in with an absolute URI and a different host header,
> Django still uses the Host header value to service the request. RFC 7230
> specifies:
>

> If the request-target is in absolute-form, the effective request URI
> is the same as the request-target.
>
> (https://tools.ietf.org/html/rfc7230#section-5.5)
>
> Thus, if a request comes in where the host header is different from the
> host in the absolute URI, Django should use the absolute URI, rather than
> the host value.
>
> This is a problem when a request comes in looking like:
>
> GET https://valid.hostname/ HTTP/1.1
> Host: invalid.hostname
>
> Django currently fails this as a violation of ALLOWED_HOSTS, but it
> shouldn't. Granted, we only see this in attacks, but nginx passes these
> requests through (because it should) and Django fails them because of the
> wonky host.

New description:

 For a request coming in with an absolute URI and a different host header,
 Django still uses the Host header value to service the request. RFC 7230
 specifies:


 If the request-target is in absolute-form, the effective request URI
 is the same as the request-target.

 (https://tools.ietf.org/html/rfc7230#section-5.5)

 Thus, if a request comes in where the host header is different from the
 host in the absolute URI, Django should use the absolute URI, rather than
 the host value.

 This is a problem when a request comes in looking like:

 {{{
 GET https://valid.hostname/ HTTP/1.1
 Host: invalid.hostname
 }}}

 Django currently fails this as a violation of ALLOWED_HOSTS, but it
 shouldn't. Granted, we only see this in attacks, but nginx passes these
 requests through (because it should) and Django fails them because of the
 wonky host.

--

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

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

[Django] #27379: Django violates RFC7230 when handling requests.

2016-10-24 Thread Django

#27379: Django violates RFC7230 when handling requests.
--+
Reporter: Stavros Korokithakis | 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
--+
For a request coming in with an absolute URI and a different host header,
Django still uses the Host header value to service the request. RFC 7230
specifies:

If the request-target is in absolute-form, the effective request URI
is the same as the request-target.

(https://tools.ietf.org/html/rfc7230#section-5.5)

Thus, if a request comes in where the host header is different from the
host in the absolute URI, Django should use the absolute URI, rather than
the host value.

This is a problem when a request comes in looking like:

GET https://valid.hostname/ HTTP/1.1
Host: invalid.hostname

Django currently fails this as a violation of ALLOWED_HOSTS, but it
shouldn't. Granted, we only see this in attacks, but nginx passes these
requests through (because it should) and Django fails them because of the
wonky host.

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

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

Re: [Django] #26967: add support for GIS functions added in MySQL 5.7.5 (AsGeoJSON, GeoHash and IsValid)

2016-10-24 Thread Django

#26967: add support for GIS functions added in MySQL 5.7.5 (AsGeoJSON, GeoHash 
and
IsValid)
-+-
 Reporter:  Sergey Fedoseev  |Owner:  Sergey
 |  Fedoseev
 Type:  New feature  |   Status:  assigned
Component:  GIS  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Sergey Fedoseev):

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


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

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

Re: [Django] #26789: ORM produces query with NULL instead of empty geometry

2016-10-24 Thread Django

#26789: ORM produces query with NULL instead of empty geometry
-+-
 Reporter:  Sergey Fedoseev  |Owner:  Sergey
 |  Fedoseev
 Type:  Bug  |   Status:  assigned
Component:  GIS  |  Version:  1.9
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Sergey Fedoseev):

 * needs_better_patch:  1 => 0


Comment:

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

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

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

Re: [Django] #26819: Using a ArrayField on Meta.unique_together throws "unhashable type: 'list'" on validate_unique method

2016-10-24 Thread Django

#26819: Using a ArrayField on Meta.unique_together throws "unhashable type: 
'list'"
on validate_unique method
--+-
 Reporter:  Gleber Diniz  |Owner:  PREMANAND
 Type:  Bug   |   Status:  assigned
Component:  Forms |  Version:  1.9
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+-
Changes (by Tim Graham):

 * component:  contrib.admin => Forms


Old description:

> It happens on a second save (when there is already data to be validated)
>
> On this line: "if row_data in seen_data:", because row_data contains a
> list and seen_data is a set (row_data: (1, [1, 1]) / seen_data: set())
>
> Example to reproduce:
>
> models:
> {{{#!python
> class Map(models.Model):
> name = models.CharField(_('name'), max_length=128)
>

> class MapSpot(models.Model):
> map = models.ForeignKey('body.Map', related_name='spots')
> position = ArrayField(models.IntegerField(), size=2)
>
> class Meta:
> unique_together = [('map', 'position')]
> }}}
>
> admin:
> {{{#!python
> class MapSpotInline(admin.TabularInline):
> model = MapSpot
> extra = 0
>

> @admin.register(Map)
> class MapAdmin(admin.ModelAdmin):
> inlines = [MapSpotInline]
> }}}

New description:

 It happens on a second save (when there is already data to be validated)

 On this line: "if row_data in seen_data:", because row_data contains a
 list and seen_data is a set (row_data: (1, [1, 1]) / seen_data: set())

 Example to reproduce:

 models:
 {{{#!python
 class Map(models.Model):
 name = models.CharField('name', max_length=128)


 class MapSpot(models.Model):
 map = models.ForeignKey('body.Map', related_name='spots')
 position = ArrayField(models.IntegerField(), size=2)

 class Meta:
 unique_together = [('map', 'position')]
 }}}

 admin:
 {{{#!python
 class MapSpotInline(admin.TabularInline):
 model = MapSpot
 extra = 0


 @admin.register(Map)
 class MapAdmin(admin.ModelAdmin):
 inlines = [MapSpotInline]
 }}}

--

Comment:

 I believe it affects all inline formsets, not just those in the admin.
 There's a [https://github.com/django/django/pull/7094 PR] without tests.

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

Re: [Django] #27378: Add UUID serialization support to migration writer (was: makemigration unable to serialize UUID when UUIDField have choices set)

2016-10-24 Thread Django

#27378: Add UUID serialization support to migration writer
-+-
 Reporter:  Yuriy Korobko|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  uuid choices | Triage Stage:  Accepted
  migration  |
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Tim Graham):

 * needs_docs:  0 => 1
 * type:  Bug => New feature
 * needs_tests:  0 => 1


Comment:

 Tests and documentation are needed for a complete patch. See
 998894e1b9f5a8715f4cac5f6201b5e9ac80510c for a similar commit.

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

Re: [Django] #27374: JavaScriptCatalog view ignores the packages argument

2016-10-24 Thread Django

#27374: JavaScriptCatalog view ignores the packages argument
-+-
 Reporter:  Alvin Lindstam   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:   |  Version:  1.10
  Internationalization   |
 Severity:  Release blocker  |   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 Tim Graham ):

 In [changeset:"3a416e4ba9f7094be55110dae8e5a6451984d226" 3a416e4b]:
 {{{
 #!CommitTicketReference repository=""
 revision="3a416e4ba9f7094be55110dae8e5a6451984d226"
 [1.10.x] Fixed #27374 -- Made JavaScriptCatalog respect the packages
 argument.

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

Re: [Django] #27374: JavaScriptCatalog view ignores the packages argument

2016-10-24 Thread Django

#27374: JavaScriptCatalog view ignores the packages argument
-+-
 Reporter:  Alvin Lindstam   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:   |  Version:  1.10
  Internationalization   |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"6b5106b1ceec03d945c1104b21feed3e25470fe0" 6b5106b1]:
 {{{
 #!CommitTicketReference repository=""
 revision="6b5106b1ceec03d945c1104b21feed3e25470fe0"
 Fixed #27374 -- Made JavaScriptCatalog respect the packages argument.
 }}}

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

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

Re: [Django] #27378: makemigration unable to serialize UUID when UUIDField have choices set

2016-10-24 Thread Django

#27378: makemigration unable to serialize UUID when UUIDField have choices set
-+-
 Reporter:  make.kernel  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  uuid choices | Triage Stage:  Accepted
  migration  |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Simon Charette):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * version:  1.10 => master
 * easy:  0 => 1
 * needs_docs:   => 0
 * 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/069.be631af6e1dff7d1983fae0846c66fa4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27316: Multiple LiveServerTestCase subclasses cannot reuse the same port

2016-10-24 Thread Django

#27316: Multiple LiveServerTestCase subclasses cannot reuse the same port
---+
 Reporter:  Jeremy Bowman  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  Version:  1.10
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by Jeremy Bowman):

 I started working on a patch, but a family emergency came up.  I'll try to
 finish the patch (or determine that one isn't really feasible) within the
 next week.

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

[Django] #27378: makemigration unable to serialize UUID when UUIDField have choices set

2016-10-24 Thread Django

#27378: makemigration unable to serialize UUID when UUIDField have choices set
-+
 Reporter:  make.kernel  |  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  Migrations   |Version:  1.10
 Severity:  Normal   |   Keywords:  uuid choices migration
 Triage Stage:  Unreviewed   |  Has patch:  1
Easy pickings:  0|  UI/UX:  0
-+
 Using following model

 {{{
 import uuid
 from django.db import models

 # Create your models here.

 class Student(models.Model):
 FRESHMAN = uuid.UUID('5c859437-d061-4847-b3f7-e6b78852f8c8')
 SOPHOMORE = uuid.UUID('c7853ec1-2ea3-4359-b02d-b54e8f1bcee2')
 JUNIOR = uuid.UUID('94a43637-6dfc-4209-852a-bd9bd8c0101f')
 SENIOR = uuid.UUID('dfb9cc50-c332-4809-9b4c-69c81a7489d0')
 MENTOR = uuid.UUID('b8f3897a-0a0a-4630-8f1b-1ca4b0ee37ca')
 YEAR_IN_SCHOOL_CHOICES = (
 (FRESHMAN, 'Freshman'),
 (SOPHOMORE, 'Sophomore'),
 (JUNIOR, 'Junior'),
 (SENIOR, 'Senior'),
 (MENTOR, 'Mentor'),
 )
 year_in_school = models.UUIDField(choices=YEAR_IN_SCHOOL_CHOICES,
 default=FRESHMAN)
 }}}

 According to documentation it should work, and it works until you try to
 make migrations for this model, it fails with exception

 {{{
 Migrations for 'testapp':
   testapp/migrations/0001_initial.py:
 - Create model Student
 Traceback (most recent call last):
   File "./manage.py", line 22, in 
 execute_from_command_line(sys.argv)
   File "/home/yuriy/dev/uuidtest/env/lib/python3.5/site-
 packages/django/core/management/__init__.py", line 367, in
 execute_from_command_line
 utility.execute()
   File "/home/yuriy/dev/uuidtest/env/lib/python3.5/site-
 packages/django/core/management/__init__.py", line 359, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "/home/yuriy/dev/uuidtest/env/lib/python3.5/site-
 packages/django/core/management/base.py", line 294, in run_from_argv
 self.execute(*args, **cmd_options)
   File "/home/yuriy/dev/uuidtest/env/lib/python3.5/site-
 packages/django/core/management/base.py", line 345, in execute
 output = self.handle(*args, **options)
   File "/home/yuriy/dev/uuidtest/env/lib/python3.5/site-
 packages/django/core/management/commands/makemigrations.py", line 189, in
 handle
 self.write_migration_files(changes)
   File "/home/yuriy/dev/uuidtest/env/lib/python3.5/site-
 packages/django/core/management/commands/makemigrations.py", line 224, in
 write_migration_files
 migration_string = writer.as_string()
   File "/home/yuriy/dev/uuidtest/env/lib/python3.5/site-
 packages/django/db/migrations/writer.py", line 163, in as_string
 operation_string, operation_imports =
 OperationWriter(operation).serialize()
   File "/home/yuriy/dev/uuidtest/env/lib/python3.5/site-
 packages/django/db/migrations/writer.py", line 120, in serialize
 _write(arg_name, arg_value)
   File "/home/yuriy/dev/uuidtest/env/lib/python3.5/site-
 packages/django/db/migrations/writer.py", line 84, in _write
 arg_string, arg_imports = MigrationWriter.serialize(_arg_value)
   File "/home/yuriy/dev/uuidtest/env/lib/python3.5/site-
 packages/django/db/migrations/writer.py", line 293, in serialize
 return serializer_factory(value).serialize()
   File "/home/yuriy/dev/uuidtest/env/lib/python3.5/site-
 packages/django/db/migrations/serializer.py", line 228, in serialize
 return self.serialize_deconstructed(path, args, kwargs)
   File "/home/yuriy/dev/uuidtest/env/lib/python3.5/site-
 packages/django/db/migrations/serializer.py", line 100, in
 serialize_deconstructed
 arg_string, arg_imports = serializer_factory(arg).serialize()
   File "/home/yuriy/dev/uuidtest/env/lib/python3.5/site-
 packages/django/db/migrations/serializer.py", line 43, in serialize
 item_string, item_imports = serializer_factory(item).serialize()
   File "/home/yuriy/dev/uuidtest/env/lib/python3.5/site-
 packages/django/db/migrations/serializer.py", line 43, in serialize
 item_string, item_imports = serializer_factory(item).serialize()
   File "/home/yuriy/dev/uuidtest/env/lib/python3.5/site-
 packages/django/db/migrations/serializer.py", line 388, in
 serializer_factory
 "topics/migrations/#migration-serializing" % (value,
 get_docs_version())
 ValueError: Cannot serialize: UUID('5c859437-d061-4847-b3f7-e6b78852f8c8')
 There are some values Django cannot serialize into migration files.
 For more, see https://docs.djangoproject.com/en/1.10/topics/migrations
 /#migration-serializing
 }}}

 Here is a small patch that add UUIDSerializer to migration serializers and
 tells serializer_factory to use it in case of UUID value

 {{{
 --- django/db/migrations/serializer.py.orig 2016-10-24
 12:16:21.0 +0300
 +++ django/db/migrations/serializer.py  2016-10-24 15:32:33.908818046
 +0300
 @@ -6,6 +6,7 @@
  import

[Django] #27377: Prepopulated Fields in Django Admin

2016-10-24 Thread Django

#27377: Prepopulated Fields in Django Admin
---+---
Reporter: Malik A. Rumi | Owner: nobody
Type: Bug| Status: new
Component: Documentation |Version: 1.10
Severity: Normal | Keywords: prepopulated_fields, admin.py
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
---+---
I don't know if this should be a bug report or a feature request.

I know that some variation on this question has been asked and answered
many times on Stack Overflow. Usually, however, it is about using a
foreign key. This is not my question. "prepopulated_fields doesn’t accept
DateTimeField, ForeignKey, nor ManyToManyField fields."

https://docs.djangoproject.com/en/1.10/ref/contrib/admin/#django.contrib.admin.ModelAdmin.prepopulated_fields

By implication, the docs are saying OneToOne fields are ok. This makes
even more sense where the inherited models are a concrete subclass of a
concrete base and we are really talking about a single object. For
example, a Place can be a Restaurant, and a Restaurant can have a closed
off, separate Bar where kids are not allowed.
https://docs.djangoproject.com/en/1.10/topics/db/models/#one-to-one-
relationships

However, admin.py is looking for a string to concatenate, not a filtered
queryset leading to a related field or object. Furthermore, it expects
that string to match the name of an existing field on the instant model,
not some other model, even if they are the same object. How, then, can one
use a OneToOne field or model in admin.py? I posted this to SO myself, and
got ZERO responses. http://stackoverflow.com/questions/39778945/django-
prepopulated-fields-inheritance

Yes, I know about model-utils and polymorphic. But if I am reading the
docs correctly, this should be possible without resort to those tools.
Besides, both are aimed primarily at queries, and say nothing directly
about this specific issue with prepopulated fields in admin.py. Please
advise. Thanks.

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

Re: [Django] #27362: Omitting default_app_config in init.py happens too easily.

2016-10-24 Thread Django

#27362: Omitting default_app_config in __init__.py happens too easily.
-+-
 Reporter:  Thomas Güttler   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Core (Other) |  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
-+-

Comment (by Tim Graham):

 A proposed solution.

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

Re: [Django] #27376: Why not use plural format MIDDLEWARES in settings.py in Django 1.10.x

2016-10-24 Thread Django

#27376: Why not use plural format MIDDLEWARES  in settings.py in Django 1.10.x
-+-
 Reporter:  WeizhongTu   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Core (Other) |  Version:  1.10
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  MIDDLEWARE   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * status:  new => closed
 * component:  Uncategorized => Core (Other)
 * resolution:   => invalid


Comment:

 This came up during the feature design, but actually `MIDDLEWARE` is both
 singular and plural.

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

Re: [Django] #27362: Omitting default_app_config in init.py happens too easily.

2016-10-24 Thread Django

#27362: Omitting default_app_config in __init__.py happens too easily.
-+-
 Reporter:  Thomas Güttler   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Core (Other) |  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
-+-

Comment (by Thomas Güttler):

 What kind of info is needed?

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

37 matches

Mail list logo