Re: [Django] #24485: Support for annotate(end=F('start') + F('duration'), output_field=DateTimeField)

2015-03-18 Thread Django
#24485: Support for annotate(end=F('start') + F('duration'),
output_field=DateTimeField)
-+-
 Reporter:  yoyoma   |Owner:  jarshwah
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  1.8beta2
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  durationfield,   | Triage Stage:  Accepted
  aggregation, annotation|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

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


Re: [Django] #24500: Django runtests - 3 tests fail on windows due to encoding troubles

2015-03-18 Thread Django
#24500: Django runtests - 3 tests fail on windows due to encoding troubles
-+-
 Reporter:  pakal|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:   |  Version:  1.7
  Internationalization   |
 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 timgraham):

 {{{
 >>> locale.getdefaultlocale()
 ('en_US', 'cp1252')

 $ xgettext -V
 xgettext.exe (GNU gettext-tools) 0.17
 Copyright (C) 1995-1998, 2000-2007 Free Software Foundation, Inc.
 License GPLv3+: GNU GPL version 3 or later
 
 This is free software: you are free to change and redistribute it.
 There is NO WARRANTY, to the extent permitted by law.
 Written by Ulrich Drepper.
 }}}

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


Re: [Django] #24485: Support for annotate(end=F('start') + F('duration'), output_field=DateTimeField)

2015-03-18 Thread Django
#24485: Support for annotate(end=F('start') + F('duration'),
output_field=DateTimeField)
-+-
 Reporter:  yoyoma   |Owner:  jarshwah
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  1.8beta2
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  durationfield,   | Triage Stage:  Ready for
  aggregation, annotation|  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by jarshwah):

 You're right, I thought I had tested and written the result here, but that
 was for 24486. Doing both tickets at the same time was a mistake. I'll
 take a look at this now, and any fix I come up (and document) will also be
 replicated in the tests to ensure I don't not-fix it again.

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


Re: [Django] #24486: UnboundLocalError in db.models.expressions

2015-03-18 Thread Django
#24486: UnboundLocalError in db.models.expressions
-+-
 Reporter:  yoyoma   |Owner:  jarshwah
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.8beta2
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by yoyoma):

 For posterity, the patch addressed the issue fully, and sqlite3 is also
 supported. Thanks again, @timgraham and @jarshwah.

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


Re: [Django] #24485: Support for annotate(end=F('start') + F('duration'), output_field=DateTimeField)

2015-03-18 Thread Django
#24485: Support for annotate(end=F('start') + F('duration'),
output_field=DateTimeField)
-+-
 Reporter:  yoyoma   |Owner:  jarshwah
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  1.8beta2
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  durationfield,   | Triage Stage:  Ready for
  aggregation, annotation|  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by yoyoma):

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


Comment:

 Sorry to reopen this ticket, guys. I've been so busy the past few days I
 didn't get a chance to try out the new code / docs until after work
 tonight. The issue with the docs update and code updates, as I see them,
 is that {{{Expression}}} takes only 2 arguments, namely {{{self}}} and
 {{{output_field}}}, so the example in the docs (fitted to my schema):

 {{{
 from django.db import models
 from myapp.models import Ticket

 Ticket.objects.annotate(
 expires_at=models.Expression(
 models.F('active_at') + models.F('duration'),
 output_field=models.DateTimeField()
 )
 )
 }}}

 results in {{{TypeError: __init__() got multiple values for argument
 'output_field'}}}

 The aforementioned (by @jarshwah) method of simply adding an
 `output_field` to an a combined {{{F}}} didn't work either:

 {{{
 expires_at = models.F('active_at') + models.F('duration')
 expires_at.output_field = models.DateTimeField()
 Ticket.objects.annotate(expires_at=expires_at)
 }}}

 That resulted in:

 {{{
 django/db/models/query.py in iterator(self)
 259 if annotation_col_map:
 260 for attr_name, col_pos in
 annotation_col_map.items():
 --> 261 setattr(obj, attr_name, row[col_pos])
 262
 263 # Add the known related objects to the model, if there
 are any

 AttributeError: can't set attribute
 }}}

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


Re: [Django] #24495: Allow unsaved objects in ForeignKey check to be bypassed

2015-03-18 Thread Django
#24495: Allow unsaved objects in ForeignKey check to be bypassed
-+-
 Reporter:  kaedroho |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.8beta2
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"a8c53041f9645df9bfa744027efb2a36867422d8" a8c53041]:
 {{{
 #!CommitTicketReference repository=""
 revision="a8c53041f9645df9bfa744027efb2a36867422d8"
 [1.8.x] Fixed #24495 -- Allowed unsaved model instance assignment check to
 be bypassed.

 Backport of 81e1a35c364e5353d2bf99368ad30a4184fbb653 from master
 }}}

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

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


Re: [Django] #24498: Issues with migrations while running tests

2015-03-18 Thread Django
#24498: Issues with migrations while running tests
-+-
 Reporter:  mmartincevic |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (Management |  Version:  1.7
  commands)  |
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by timgraham):

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


Re: [Django] #24495: Allow unsaved objects in ForeignKey check to be bypassed

2015-03-18 Thread Django
#24495: Allow unsaved objects in ForeignKey check to be bypassed
-+-
 Reporter:  kaedroho |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.8beta2
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"81e1a35c364e5353d2bf99368ad30a4184fbb653" 81e1a35]:
 {{{
 #!CommitTicketReference repository=""
 revision="81e1a35c364e5353d2bf99368ad30a4184fbb653"
 Fixed #24495 -- Allowed unsaved model instance assignment check to be
 bypassed.
 }}}

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


Re: [Django] #23757: Spatialite backend doesn't support 3d introspection

2015-03-18 Thread Django
#23757: Spatialite backend doesn't support 3d introspection
-+-
 Reporter:  claudep  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  GIS  |  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:"02d78bb1a80706d941ffc6c892cc75208eb6b782" 02d78bb]:
 {{{
 #!CommitTicketReference repository=""
 revision="02d78bb1a80706d941ffc6c892cc75208eb6b782"
 Fixed build failure introduced by refs #23757.
 }}}

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


Re: [Django] #24495: Allow unsaved objects in ForeignKey check to be bypassed

2015-03-18 Thread Django
#24495: Allow unsaved objects in ForeignKey check to be bypassed
-+-
 Reporter:  kaedroho |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.8beta2
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * needs_better_patch:  1 => 0
 * 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/066.8a44849c6acaa1c5bd7269218e483cb5%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #24469: Revisit strategy of escaping Django's form elements in non-Django forms

2015-03-18 Thread Django
#24469: Revisit strategy of escaping Django's form elements in non-Django forms
-+-
 Reporter:  MoritzS  |Owner:  aaugustin
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Template system  |  Version:  1.8beta2
 Severity:  Normal   |   Resolution:
 Keywords:  forms fields media   | Triage Stage:  Accepted
  escape template jinja2 |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by MoritzS):

 I added the decorator in a [https://github.com/django/django/pull/4347 new
 PR].
 I'll work on adding it to where it's 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.cc8f06c05ff6b22e6e7f5bb3243fd486%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #24503: Misleading doc regarding language_code fallback

2015-03-18 Thread Django
#24503: Misleading doc regarding language_code fallback
--+
 Reporter:  pakal |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Internationalization  |  Version:  1.7
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by pakal):

 Attached is a patch for django <= 1.7,

 regarding the patching of 1.8 docs, I don't know what the status is
 exactly (work in progress ? followed in another ticket ?), I guess the
 person(s) refactoring i18n will be best placed to update the doc, below is
 just a draft sample in case it helps.

 {{{
 .. versionchanged:: 1.8

   The ``LANGUAGE_CODE`` is now  also used to provide a fallback
 translation,
   when no translation exists for a given literal in the user's preferred
 language.
 }}}

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


Re: [Django] #24503: Misleading doc regarding language_code fallback

2015-03-18 Thread Django
#24503: Misleading doc regarding language_code fallback
--+
 Reporter:  pakal |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Internationalization  |  Version:  1.7
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by pakal):

 * Attachment "0001-Correct-LANGUAGE_CODE-doc-for-django-1.7.patch" 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/063.27e219f6fd3d394f20868287706afdb4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #24503: Misleading doc regarding language_code fallback

2015-03-18 Thread Django
#24503: Misleading doc regarding language_code fallback
--+
 Reporter:  pakal |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Internationalization  |  Version:  1.7
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by claudep):

 * stage:  Unreviewed => Accepted


Comment:

 You are right, this is fixed in Django 1.8/master. Documentation patch
 welcome.

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


Re: [Django] #23757: Spatialite backend doesn't support 3d introspection

2015-03-18 Thread Django
#23757: Spatialite backend doesn't support 3d introspection
-+-
 Reporter:  claudep  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  GIS  |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Claude Paroz ):

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


Comment:

 In [changeset:"65129aac07022f23afa1df7ec7fad2216634cb38" 65129aa]:
 {{{
 #!CommitTicketReference repository=""
 revision="65129aac07022f23afa1df7ec7fad2216634cb38"
 Fixed #23757 -- Added 3D introspection support to Spatialite backend

 Thanks Tim Graham for the review.
 }}}

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

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


Re: [Django] #24500: Django runtests - 3 tests fail on windows due to encoding troubles

2015-03-18 Thread Django
#24500: Django runtests - 3 tests fail on windows due to encoding troubles
-+-
 Reporter:  pakal|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:   |  Version:  1.7
  Internationalization   |
 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 pakal):

 Weird, I updated to python 2.7.9 and tried with cmd.exe or git bash, still
 the same problem.

 I continued investigating, problems occur when django tries to lookup
 xgettext version.

 In gettext_popen_wrapper(), the output of
 django.core.management.utils.popen_wrapper is expected by django to be
 utf8 bytes, on python2 :

 {{{
 if six.PY2:
 stdout = stdout.decode('utf-8')
 }}}

 However, from what I see in the initial popen_wrapper(), there are no
 reasons for stdout to be unicode on python2, only stderr gets converted,
 and Popen (AFAIK) outputs bytes (in cp1252 encoding, in that case).

 {{{
 def  popen_wrapper(args, os_err_exc_type=CommandError):
 """
 Friendly wrapper around Popen.

 Returns stdout output, stderr output and OS status code.
 """
 print "USING ENCODING >", DEFAULT_LOCALE_ENCODING   # outputs
 "cp1252"
 try:
 p = Popen(args, shell=False, stdout=PIPE, stderr=PIPE,
 close_fds=os.name != 'nt', universal_newlines=True)
 except OSError as e:
 strerror = force_text(e.strerror, DEFAULT_LOCALE_ENCODING,
   strings_only=True)
 six.reraise(os_err_exc_type, os_err_exc_type('Error executing %s:
 %s' %
 (args[0], strerror)), sys.exc_info()[2])
 output, errors = p.communicate()
 return (
 output,
 force_text(errors, DEFAULT_LOCALE_ENCODING, strings_only=True),
 p.returncode
 )
 }}}

 This is a mystery to me... could anybody check the intermediate values of
 this "xgettext -V" stdout, as well as the system encodings
 (locale.getdefaultlocale() and stuffs), on a machine which doesn't fail
 these tests ?

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

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


Re: [Django] #16614: Support server-side cursors for queryset iteration in database backends

2015-03-18 Thread Django
#16614: Support server-side cursors for queryset iteration in database backends
-+-
 Reporter:  toofishes|Owner:  auvipy
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  memory cursors   | Triage Stage:  Accepted
  database   |
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by auvipy):

 * status:  new => assigned
 * owner:  nobody => auvipy
 * version:  1.3 => master


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

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


Re: [Django] #24483: keepdb migrations break choices as generators

2015-03-18 Thread Django
#24483: keepdb migrations break choices as generators
-+-
 Reporter:  davidszotten |Owner:  timgraham
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  1.8beta2
 Severity:  Normal   |   Resolution:
 Keywords:  migrations test  | Triage Stage:  Accepted
  keepdb |
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:"247251c2e1702831b7ab80a69a3f7f5831be3b96" 247251c]:
 {{{
 #!CommitTicketReference repository=""
 revision="247251c2e1702831b7ab80a69a3f7f5831be3b96"
 [1.8.x] Refs #24483 -- Added a test for deconstruction of Field.choices

 Backport of b4a56ed4f55502239cb11b57f0fa75baa0a97640 from master
 }}}

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

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


Re: [Django] #24483: keepdb migrations break choices as generators

2015-03-18 Thread Django
#24483: keepdb migrations break choices as generators
-+-
 Reporter:  davidszotten |Owner:  timgraham
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  1.8beta2
 Severity:  Normal   |   Resolution:
 Keywords:  migrations test  | Triage Stage:  Accepted
  keepdb |
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:"b4a56ed4f55502239cb11b57f0fa75baa0a97640" b4a56ed]:
 {{{
 #!CommitTicketReference repository=""
 revision="b4a56ed4f55502239cb11b57f0fa75baa0a97640"
 Refs #24483 -- Added a test for deconstruction of Field.choices
 }}}

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


Re: [Django] #17092: Internal Redirects with Apache

2015-03-18 Thread Django
#17092: Internal Redirects with Apache
--+
 Reporter:  anonymous |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  HTTP handling |  Version:  1.6
 Severity:  Normal|   Resolution:  fixed
 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 claudep):

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


Re: [Django] #23960: HTTP standard no longer requires the Location header to be an absolute URI

2015-03-18 Thread Django
#23960: HTTP standard no longer requires the Location header to be an absolute 
URI
-+-
 Reporter:  carljm   |Owner:  claudep
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  HTTP handling|  Version:  1.7
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Claude Paroz ):

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


Comment:

 In [changeset:"a0c2eb46dd5a782c11c44f13c8efad2778be1641" a0c2eb46]:
 {{{
 #!CommitTicketReference repository=""
 revision="a0c2eb46dd5a782c11c44f13c8efad2778be1641"
 Fixed #23960 -- Removed http.fix_location_header

 Thanks Carl Meyer for the report and Tim Graham for the review.
 }}}

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

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


Re: [Django] #24476: Allow using set_script_prefix as a contextmanager

2015-03-18 Thread Django
#24476: Allow using set_script_prefix as a contextmanager
-+-
 Reporter:  timgraham|Owner:  bpeschier
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Core (URLs)  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * has_patch:  0 => 1
 * stage:  Accepted => Ready for checkin


Comment:

 Don't forget to check "Has patch" so the ticket appears in the review
 queue.

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


Re: [Django] #24476: Allow using set_script_prefix as a contextmanager

2015-03-18 Thread Django
#24476: Allow using set_script_prefix as a contextmanager
-+-
 Reporter:  timgraham|Owner:  bpeschier
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Core (URLs)  |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"0339844b70895d6162b4595ae615e6edf843c6cd" 0339844b]:
 {{{
 #!CommitTicketReference repository=""
 revision="0339844b70895d6162b4595ae615e6edf843c6cd"
 Fixed #24476 -- Added context manager/decorator for overriding script
 prefix.

 Tests were using an undocumented keyword argument for easily overriding
 script prefix while reversing. This is now changed into a test utility
 which can be used as decorator or context manager.
 }}}

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


Re: [Django] #24495: Allow unsaved objects in ForeignKey check to be bypassed

2015-03-18 Thread Django
#24495: Allow unsaved objects in ForeignKey check to be bypassed
-+-
 Reporter:  kaedroho |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.8beta2
  (models, ORM)  |
 Severity:  Release blocker  |   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 timgraham):

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


Re: [Django] #24504: StandardError is not defined in django.utils.dictconfig

2015-03-18 Thread Django
#24504: StandardError is not defined in django.utils.dictconfig
-+-
 Reporter:  bh   |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Utilities|  Version:  1.7
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  Python 3, logging,   | Triage Stage:
  utils  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

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


Comment:

 `django.utils.dictconfig` is deprecated, please use Python's
 `logging.config` instead.

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


[Django] #24504: StandardError is not defined in

2015-03-18 Thread Django
#24504: StandardError is not defined in
---+--
 Reporter:  bh |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Utilities  |Version:  1.7
 Severity:  Normal |   Keywords:  Python 3, logging, utils
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+--
 I'm on Python 3.4.1 with Django 1.7.4.

 When using django.utils.dictconfig to configure custom logging and this
 function cannot configure a logging formatter than the code will "except"
 an SystemError which is not defined in this module or in __builtin__.

 I fixed this temporarily to fix my logging config with this workaround:

 {{{
 from django.utils import dictconfig
 class StandardError(Exception):
 pass

 dictconfig.StandardError = StandardError
 }}}

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


Re: [Django] #24504: StandardError is not defined in django.utils.dictconfig (was: StandardError is not defined in)

2015-03-18 Thread Django
#24504: StandardError is not defined in django.utils.dictconfig
-+-
 Reporter:  bh   |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Utilities|  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:  Python 3, logging,   | Triage Stage:
  utils  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by bh):

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


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

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


Re: [Django] #24469: Revisit strategy of escaping Django's form elements in non-Django forms

2015-03-18 Thread Django
#24469: Revisit strategy of escaping Django's form elements in non-Django forms
-+-
 Reporter:  MoritzS  |Owner:  aaugustin
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Template system  |  Version:  1.8beta2
 Severity:  Normal   |   Resolution:
 Keywords:  forms fields media   | Triage Stage:  Accepted
  escape template jinja2 |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by timgraham):

 Sounds good to me.

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

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


Re: [Django] #24469: Revisit strategy of escaping Django's form elements in non-Django forms

2015-03-18 Thread Django
#24469: Revisit strategy of escaping Django's form elements in non-Django forms
-+-
 Reporter:  MoritzS  |Owner:  aaugustin
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Template system  |  Version:  1.8beta2
 Severity:  Normal   |   Resolution:
 Keywords:  forms fields media   | Triage Stage:  Accepted
  escape template jinja2 |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by MoritzS):

 I looked into it and found 8 more classes that return `SafeStr` in their
 `__str__`:
 `django.contrib.gis.maps.google.overlays.GEvent`
 `django.contrib.gis.maps.google.overlays.GOverlayBase`
 `django.forms.formsets.BaseFormSet`
 `django.forms.utils.ErrorDict`
 `django.forms.utils.ErrorList`
 `django.forms.widgets.SubWidget`
 `django.forms.widgets.ChoiceInput`
 `django.forms.widgets.ChoiceFieldRenderer`

 I agree that using a mixin would add too much overhead, what about a
 decorator that adds the `__html__` method instead?
 Something like:
 {{{
 @html_safe
 class MyClass(object):
 def __str__(self):
 ...
 }}}

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


[Django] #24503: Misleading doc regarding language_code fallback

2015-03-18 Thread Django
#24503: Misleading doc regarding language_code fallback
--+
 Reporter:  pakal |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Internationalization  |Version:  1.7
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 The docs state that LANGUAGE_CODE will be used as fallback if a specific
 string has no translation in the active request language
 (https://docs.djangoproject.com/en/1.7/ref/settings/#language-code).

 However, my tests and my exploration of "real_trans.py" suggest that
 LANGUAGE_CODE is only used as a global fallback if the whole selected
 language is missing. Per-string fallback doesn't work it seems, on django
 <=1.7 at least (on current dev branch, lots of stuffs have moved in that
 code, so it seems a real fallback is getting implemented).

 Example of a test output:

 2015-03-18_14:48:34 UTC -  INFO - <722724742146458> Language active for
 request: 'de' (LANGUAGE_CODE: 'fr-FR')

 Translated string received : "'invalid input parameters'"  (so no
 translation occurred)

 When forcing active language to fr or fr-FR, the string is properly
 translated to "Paramètres invalides" in french.


 Is that a bug of django, an error in the docs, or an ertror on my side ? I
 may provide a patch to fix django<=1.7 docs, if it occurs that per-string
 language was actually never implemented.

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


Re: [Django] #24503: Misleading doc regarding language_code fallback

2015-03-18 Thread Django
#24503: Misleading doc regarding language_code fallback
-+-
 Reporter:  pakal|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:   |  Version:  1.7
  Internationalization   |
 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 pakal):

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


Old description:

> The docs state that LANGUAGE_CODE will be used as fallback if a specific
> string has no translation in the active request language
> (https://docs.djangoproject.com/en/1.7/ref/settings/#language-code).
>
> However, my tests and my exploration of "real_trans.py" suggest that
> LANGUAGE_CODE is only used as a global fallback if the whole selected
> language is missing. Per-string fallback doesn't work it seems, on django
> <=1.7 at least (on current dev branch, lots of stuffs have moved in that
> code, so it seems a real fallback is getting implemented).
>
> Example of a test output:
>
> 2015-03-18_14:48:34 UTC -  INFO - <722724742146458> Language active for
> request: 'de' (LANGUAGE_CODE: 'fr-FR')
>
> Translated string received : "'invalid input parameters'"  (so no
> translation occurred)
>
> When forcing active language to fr or fr-FR, the string is properly
> translated to "Paramètres invalides" in french.
>

> Is that a bug of django, an error in the docs, or an ertror on my side ?
> I may provide a patch to fix django<=1.7 docs, if it occurs that per-
> string language was actually never implemented.

New description:

 The docs state that LANGUAGE_CODE will be used as fallback if a specific
 string has no translation in the active request language
 (https://docs.djangoproject.com/en/1.7/ref/settings/#language-code).

 However, my tests and my exploration of "real_trans.py" suggest that
 LANGUAGE_CODE is only used as a global fallback if the whole selected
 language is missing. Per-string fallback doesn't work it seems, on django
 <=1.7 at least (on current dev branch, lots of stuffs have moved in that
 code, so it seems a real fallback is getting implemented).

 Example of a test output:

 2015-03-18_14:48:34 UTC -  INFO - <722724742146458> Language active for
 request: 'de' (LANGUAGE_CODE: 'fr-FR')

 Translated string received : "'invalid input parameters'"  (so no
 translation occurred)

 When forcing active language to fr or fr-FR, the string is properly
 translated to "Paramètres invalides" in french.


 Is that a bug of django, an error in the docs, or an error on my side ? I
 may provide a patch to fix django<=1.7 docs, if it occurs that per-string
 language fallback was actually never implemented yet.

--

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


Re: [Django] #24469: Revisit strategy of escaping Django's form elements in non-Django forms (was: forms, form fields and media are escaped wrongfully in non django templates)

2015-03-18 Thread Django
#24469: Revisit strategy of escaping Django's form elements in non-Django forms
-+-
 Reporter:  MoritzS  |Owner:  aaugustin
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Template system  |  Version:  1.8beta2
 Severity:  Normal   |   Resolution:
 Keywords:  forms fields media   | Triage Stage:  Accepted
  escape template jinja2 |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * has_patch:  1 => 0
 * type:  Bug => Cleanup/optimization
 * severity:  Release blocker => Normal
 * stage:  Ready for checkin => Accepted


Comment:

 Leaving this ticket open at Aymeric's request pending his further
 investigation.

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


Re: [Django] #24469: forms, form fields and media are escaped wrongfully in non django templates

2015-03-18 Thread Django
#24469: forms, form fields and media are escaped wrongfully in non django 
templates
-+-
 Reporter:  MoritzS  |Owner:  aaugustin
 Type:  Bug  |   Status:  assigned
Component:  Template system  |  Version:  1.8beta2
 Severity:  Release blocker  |   Resolution:
 Keywords:  forms fields media   | Triage Stage:  Ready for
  escape template jinja2 |  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:"571e093a258b00b25c24481af7acf0d0a034ec8c" 571e093a]:
 {{{
 #!CommitTicketReference repository=""
 revision="571e093a258b00b25c24481af7acf0d0a034ec8c"
 [1.8.x] Refs #24469 -- Fixed escaping of forms, fields, and media in non-
 Django templates.

 Backport of 6bff3439894ac22d80f270f36513fc86586273f3 from master
 }}}

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

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


Re: [Django] #24469: forms, form fields and media are escaped wrongfully in non django templates

2015-03-18 Thread Django
#24469: forms, form fields and media are escaped wrongfully in non django 
templates
-+-
 Reporter:  MoritzS  |Owner:  aaugustin
 Type:  Bug  |   Status:  assigned
Component:  Template system  |  Version:  1.8beta2
 Severity:  Release blocker  |   Resolution:
 Keywords:  forms fields media   | Triage Stage:  Ready for
  escape template jinja2 |  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:"6bff3439894ac22d80f270f36513fc86586273f3" 6bff343]:
 {{{
 #!CommitTicketReference repository=""
 revision="6bff3439894ac22d80f270f36513fc86586273f3"
 Refs #24469 -- Fixed escaping of forms, fields, and media in non-Django
 templates.
 }}}

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


Re: [Django] #24502: Using non model fields in an admin ModelForm does not work if the field is listed in fieldsets (and fields I think)

2015-03-18 Thread Django
#24502: Using non model fields in an admin ModelForm does not work if the field 
is
listed in fieldsets (and fields I think)
---+--
 Reporter:  bdauvergne |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  1.7
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by bdauvergne):

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


Comment:

 I worked around the problem with this hack in my code:

 {{{

 @@ -188,16 +189,30 @@ class AuthenticUserAdmin(UserAdmin):
  qs = models.Attribute.objects.filter(required=True)
  insertion_idx = 1
  if qs.exists():
  fieldsets = list(fieldsets)
  fieldsets.insert(insertion_idx,
  (_('Attributes'), {'fields': [at.name for at in
 qs]}))
  return fieldsets

 +def get_form(self, request, obj=None, **kwargs):
 +if 'fields' in kwargs:
 +fields = kwargs.pop('fields')
 +else:
 +fields = flatten_fieldsets(self.get_fieldsets(request, obj))
 +if obj:
 +qs = models.Attribute.objects.all()
 +else:
 +qs = models.Attribute.objects.filter(required=True)
 +non_model_fields = [a.name for a in qs]
 +fields = list(set(fields) - set(non_model_fields))
 +kwargs['fields'] = fields
 +return super(AuthenticUserAdmin, self).get_form(request, obj=obj,
 **kwargs)
 +
 }}}

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


[Django] #24502: Using non model fields in an admin ModelForm does not work if the field is listed in fieldsets (and fields I think)

2015-03-18 Thread Django
#24502: Using non model fields in an admin ModelForm does not work if the field 
is
listed in fieldsets (and fields I think)
---+
 Reporter:  bdauvergne |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  1.7
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 I have such change form:

 {{{
  19 class UserAttributeFormMixin(object):
  20 def __init__(self, *args, **kwargs):
  21 super(UserAttributeFormMixin, self).__init__(*args, **kwargs)
  22 self.attributes = self.get_attributes()
  23 initial = {}
  24 if 'instance' in kwargs:
  25 content_type =
 ContentType.objects.get_for_model(self.instance)
  26 for av in models.AttributeValue.objects.filter(
  27 content_type=content_type,
  28 object_id=self.instance.pk):
  29 initial[av.attribute.name] = av.to_python()
  30 for attribute in self.attributes:
  31 iv = initial.get(attribute.name)
  32 attribute.contribute_to_form(self, initial=iv)
  33

 class UserChangeForm(forms.UserAttributeFormMixin,
  11 AuthUserChangeForm):
  12
  13 class Meta(AuthUserChangeForm.Meta):
  14 model = get_user_model()
  15 fields = '__all__'
  16
 }}}

 Use by the following ModelAdmin:

 {{{
 161 class AuthenticUserAdmin(UserAdmin):
 162 fieldsets = (
 163 (None, {'fields': ('username', 'password')}),
 164 (_('Personal info'), {'fields': ('first_name', 'last_name',
 'email')}),
 165 (_('Permissions'), {'fields': ('is_active', 'is_staff',
 'is_superuser',
 166'groups')}),
 167 (_('Important dates'), {'fields': ('last_login',
 'date_joined')}),
 168 )
 169 form = admin_forms.UserChangeForm
 170 add_form = admin_forms.UserCreationForm
 171 add_fieldsets = (
 172 (None, {
 173 'classes': ('wide',),
 174 'fields': ('username', 'first_name', 'last_name',
 'email', 'password1', 'password2')}
 175 ),
 176 )
 177 list_filter = UserAdmin.list_filter +
 (UserRealmListFilter,ExternalUserListFilter)
 178
 179 def get_fieldsets(self, request, obj=None):
 180 fieldsets = deepcopy(super(AuthenticUserAdmin,
 self).get_fieldsets(request, obj))
 181 if obj:
 182 if not request.user.is_superuser:
 183 fieldsets[2][1]['fields'] = filter(lambda x: x !=
 184 'is_superuser', fieldsets[2][1]['fields'])
 185 qs = models.Attribute.objects.all()
 186 insertion_idx = 2
 187 else:
 188 qs = models.Attribute.objects.filter(required=True)
 189 insertion_idx = 1
 190 if qs.exists():
 191 fieldsets = list(fieldsets)
 192 fieldsets.insert(insertion_idx,·
 193 (_('Attributes'), {'fields': [at.name for at in
 qs]}))
 194 return fieldsets
 }}}

 I get the following traceback I did not get with Django 1.5 (I cannot say
 if it was already the case with Django 1.6 we skiped it):

 {{{

 /home/bdauvergne/.virtualenvs/authentic/local/lib/python2.7/site-
 packages/django/contrib/admin/options.py in changeform_view

 'name': force_text(opts.verbose_name), 'key':
 escape(object_id)})

 if request.method == 'POST' and "_saveasnew" in
 request.POST:

 return self.add_view(request,
 form_url=reverse('admin:%s_%s_add' % (

 opts.app_label, opts.model_name),

 current_app=self.admin_site.name))

 ModelForm = self.get_form(request, obj)

 ...

 if request.method == 'POST':

 form = ModelForm(request.POST, request.FILES,
 instance=obj)

 if form.is_valid():

 form_validated = True

 new_object = self.save_form(request, form, change=not
 add)

 else:

 ▶ Local vars
 /home/bdauvergne/.virtualenvs/authentic/local/lib/python2.7/site-
 packages/django/contrib/auth/admin.py in get_form

 """

 Use special form during user creation

 """

 defaults = {}

 if obj is None:

 defaults['form'] = self.add_form

 defaults.update(kwargs)

 return super(UserAdmin, self).get_form(request, obj,
 **defaults)

 ...

 def get_urls(self):

 from django.conf.urls import patterns

 return patterns('',

 (r'^(\d+)/password/$',

  self.admin_site.admin_view(self.user_change_password))

 ▶ 

Re: [Django] #24501: Documentation for user_passes_test is wrong and confusing

2015-03-18 Thread Django
#24501: Documentation for user_passes_test is wrong and confusing
--+
 Reporter:  lietu |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.7
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by bmispelon):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * easy:  0 => 1
 * needs_docs:   => 0
 * type:  Bug => Cleanup/optimization
 * stage:  Unreviewed => Accepted


Comment:

 Hi,

 You're right, the two examples are inconsistent and can be confusing.

 There's definitely room for improvement here.

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


[Django] #24501: Documentation for user_passes_test is wrong and confusing

2015-03-18 Thread Django
#24501: Documentation for user_passes_test is wrong and confusing
---+
 Reporter:  lietu  |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Documentation  |Version:  1.7
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 On the page https://docs.djangoproject.com/en/1.7/topics/auth/default/ it
 says on "Limiting access to logged-in users that pass a test" (
 https://docs.djangoproject.com/en/1.7/topics/auth/default/#limiting-
 access-to-logged-in-users-that-pass-a-test ) the following:

   {{{
   The simple way is to run your test on request.user in the view directly.
 For example, this view checks to make sure the user has an email in the
 desired domain:

   def my_view(request):
   if not request.user.email.endswith('@example.com'):
   return HttpResponse("You can't vote in this poll.")
   # ...
   }}}

 Then under that there's the "user_passes_test" -documentation and it's
 mentioned to be a shortcut for the above.

 This is just plain wrong, user_passes_test checks for something, then
 redirects to login page if the test fails. It does not return
 HttpResponse("You can't vote in this poll.") and it definitely does not
 return the 403 that makes me expect it to return.

 Also there is only a very casual mention of the "login_url" argument but
 no mention of what it could possibly be used for, e.g. redirecting users
 there if the test fails.

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


Re: [Django] #24476: Allow using set_script_prefix as a contextmanager

2015-03-18 Thread Django
#24476: Allow using set_script_prefix as a contextmanager
-+-
 Reporter:  timgraham|Owner:  bpeschier
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Core (URLs)  |  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 bpeschier):

 It is! :-)

 The PR uses ContextDecorator, but since a decorator gets called before you
 do anything, it would set the script prefix while importing the module if
 you put the meat in {{{__init__}}} which is required to make a direct call
 work.

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


Re: [Django] #24469: forms, form fields and media are escaped wrongfully in non django templates

2015-03-18 Thread Django
#24469: forms, form fields and media are escaped wrongfully in non django 
templates
-+-
 Reporter:  MoritzS  |Owner:  aaugustin
 Type:  Bug  |   Status:  assigned
Component:  Template system  |  Version:  1.8beta2
 Severity:  Release blocker  |   Resolution:
 Keywords:  forms fields media   | Triage Stage:  Ready for
  escape template jinja2 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by aaugustin):

 I'm fine with the patch as is. Let's commit it rather than delay RC1.

 Like I said on IRC, generally speaking, I'm wondering if adding this
 `__html__` method on a case by case basis to some classes is the best idea
 in the long run.

 Can we identify every class whose `__str__` method returns a `SafeStr`? If
 there's three of them, perhaps the ad-hoc method is fine. If there's
 seventeen, then it's a different story.

 Turning it into a mixin wouldn't save much code, would add a layer of
 indirection and a small overhead, but it would also allow us to provide a
 docstring.

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


Re: [Django] #24499: Drop support for PostGIS 1.5

2015-03-18 Thread Django
#24499: Drop support for PostGIS 1.5
-+-
 Reporter:  timgraham|Owner:  timgraham
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  GIS  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  2.0  | Triage Stage:
 |  Someday/Maybe
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by claudep):

 You could ask on the Geodjango ML if withdrawal of PostGIS 1.5 from Django
 1.9 would hurt anyone.

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