[Django] #17690: admin list_editable broken

[Django]

#17690: admin list_editable broken
--+
 Reporter:  michaelritsema@…  |  Owner:  nobody
 Type:  Uncategorized | Status:  new
Component:  contrib.admin |Version:  SVN
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 I've tried every combination I can think of with setting these guys for
 the admin section:
 list_display_links
 list_display
 list_editable

 I'll get different errors depending on the order. This works fine in 1.3.X
 branch.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #17689: CachedFilesMixin causes ValueError when provided with a path to url()

[Django]

#17689: CachedFilesMixin causes ValueError when provided with a path to url()
-+
 Reporter:  tkaemming|  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  contrib.staticfiles  |Version:  1.3
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  1
Easy pickings:  0|  UI/UX:  0
-+
 For example, trying to set `window.__admin_media_prefix__` in
 `admin/base.html` causes this error.

 Here's the offending template tag:
 
https://code.djangoproject.com/browser/django/trunk/django/contrib/admin/templates/admin/base.html#L9

 Traceback (I cut out the `render` bits and only left the parts significant
 to the issue at hand):
 {{{
 [pid: 23479|app: 0|req: 2/11] 127.0.0.1 () {40 vars in 780 bytes} [Tue Feb
 14 19:42:53 2012] GET /admin/ => generated 168 bytes in 430 msecs
 (HTTP/1.0 500) 4 headers in 174 bytes (1 switches on core 0)
 Internal Server Error: /admin/
 Traceback (most recent call last):
   File
 
"/srv/versions/development/src/django/django/contrib/staticfiles/templatetags/staticfiles.py",
 line 13, in static
 return staticfiles_storage.url(path)
   File
 "/srv/versions/development/src/django/django/contrib/staticfiles/storage.py",
 line 111, in url
 hashed_name = self.hashed_name(clean_name).replace('\\', '/')
   File
 "/srv/versions/development/src/django/django/contrib/staticfiles/storage.py",
 line 74, in hashed_name
 (clean_name, self))
 ValueError: The file 'admin/' could not be found with
 .
 }}}

 I've attached a patch that prevents CachedStaticMixin from attempting to
 hash names ending in a path separator (forward slash only), incl. 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #15649: Doc buliding fails with: DjangoHTMLTranslator instance has no attribute '_table_row_index'

[Django]

#15649: Doc buliding fails with: DjangoHTMLTranslator instance has no attribute
'_table_row_index'
---+--
 Reporter:  bmihelac   |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Documentation  |  Version:  1.3
 Severity:  Normal |   Resolution:  wontfix
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by anonymous):

 You might want to consider to port the fix to 1.3.x since this occurs on
 CentOS/RHEL 6.2.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17543: Broken link to django-debug-toolbar repository

[Django]

#17543: Broken link to django-debug-toolbar repository
-+-
 Reporter:  rowynm@… |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Documentation|  Version:  1.3
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  1|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by timo):

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


Comment:

 In [17523]:
 {{{
 #!CommitTicketReference repository="" revision="17523"
 [1.3.X] Updated link to Django Debug Toolbar homepage.

 Thanks to rowynm AT gmail DOT com for the report and to Claude Paroz for
 the patch.

 Fixes #17543.

 Backport of r17376 from trunk.
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r17523 - django/branches/releases/1.3.X/docs/topics/db

[noreply]

Author: timo
Date: 2012-02-14 15:05:23 -0800 (Tue, 14 Feb 2012)
New Revision: 17523

Modified:
   django/branches/releases/1.3.X/docs/topics/db/optimization.txt
Log:
[1.3.X] Updated link to Django Debug Toolbar homepage.

Thanks to rowynm AT gmail DOT com for the report and to Claude Paroz for
the patch.

Fixes #17543.

Backport of r17376 from trunk.

Modified: django/branches/releases/1.3.X/docs/topics/db/optimization.txt
===
--- django/branches/releases/1.3.X/docs/topics/db/optimization.txt  
2012-02-14 21:29:50 UTC (rev 17522)
+++ django/branches/releases/1.3.X/docs/topics/db/optimization.txt  
2012-02-14 23:05:23 UTC (rev 17523)
@@ -29,7 +29,7 @@
 that in your circumstances the general principle might not apply, or might even
 be reversed.
 
-.. _django-debug-toolbar: http://robhudson.github.com/django-debug-toolbar/
+.. _django-debug-toolbar: 
https://github.com/django-debug-toolbar/django-debug-toolbar/
 
 Use standard DB optimization techniques
 ===

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17688: No m2m_changed signal sent to when referenced object is deleted

[Django]

#17688: No m2m_changed signal sent to when referenced object is deleted
-+-
 Reporter:  jblaine@…|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by akaariai):

 * cc: anssi.kaariainen@… (added)
 * needs_better_patch:   => 0
 * needs_docs:   => 0
 * needs_tests:   => 0
 * stage:  Unreviewed => Accepted


Comment:

 I confirmed that no m2m_changed signal is sent. It seems it would be
 somewhat easy to send m2m_changed signals from models/deletion.py. I have
 no clue what the correct arguments for all the m2m_signal args should be.

 The attached test shows that no signal is sent.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16128: cascade delete does not work for proxy models

[Django]

#16128: cascade delete does not work for proxy models
-+-
 Reporter:  xkennyx@…|Owner:  nobody
 Type:  Bug  |   Status:  reopened
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  cascade delete   |  Needs documentation:  0
  proxy meta |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by akaariai):

 * needs_better_patch:  1 => 0


Comment:

 Ok, another try for this ticket. The patch includes the patch of #17678.

 There is no meta proxy_equivalence_class. The reason is, it is very easy
 to test if this model is in proxy-equivalence with the other: if
 self._meta.concrete_class == other._meta.concrete_class. This should work
 for the `ForeignKey` example.

 I think there might be similar bug still waiting for generic foreign key
 case, but I would like to deal with that separately.

 I hope the patch is OK, too long day to actually think it through... :)

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #17688: No m2m_changed signal sent to when referenced object is deleted

[Django]

#17688: No m2m_changed signal sent to when referenced object is deleted
--+
 Reporter:  jblaine@… |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.3
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 {{{
 class Topping(models.Model):
 name = models.CharField()

 class Pizza(models.Model):
 name = models.CharField()
 toppings = models.ManyToManyField(Topping, null=true, blank=true)
 }}}

 And this data established using those models:

 {{{
 TOPPING
 id=1, name="Pepperoni"
 id=2, name="Onion"
 id=3, name="Mushroom"

 PIZZA
 id=1, name="foopizza"
 toppings=1,2,3
 }}}

 1. Deleting any Topping object (for example, deleting id=1,
 name="Pepperoni") also removes it from foopizza.toppings.  '''GOOD'''

 2. No m2m_changed signal is sent when 1 (above happens).  '''BAD?'''

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17664: Smart `if` tag silencing exceptions plus `QuerySet` caching equals buggy behaviour.

[Django]

#17664: Smart `if` tag silencing exceptions plus `QuerySet` caching equals buggy
behaviour.
-+-
 Reporter:  mrmachine|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Uncategorized|  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:  smart if tag | Triage Stage:
  queryset exception silenced|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by mrmachine):

 I'm not sure I really follow the inner workings of the smart if tag. But
 why would `qs` from `{% if qs %}` still be lazy (not evaluated) when `{%
 if not qs %}` is no longer lazy (is evaluated)? I thought the first would
 be equivalent to `if qs` in Python, which is `if bool(qs)`? Or is `{% if
 qs %}` just testing that the variable exists, and doesn't check the value
 of it?

 Either way, what do you think about the way `QuerySet` will be an empty
 queryset after an exception is raised, even though the query is still
 invalid and never executed? Shouldn't `QuerySet` cache the exception (not
 an empty result set), or just not cache anything and re-execute the query
 when evaluated a second time? This wouldn't fix the `{% if qs %}` / `{% if
 not qs %}` disparity, but it would prevent the strange side-effect where
 subsequent attempts to access `qs` yield an empty queryset.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #6535: parser.compile_filter() does not support negative numbers

[Django]

#6535: parser.compile_filter() does not support negative numbers
-+-
 Reporter:  Collin Grady |Owner:  aaugustin
   |   Status:  new
 Type:  Bug  |  Version:  SVN
Component:  Template system  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  tplrf-fixed  |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  1|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by aaugustin):

 * owner:  nobody => aaugustin
 * ui_ux:   => 0
 * easy:   => 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #4746: [patch] Allow whitespace before and after filter separator

[Django]

#4746: [patch] Allow whitespace before and after filter separator
-+-
 Reporter:  sciyoshi@…   |Owner:  aaugustin
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  SVN
Component:  Template system  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  template filter  |  Needs documentation:  0
  separator whitespace tplrf-fixed   |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  1|
Easy pickings:  0|
-+-
Changes (by aaugustin):

 * owner:  nobody => aaugustin
 * ui_ux:   => 0
 * easy:   => 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #7806: django.template refactoring

[Django]

#7806: django.template refactoring
-+-
 Reporter:  emulbreh |Owner:  aaugustin
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  SVN
Component:  Template system  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  tplrf|  Needs documentation:  1
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  1|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by aaugustin):

 * owner:  nobody => aaugustin
 * status:  reopened => new
 * ui_ux:   => 0
 * easy:   => 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17664: Smart `if` tag silencing exceptions plus `QuerySet` caching equals buggy behaviour.

[Django]

#17664: Smart `if` tag silencing exceptions plus `QuerySet` caching equals buggy
behaviour.
-+-
 Reporter:  mrmachine|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Uncategorized|  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:  smart if tag | Triage Stage:
  queryset exception silenced|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by krzysiumed):

 * cc: krzysiumed@… (added)


Comment:

 The problem is that `QuerySets` are lazy and the exception occures in
 different places in these two situations.

 Look here:
 
https://code.djangoproject.com/browser/django/trunk/django/template/defaulttags.py#L269.

 Consider the situation with `{% if qs %}`. When the `` is being
 rendering, attribute `condition` is `TemplateLiteral` instance with
 `text="qs"`. After executing line 274, attribute `match` is `QuerySet`.
 There is no exception, because `QuerySets` are lazy. Then line 280
 becomes. Method `__nonzero__` of `QuerySet` is being executing and the
 exception is being raising at this moment.

 Now consider `{% if not qs %}`. Line 274 is being executing. What
 happened? Operator `not` is being executing. See
 
https://code.djangoproject.com/browser/django/trunk/django/template/smartif.py#L81
 - all exceptions are caught. `match` is `False`.

 The solution may be to change
 
https://code.djangoproject.com/browser/django/trunk/django/template/smartif.py#L84
 - except clause should be less strict and should not catch all exception.
 But which ones?

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17675: using date filter with regroup tag not working with 1.4 TZ

[Django]

#17675: using date filter with regroup tag not working with 1.4 TZ
-+-
 Reporter:  ptone|Owner:  aaugustin
 Type:  Bug  |   Status:  closed
Component:  Core (Other) |  Version:
 Severity:  Release blocker  |  1.4-alpha-1
 Keywords:   |   Resolution:  fixed
Has patch:  1| Triage Stage:  Ready for
  Needs tests:  0|  checkin
Easy pickings:  0|  Needs documentation:  0
 |  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by aaugustin):

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


Comment:

 In [17522]:
 {{{
 #!CommitTicketReference repository="" revision="17522"
 Fixed #17675 -- Changed the implementation of the {% regroup %} template
 tag to use the context properly when resolving 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r17522 - in django/trunk: django/template tests/regressiontests/templates

[noreply]

Author: aaugustin
Date: 2012-02-14 13:29:50 -0800 (Tue, 14 Feb 2012)
New Revision: 17522

Modified:
   django/trunk/django/template/defaulttags.py
   django/trunk/tests/regressiontests/templates/tests.py
Log:
Fixed #17675 -- Changed the implementation of the {% regroup %} template tag to 
use the context properly when resolving expressions.


Modified: django/trunk/django/template/defaulttags.py
===
--- django/trunk/django/template/defaulttags.py 2012-02-14 09:55:09 UTC (rev 
17521)
+++ django/trunk/django/template/defaulttags.py 2012-02-14 21:29:50 UTC (rev 
17522)
@@ -10,7 +10,7 @@
 TemplateSyntaxError, VariableDoesNotExist, InvalidTemplateLibrary,
 BLOCK_TAG_START, BLOCK_TAG_END, VARIABLE_TAG_START, VARIABLE_TAG_END,
 SINGLE_BRACE_START, SINGLE_BRACE_END, COMMENT_TAG_START, COMMENT_TAG_END,
-get_library, token_kwargs, kwarg_re)
+VARIABLE_ATTRIBUTE_SEPARATOR, get_library, token_kwargs, kwarg_re)
 from django.template.smartif import IfParser, Literal
 from django.template.defaultfilters import date
 from django.utils.encoding import smart_str, smart_unicode
@@ -287,6 +287,12 @@
 self.target, self.expression = target, expression
 self.var_name = var_name
 
+def resolve_expression(self, obj, context):
+# This method is called for each object in self.target. See regroup()
+# for the reason why we temporarily put the object in the context.
+context[self.var_name] = obj
+return self.expression.resolve(context, True)
+
 def render(self, context):
 obj_list = self.target.resolve(context, True)
 if obj_list == None:
@@ -298,7 +304,7 @@
 context[self.var_name] = [
 {'grouper': key, 'list': list(val)}
 for key, val in
-groupby(obj_list, lambda v, f=self.expression.resolve: f(v, True))
+groupby(obj_list, lambda obj: self.resolve_expression(obj, 
context))
 ]
 return ''
 
@@ -1112,10 +1118,16 @@
 if lastbits_reversed[1][::-1] != 'as':
 raise TemplateSyntaxError("next-to-last argument to 'regroup' tag must"
   " be 'as'")
-
-expression = parser.compile_filter(lastbits_reversed[2][::-1])
-
 var_name = lastbits_reversed[0][::-1]
+# RegroupNode will take each item in 'target', put it in the context under
+# 'var_name', evaluate 'var_name'.'expression' in the current context, and
+# group by the resulting value. After all items are processed, it will
+# save the final result in the context under 'var_name', thus clearing the
+# temporary values. This hack is necessary because the template engine
+# doesn't provide a context-aware equivalent of Python's getattr.
+expression = parser.compile_filter(var_name +
+   VARIABLE_ATTRIBUTE_SEPARATOR +
+   lastbits_reversed[2][::-1])
 return RegroupNode(target, expression, var_name)
 
 @register.tag

Modified: django/trunk/tests/regressiontests/templates/tests.py
===
--- django/trunk/tests/regressiontests/templates/tests.py   2012-02-14 
09:55:09 UTC (rev 17521)
+++ django/trunk/tests/regressiontests/templates/tests.py   2012-02-14 
21:29:50 UTC (rev 17522)
@@ -8,7 +8,7 @@
 # before importing 'template'.
 settings.configure()
 
-from datetime import datetime, timedelta
+from datetime import date, datetime, timedelta
 import time
 import os
 import sys
@@ -1376,6 +1376,33 @@
   '{% endfor %},'
   '{% endfor %}',
   {}, ''),
+
+# Regression tests for #17675
+# The date template filter has expects_localtime = True
+'regroup03': ('{% regroup data by at|date:"m" as grouped %}'
+  '{% for group in grouped %}'
+  '{{ group.grouper }}:'
+  '{% for item in group.list %}'
+  '{{ item.at|date:"d" }}'
+  '{% endfor %},'
+  '{% endfor %}',
+  {'data': [{'at': date(2012, 2, 14)},
+{'at': date(2012, 2, 28)},
+{'at': date(2012, 7, 4)}]},
+  '02:1428,07:04,'),
+# The join template filter has needs_autoescape = True
+'regroup04': ('{% regroup data by bar|join:"" as grouped %}'
+  '{% for group in grouped %}'
+  '{{ group.grouper }}:'
+  '{% for item in group.list %}'
+  '{{ item.foo|first }}'
+  '{% endfor %},'
+  '{% endfor %}',
+  {'data': [{'foo': 'x', 'bar': ['ab', 'c']},
+   

Re: [Django] #9176: NoReverseMatch for optional arguments

[Django]

#9176: NoReverseMatch for optional arguments
-+-
 Reporter:   |Owner:
  to.roma.from.djbug@…   |  mtredinnick
 Type:  Uncategorized|   Status:  closed
Component:  Core (Other) |  Version:  1.0
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:  Design
Has patch:  0|  decision needed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by anonymous):

 * ui_ux:   => 0
 * type:   => Uncategorized
 * severity:   => Normal
 * easy:   => 0


Comment:

 I noticed that this might be a workaround to the ticket. Basically being
 smarter with your URL regexs:
 http://c4urself.posterous.com/optional-arguments-with-django-url-patterns

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17681: Annotating an EmptyQueryset lead to not empty queryset

[Django]

#17681: Annotating an EmptyQueryset lead to not empty queryset
-+-
 Reporter:   |Owner:  nobody
  inscription.tresontani@…   |   Status:  new
 Type:  Bug  |  Version:  1.3
Component:  ORM aggregation  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:  EmptyQueryset,   |  Unreviewed
  annotate   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by akaariai):

 I don't see how what you describe could happen on trunk version.
 `EmptyQuerySet`.annotate() clearly does nothing.

 I have attached a patch implementing `EmptyQuerySet` removal. I am not at
 all sure it is a good idea, but at least it whacks a good 200 lines of
 code away.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17665: Inconsitent behaviour of filter() with multi-valued relations.

[Django]

#17665: Inconsitent behaviour of filter() with multi-valued relations.
-+-
 Reporter:  lrekucki |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:  invalid
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by lrekucki):

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


Comment:

 Ugh, my bad for not testing this with a different set of model. Now that I
 did, it turns out to be fault of "eav-django"
 (https://bitbucket.org/neithere/eav-
 django/src/df6fac3e18be/eav/managers.py#cl-53), which redefines
 {{{filter()}}} on the manager (but not the {{{QuerySet}}}, wth?). Thanks
 for the sanity check and sorry for the noise.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17687: LayerMapping ignores database routers

[Django]

#17687: LayerMapping ignores database routers
+--
 Reporter:  nosamanuel@…|Owner:  nobody
 Type:  Uncategorized   |   Status:  new
Component:  Uncategorized   |  Version:  1.3
 Severity:  Normal  |   Resolution:
 Keywords:  gis router multidb  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  1   |UI/UX:  0
+--
Changes (by anonymous):

 * needs_better_patch:   => 0
 * version:  1.3-rc1 => 1.3
 * 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17665: Inconsitent behaviour of filter() with multi-valued relations.

[Django]

#17665: Inconsitent behaviour of filter() with multi-valued relations.
-+-
 Reporter:  lrekucki |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by krzysiumed):

 * cc: krzysiumed@… (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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #14394: Assigning bad data to an m2m attribute should not clear existing data

[Django]

#14394: Assigning bad data to an m2m attribute should not clear existing data
-+-
 Reporter:  carljm   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by akaariai):

 The "lets iterate through the objects and fetch them one at a time" is a
 clear no-no. However, you can't assume a primary key is an int.

 I really don't know what there is to do here. You are at a point where
 data validation should have prevented the errors. If you get an error,
 rollback your transaction. If you don't want to do that, use a savepoint.

 This is not a unique situation in Django. For example, if you do a .save()
 on multitable inherited model, you can get it half saved if there is a
 data type mismatch in the topmost object in the inheritance chain.
 Something like:
 {{{
 class A:
 pass
 class B(A):
 f = models.IntegerField()
 B(f='not an integer').save()
 }}}
 do that and you got a save into A's table, but not into B's table.

 Now, this is not a reason to avoid all sanity checks. But, aiming for
 anything like perfection (guaranteeing that the insert will succeed after
 the delete) isn't worth the effort in my opinion. Even the query for all
 the objects one by one will not be guaranteed to work under normal
 transactional rules. You would need something like select for update. Lets
 not go there.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17665: Inconsitent behaviour of filter() with multi-valued relations.

[Django]

#17665: Inconsitent behaviour of filter() with multi-valued relations.
-+-
 Reporter:  lrekucki |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by krzysiumed):

 I cannot reproduce it. Could you attach your `models.py` and example set
 of `Company`, `Person` and `Membership_set` objects please?

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16128: cascade delete does not work for proxy models

[Django]

#16128: cascade delete does not work for proxy models
-+-
 Reporter:  xkennyx@…|Owner:  nobody
 Type:  Bug  |   Status:  reopened
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  cascade delete   |  Needs documentation:  0
  proxy meta |  Patch needs improvement:  1
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by carljm):

 Replying to [comment:23 anonymous]:
 > Any chance this, assuming you will come to a satisfactory patch, will
 also go into 1.3?

 No. It is not a security, data-loss, or crash bug, so it does not meet the
 [https://docs.djangoproject.com/en/dev/internals/release-process
 /#supported-versions criteria 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #17687: LayerMapping ignores database routers

[Django]

#17687: LayerMapping ignores database routers
---+
 Reporter:  nosamanuel@…   |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  1.3-rc1
 Severity:  Normal |   Keywords:  gis router multidb
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  1  |  UI/UX:  0
---+
 The `LayerMapping` class from `contrib.gis` currently supports multiple
 databases via a `using` argument that defaults to `DEFAULT_DB_ALIAS`. This
 fails when mapping a model that is routed to a non-default database.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #15760: Feature: JS Hooks for Dynamic Inlines

[Django]

#15760: Feature: JS Hooks for Dynamic Inlines
-+-
 Reporter:  mlavin   |Owner:  mlavin
 Type:  New feature  |   Status:  new
Component:  contrib.admin|  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:  inlines jquery   | Triage Stage:  Accepted
  callback   |  Needs documentation:  1
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  1
Easy pickings:  0|
-+-
Changes (by anonymous):

 * keywords:  inlines jquery => inlines jquery callback
 * owner:  nobody => mlavin


-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16941: naturaltime documentation is misleading

[Django]

#16941: naturaltime documentation is misleading
---+
 Reporter:  jaap3  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Documentation  |  Version:  SVN
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  1
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+
Changes (by anonymous):

 * needs_docs:  0 => 1
 * easy:  0 => 1


Comment:

 Seems to be a documentation issue then. Should be easy to fix right?

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #16128: cascade delete does not work for proxy models

[Django]

#16128: cascade delete does not work for proxy models
-+-
 Reporter:  xkennyx@…|Owner:  nobody
 Type:  Bug  |   Status:  reopened
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  cascade delete   |  Needs documentation:  0
  proxy meta |  Patch needs improvement:  1
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by anonymous):

 Any chance this, assuming you will come to a satisfactory patch, will also
 go into 1.3?

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #14394: Assigning bad data to an m2m attribute should not clear existing data

[Django]

#14394: Assigning bad data to an m2m attribute should not clear existing data
-+-
 Reporter:  carljm   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by krzysiumed):

 * cc: krzysiumed@… (added)
 * needs_better_patch:  0 => 1
 * ui_ux:   => 0
 * easy:   => 0


Comment:

 The last patch seems to be almost ready-for-checkin, but I think we should
 not check if primary keys are valid (lines 743-746 in last patch), because
 it requires large amount of sql queries and it could be slow. Instead, we
 should check if primary key is `int`. Maybe we should add note in
 documentation that django does not check it?

 In my opinion tests need small improvements:
 * In `test_assigning_any_iterable_with_valid_models_to_m2m_works` we don't
 need to check all possible iterables: sets, lists, tuples.
 * As I wrote, we should not validate primary keys, so we don't need
 
`test_assigning_iterable_with_invalid_pks_to_m2m_doesnt_clear_existing_relations`.
 * We can join `test_assigning_any_iterable_with_valid_models_to_m2m_works`
 and `test_assigning_any_iterable_with_valid_primary_keys_to_m2m_works` by
 testing `c1.tags = [t1, t2.pk]`.
 * There are redundant lines of code (for example `t1 =
 Tag.objects.create(name='t1')`). We can move them to `setUp`.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17543: Broken link to django-debug-toolbar repository

[Django]

#17543: Broken link to django-debug-toolbar repository
-+-
 Reporter:  rowynm@… |Owner:  nobody
 Type:  Bug  |   Status:  reopened
Component:  Documentation|  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  1|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by aaugustin):

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


Comment:

 Yes, let's backport the fix.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #15107: Convert core commands to use self.std(out|err) instead of sys.std(out|err)/print

[Django]

#15107: Convert core commands to use self.std(out|err) instead of
sys.std(out|err)/print
-+-
 Reporter:  mmcnickle|Owner:  mmcnickle
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  SVN
Component:  Core (Management |   Resolution:
  commands)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by claudep):

 * needs_better_patch:  1 => 0
 * ui_ux:   => 0
 * easy:   => 0


Comment:

 I worked on a refactor of commands output using logging infrastructure,
 adding new !BaseCommand.info() and !BaseCommand.error() proxy methods, and
 deprecating self.stderr and self.stdout. Hopefully this is in the right
 direction, as of jezdez comment:5.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17543: Broken link to django-debug-toolbar repository

[Django]

#17543: Broken link to django-debug-toolbar repository
-+-
 Reporter:  rowynm@… |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Documentation|  Version:  1.3
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  1|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by claudep):

 #17682 reported this again, with 1.3 as target. What about a backport of
 the fix?

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17682: django-debug-toolbar url changed

[Django]

#17682: django-debug-toolbar url changed
---+--
 Reporter:  mariuz |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Documentation  |  Version:  1.3
 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 claudep):

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


Comment:

 Duplicate of #17543

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #17686: file.save crashes on unicode filename

[Django]

#17686: file.save crashes on unicode filename
--+
 Reporter:  sylvain.lebon@…   |  Owner:  nobody
 Type:  Uncategorized | Status:  new
Component:  File uploads/storage  |Version:  1.3
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 I try to add a file into a FileField of one of my object.
 The problem is I get a file with a unicode name with special characters.

 I have
 {{{name = (u'l\u2019\xe9cran.png').encode("utf-8")}}}

 now if I do
 {{{str1 = "%s%s"(MEDIA_ROOT, name)}}}

 I have
 {{{'/home/oi/OIFS/Capture d\xe2\x80\x99\xc3\xa9cran 2012-01-24 \xc3\xa0
 14.58.48.png'}}}

 and os.stat(str1) passes.

 but with
 {{{str2 = safe_join(MEDIA_ROOT, name)}}}

 str is then
 {{{u'/home/oi/OIFS/Capture d\u2019\xe9cran 2012-01-24 \xe0
 14.58.48.png'}}}

 and os.stat fails.

 The thing is file.save(name, content, False) uses safe_join and then
 os.stat.

 Now I'm not sure if I should get the name in a different encoding but I
 don't seem to manage to get it right.

 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17675: using date filter with regroup tag not working with 1.4 TZ

[Django]

#17675: using date filter with regroup tag not working with 1.4 TZ
-+-
 Reporter:  ptone|Owner:  aaugustin
 Type:  Bug  |   Status:  new
Component:  Core (Other) |  Version:
 Severity:  Release blocker  |  1.4-alpha-1
 Keywords:   |   Resolution:
Has patch:  1| Triage Stage:  Ready for
  Needs tests:  0|  checkin
Easy pickings:  0|  Needs documentation:  0
 |  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by aaugustin):

 * stage:  Accepted => Ready for checkin


Comment:

 The same problem has "always" existed for template filters that have
 `needs_autoescape = True`. However, none of these are likely to be used in
 a `{% regroup %}` tag, so the bug went undetected. Since I added support
 for time zones, the problem also occurs for template filters that have
 `expects_localtime = True`: `|date` and `|time`, making it effectively a
 regression and a release blocker.

 I'm uploading a new patch that adds a contrived example (`'regroup04'`) in
 the tests for the shake of completeness, and more comments in the
 implementation of `{% regroup %}`. I believe it's good to go, I'm putting
 it in RFC in case someone wants to take a look or commit 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #9112: New releases do not reliably overwrite old ones

[Django]

#9112: New releases do not reliably overwrite old ones
-+
 Reporter:  holdenweb|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Documentation|  Version:  1.0
 Severity:  Release blocker  |   Resolution:
 Keywords:  release engineering  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by krzysiumed):

 * cc: krzysiumed@… (added)
 * has_patch:  0 => 1


Comment:

 I've sent initial draft.

 Some changes on `download` page are required.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #17685: Inconsistent 3-tuple item naming in BaseDateListView.get_dated_items()

[Django]

#17685: Inconsistent 3-tuple item naming in BaseDateListView.get_dated_items()
---+
 Reporter:  ejb|  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Documentation  |Version:  1.3
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  1
Easy pickings:  0  |  UI/UX:  0
---+
 https://docs.djangoproject.com/en/dev/ref/class-based-
 views/#django.views.generic.dates.BaseDateListView

 Says that get_dated_items() "Returns a 3-tuple containing (date_list,
 latest, extra_context)." then goes on to reference the second item as
 object_list.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #6271: filter arguments with spaces break several template tags

[Django]

#6271: filter arguments with spaces break several template tags
-+-
 Reporter:  Rob Hudson   |Owner:  aaugustin
     |   Status:  new
 Type:  New feature  |  Version:  SVN
Component:  Template system  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  tplrf-fixed  |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by aaugustin):

 * owner:   => aaugustin
 * ui_ux:   => 0
 * easy:   => 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17653: using id = 0 on get_or_create

[Django]

#17653: using id = 0 on get_or_create
-+-
 Reporter:  sylvain.lebon@…  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by krzysiumed):

 * needs_better_patch:  1 => 0


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17681: Annotating an EmptyQueryset lead to not empty queryset

[Django]

#17681: Annotating an EmptyQueryset lead to not empty queryset
-+-
 Reporter:   |Owner:  nobody
  inscription.tresontani@…   |   Status:  new
 Type:  Bug  |  Version:  1.3
Component:  ORM aggregation  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:  EmptyQueryset,   |  Unreviewed
  annotate   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by akaariai):

 * cc: akaariai (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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17681: Annotating an EmptyQueryset lead to not empty queryset

[Django]

#17681: Annotating an EmptyQueryset lead to not empty queryset
-+-
 Reporter:   |Owner:  nobody
  inscription.tresontani@…   |   Status:  new
 Type:  Bug  |  Version:  1.3
Component:  ORM aggregation  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:  EmptyQueryset,   |  Unreviewed
  annotate   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by akaariai):

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


Comment:

 I did some work of removing the `EmptyQuerySet` class altogether some time
 ago. The idea is to add something that returns `EmptyResultSet` as a top-
 level ANDed where condition. Thus, the query would not get executed at all
 because compiler.py would see there is no potential for any results. Can't
 find the code anywhere, maybe it is hidden in my home machine's git
 repo... Another way to get the same result would be to just add an
 attribute to `sql/query/QuerySet` called "empty".

 The change above should make models/query.py a lot more DRY (whack away
 all the `EmptyQuerySet` stub methods). The cost would be somewhat slower
 execution of operations after .none(), as the code would actually record
 the operations done, even if they never have any effect to anything. If I
 recall correctly what I did passed all tests.

 I haven't verified this ticket. But I think the above solution could be a
 easy way to avoid this bug and at the same time remove some code.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17684: URLValidator: Validation fails when URL requires User-Agent header

[Django]

#17684: URLValidator: Validation fails when URL requires User-Agent header
-+--
 Reporter:  pennersr |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (URLs)  |  Version:  1.3
 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 aaugustin):

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


Comment:

 Thanks for reporting this bug. However, the URL verification feature was
 removed in Django 1.4, thus "resolving" the issue. See r16760

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #12241: Admin forgets URL used for prefilling forms when hitting Save and add another

[Django]

#12241: Admin forgets URL used for prefilling forms when hitting Save and add
another
---+
 Reporter:  velmont|Owner:  batiste
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  SVN
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+
Changes (by michelts):

 * cc: michelts@… (added)
 * ui_ux:   => 0
 * easy:   => 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #17684: URLValidator: Validation fails when URL requires User-Agent header

[Django]

#17684: URLValidator: Validation fails when URL requires User-Agent header
-+
 Reporter:  pennersr |  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  Core (URLs)  |Version:  1.3
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 The following example shows a link that returns a 403 in case no user
 agent is passed. When passed, a proper 200 is returned. However, this does
 not seem to work with the URLValidator. The ValidationError is unexpected
 here...

 {{{
 >>> import django
 >>> django.VERSION
 (1, 3, 1, 'final', 0)
 >>> import requests
 >>> from django.core.validators import URLValidator
 >>> ua = 'foobar'
 >>> requests.get('http://www.autoedizione.nl/feed/')
 
 >>> requests.get('http://www.autoedizione.nl/feed/', headers={ 'User-
 Agent': ua})
 
 >>> URLValidator(verify_exists=True,
 validator_user_agent=ua)('http://www.autoedizione.nl/feed/')
 Traceback (most recent call last):
   File "", line 1, in 
   File "...HIDDEN.../django/django/core/validators.py", line 121, in
 __call__
 raise broken_error
 ValidationError: [u'This URL appears to be a broken link.']
 }}}

 (Python 2.6.5)

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #17683: `BaseModelFormSet` ignore form's widgets options when adding the pk field

[Django]

#17683: `BaseModelFormSet` ignore form's widgets options when adding the pk 
field
---+-
 Reporter:  charettes  |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Forms  |Version:  SVN
 Severity:  Normal |   Keywords:  basemodelformset widget
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  1  |  UI/UX:  0
---+-
 When defining a custom widget for the pk field of a modelform used in a
 modelformset this way:

 {{{
 #!python
 class MyModelForm(forms.ModelForm):
 class Meta:
 model = MyModel
 widgets = {
   'id': forms.HiddenInput(attrs={'class': 'a-useful-class'})
 }

 MyFormSet = modelformset_factory(MyModel, MyModelForm)
 }}}

 The specified widget is ignored because of
 [https://github.com/django/django/blob/master/django/forms/models.py#L661
 this line].

 It should be replaced by something along
 {{{
 #!python
 widget = form._meta.widgets.get(self._pk_field.name, HiddenInput)
 form.fields[self._pk_field.name] = ModelChoiceField(qs, initial=pk_value,
 required=False, widget=widget)
 }}}

 I'll provide patch with tests if this gets 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #17682: django-debug-toolbar url changed

[Django]

#17682: django-debug-toolbar url changed
---+
 Reporter:  mariuz |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Documentation  |Version:  1.3
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 On the optimization page
 https://docs.djangoproject.com/en/1.3/topics/db/optimization/
 The new django-debug-toolbar url should be

 https://github.com/django-debug-toolbar/django-debug-toolbar

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r17521 - in django/trunk: django/contrib/staticfiles django/contrib/staticfiles/management/commands docs/ref/contrib

[noreply]

Author: jezdez
Date: 2012-02-14 01:55:09 -0800 (Tue, 14 Feb 2012)
New Revision: 17521

Modified:
   django/trunk/django/contrib/staticfiles/management/commands/collectstatic.py
   django/trunk/django/contrib/staticfiles/storage.py
   django/trunk/docs/ref/contrib/staticfiles.txt
Log:
Stopped the collectstatic management from being wastful with file handlers. 
Refs r17519.

Modified: 
django/trunk/django/contrib/staticfiles/management/commands/collectstatic.py
===
--- 
django/trunk/django/contrib/staticfiles/management/commands/collectstatic.py
2012-02-13 20:57:44 UTC (rev 17520)
+++ 
django/trunk/django/contrib/staticfiles/management/commands/collectstatic.py
2012-02-14 09:55:09 UTC (rev 17521)
@@ -107,7 +107,7 @@
 prefixed_path = os.path.join(storage.prefix, path)
 else:
 prefixed_path = path
-found_files[prefixed_path] = storage.open(path)
+found_files[prefixed_path] = (storage, path)
 handler(path, prefixed_path, storage)
 
 # Here we check if the storage backend has a post_process

Modified: django/trunk/django/contrib/staticfiles/storage.py
===
--- django/trunk/django/contrib/staticfiles/storage.py  2012-02-13 20:57:44 UTC 
(rev 17520)
+++ django/trunk/django/contrib/staticfiles/storage.py  2012-02-14 09:55:09 UTC 
(rev 17521)
@@ -198,7 +198,8 @@
 
 # use the original, local file, not the copied-but-unprocessed
 # file, which might be somewhere far away, like S3
-with paths[name] as original_file:
+storage, path = paths[name]
+with storage.open(path) as original_file:
 
 # generate the hash with the original content, even for
 # adjustable files.

Modified: django/trunk/docs/ref/contrib/staticfiles.txt
===
--- django/trunk/docs/ref/contrib/staticfiles.txt   2012-02-13 20:57:44 UTC 
(rev 17520)
+++ django/trunk/docs/ref/contrib/staticfiles.txt   2012-02-14 09:55:09 UTC 
(rev 17521)
@@ -281,8 +281,8 @@
 .. versionadded:: 1.4
 
 This method is called by the :djadmin:`collectstatic` management command
-after each run and gets passed the paths of found files, as well as the
-command line options.
+after each run and gets passed the local storages and paths of found
+files as a dictionary, as well as the command line options.
 
 The :class:`~django.contrib.staticfiles.storage.CachedStaticFilesStorage`
 uses this behind the scenes to replace the paths with their hashed

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17600: Error in encapsulates filters (Q)

[Django]

#17600: Error in encapsulates filters (Q)
-+-
 Reporter:  pmartin  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Design
 Keywords:   |  decision needed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by pmartin):

 Replying to [comment:11 akaariai]:

 I think the same. Thanks akaariai, your comment is perfect. Good work!

 I sent this ticket to django-developers, to try that a core developer are
 interested. Subject: "A important bug in queryset"

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #14087: django.core.management.get_commands only sees commands in the last package of a namespace package

[Django]

#14087: django.core.management.get_commands only sees commands in the last 
package
of a namespace package
--+
 Reporter:  KyleMac   |Owner:  nobody
 Type:  Bug   |   Status:  reopened
Component:  Core (Other)  |  Version:  1.2
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+
Changes (by bhuztez):

 * needs_docs:  1 => 0


Comment:

 namespace_package_pth.2.diff will not look up importer in
 sys.path_importer_cache, since django do not support PEP 302 importer.

 should find commands in modules loaded by PEP 302 importer be in another
 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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #17681: Annotating an EmptyQueryset lead to not empty queryset

[Django]

#17681: Annotating an EmptyQueryset lead to not empty queryset
--+
 Reporter:  inscription.tresontani@…  |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  ORM aggregation   |Version:  1.3
 Severity:  Normal|   Keywords:  EmptyQueryset,
 Triage Stage:  Unreviewed|  annotate
Easy pickings:  0 |  Has patch:  0
  |  UI/UX:  0
--+
 Doing Table.objects.none().annotate(result=Sum("field1")) run a query.

 On big table, 5 millions row in our case, this lead to a query making
 mySQL crashed.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17679: Error messages from field.validators never used if the ValidationError has a code matching an error message on the Field

[Django]

#17679: Error messages from field.validators never used if the ValidationError 
has
a code matching an error message on the Field
+--
 Reporter:  insin   |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  Forms   |  Version:  SVN
 Severity:  Normal  |   Resolution:  duplicate
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Changes (by claudep):

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


Comment:

 This is a duplicate of #17051

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #17051: RegexValidator.message is not used

[Django]

#17051: RegexValidator.message is not used
+-
 Reporter:  jbcurtincode@…  |Owner:  anonymous
 Type:  Bug |   Status:  new
Component:  Forms   |  Version:  1.3
 Severity:  Normal  |   Resolution:
 Keywords:  validator   | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+-
Changes (by claudep):

 * component:  Core (Other) => Forms


Comment:

 #17679 is a duplicate with a link to a Github branch for a fix
 (https://github.com/insin/django/compare/validators-error-messages).

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.