Re: [Django] #20456: Easier unit testing for class-based views

[Django]

#20456: Easier unit testing for class-based views
---+
 Reporter:  benoitbryon|Owner:  mjtamlyn
 Type:  New feature|   Status:  assigned
Component:  Testing framework  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords:  cbv test   | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+

Comment (by auvipy):

 Hi Marc what are the tasks remaining to get this ticket merged? If you
 don't have time let me do the rest on behalf of you

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

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

Re: [Django] #24452: Staticfiles backends using HashedFilesMixin don't update CSS files' hash when referenced media changes

[Django]

#24452: Staticfiles backends using HashedFilesMixin don't update CSS files' hash
when referenced media changes
-+-
 Reporter:  pmclanahan   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.staticfiles  |  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 pmclanahan):

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


Old description:

> Steps to reproduce when using the Cached or Manifest staticfiles
> storages:
>
> 1. Have an image ({{{a.jpg}}}) and a CSS file that references this image
> in a {{{url()}}} call.
> 2. Run {{{collectstatic}}} and observe that copies of said files now have
> hashed names.
> 3. Change the content of {{{a.jpg}}} (the color was clearly wrong).
> 4. Run {{{collectstatic}}} again
> 5. Observe that {{{a.jpg}}} now has a new hashed name version
> 6. Obesrve that the CSS file refers to this new version, but the hashed
> name of the CSS file has '''not''' changed.
>
> Because the CSS file's hash name was determined before processing the
> file's contents, changes in the referenced assets (images, fonts, etc.)
> will not result in a new hashed CSS file name. Thus when using a CDN and
> very long cache expire headers the CSS will never update, and the new
> version of the image will never be seen on the site.
>
> We're currently working around this by making insignificant changes to
> the CSS whenever we need to make changes to only the content of
> referenced media, but this is error prone and clearly suboptimal.
>
> This was observed in 1.6 using the {{{CachedStaticFilesStorage}}}, but I
> testing in 1.7 as well. A fix could be backported to the 1.6 line should
> it come before 1.6 is unsupported and a patch release is desired.

New description:

 Steps to reproduce when using the Cached or Manifest staticfiles storages:

 1. Have an image ({{{a.jpg}}}) and a CSS file that references this image
 in a {{{url()}}} call.
 2. Run {{{collectstatic}}} and observe that copies of said files now have
 hashed names.
 3. Change the content of {{{a.jpg}}} (the color was clearly wrong).
 4. Run {{{collectstatic}}} again
 5. Observe that {{{a.jpg}}} now has a new hashed name version
 6. Obesrve that the CSS file refers to this new version, but the hashed
 name of the CSS file has '''not''' changed.

 Because the CSS file's hash name was determined before processing the
 file's contents, changes in the referenced assets (images, fonts, etc.)
 will not result in a new hashed CSS file name. Thus when using a CDN and
 very long cache expire headers the CSS will never update, and the new
 version of the image will never be seen on the site.

 We're currently working around this by making insignificant changes to the
 CSS whenever we need to make changes to only the content of referenced
 media, but this is error prone and clearly suboptimal.

 This was observed in 1.6 using the {{{CachedStaticFilesStorage}}}, but I
 testing in 1.7 as well. A fix could be backported to the 1.6 line should
 it come before 1.6 is unsupported and a patch release is desired.

 Note: This was discovered in [https://github.com/mozilla/bedrock/
 mozilla/bedrock] (www.mozilla.org). More information may be added to
 [https://bugzilla.mozilla.org/show_bug.cgi?id=1139606 the Mozilla bug
 about this] as well.

--

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

[Django] #24452: Staticfiles backends using HashedFilesMixin don't update CSS files' hash when referenced media changes

[Django]

#24452: Staticfiles backends using HashedFilesMixin don't update CSS files' hash
when referenced media changes
-+
 Reporter:  pmclanahan   |  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  contrib.staticfiles  |Version:  1.7
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 Steps to reproduce when using the Cached or Manifest staticfiles storages:

 1. Have an image ({{{a.jpg}}}) and a CSS file that references this image
 in a {{{url()}}} call.
 2. Run {{{collectstatic}}} and observe that copies of said files now have
 hashed names.
 3. Change the content of {{{a.jpg}}} (the color was clearly wrong).
 4. Run {{{collectstatic}}} again
 5. Observe that {{{a.jpg}}} now has a new hashed name version
 6. Obesrve that the CSS file refers to this new version, but the hashed
 name of the CSS file has '''not''' changed.

 Because the CSS file's hash name was determined before processing the
 file's contents, changes in the referenced assets (images, fonts, etc.)
 will not result in a new hashed CSS file name. Thus when using a CDN and
 very long cache expire headers the CSS will never update, and the new
 version of the image will never be seen on the site.

 We're currently working around this by making insignificant changes to the
 CSS whenever we need to make changes to only the content of referenced
 media, but this is error prone and clearly suboptimal.

 This was observed in 1.6 using the {{{CachedStaticFilesStorage}}}, but I
 testing in 1.7 as well. A fix could be backported to the 1.6 line should
 it come before 1.6 is unsupported and a patch release is desired.

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

Re: [Django] #24420: Can't order_by annotated field if annotated field uses conditional expression

[Django]

#24420: Can't order_by annotated field if annotated field uses conditional
expression
-+-
 Reporter:  krisfields   |Owner:  jarshwah
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.8beta1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  order_by,| Triage Stage:  Ready for
  annotation, conditional|  checkin
  expression |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Josh Smeaton ):

 In [changeset:"823f8cdbc91f85a8ab3cb1ccfec5659037b5c148"]:
 {{{
 #!CommitTicketReference repository=""
 revision="823f8cdbc91f85a8ab3cb1ccfec5659037b5c148"
 [1.8.x] Fixed #24420 -- Allowed ordering by case expressions

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

Re: [Django] #24420: Can't order_by annotated field if annotated field uses conditional expression

[Django]

#24420: Can't order_by annotated field if annotated field uses conditional
expression
-+-
 Reporter:  krisfields   |Owner:  jarshwah
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.8beta1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  order_by,| Triage Stage:  Ready for
  annotation, conditional|  checkin
  expression |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Josh Smeaton ):

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


Comment:

 In [changeset:"ceaf31adfff3801f1092a215f73704e15a70e90c"]:
 {{{
 #!CommitTicketReference repository=""
 revision="ceaf31adfff3801f1092a215f73704e15a70e90c"
 Fixed #24420 -- Allowed ordering by case expressions
 }}}

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

Re: [Django] #20846: Increase contrib.auth's User.username length

[Django]

#20846: Increase contrib.auth's User.username length
--+
 Reporter:  ivoras@…  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  contrib.auth  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by collinanderson):

 * cc: cmawebsite@… (added)
 * has_patch:  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/074.39418cee5abd5e2aa0985b4d76dd186e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #21495: Add a setting for CSRF Header name

[Django]

#21495: Add a setting for CSRF Header name
-+-
 Reporter:  hello@…  |Owner:  gregorth
 Type:  New feature  |   Status:  closed
Component:  CSRF |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
  csrf,header,angularjs  |
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:"668d53cd125175eb708cc0af143f47b42cd42153"]:
 {{{
 #!CommitTicketReference repository=""
 revision="668d53cd125175eb708cc0af143f47b42cd42153"
 Fixed #21495 -- Added settings.CSRF_HEADER_NAME
 }}}

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

Re: [Django] #24451: TemplateSyntaxError with {% cycle "Hello, how are you?" "Fine!" %}

[Django]

#24451: TemplateSyntaxError with {% cycle "Hello, how are you?" "Fine!" %}
-+-
 Reporter:  CarstenF |Owner:  timgraham
 Type:  Bug  |   Status:  assigned
Component:  Template system  |  Version:  1.7
 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
-+-

Comment (by collinanderson):

 I agree deprecation makes sense.

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

Re: [Django] #24286: Move django.core.files.locks to django.utils.locks

[Django]

#24286: Move django.core.files.locks to django.utils.locks
--+
 Reporter:  aaugustin |Owner:  gmunumel
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Utilities |  Version:  master
 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 aaugustin):

 No. I just filed the ticket as I came across the module and it seemed
 misplaced. I didn't investigate much.

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

Re: [Django] #18830: FormWizard with Formset and Form Fields mixed on same page

[Django]

#18830: FormWizard with Formset and Form Fields mixed on same page
-+
 Reporter:  jeff@…   |Owner:  inglesp
 Type:  New feature  |   Status:  assigned
Component:  Forms|  Version:  1.4
 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 inglesp):

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

Re: [Django] #24286: Move django.core.files.locks to django.utils.locks

[Django]

#24286: Move django.core.files.locks to django.utils.locks
--+
 Reporter:  aaugustin |Owner:  gmunumel
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Utilities |  Version:  master
 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 timgraham):

 I'm less enthusiastic about the idea after seeing
 `django/core/files/move.py` which is a file utility that only relies on
 locks (but documented) and #20488 which adds `django/core/files/copy.py`
 which also seems suitable for `utils`. I guess most of `django.core.files`
 could go in `utils` if we had to do it over again, but not sure there's
 much benefit in splitting things now. Aymeric, did you have any more
 motivation than what you stated in the ticket?

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

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

Re: [Django] #24451: TemplateSyntaxError with {% cycle "Hello, how are you?" "Fine!" %}

[Django]

#24451: TemplateSyntaxError with {% cycle "Hello, how are you?" "Fine!" %}
-+-
 Reporter:  CarstenF |Owner:  timgraham
 Type:  Bug  |   Status:  assigned
Component:  Template system  |  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * has_patch:  0 => 1


Comment:

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

Re: [Django] #24451: TemplateSyntaxError with {% cycle "Hello, how are you?" "Fine!" %}

[Django]

#24451: TemplateSyntaxError with {% cycle "Hello, how are you?" "Fine!" %}
-+-
 Reporter:  CarstenF |Owner:  timgraham
 Type:  Bug  |   Status:  assigned
Component:  Template system  |  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 timgraham):

 * status:  new => assigned
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * owner:  nobody => timgraham
 * needs_docs:   => 0
 * stage:  Unreviewed => Accepted


Comment:

 I confirmed the suspection on the mailing list that this is caused by
 those particular arguments being parsed using the legacy syntax. I'll use
 this as an excuse to deprecate that syntax.

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

[Django] #24451: TemplateSyntaxError with {% cycle "Hello, how are you?" "Fine!" %}

[Django]

#24451: TemplateSyntaxError with {% cycle "Hello, how are you?" "Fine!" %}
-+
 Reporter:  CarstenF |  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  Template system  |Version:  1.7
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 Originating thread at django-users:
 https://groups.google.com/forum/#!topic/django-users/hSqSVpWMDqs

 Using Django 1.7.5, there is a problem with commas in string literals in
 the cycle tag, e.g. with

 {{{
 {% cycle "Hello, how are you?" "Fine!" %}
 }}}

 Please consider this example in the management shell (newlines added for
 clarity):

 {{{
 #!python
 >>> from django.template import *
 >>> t = Template('''{% cycle "Hello, how are you?" "Fine!" %}''')

 /home/carsten/.virtualenvs/Ze/local/lib/python2.7/site-
 packages/django/template/base.py:290: RemovedInDjango18Warning: 'The
 `cycle` template tag is changing to escape its arguments; the non-
 autoescaping version is deprecated. Load it from the `future` tag library
 to start using the new behavior.
   compiled_result = compile_func(self, token)

 Traceback (most recent call last):
   File "", line 1, in 
   File "/home/carsten/.virtualenvs/Ze/local/lib/python2.7/site-
 packages/django/template/base.py", line 132, in __init__
 self.nodelist = compile_string(template_string, origin)
   File "/home/carsten/.virtualenvs/Ze/local/lib/python2.7/site-
 packages/django/template/base.py", line 162, in compile_string
 return parser.parse()
   File "/home/carsten/.virtualenvs/Ze/local/lib/python2.7/site-
 packages/django/template/base.py", line 290, in parse
 compiled_result = compile_func(self, token)
   File "/home/carsten/.virtualenvs/Ze/local/lib/python2.7/site-
 packages/django/template/defaulttags.py", line 648, in cycle
 values = [parser.compile_filter(arg) for arg in args[1:]]
   File "/home/carsten/.virtualenvs/Ze/local/lib/python2.7/site-
 packages/django/template/base.py", line 372, in compile_filter
 return FilterExpression(token, self)
   File "/home/carsten/.virtualenvs/Ze/local/lib/python2.7/site-
 packages/django/template/base.py", line 588, in __init__
 "from '%s'" % (token[upto:], token))
 TemplateSyntaxError: Could not parse the remainder: 'Hello"' from
 '""Hello"'
 }}}

 (Probably not relevant, but fyi, this happens with or without `{% load
 cycle from future %}`.)

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

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

Re: [Django] #24420: Can't order_by annotated field if annotated field uses conditional expression

[Django]

#24420: Can't order_by annotated field if annotated field uses conditional
expression
-+-
 Reporter:  krisfields   |Owner:  jarshwah
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.8beta1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  order_by,| Triage Stage:  Ready for
  annotation, conditional|  checkin
  expression |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * has_patch:  0 => 1
 * component:  Uncategorized => Database layer (models, ORM)
 * stage:  Accepted => Ready for checkin


Comment:

 Seems like a candidate for backport.

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

Re: [Django] #24085: @login_required decorator redirects to a locale specific URL when using i18n_patterns (was: @requires_login decorator redirects to a locale specific URL when using i18n_patterns)

[Django]

#24085: @login_required decorator redirects to a locale specific URL when using
i18n_patterns
-+-
 Reporter:  thedrow  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:   |  Version:  master
  Internationalization   |
 Severity:  Normal   |   Resolution:
 Keywords:  authentication i18n  | Triage Stage:
  login_required |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

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


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

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

Re: [Django] #24450: Should the WSGI Core handler accept request with a missing slash '/'

[Django]

#24450: Should the WSGI Core handler accept request with a missing slash '/'
-+-
 Reporter:  paschembri   |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Core (URLs)  |  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:  wsgi nginx   | Triage Stage:
  script_name|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

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


Comment:

 Hi, could you add a little more detail about the steps to reproduce the
 issue and also a pointer to the documentation you refer to in your third
 paragraph?

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

[Django] #24450: Should the WSGI Core handler accept request with a missing slash '/'

[Django]

#24450: Should the WSGI Core handler accept request with a missing slash '/'
---+
 Reporter:  paschembri |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Core (URLs)|Version:  1.7
 Severity:  Normal |   Keywords:  wsgi nginx script_name
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 I observed that when using nginx with gunicorn and the SCRIPT_NAME is set
 to '/' every request is stripped from the leading '/'.

 The consequence is that these requests cannot be correctly resolved.

 As documented, when path_info is empty, it is graciously forced to '/'.
 But when path_info does not start with '/', nothing is done.

 Is this behavior desirable ?

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

Re: [Django] #24243: HashedFilesMixin doesn't handle file name fragments (thus the url template tag neither)

[Django]

#24243: HashedFilesMixin doesn't handle file name fragments (thus the url 
template
tag neither)
-+-
 Reporter:  atleta   |Owner:  atleta
 Type:  Uncategorized|   Status:  closed
Component:  contrib.staticfiles  |  Version:  1.7
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by atleta):

 Nope, it isn't. What I'm doing is being able to use

 {{{
 {% static 'wherever/some/of/your/files/are/' %}
 }}}

 or e.g. (generated js)
 {{{
 var sound = '{% static 'sounds/mysound' %}';
 }}}

 and then append .mp3 or .ogg depending on the browser capabilities. Both
 files are present. Actually #18958 would still be an issue for the
 reporter after accepting my patch.

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

Re: [Django] #24243: HashedFilesMixin doesn't handle file name fragments (thus the url template tag neither)

[Django]

#24243: HashedFilesMixin doesn't handle file name fragments (thus the url 
template
tag neither)
-+-
 Reporter:  atleta   |Owner:  atleta
 Type:  Uncategorized|   Status:  closed
Component:  contrib.staticfiles  |  Version:  1.7
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by aaugustin):

 Isn't this a duplicate of #18958?

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

Re: [Django] #24243: HashedFilesMixin doesn't handle file name fragments (thus the url template tag neither)

[Django]

#24243: HashedFilesMixin doesn't handle file name fragments (thus the url 
template
tag neither)
-+-
 Reporter:  atleta   |Owner:  atleta
 Type:  Uncategorized|   Status:  closed
Component:  contrib.staticfiles  |  Version:  1.7
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by atleta):

 Pull request created. Can't remember the documentation that caused the
 confusion, it was over a month ago. Will let you know if I see 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.fff03bf8974c8fbf9b33f8fa062dec3a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24445: DurationField with default='1 00:00' triggers validation on otherwise empty inline formsets

[Django]

#24445: DurationField with default='1 00:00' triggers validation on otherwise 
empty
inline formsets
+--
 Reporter:  yoyoma  |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  Forms   |  Version:  master
 Severity:  Normal  |   Resolution:  invalid
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--

Comment (by yoyoma):

 @claudep @timgraham {{{timedelta}}} is obviously the right thing to use
 here, and I'm not sure what in the world I was thinking when I used a
 string. I think it was because I was getting so used to typing the string
 value into the admin, and just totally spaced it. I'm sorry for wasting a
 ticket and your time before simply taking 30 seconds to RTFM @
 https://docs.djangoproject.com/en/1.8/ref/models/fields/#durationfield

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

Re: [Django] #24243: HashedFilesMixin doesn't handle file name fragments (thus the url template tag neither)

[Django]

#24243: HashedFilesMixin doesn't handle file name fragments (thus the url 
template
tag neither)
-+-
 Reporter:  atleta   |Owner:  atleta
 Type:  Uncategorized|   Status:  closed
Component:  contrib.staticfiles  |  Version:  1.7
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by timgraham):

 Pull requests are preferred. Let me know which documentation you were
 confused by so we can update it.

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

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

Re: [Django] #24243: HashedFilesMixin doesn't handle file name fragments (thus the url template tag neither)

[Django]

#24243: HashedFilesMixin doesn't handle file name fragments (thus the url 
template
tag neither)
-+-
 Reporter:  atleta   |Owner:  atleta
 Type:  Uncategorized|   Status:  closed
Component:  contrib.staticfiles  |  Version:  1.7
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by atleta):

 The change I'm suggesting is that resolving a non-existent file name
 doesn't raise a ValueError when using ManifestStaticFilesStorage (change
 needed in HashedFilesMixin). Though it was 5 weeks ago, it seems I have
 done the fix back then.

 Do I attach a file containing the suggested fix here or do I create a pull
 request? (The documentation wasn't 100% clear.)

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

Re: [Django] #24449: Link in debug information for csrf points to dead link

[Django]

#24449: Link in debug information for csrf points to dead link
---+--
 Reporter:  wimfeijen  |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Uncategorized  |  Version:  1.4
 Severity:  Normal |   Resolution:  duplicate
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by timgraham):

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


Comment:

 Duplicate of https://github.com/django/djangoproject.com/issues/393

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

[Django] #24449: Link in debug information for csrf points to dead link

[Django]

#24449: Link in debug information for csrf points to dead link
---+
 Reporter:  wimfeijen  |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  1.4
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 The link pointing to:
 https://docs.djangoproject.com/en/dev/ref/contrib/csrf/#ref-contrib-csrf
 gives a 404 Page Not Found error.

 Sometimes is going wrong with my csrf and I get the following error page,
 which contains the faulty link:

 Forbidden (403)
 CSRF verification failed. Request aborted.
 Help
 Reason given for failure:
 CSRF cookie not set.

 In general, this can occur when there is a genuine Cross Site Request
 Forgery, or when Django's CSRF mechanism has not been used correctly. For
 POST forms, you need to ensure:
 Your browser is accepting cookies.
 The view function uses RequestContext for the template, instead of
 Context.
 In the template, there is a {% csrf_token %} template tag inside each POST
 form that targets an internal URL.
 If you are not using CsrfViewMiddleware, then you must use csrf_protect on
 any views that use the csrf_token template tag, as well as those that
 accept the POST data.
 You're seeing the help section of this page because you have DEBUG = True
 in your Django settings file. Change that to False, and only the initial
 error message will be displayed.
 You can customize this page using the CSRF_FAILURE_VIEW setting.

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

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

Re: [Django] #19538: Remove __admin_media_prefix__ in admin templates

[Django]

#19538: Remove __admin_media_prefix__ in admin templates
-+-
 Reporter:  andrew@… |Owner:  timgraham
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  admin S3 DateTime| 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:"d61ebc8fed212366340b1ed6f5d7722613801459"]:
 {{{
 #!CommitTicketReference repository=""
 revision="d61ebc8fed212366340b1ed6f5d7722613801459"
 Fixed #19538 -- Removed window.__admin_media_prefix__ from admin
 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/079.c6673ce54afd69741780ed7975119e86%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #373: Add support for multiple-column primary keys

[Django]

#373: Add support for multiple-column primary keys
-+-
 Reporter:  jacob|Owner:  konk
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  database | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by nattster):

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

Re: [Django] #24171: (1054, "Unknown column '__col1' in 'field list'") when using values, annotate, and aggregate

[Django]

#24171: (1054, "Unknown column '__col1' in 'field list'") when using values,
annotate, and aggregate
-+-
 Reporter:  abdulhaq-e   |Owner:  jarshwah
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.8beta1
  (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):

 * keywords:  1.8-beta =>
 * needs_better_patch:  0 => 1
 * has_patch:  0 => 1
 * version:  1.8alpha1 => 1.8beta1


Comment:

 [https://github.com/django/django/pull/4240 PR] from Anssi (not passing
 tests as of now).

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

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

Re: [Django] #24424: Removing a model's last field results in SQL syntax error on SQLite (was: Migrating an 'empty' model with SQLite gives an SQL syntax error)

[Django]

#24424: Removing a model's last field results in SQL syntax error on SQLite
-+-
 Reporter:  adnam|Owner:  adnam
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  sqlite3 migrations   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by MarkusH):

 * needs_better_patch:  0 => 1
 * version:  master => 1.7
 * component:  Migrations => Database layer (models, ORM)
 * needs_docs:  0 => 1


Comment:

 Although this bug manifests using migrations, the underlying problem is
 inside the schema editor for SQLite3. Thus I'm changing the component.

 The bug is already in 1.7 as part of a new feature and would have
 prevented a release back then.

 Pleae see the PR for notes regarding the patch itself.

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

Re: [Django] #24243: HashedFilesMixin doesn't handle file name fragments (thus the url template tag neither)

[Django]

#24243: HashedFilesMixin doesn't handle file name fragments (thus the url 
template
tag neither)
-+-
 Reporter:  atleta   |Owner:  atleta
 Type:  Uncategorized|   Status:  closed
Component:  contrib.staticfiles  |  Version:  1.7
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

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

Re: [Django] #24446: ATOMIC_REQUESTS add extra queries if the view was already in a transaction

[Django]

#24446: ATOMIC_REQUESTS add extra queries if the view was already in a 
transaction
-+-
 Reporter:  diox |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

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

Re: [Django] #24348: Allow to pass on initial data to change form for existing objects (again).

[Django]

#24348: Allow to pass on initial data to change form for existing objects 
(again).
---+--
 Reporter:  slachinger |Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  contrib.admin  |  Version:  1.7
 Severity:  Normal |   Resolution:  needsinfo
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by timgraham):

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


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

Re: [Django] #24276: django.contrib.auth.decorators.user_passes_test doesn't pass *args and *kwargs to resolve_url

[Django]

#24276: django.contrib.auth.decorators.user_passes_test doesn't pass *args and
*kwargs to resolve_url
-+-
 Reporter:  rubengrill   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.auth |  Version:  1.7
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  login_url| Triage Stage:
  resolve_url login_required |  Unreviewed
  user_passes_test   |
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:

 Please reopen if you can make a reply, 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/068.79a453da94ea43e09254624e1d86d0a7%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24445: DurationField with default='1 00:00' triggers validation on otherwise empty inline formsets

[Django]

#24445: DurationField with default='1 00:00' triggers validation on otherwise 
empty
inline formsets
+--
 Reporter:  yoyoma  |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  Forms   |  Version:  master
 Severity:  Normal  |   Resolution:  invalid
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Changes (by timgraham):

 * resolution:  wontfix => invalid


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

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

Re: [Django] #24445: DurationField with default='1 00:00' triggers validation on otherwise empty inline formsets

[Django]

#24445: DurationField with default='1 00:00' triggers validation on otherwise 
empty
inline formsets
+--
 Reporter:  yoyoma  |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  Forms   |  Version:  master
 Severity:  Normal  |   Resolution:  wontfix
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Changes (by timgraham):

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


Comment:

 I don't see a need to complicate things by allowing differing types for
 defaults. Maybe there's an opportunity to use the checks framework to
 validate defaults are the proper type, but I'll leave that for a new
 ticket if someone wants to try implementing it.

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

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

Re: [Django] #24448: Add a management command to generate new SECRET_KEY (was: generate new SECRET_KEY command)

[Django]

#24448: Add a management command to generate new SECRET_KEY
---+--
 Reporter:  wimfeijen  |Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  Uncategorized  |  Version:  master
 Severity:  Normal |   Resolution:  wontfix
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  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/067.9d779529dfb5e5702373263c16d29a8b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24448: generate new SECRET_KEY command

[Django]

#24448: generate new SECRET_KEY command
---+--
 Reporter:  wimfeijen  |Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  Uncategorized  |  Version:  master
 Severity:  Normal |   Resolution:  wontfix
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--
Changes (by timgraham):

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


Comment:

 I don't see this as something Django needs to provide. My understanding is
 that any random string is fine. There are online generators that use
 https. I'm averse to adding management commands for every little task as
 there are overheads for code, docs, and tests. If someone has stronger
 arguments, please reopen or use the DevelopersMailingList for discussion.
 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/067.24c7388dc534df4752ff6a9ac812ae92%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #24448: generate new SECRET_KEY command

[Django]

#24448: generate new SECRET_KEY command
---+
 Reporter:  wimfeijen  |  Owner:  nobody
 Type:  New feature| Status:  new
Component:  Uncategorized  |Version:  master
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 Hi,

 My proposal is to add a django-admin.py command or manage.py command which
 generates a new SECRET_KEY in order to improve safety.

 Sometimes I copy projects. I'd like to change the SECRET_KEY then. As far
 as I know, there is no (documented) way to generate a new SECRET_KEY,
 except for creating a new online project and copying that key.

 Or I could implement a random function myself (which might be actually
 worse implemented then django's default key generation), or I could use
 the first Google hit to generate a key over an insecure connection. Both
 raise my safety concerns.

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

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

Re: [Django] #24448: generate new SECRET_KEY command

[Django]

#24448: generate new SECRET_KEY command
---+--
 Reporter:  wimfeijen  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Uncategorized  |  Version:  master
 Severity:  Normal |   Resolution:
 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 wimfeijen):

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

Re: [Django] #24445: DurationField with default='1 00:00' triggers validation on otherwise empty inline formsets

[Django]

#24445: DurationField with default='1 00:00' triggers validation on otherwise 
empty
inline formsets
+--
 Reporter:  yoyoma  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Forms   |  Version:  master
 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 claudep):

 * severity:  Release blocker => Normal


Comment:

 In fact, you'll find the exact same behavior with current date-based
 fields. If you provide an initial or default value, you should provide a
 date/datetime Python value, not a string representation. By analogy, you
 should provide a `timedelta` value for your `DurationField` default value.

 We *could* change that, other opinions 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/064.3e3e9f783f157f1764e02ff71893e3c4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23784: Error reporting docs needs to state clearly that changing logging conf error emails are not sent out unless configuring it again

[Django]

#23784: Error reporting docs needs to state clearly that changing logging conf
error emails are not sent out unless configuring it again
--+
 Reporter:  peterlauri|Owner:
 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 gmunumel):

 * owner:  gmunumel =>
 * status:  assigned => new


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

Re: [Django] #24286: Move django.core.files.locks to django.utils.locks

[Django]

#24286: Move django.core.files.locks to django.utils.locks
--+
 Reporter:  aaugustin |Owner:  gmunumel
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Utilities |  Version:  master
 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 gmunumel):

 New PR added:
 
https://github.com/gmunumel/django/commit/9f63fad5e29a6b093e951ee10a5f4f4d2fc9e8a5

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

Re: [Django] #24428: Model field with default=callable and choices is always reported as changed

[Django]

#24428: Model field with default=callable and choices is always reported as 
changed
--+-
 Reporter:  CarstenF  |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  Forms |  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:"8714403614c4dfa37e806db4a6708b8a91a827a4"]:
 {{{
 #!CommitTicketReference repository=""
 revision="8714403614c4dfa37e806db4a6708b8a91a827a4"
 Fixed #24428 -- Fixed has_changed for fields with coercion

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