date:20161128

Re: [Django] #27547: Unicode in Textarea breaks rendering

2016-11-28 Thread Django

#27547: Unicode in Textarea breaks rendering
+--
 Reporter:  Nitesh Lohchab  |Owner:  nobody
 Type:  Uncategorized   |   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 Nitesh Lohchab):

 Changing `'\r\n{}'` to
 `u'\r\n{}'` should fix this. I can send a pull
 request.

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

Re: [Django] #27546: Replace hardcoded class names in repr-methods

2016-11-28 Thread Django

#27546: Replace hardcoded class names in __repr__-methods
-+-
 Reporter:  Mads Jensen  |Owner:  Adiyat
 Type:   |  Mubarak
  Cleanup/optimization   |   Status:  assigned
Component:  Core (Other) |  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Adiyat Mubarak):

 * has_patch:  0 => 1


Comment:

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

[Django] #27547: Unicode in Textarea breaks rendering

2016-11-28 Thread Django

#27547: Unicode in Textarea breaks rendering
--+
   Reporter:  Nitesh Lohchab  |  Owner:  nobody
   Type:  Uncategorized   | Status:  new
  Component:  Uncategorized   |Version:  1.10
   Severity:  Normal  |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+
 If you try to render unicode context in textarea, the rendering breaks
 with : ascii codec can't encode unciode error

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

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

Re: [Django] #27402: When using i18n_patterns and prefix_default_language=False, 404 page redirects incorrectly

2016-11-28 Thread Django

#27402: When using i18n_patterns and prefix_default_language=False, 404 page
redirects incorrectly
--+
 Reporter:  Hovi  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Internationalization  |  Version:  1.10
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by François Freitag):

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

Re: [Django] #27546: Replace hardcoded class names in repr-methods

2016-11-28 Thread Django

#27546: Replace hardcoded class names in __repr__-methods
-+-
 Reporter:  Mads Jensen  |Owner:  Adiyat
 Type:   |  Mubarak
  Cleanup/optimization   |   Status:  assigned
Component:  Core (Other) |  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:  1|UI/UX:  0
-+-

Comment (by Adiyat Mubarak):

 Replying to [ticket:27546 Mads Jensen]:
 > I noticed there are a few places where {{{__repr__}}} does not use
 {{{self.__class__.__name__}}}. I think this is a small clean-up that would
 make sense to do, but perhaps there was a good reason not to do that
 (probably they're never subclassed?). The following output is from grep:
 >
 > {{{
 > django/db/models/query.py:return "" %
 self.query
 > django/db/models/sql/query.py:return "" % self
 > django/db/migrations/state.py:return "" %
 (self.app_label, self.name)
 > django/utils/baseconv.py:return "" %
 (len(self.digits), self.digits)
 > django/core/management/commands/makemessages.py:return
 "" % os.sep.join([self.dirpath, self.file])
 > django/core/serializers/base.py:return "" % (
 > }}}

 Hi, I just learn to contribute on django project by taking this easy task
 on this [https://github.com/django/django/pull/7629 PR]
 Do I need to update this ticket to `resolve as fixed`? or this ticket will
 closed automatically?

 Thank in advance

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

Re: [Django] #27546: Replace hardcoded class names in repr-methods

2016-11-28 Thread Django

#27546: Replace hardcoded class names in __repr__-methods
-+-
 Reporter:  Mads Jensen  |Owner:  Adiyat
 Type:   |  Mubarak
  Cleanup/optimization   |   Status:  assigned
Component:  Core (Other) |  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:  1|UI/UX:  0
-+-
Changes (by Adiyat Mubarak):

 * owner:  nobody => Adiyat Mubarak
 * 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.1e6b2a2c4b8e62e672d5250a2bafc0b5%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27541: Provide hooks to override manifest file storage in ManifestFilesMixin

2016-11-28 Thread Django

#27541: Provide hooks to override manifest file storage in ManifestFilesMixin
-+-
 Reporter:  Ryan Lopopolo|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  contrib.staticfiles  |  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 Ryan Lopopolo):

 The latest patch passes all tests when running

 ../venv/bin/python ./runtests.py staticfiles_tests.test_storage

 I could not get the whole staticfiles suite to run

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

Re: [Django] #27541: Provide hooks to override manifest file storage in ManifestFilesMixin

2016-11-28 Thread Django

#27541: Provide hooks to override manifest file storage in ManifestFilesMixin
-+-
 Reporter:  Ryan Lopopolo|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  contrib.staticfiles  |  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 Ryan Lopopolo):

 * Attachment "manifest_storage.patch" added.

 manifest_storage indirection

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

Re: [Django] #27541: Provide hooks to override manifest file storage in ManifestFilesMixin

2016-11-28 Thread Django

#27541: Provide hooks to override manifest file storage in ManifestFilesMixin
-+-
 Reporter:  Ryan Lopopolo|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  contrib.staticfiles  |  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 Ryan Lopopolo):

 * Attachment "manifest_storage.patch" added.

 manifest_storage indirection

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

Re: [Django] #27541: Provide hooks to override manifest file storage in ManifestFilesMixin

2016-11-28 Thread Django

#27541: Provide hooks to override manifest file storage in ManifestFilesMixin
-+-
 Reporter:  Ryan Lopopolo|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  contrib.staticfiles  |  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 Ryan Lopopolo):

 My intent is to add a layer of indirection to allow the manifest file to
 be saved to a separate storage backend than the static files themselves.

 I've attached a patch. It should be backwards compatible.

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

Re: [Django] #27541: Provide hooks to override manifest file storage in ManifestFilesMixin

2016-11-28 Thread Django

#27541: Provide hooks to override manifest file storage in ManifestFilesMixin
-+-
 Reporter:  Ryan Lopopolo|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  contrib.staticfiles  |  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 Ryan Lopopolo):

 * Attachment "manifest_storage.patch" added.

 manifest_storage indirection

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

Re: [Django] #27542: Client.force_login() shouldn't use authentication backends without a get_user() method

2016-11-28 Thread Django

#27542: Client.force_login() shouldn't use authentication backends without a
get_user() method
--+
 Reporter:  Tom   |Owner:  nobody
 Type:  Cleanup/optimization  |   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
--+
Changes (by Daniel Hahler):

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

Re: [Django] #27358: Add a system check for FileField upload_to starting with a slash

2016-11-28 Thread Django

#27358: Add a system check for FileField upload_to starting with a slash
-+-
 Reporter:  Tim Graham   |Owner:  Henry
 Type:   |  Dang
  Cleanup/optimization   |   Status:  assigned
Component:  Core (System |  Version:  1.10
  checks)|
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Tim Graham):

 François, I'm not sure how/if your idea is related to this ticket?

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

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

Re: [Django] #27546: Replace hardcoded class names in repr-methods

2016-11-28 Thread Django

#27546: Replace hardcoded class names in __repr__-methods
--+
 Reporter:  Mads Jensen   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Core (Other)  |  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:  1 |UI/UX:  0
--+
Changes (by Tim Graham):

 * component:  Uncategorized => Core (Other)
 * stage:  Unreviewed => Accepted


Comment:

 Sure, while there it would be nice to add tests if missing.

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

Re: [Django] #27545: Django conditional If-Match: * returns precondition failed response

2016-11-28 Thread Django

#27545: Django conditional If-Match: * returns precondition failed response
-+-
 Reporter:  David Harrigan   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  HTTP handling|  Version:  1.10
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  precondition,| Triage Stage:
  etags, etag,  if-match |  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:

 It's not clear to me that this is a critical issue that qualifies for a
 backport. As described in the supported versions policy, 1.9 and 1.8 are
 only receiving fixes for security and data loss issues.

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

Re: [Django] #27545: Django conditional If-Match: * returns precondition failed response

2016-11-28 Thread Django

#27545: Django conditional If-Match: * returns precondition failed response
-+-
 Reporter:  David Harrigan   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  HTTP handling|  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:  precondition,| Triage Stage:
  etags, etag,  if-match |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by David Harrigan):

 Replying to [comment:1 Tim Graham]:
 > Unless the issue is a regression from an older version of Django, it's
 unlikely to qualify for a fix on the 1.10 branch. See our
 [https://docs.djangoproject.com/en/dev/internals/release-process
 /#supported-versions support versions policy].

 Yes, I believe this behavior exists for version 1.8.x (LTS) and 1.9.x.  I
 can prepare a patch for these branches if this issue qualifies for a fix?

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

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

Re: [Django] #27534: Add CSRF_COOKIE_HTTPONLY note to CSRF AJAX docs

2016-11-28 Thread Django

Comment (by Andrew Charles):

Replying to [comment:1 Tim Graham]:
> It seems fine, but allegedly `CSRF_COOKIE_HTTPONLY`
[https://groups.google.com/forum/#!topic/django-developers/nXjfLd8ba5k
doesn't provide any additional security]. So I'm not sure if we're wasting
our time enhancing its documentation rather than deemphasizing it in the
documentation (or even removing it)?
I know that a browser can ignore this setting and that it doesn't really
provide additional security, but `CSRF_COOKIE_HTTPONLY` is currently
recommended when running `python manage.py check --deploy`. Until it is
removed I think this would improve the docs and avoid confusion when using
it with AJAX.

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

[Django] #27546: Replace hardcoded class names in repr-methods

2016-11-28 Thread Django

#27546: Replace hardcoded class names in __repr__-methods
+
   Reporter:  Mads Jensen   |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Uncategorized |Version:  1.10
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  1
  UI/UX:  0 |
+
 I noticed there are a few places where {{{__repr__}}} does not use
 {{{self.__class__.__name__}}}. I think this is a small clean-up that would
 make sense to do, but perhaps there was a good reason not to do that
 (probably they're never subclassed?). The following output is from grep:

 {{{
 django/db/models/query.py:return "" % self.query
 django/db/models/sql/query.py:return "" % self
 django/db/migrations/state.py:return "" %
 (self.app_label, self.name)
 django/utils/baseconv.py:return "" %
 (len(self.digits), self.digits)
 django/core/management/commands/makemessages.py:return
 "" % os.sep.join([self.dirpath, self.file])
 django/core/serializers/base.py:return "" % (
 }}}

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

Re: [Django] #27545: Django conditional If-Match: * returns precondition failed response

2016-11-28 Thread Django

#27545: Django conditional If-Match: * returns precondition failed response
-+-
 Reporter:  David Harrigan   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  HTTP handling|  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:  precondition,| Triage Stage:
  etags, etag,  if-match |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 Unless the issue is a regression from an older version of Django, it's
 unlikely to qualify for a fix on the 1.10 branch. See our
 [https://docs.djangoproject.com/en/dev/internals/release-process
 /#supported-versions support versions policy].

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

[Django] #27545: Django conditional If-Match: * returns precondition failed response

2016-11-28 Thread Django

#27545: Django conditional If-Match: * returns precondition failed response
-+-
   Reporter:  David  |  Owner:  nobody
  Harrigan   |
   Type:  Bug| Status:  new
  Component:  HTTP   |Version:  1.10
  handling   |   Keywords:  precondition,
   Severity:  Normal |  etags, etag,  if-match
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 I believe there is a small bug in how `If-Match: *` behavior is supposed
 to work in Django version <= 1.10.  I know that 1.11 is migrating to
 RFC-7232 specification conditional header, and that version <= 1.10
 implements according to RFC-2616.

 Expected behavior of `If-Match: *` according to RFC-2616:
 > If any of the entity tags match the entity tag of the entity that
 > would have been returned in the response to a similar GET request
 > (without the If-Match header) on that resource, or if "*" is given
 > and any current entity exists for that resource, then the server MAY
 > perform the requested method as if the If-Match header field did not
 > exist.

 So if `*` is given as the field-value, Django should allow the process to
 continue as long as the entity exits.

 Current behavior:
 https://github.com/django/django/blob/1.10.3/django/utils/cache.py#L184

 Where `etag` variable is the etag for the entity in question.

 {{{
 # returns precondition failed if this evaluates to true
 (not etag and '*' in etags) or (etag and etag not in etags)
 }}}

 **Problem**: * in etags not considered here if `etag` is present.
 According to the RFC,  as long as the entity is present on the server,
 If-Match: * should yield in as If-Match header was not given by the
 client.   This scenario here in Django implementation results in
 precondition failed.

 I believe the above code should be re-written as something like:
 {{{
 not etag or  # not etag == no
 entity, so always return a 412
 not ('*' in etags or etag in etags)# allow * in etags or client
 specified etag in etags
 }}}

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

Re: [Django] #27402: When using i18n_patterns and prefix_default_language=False, 404 page redirects incorrectly

2016-11-28 Thread Django

#27402: When using i18n_patterns and prefix_default_language=False, 404 page
redirects incorrectly
--+
 Reporter:  Hovi  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Internationalization  |  Version:  1.10
 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
 * stage:  Ready for checkin => Accepted


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

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

Re: [Django] #27544: F() Expressions updating dates in .update() field fails on SQLite

2016-11-28 Thread Django

#27544: F() Expressions updating dates in .update() field fails on SQLite
-+-
 Reporter:  Gary Graham  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  F()  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 In the `sqlite3/operations.py` file referenced in the traceback, it might
 be enough to check the `datetime` using `django.utils.timezone.is_aware()`
 and skip the `timezone.make_aware()` call if appropriate.

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

Re: [Django] #27544: F() Expressions updating dates in .update() field fails on SQLite

2016-11-28 Thread Django

#27544: F() Expressions updating dates in .update() field fails on SQLite
-+-
 Reporter:  Gary Graham  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  F()  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Gary Graham):

 Replying to [comment:2 Tim Graham]:
 > The regression seems limited to SQLite. If you could provide a patch, we
 can backport to 1.10. Thanks.

 OK, but I have no clue where to even start looking. I will start tracing,
 but if you could give me a reasonable starting point, I would appreciate
 it. The first time I ever opened the Django repo was to submit this bug.

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

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

Re: [Django] #27321: ignores_quoted_identifier_case broken on MySQL on OS X/Windows

2016-11-28 Thread Django

#27321: ignores_quoted_identifier_case broken on MySQL on OS X/Windows
-+-
 Reporter:  Adam Chainz  |Owner:  Adam
 |  Chainz
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  mysql, mariadb   | 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:  assigned => closed
 * resolution:   => fixed


Comment:

 In [changeset:"95238a7de867e2a23a9247e3d6d8f654f4cee908" 95238a7d]:
 {{{
 #!CommitTicketReference repository=""
 revision="95238a7de867e2a23a9247e3d6d8f654f4cee908"
 Fixed #27321 -- Added detection for table case name sensitivity on 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.e7c4846e65eb246ff703ec9b78058c19%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27544: F() Expressions updating dates in .update() field fails on SQLite (was: F() Expressions updating dates in .update() field fails)

2016-11-28 Thread Django

#27544: F() Expressions updating dates in .update() field fails on SQLite
-+-
 Reporter:  Gary Graham  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  F()  | 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):

 * stage:  Unreviewed => Accepted


Comment:

 The regression seems limited to SQLite. If you could provide a patch, we
 can backport to 1.10. 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/063.91b5a0b576da46c0b341a32b6730f50f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27544: F() Expressions updating dates in .update() field fails

2016-11-28 Thread Django

#27544: F() Expressions updating dates in .update() field fails
-+-
 Reporter:  Gary Graham  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  F()  | 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):

 * component:  Uncategorized => Database layer (models, ORM)


Old description:

> Upon upgrading from 1.8 -> 1.10, I noticed that some code I had written
> now threw an error.  Specifically, attempting to update datetime field's
> via F expression.
>
> Bisect log, about 3000 commits back -> https://dpaste.de/HGYb
>
> Branch with test showing regression ->
> https://github.com/tadgh/django/commit/c31133261c68b10525b8e3b34e6895a0c6ece4d0
>
> Apparent first commit where regression occurs ->
> https://github.com/django/django/pull/4601/commits/ed83881e648771d22658f21b939f66e75c499864
>
> Stacktrace from failure -> https://dpaste.de/DkSV

New description:

 Upon upgrading from 1.8 -> 1.10, I noticed that some code I had written
 now threw an error.  Specifically, attempting to update datetime field's
 via F expression.

 Branch with test showing regression ->
 https://github.com/tadgh/django/commit/c31133261c68b10525b8e3b34e6895a0c6ece4d0

 Bisected to ed83881e648771d22658f21b939f66e75c499864: Fixed #23820 --
 Supported per-database time zone.

 Stacktrace from failure:
 {{{
 ==
 ERROR: test_F_expression_fails (timezones.test_regression.ProveRegression)
 --
 Traceback (most recent call last):
   File "/home/tadgh/Projects/django/tests/timezones/test_regression.py",
 line 22, in test_F_expression_fails
 self.timestamp.refresh_from_db()
   File "/home/tadgh/Projects/django/django/db/models/base.py", line 585,
 in refresh_from_db
 db_instance = db_instance_qs.get()
   File "/home/tadgh/Projects/django/django/db/models/query.py", line 381,
 in get
 num = len(clone)
   File "/home/tadgh/Projects/django/django/db/models/query.py", line 240,
 in __len__
 self._fetch_all()
   File "/home/tadgh/Projects/django/django/db/models/query.py", line 1061,
 in _fetch_all
 self._result_cache = list(self.iterator())
   File "/home/tadgh/Projects/django/django/db/models/query.py", line 68,
 in __iter__
 for row in compiler.results_iter(results):
   File "/home/tadgh/Projects/django/django/db/models/sql/compiler.py",
 line 806, in results_iter
 row = self.apply_converters(row, converters)
   File "/home/tadgh/Projects/django/django/db/models/sql/compiler.py",
 line 790, in apply_converters
 value = converter(value, expression, self.connection,
 self.query.context)
   File
 "/home/tadgh/Projects/django/django/db/backends/sqlite3/operations.py",
 line 159, in convert_datetimefield_value
 value = timezone.make_aware(value, self.connection.timezone)
   File "/home/tadgh/Projects/django/django/utils/timezone.py", line 364,
 in make_aware
 return timezone.localize(value, is_dst=is_dst)
   File "/home/tadgh/.venvs/django_env/lib/python3.4/site-
 packages/pytz/__init__.py", line 227, in localize
 raise ValueError('Not naive datetime (tzinfo is already set)')
 ValueError: Not naive datetime (tzinfo is already set)
 }}}

--

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

[Django] #27544: F() Expressions updating dates in .update() field fails

2016-11-28 Thread Django

#27544: F() Expressions updating dates in .update() field fails
-+
Reporter: Gary Graham| Owner: nobody
Type: Bug| Status: new
Component: Uncategorized |Version: 1.10
Severity: Normal | Keywords: F()
Triage Stage: Unreviewed | Has patch: 0
Needs documentation: 0 |Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-+
Upon upgrading from 1.8 -> 1.10, I noticed that some code I had written
now threw an error. Specifically, attempting to update datetime field's
via F expression.

Bisect log, about 3000 commits back -> https://dpaste.de/HGYb

Branch with test showing regression ->
https://github.com/tadgh/django/commit/c31133261c68b10525b8e3b34e6895a0c6ece4d0

Apparent first commit where regression occurs ->

https://github.com/django/django/pull/4601/commits/ed83881e648771d22658f21b939f66e75c499864

Stacktrace from failure -> https://dpaste.de/DkSV

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

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

Re: [Django] #27543: AttributeError: '_Frame' object has no attribute 'f_back' / Django and celery error logging gone wrong

2016-11-28 Thread Django

#27543: AttributeError: '_Frame' object has no attribute 'f_back' / Django and
celery error logging gone wrong
-+-
 Reporter:  Simon Chenard|Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  Error reporting  |  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:  celery logging   | Triage Stage:
  traceback  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 Can you provide a way to reproduce the issue without celery to confirm
 it's a Django bug and not something that should be fixed in celery?

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

Re: [Django] #27543: AttributeError: '_Frame' object has no attribute 'f_back' / Django and celery error logging gone wrong

2016-11-28 Thread Django

#27543: AttributeError: '_Frame' object has no attribute 'f_back' / Django and
celery error logging gone wrong
-+-
 Reporter:  Simon Chenard|Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  Error reporting  |  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:  celery logging   | Triage Stage:
  traceback  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette):

 That looks similar to #17699.

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

Re: [Django] #27543: AttributeError: '_Frame' object has no attribute 'f_back' / Django and celery error logging gone wrong

2016-11-28 Thread Django

#27543: AttributeError: '_Frame' object has no attribute 'f_back' / Django and
celery error logging gone wrong
-+-
 Reporter:  Simon Chenard|Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  Error reporting  |  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:  celery logging   | Triage Stage:
  traceback  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Simon Chenard:

Old description:

> When an error is raised inside a celery task, django crashes with the
> error described in the summary. This error is not raised anywhere else in
> the application, only in a celery task. Came across this situation trying
> to understand why I was not getting error emails for celery tasks.
> Triggered this exception by adding :
>
> CELERY_WORKER_HIJACK_ROOT_LOGGER = False
>
> Implying otherwise the error is not redirected to the AdminEmailHandler.
>
> Django version : 1.10.2
> Celery version : 4.0.0
>
> (stacktrace is below)
>
> The method "get_traceback_frame_variables" is the cause of this problem.
> By wrapping a try except around the code of the method and returning an
> empty array, I roughly get what I expect : an email describing the error
> with the adequate traceback.
>
> My logging setup :
>  LOGGING = {
>  'version': 1,
>  'disable_existing_loggers': False,
>  'filters': {
>  'task_id': {
>  '()': 'lib.logging.task_filter.TaskIDFilter'
>  },
>  'require_debug_false': {
>  '()': 'django.utils.log.RequireDebugFalse'
>  }
>  },
>  'formatters' : {
>  'task': {
>  'format': LOGGING_TASK_FORMAT
>  },
>  },
>  'handlers': {
>  'mail_admins': {
>  'level': 'ERROR',
>  'class': 'django.utils.log.AdminEmailHandler',
>  'include_html': True,
>  'filters': ['require_debug_false'], # commented or not, the
> error happens with DEBUG = True or False
>  },
>  },
>  'loggers': {
>  '': {
>  'handlers': ['console', 'mail_admins'],
>  'level': 'INFO',
>  'propagate': True
>  },
>  }
>   }
>

> Here is the stacktrace :
>
> Traceback (most recent call last):
>   File "/home/simon/code/caravan/fibre/env-aws/lib/python3.4/site-
> packages/celery/app/trace.py", line 382, in trace_task
> I, R, state, retval = on_error(task_request, exc, uuid)
>   File "/home/simon/code/caravan/fibre/env-aws/lib/python3.4/site-
> packages/celery/app/trace.py", line 324, in on_error
> task, request, eager=eager, call_errbacks=call_errbacks,
>   File "/home/simon/code/caravan/fibre/env-aws/lib/python3.4/site-
> packages/celery/app/trace.py", line 158, in handle_error_state
> call_errbacks=call_errbacks)
>   File "/home/simon/code/caravan/fibre/env-aws/lib/python3.4/site-
> packages/celery/app/trace.py", line 212, in handle_failure
> self._log_error(task, req, einfo)
>   File "/home/simon/code/caravan/fibre/env-aws/lib/python3.4/site-
> packages/celery/app/trace.py", line 242, in _log_error
> extra={'data': context})
>   File "/usr/lib/python3.4/logging/__init__.py", line 1341, in log
> self._log(level, msg, args, **kwargs)
>   File "/usr/lib/python3.4/logging/__init__.py", line 1409, in _log
> self.handle(record)
>   File "/usr/lib/python3.4/logging/__init__.py", line 1419, in handle
> self.callHandlers(record)
>   File "/usr/lib/python3.4/logging/__init__.py", line 1481, in
> callHandlers
> hdlr.handle(record)
>   File "/usr/lib/python3.4/logging/__init__.py", line 853, in handle
> self.emit(record)
>   File "/home/simon/code/caravan/fibre/env-aws/lib/python3.4/site-
> packages/django/utils/log.py", line 119, in emit
> message = "%s\n\n%s" % (self.format(no_exc_record),
> reporter.get_traceback_text())
>   File "/home/simon/code/caravan/fibre/env-aws/lib/python3.4/site-
> packages/django/views/debug.py", line 325, in get_traceback_text
> c = Context(self.get_traceback_data(), autoescape=False,
> use_l10n=False)
>   File "/home/simon/code/caravan/fibre/env-aws/lib/python3.4/site-
> packages/django/views/debug.py", line 264, in get_traceback_data
> frames = self.get_traceback_frames()
>   File "/home/simon/code/caravan/fibre/env-aws/lib/python3.4/site-
> packages/django/views/debug.py", line 420, in get_traceback_frames
> 'vars': self.filter.get_traceback_frame_variables(self.request,
> tb.tb_frame),
>   File

[Django] #27543: AttributeError: '_Frame' object has no attribute 'f_back' / Django and celery error logging gone wrong

2016-11-28 Thread Django

#27543: AttributeError: '_Frame' object has no attribute 'f_back' / Django and
celery error logging gone wrong
-+-
   Reporter:  Simon  |  Owner:  (none)
  Chenard|
   Type:  Bug| Status:  new
  Component:  Error  |Version:  1.10
  reporting  |   Keywords:  celery logging
   Severity:  Normal |  traceback
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 When an error is raised inside a celery task, django crashes with the
 error described in the summary. This error is not raised anywhere else in
 the application, only in a celery task. Came across this situation trying
 to understand why I was not getting error emails for celery tasks.
 Triggered this exception by adding :

 CELERY_WORKER_HIJACK_ROOT_LOGGER = False

 Implying otherwise the error is not redirected to the AdminEmailHandler.

 Django version : 1.10.2
 Celery version : 4.0.0

 (stacktrace is below)

 The method "get_traceback_frame_variables" is the cause of this problem.
 By wrapping a try except around the code of the method and returning an
 empty array, I roughly get what I expect : an email describing the error
 with the adequate traceback.

 My logging setup :
  LOGGING = {
  'version': 1,
  'disable_existing_loggers': False,
  'filters': {
  'task_id': {
  '()': 'lib.logging.task_filter.TaskIDFilter'
  },
  'require_debug_false': {
  '()': 'django.utils.log.RequireDebugFalse'
  }
  },
  'formatters' : {
  'task': {
  'format': LOGGING_TASK_FORMAT
  },
  },
  'handlers': {
  'mail_admins': {
  'level': 'ERROR',
  'class': 'django.utils.log.AdminEmailHandler',
  'include_html': True,
  'filters': ['require_debug_false'], # commented or not, the
 error happens with DEBUG = True or False
  },
  },
  'loggers': {
  '': {
  'handlers': ['console', 'mail_admins'],
  'level': 'INFO',
  'propagate': True
  },
  }
   }


 Here is the stacktrace :

 Traceback (most recent call last):
   File "/home/simon/code/caravan/fibre/env-aws/lib/python3.4/site-
 packages/celery/app/trace.py", line 382, in trace_task
 I, R, state, retval = on_error(task_request, exc, uuid)
   File "/home/simon/code/caravan/fibre/env-aws/lib/python3.4/site-
 packages/celery/app/trace.py", line 324, in on_error
 task, request, eager=eager, call_errbacks=call_errbacks,
   File "/home/simon/code/caravan/fibre/env-aws/lib/python3.4/site-
 packages/celery/app/trace.py", line 158, in handle_error_state
 call_errbacks=call_errbacks)
   File "/home/simon/code/caravan/fibre/env-aws/lib/python3.4/site-
 packages/celery/app/trace.py", line 212, in handle_failure
 self._log_error(task, req, einfo)
   File "/home/simon/code/caravan/fibre/env-aws/lib/python3.4/site-
 packages/celery/app/trace.py", line 242, in _log_error
 extra={'data': context})
   File "/usr/lib/python3.4/logging/__init__.py", line 1341, in log
 self._log(level, msg, args, **kwargs)
   File "/usr/lib/python3.4/logging/__init__.py", line 1409, in _log
 self.handle(record)
   File "/usr/lib/python3.4/logging/__init__.py", line 1419, in handle
 self.callHandlers(record)
   File "/usr/lib/python3.4/logging/__init__.py", line 1481, in
 callHandlers
 hdlr.handle(record)
   File "/usr/lib/python3.4/logging/__init__.py", line 853, in handle
 self.emit(record)
   File "/home/simon/code/caravan/fibre/env-aws/lib/python3.4/site-
 packages/django/utils/log.py", line 119, in emit
 message = "%s\n\n%s" % (self.format(no_exc_record),
 reporter.get_traceback_text())
   File "/home/simon/code/caravan/fibre/env-aws/lib/python3.4/site-
 packages/django/views/debug.py", line 325, in get_traceback_text
 c = Context(self.get_traceback_data(), autoescape=False,
 use_l10n=False)
   File "/home/simon/code/caravan/fibre/env-aws/lib/python3.4/site-
 packages/django/views/debug.py", line 264, in get_traceback_data
 frames = self.get_traceback_frames()
   File "/home/simon/code/caravan/fibre/env-aws/lib/python3.4/site-
 packages/django/views/debug.py", line 420, in get_traceback_frames
 'vars': self.filter.get_traceback_frame_variables(self.request,
 tb.tb_frame),
   File "/home/simon/code/caravan/fibre/env-aws/lib/python3.4/site-
 packages/django/views/debug.py", line 191, in
 get_traceback_frame_variables
 current_frame = tb_frame.f_back
 AttributeError:

Re: [Django] #27321: ignores_quoted_identifier_case broken on MySQL on OS X/Windows

2016-11-28 Thread Django

#27321: ignores_quoted_identifier_case broken on MySQL on OS X/Windows
-+-
 Reporter:  Adam Chainz  |Owner:  Adam
 |  Chainz
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  mysql, mariadb   | 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):

 * stage:  Accepted => Ready for checkin


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

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

Re: [Django] #27542: Client.force_login() shouldn't use authentication backends without a get_user() method (was: Testclients force_login should be smarter about which authentication backend is used)

2016-11-28 Thread Django

#27542: Client.force_login() shouldn't use authentication backends without a
get_user() method
--+
 Reporter:  Tom   |Owner:  nobody
 Type:  Cleanup/optimization  |   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
--+
Changes (by Tim Graham):

 * type:  New feature => Cleanup/optimization
 * 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/061.88d7700c54595179443fbc8ba78337f5%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #27542: Testclients force_login should be smarter about which authentication backend is used

2016-11-28 Thread Django

#27542: Testclients force_login should be smarter about which authentication
backend is used
-+
   Reporter:  Tom|  Owner:  nobody
   Type:  New feature| Status:  new
  Component:  Testing framework  |Version:  1.10
   Severity:  Normal |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 In the current code if no `backend` is passed to the
 TestClient.force_login it simply uses the first one:

 https://github.com/django/django/blob/master/django/test/client.py#L635

 I think this could be improved. Libraries like `django-rules` are
 implemented as an authentication backend but don't implement a `get_user`
 method. This leads to confusing errors, as described in this ticket:
 https://github.com/dfunckt/django-rules/issues/46

 Perhaps rather than doing `backend = settings.AUTHENTICATION_BACKENDS[0]`
 it could filter out backends that don't implement a `get_user` method, or
 follow the usual chain of authentication backends (i.e skipping ones that
 return None)?

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

Re: [Django] #27537: Provide a simpler way to default runserver IP/port to 0.0.0.0:8000

2016-11-28 Thread Django

#27537: Provide a simpler way to default runserver IP/port to 0.0.0.0:8000
-+-
 Reporter:  Ed Morley|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Core (Management |  Version:  1.10
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:  runserver, bind, | Triage Stage:
  loopback   |  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Ed Morley):

 Posted:
 https://groups.google.com/forum/#!topic/django-developers/-f_6QVC7fic

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

Re: [Django] #26632: System check for list_display_links ignores value of ModelAdmin.get_list_display()

2016-11-28 Thread Django

#26632: System check for list_display_links ignores value of
ModelAdmin.get_list_display()
---+
 Reporter:  Zach Borboa|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  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


Comment:

 A test is also 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/068.9a1ce1b634e5d311c3ee6687131aad32%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #15727: Add support for Content-Security-Policy (CSP) to core

2016-11-28 Thread Django

#15727: Add support for Content-Security-Policy (CSP) to core
---+--
 Reporter:  db.pub.mail@…  |Owner:  Rudolph Froger
 Type:  New feature|   Status:  assigned
Component:  HTTP handling  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  1
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by Vlastimil Zíma):

 If the `django-csp` should be included in Django. I suggest to modify it
 to allow enforcing and monitoring mode alongside, as noted in CSP
 specification itself. One set of rules may be enforced and different set
 of rules may be reported.

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

Re: [Django] #27533: inspectdb crashes on unsupported unique_together constraints in PostgreSQL (was: inspectdb command crashes when generate model classes from postgres db)

2016-11-28 Thread Django

#27533: inspectdb crashes on unsupported unique_together constraints in 
PostgreSQL
-+-
 Reporter:  Wei Ma   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 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):

 * stage:  Unreviewed => Accepted
 * component:  Core (Other) => Database layer (models, ORM)
 * needs_tests:  0 => 1


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

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

Re: [Django] #26327: Add JSONB_AGG to contrib.postgres

2016-11-28 Thread Django

#26327: Add JSONB_AGG to contrib.postgres
-+-
 Reporter:  Tomasz Nowak |Owner:  Mads
 |  Jensen
 Type:  New feature  |   Status:  new
Component:  contrib.postgres |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  JSON postgres| Triage Stage:  Ready for
  aggregate  |  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:"aa2cb4c622dfd5709ba89ac3cace959202318987" aa2cb4c]:
 {{{
 #!CommitTicketReference repository=""
 revision="aa2cb4c622dfd5709ba89ac3cace959202318987"
 Refs #26327 -- Renamed JsonAgg to JSONBAgg.

 Thanks to Christian von Roques for the report.
 }}}

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

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

Re: [Django] #26327: Add JSONB_AGG to contrib.postgres

2016-11-28 Thread Django

#26327: Add JSONB_AGG to contrib.postgres
-+-
 Reporter:  Tomasz Nowak |Owner:  Mads
 |  Jensen
 Type:  New feature  |   Status:  closed
Component:  contrib.postgres |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  JSON postgres| Triage Stage:  Ready for
  aggregate  |  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


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

Re: [Django] #27541: Provide hooks to override manifest file storage in ManifestFilesMixin

2016-11-28 Thread Django

#27541: Provide hooks to override manifest file storage in ManifestFilesMixin
-+-
 Reporter:  Ryan Lopopolo|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  contrib.staticfiles  |  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 Tim Graham):

 I'm not sure if I understand the suggestion, can you provide a patch? Will
 it be backwards compatible?

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

41 matches

Mail list logo