Re: [Django] #28948: CookieStorage performance issues

2017-12-28 Thread Django 
#28948: CookieStorage performance issues
-+-
 Reporter:  Michal Čihař |Owner:  Srinivas
 |  Reddy Thatiparthy
 Type:  Bug  |   Status:  assigned
Component:  contrib.messages |  Version:  2.0
 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 Srinivas Reddy Thatiparthy):

 * owner:  nobody => Srinivas Reddy Thatiparthy
 * 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/063.4d2807bdaf61460d3036af3c62992fcc%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28971: EmailMessage.message() does not override Cc header from extra_headers dict (unlike From, To, and Reply-To)

2017-12-28 Thread Django 
#28971: EmailMessage.message() does not override Cc header from extra_headers 
dict
(unlike From, To, and Reply-To)
--+
 Reporter:  Jon Dufresne  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Core (Mail)   |  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):

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

Re: [Django] #28964: RenameField after AddField after CreateModel in one operations list gives ProgrammingError: relation "field" does not exist

2017-12-28 Thread Django 
#28964: RenameField after AddField after CreateModel in one operations list 
gives
ProgrammingError: relation "field" does not exist
--+--
 Reporter:  Matthew Pava  |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  Migrations|  Version:  1.11
 Severity:  Normal|   Resolution:  duplicate
 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 Matthew Pava):

 For clarification purposes, this bug has been fixed in Django 2.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/064.d2dc449a250b301c4920fe7cf0d1a9b8%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28959: Clicking "No, take me back" on the delete selected inline foreign key / one-to-one field confirmation page does nothing

2017-12-28 Thread Django 
#28959: Clicking "No, take me back" on the delete selected inline foreign key /
one-to-one field confirmation page does nothing
---+
 Reporter:  Josh Schneier  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  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 Josh Schneier):

 I'm happy to fix this but the popover code looked a bit complex. Since
 it's isolated to cancel.js would checking for the `is_popover` hidden
 field value (or in the URL) in the handler and then calling
 `window.close()` if it's found be sufficient?

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

Re: [Django] #28926: some big values of DurationField are saved inaccurately on SQLite and MySQL

2017-12-28 Thread Django 
#28926: some big values of DurationField are saved inaccurately on SQLite and 
MySQL
-+-
 Reporter:  Sergey Fedoseev  |Owner:  Sergey
 |  Fedoseev
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"ae6fa914aa2f43d39ae491ac7d3140dda69702fa" ae6fa914]:
 {{{
 #!CommitTicketReference repository=""
 revision="ae6fa914aa2f43d39ae491ac7d3140dda69702fa"
 Fixed #28926 -- Fixed loss of precision of big DurationField values on
 SQLite and MySQL.
 }}}

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

[Django] #28971: EmailMessage.message() does not override Cc header from extra_headers dict (unlike From, To, and Reply-To)

2017-12-28 Thread Django 
#28971: EmailMessage.message() does not override Cc header from extra_headers 
dict
(unlike From, To, and Reply-To)
+
   Reporter:  Jon Dufresne  |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Core (Mail)   |Version:  master
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  1
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 Compare how CC is built:

 https://github.com/django/django/blob/2.0/django/core/mail/message.py#L259

 To how the other headers are built:

 -
 https://github.com/django/django/blob/2.0/django/core/mail/message.py#L256
 -
 https://github.com/django/django/blob/2.0/django/core/mail/message.py#L257
 -
 https://github.com/django/django/blob/2.0/django/core/mail/message.py#L261

 Notice, unlike the others, Cc does not first use the `.extra_headers`
 dict. Like the other headers, should be able to use the `.extra_headers`
 to override Cc.

 [https://github.com/django/django/pull/9454 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/052.83fb6d8a7bf26626f3f283e2e283fc4d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28968: LiveServerTestCase prematurely closing HttpResponse with Django 2.0

2017-12-28 Thread Django 
#28968: LiveServerTestCase prematurely closing HttpResponse with Django 2.0
---+--
 Reporter:  Alexander Todorov  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  HTTP handling  |  Version:  2.0
 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
---+--

Comment (by Alexander Todorov):

 FYI the Python bug is:
 https://bugs.python.org/issue26402

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

Re: [Django] #28968: LiveServerTestCase prematurely closing HttpResponse with Django 2.0

2017-12-28 Thread Django 
#28968: LiveServerTestCase prematurely closing HttpResponse with Django 2.0
---+--
 Reporter:  Alexander Todorov  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  HTTP handling  |  Version:  2.0
 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
---+--

Comment (by Tom Forbes):

 I don't have much to add either, except that it would be good to open a
 ticket with Python if it is indeed an issue in xmlrpc. If this is causing
 issues with a core standard library, which is hopefully we'll tested, then
 this could be triggering other libraries and code that is not reported.

 I have some time this weekend to review this ticket and perhaps dig into
 it a bit, but it would be nice to just be able to enable keep alive in all
 but streaming requests.

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

Re: [Django] #28968: LiveServerTestCase prematurely closing HttpResponse with Django 2.0

2017-12-28 Thread Django 
#28968: LiveServerTestCase prematurely closing HttpResponse with Django 2.0
---+--
 Reporter:  Alexander Todorov  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  HTTP handling  |  Version:  2.0
 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 Tim Graham):

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


Comment:

 I don't have any insight to offer.

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

Re: [Django] #28968: LiveServerTestCase prematurely closing HttpResponse with Django 2.0

2017-12-28 Thread Django 
#28968: LiveServerTestCase prematurely closing HttpResponse with Django 2.0
---+--
 Reporter:  Alexander Todorov  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  HTTP handling  |  Version:  2.0
 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 Alexander Todorov):

 I think there's a bug inside Python's xmlrpc.client.Transport class which
 isn't playing nicely when Django closes the connection when HTTP 1.1 is in
 use. In particular this piece of code in xmlrpc/client.py


 {{{
1129 def request(self, host, handler, request_body, verbose=False):
1130 #retry request once if cached connection has gone cold
1131 for i in (0, 1):
1132 try:
1133 return self.single_request(host, handler,
 request_body, verbose)
1134 except OSError as e:
1135 if i or e.errno not in (errno.ECONNRESET,
 errno.ECONNABORTED,
1136 errno.EPIPE):
1137 raise
1138 except http.client.RemoteDisconnected:
1139 if i:
1140 raise

 }}}

 if I swap the except blocks then everything seems to work for me
 (ac756f16c5bbbe544ad82a8f3ab2eac6cccdb62e is applied).

 About the statement above that './manage.py test' doesn't terminate: I
 have the feeling that the server is still running while there's no client
 to issue more requests (test has finished). I'm not sure if Django can do
 anything about this.


 I'd love to hear your comments on my findings since I don't know this area
 of Django or Python's http/xmlrpc libraries very well but feel free to
 close.

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

Re: [Django] #27175: Deprecate silencing exceptions raised while rendering the {% include %} template tag

2017-12-28 Thread Django 
#27175: Deprecate silencing exceptions raised while rendering the {% include %}
template tag
-+-
 Reporter:  Jon Dufresne |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Template system  |  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 Tim Graham ):

 In [changeset:"058d112ed2635873d415661bdf0fcc8752ec37c9" 058d112]:
 {{{
 #!CommitTicketReference repository=""
 revision="058d112ed2635873d415661bdf0fcc8752ec37c9"
 Refs #27175 -- Removed an obsolete test comment and DEBUG=True.

 As of e62165b898785e890661953c3b2c9c36d98aee57, {% include %}
 doesn't silence exceptions.
 }}}

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

Re: [Django] #28968: LiveServerTestCase prematurely closing HttpResponse with Django 2.0

2017-12-28 Thread Django 
#28968: LiveServerTestCase prematurely closing HttpResponse with Django 2.0
---+--
 Reporter:  Alexander Todorov  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  HTTP handling  |  Version:  2.0
 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 Alexander Todorov):

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


Comment:

 @Tom Forbes,
 thanks for the hint, I've also been looking around the sme parts of the
 code. Reverting the commit you listed above and testing with
 ServerHandler.http_version = '1.1' makes all of my tests to PASS but
 './manage.py test' doesn't exit!.

 All of my responses also include the Content-Length header. I will let you
 know when I find more.

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

Re: [Django] #28925: durations-only expressions doesn't work on SQLite and MySQL

2017-12-28 Thread Django 
#28925: durations-only expressions doesn't work on SQLite and MySQL
-+-
 Reporter:  Sergey Fedoseev  |Owner:  Sergey
 |  Fedoseev
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * needs_better_patch:  0 => 1


Comment:

 There are test failures on the 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.16770bb66d50930e80e00f565501d77f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28785: Tracking migrations

2017-12-28 Thread Django 
#28785: Tracking migrations
---+--
 Reporter:  Ramez Kabbani  |Owner:  Sonu kumar
 Type:  New feature|   Status:  assigned
Component:  Migrations |  Version:  1.11
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Tim Graham):

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


Comment:

 A [https://github.com/django/django/pull/9339 PR] adds a check to
 makemigrations. It still needs some improvement.

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

Re: [Django] #28811: KeyError when using a regular annotation inside an F-statement in a group by annotation

2017-12-28 Thread Django 
#28811: KeyError when using a regular annotation inside an F-statement in a 
group
by annotation
-+-
 Reporter:  Robin Ramael |Owner:  Robin
 |  Ramael
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * needs_better_patch:  0 => 1


Comment:

 Are you able to send a pull request? Please reuse an existing model rather
 than adding a new one. Perhaps using `Publisher` in `tests/annotations`
 would be fine.

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

Re: [Django] #26623: Customizing environment variable for RemoteUserMiddleware requires subclass

2017-12-28 Thread Django 
#26623: Customizing environment variable for RemoteUserMiddleware requires 
subclass
---+--
 Reporter:  Jan Pazdziora  |Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  contrib.auth   |  Version:  1.9
 Severity:  Normal |   Resolution:  wontfix
 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 Jan Pazdziora):

 For the record, `django-identity-external` in https://github.com/adelton
 /django-identity-external / https://pypi.python.org/pypi/django-identity-
 external implements this functionality in external middleware.

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

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

Re: [Django] #25042: When user is authenticated using external (REMOTE_USER) authentication, their attributes should get updated if the external environment provides the data

2017-12-28 Thread Django 
#25042: When user is authenticated using external (REMOTE_USER) authentication,
their attributes should get updated if the external environment provides
the data
---+--
 Reporter:  Jan Pazdziora  |Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  contrib.auth   |  Version:  master
 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 Jan Pazdziora):

 For the record, `django-identity-external` in https://github.com/adelton
 /django-identity-external / https://pypi.python.org/pypi/django-identity-
 external implements this functionality in external middleware.

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

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

Re: [Django] #25030: The /admin/login/ should observe external authentication even when it appears in POST

2017-12-28 Thread Django 
#25030: The /admin/login/ should observe external authentication even when it
appears in POST
---+
 Reporter:  Jan Pazdziora  |Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  contrib.auth   |  Version:  master
 Severity:  Normal |   Resolution:  wontfix
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+

Comment (by Jan Pazdziora):

 For the record, `mod_intercept_form_submit` in version 1.0.1 added
 configuration directive `InterceptGETOnSuccess` to force the method in the
 request to be shown (and reported to Django) as `GET`. So this change is
 no longer 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.3abdce6b9ffce67d9c1aab4aa739f89a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28968: LiveServerTestCase prematurely closing HttpResponse with Django 2.0

2017-12-28 Thread Django 
#28968: LiveServerTestCase prematurely closing HttpResponse with Django 2.0
---+--
 Reporter:  Alexander Todorov  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  HTTP handling  |  Version:  2.0
 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 Tim Graham):

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


Comment:

 Please reopen if you can explain why Django is at fault.

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

Re: [Django] #28687: Add a 'Not Empty' option to admin's related filter (was: Not 'Empty' Related Filter option)

2017-12-28 Thread Django 
#28687: Add a 'Not Empty' option to admin's related filter
-+-
 Reporter:  Brillgen Developers  |Owner:  Jake
 Type:   |  Barber
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.admin|  Version:  2.0
 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):

 * type:  Uncategorized => Cleanup/optimization
 * easy:  1 => 0
 * stage:  Unreviewed => Accepted


Comment:

 Seems okay at first glance.

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

Re: [Django] #2750: ManyToManyField ignores 'default' option

2017-12-28 Thread Django 
#2750: ManyToManyField ignores 'default' option
-+-
 Reporter:  bangcok_dangerus@…   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by François Granade):

 Replying to [comment:22 Philip James]:
 > Has there been any movement on this? When you say forms make use of the
 default option, what do you mean?

 what is meant here is:

 the `default` option for a `ManyToManyField` is not used when saving the
 object (when calling `.save()`, or other): even if it is set (e.g.
 to a callable returning an object list), the field will be set to an empty
 list when saving.

 However, this `default` option value is used in Django `Form` set up to
 edit this object. In particular, in Django Admin, a the multivalue drop-
 down will include for the field, that will contain all the objects
 returned by the callable defined as the `default` value - and they will be
 all selected. If the user saves the object without any edit (by pushing
 the form's "save" button), then the field will indeed be set to all the
 values.

 The current behavior is a little misleading, I think (and I'm not the
 only. one, from previous comments): I would expect the options set if the
 model's fields to be used in the model's methods; if an option is only
 used for forms, I would expect it to be set in the form, not in the model.
 There may be design reasons for the current behavior though ?

 In any case, this should probably be documented in the `ManyToManyField`
 documentation ?

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

Re: [Django] #28962: Documentation of use of template tags in forms

2017-12-28 Thread Django 
#28962: Documentation of use of template tags in forms
-+-
 Reporter:  Malik A. Rumi|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  2.0
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  forms,   | Triage Stage:
  templatetags, urls |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Tim Graham):

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


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To 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.8f1369380d255cb6e33f0a396965b28c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28763: Allow SessionStore's to be easily overridden to make dynamic the session cookie age

2017-12-28 Thread Django 
#28763: Allow SessionStore's to be easily overridden to make dynamic the session
cookie age
-+-
 Reporter:  Jaime Herencia   |Owner:  (none)
  Enjuto |
 Type:  New feature  |   Status:  new
Component:  contrib.sessions |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

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


Comment:

 A test should be added so the change isn't inadvertently refactored away.

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

Re: [Django] #28783: Allow specifying custom operator classes for PostgreSQL indexes (was: Support for custom operator class for indexes)

2017-12-28 Thread Django 
#28783: Allow specifying custom operator classes for PostgreSQL indexes
-+-
 Reporter:  vinay karanam|Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  postgres, operator   | Triage Stage:
  class  |  Unreviewed
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:   => duplicate


Comment:

 Okay, I added the details from this ticket to #28077 and retitled 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/072.524489d07f1ea0db81571358d458f2bf%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28077: Allow specifying custom operator classes for PostgreSQL indexes (was: Allow specifying an operator class for GinIndex())

2017-12-28 Thread Django 
#28077: Allow specifying custom operator classes for PostgreSQL indexes
-+-
 Reporter:  IzyJeepee|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  postgres, gin,   | Triage Stage:  Accepted
  operator, class|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * owner:  (none) => nobody
 * has_patch:  0 => 1
 * component:  contrib.postgres => Database layer (models, ORM)


Comment:

 #28783 was a duplicate and provides a
 [https://github.com/django/django/pull/9332 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.8f0ebcf5e61f751f226880b4e6c30a15%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28943: Avoid the need to call get_context_data() in TemplateView subclasses (was: Unenforce manual get_context_data())

2017-12-28 Thread Django 
#28943: Avoid the need to call get_context_data() in TemplateView subclasses
-+-
 Reporter:  James Pic|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Generic views|  Version:  2.0
 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 Tim Graham):

 Is there a reason to duplicate the `render_to_response()` call in
 `post()`? I didn't test it, but I believe you could write both examples
 as:
 {{{
 class YourView(TemplateView):
 def post(self, request, *a, **k):
 if not self.dostuff():
 return http.HttpResponseBadRequest()

 return super().get(request, *a, **k)
 }}}

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

Re: [Django] #28897: FieldError when performing custom action in Admin Interface IF data is sorted by an annotated field

2017-12-28 Thread Django 
#28897: FieldError when performing custom action in Admin Interface IF data is
sorted by an annotated field
-+-
 Reporter:  Colton Hicks |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  2.0
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  Admin Interface, | Triage Stage:
  Custom Action, Annotated Field,|  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
 * resolution:   => needsinfo


Comment:

 Yes, a more minimal (but complete, with models) example seems 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/066.96827de832b954c634b74322d2fd6a90%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28852: Search in admin can't use index when several fields are in `search_fields`

2017-12-28 Thread Django 
#28852: Search in admin can't use index when several fields are in 
`search_fields`
-+-
 Reporter:  Jonathan Sundqvist   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  search   | 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
 * resolution:   => wontfix


Comment:

 Rather than adding more syntactic sugar like `@english@field_2`, I think
 overriding `ModelAdmin.get_search_results()` may be the best approach. If
 you come up with a solution that you think is particularly elegant, I'd
 please raise it on the DevelopersMailingList to see if there's a consensus
 to add it to Django.

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

Re: [Django] #28806: Mechanism of fetching related objects violates READ COMMITTED assumption of Django ORM

2017-12-28 Thread Django 
#28806: Mechanism of fetching related objects violates READ COMMITTED 
assumption of
Django ORM
-+-
 Reporter:  Aaron Tan|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  database, read-  | Triage Stage:  Accepted
  committed, concurrency control |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * stage:  Unreviewed => Accepted


Comment:

 Accepting for further investigating. I haven't taken time to understand
 whether or not a change should be made.

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

Re: [Django] #28935: Template error raised in an {% extends %} child template shows incorrect source location on debug page

2017-12-28 Thread Django 
#28935: Template error raised in an {% extends %} child template shows incorrect
source location on debug page
-+
 Reporter:  Matt Westcott|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Template system  |  Version:  2.0
 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):

 * cc: Preston Timmons (added)
 * component:  Uncategorized => Template system
 * type:  Uncategorized => Bug
 * 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/064.67463c4bf1f8a587cf02f472d4600490%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28486: Template FileLoader can't find widget templates

2017-12-28 Thread Django 
#28486: Template FileLoader can't find widget templates
-+-
 Reporter:  Andrey   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Template system  |  Version:  1.11
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  widgets, templates,  | Triage Stage:
  admin  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 Yes, there was [https://groups.google.com/d/topic/django-
 developers/TmHdj5SCGNk/discussion extensive discussion] about this feature
 and the decision about which renderer to use as the default.

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

Re: [Django] #28486: Template FileLoader can't find widget templates

2017-12-28 Thread Django 
#28486: Template FileLoader can't find widget templates
-+-
 Reporter:  Andrey   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Template system  |  Version:  1.11
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  widgets, templates,  | Triage Stage:
  admin  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Paolo):

 +1 for Federico Capoano and agree with his statement and the fact that the
 pre-configured behaviour is NOT the one expected, I have lost quite a bit
 of time on this and why I could not override the template using the
 standard Django strategy.
 I think that would have made much more sense to explain that the
 "django.forms" app should be added in the installed apps to allow the
 templates to be found!

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

Re: [Django] #28970: Option to suppress signals on save to avoid loop

2017-12-28 Thread Django 
#28970: Option to suppress signals on save to avoid loop
-+-
 Reporter:  Gustavo Henrique de  |Owner:  nobody
  Almeida Gonçalves  |
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  signal suppress  | Triage Stage:
  save recursion loop problem|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Old description:

> Calling instance.save() inside a post_save signal receiver causes a loop
> and max recursion error. This problem is very easy to fall into and the
> best solution at the moment is call the QuerySet update() method, so that
> the post_save signal is not called in this case.
>
> This is a very ugly workaround. I think Django should give the option to
> call save() and explicitly suppress signal emmiting. For example:
>
> instance.save(post_save=False)
>
> In the above method call, post_save signal would not be sent, and the
> loop problem would not occurs.

New description:

 Calling `instance.save()` inside a post_save signal receiver causes a loop
 and max recursion error. This problem is very easy to fall into and the
 best solution at the moment is call the `QuerySet update()` method, so
 that the post_save signal is not called in this case.

 This is a very ugly workaround. I think Django should give the option to
 call `save()` and explicitly suppress signal emitting. For example:

 `instance.save(post_save=False)`

 In the above method call, post_save signal would not be sent, and the loop
 problem would not occurs.

--

Comment (by Tim Graham):

 Resaving the object in `post_save()` doesn't sound like a common use case
 (or a wise thing to do, from a performance standpoint). Can you explain
 your use case?

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

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

[Django] #28970: Option to suppress signals on save to avoid loop

2017-12-28 Thread Django 
#28970: Option to suppress signals on save to avoid loop
-+-
   Reporter:  Gustavo|  Owner:  nobody
  Henrique de Almeida Gonçalves  |
   Type:  New| Status:  new
  feature|
  Component:  Database   |Version:  2.0
  layer (models, ORM)|   Keywords:  signal suppress
   Severity:  Normal |  save recursion loop problem
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Calling instance.save() inside a post_save signal receiver causes a loop
 and max recursion error. This problem is very easy to fall into and the
 best solution at the moment is call the QuerySet update() method, so that
 the post_save signal is not called in this case.

 This is a very ugly workaround. I think Django should give the option to
 call save() and explicitly suppress signal emmiting. For example:

 instance.save(post_save=False)

 In the above method call, post_save signal would not be sent, and the loop
 problem would not occurs.

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

Re: [Django] #28783: Support for custom operator class for indexes

2017-12-28 Thread Django 
#28783: Support for custom operator class for indexes
-+-
 Reporter:  vinay karanam|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  postgres, operator   | Triage Stage:
  class  |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by vinay karanam):

 #28077 requires almost same amount of work. It is only asking operator
 support for `GinIndex`, whereas this adds support for any postgres index.
 We can close it in favour of this or retitle #28077 and close this ticket.

 Regarding code changes, even I was skeptical at first about adding
 `operator_class` to `Index.__init__()` but then I saw `Index.create_sql`
 accepts `using` kwarg which is only valid for postgres index.
 If necessary we can have a subclass `PGIndex` and move postgres specific
 options into 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/072.073a6486a8c545c89e614db60ee00699%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.