[Changeset] r10463 - in django/branches/releases/1.0.X: . django/template django/utils tests/regressiontests/templates tests/regressiontests/text

[noreply]

Author: mtredinnick
Date: 2009-04-09 23:49:00 -0500 (Thu, 09 Apr 2009)
New Revision: 10463

Modified:
   django/branches/releases/1.0.X/AUTHORS
   django/branches/releases/1.0.X/django/template/__init__.py
   django/branches/releases/1.0.X/django/template/defaulttags.py
   django/branches/releases/1.0.X/django/utils/text.py
   django/branches/releases/1.0.X/tests/regressiontests/templates/tests.py
   django/branches/releases/1.0.X/tests/regressiontests/text/tests.py
Log:
[1.0.X] Fixed #9315 -- Handle spaces in URL tag arguments.

Thanks Natalia Bidart and Mat?\195?\173as Bordese for most of this patch.

Backport of r10462 from trunk.

Modified: django/branches/releases/1.0.X/AUTHORS
===
--- django/branches/releases/1.0.X/AUTHORS  2009-04-10 04:13:27 UTC (rev 
10462)
+++ django/branches/releases/1.0.X/AUTHORS  2009-04-10 04:49:00 UTC (rev 
10463)
@@ -59,11 +59,13 @@
 James Bennett
 Julian Bez
 Arvis Bickovskis 
+Natalia Bidart
 Paul Bissex 
 Simon Blanchard
 David Blewett 
 Matt Boersma 
 boo...@gmail.com
+Matías Bordese
 Andrew Brehaut 
 brut.a...@gmail.com
 bt...@bestweb.net

Modified: django/branches/releases/1.0.X/django/template/__init__.py
===
--- django/branches/releases/1.0.X/django/template/__init__.py  2009-04-10 
04:13:27 UTC (rev 10462)
+++ django/branches/releases/1.0.X/django/template/__init__.py  2009-04-10 
04:49:00 UTC (rev 10463)
@@ -465,8 +465,7 @@
 'i18n_close' : re.escape(")"),
   }
 
-filter_raw_string = filter_raw_string.replace("\n", "").replace(" ", "")
-filter_re = re.compile(filter_raw_string, re.UNICODE)
+filter_re = re.compile(filter_raw_string, re.UNICODE|re.VERBOSE)
 
 class FilterExpression(object):
 """

Modified: django/branches/releases/1.0.X/django/template/defaulttags.py
===
--- django/branches/releases/1.0.X/django/template/defaulttags.py   
2009-04-10 04:13:27 UTC (rev 10462)
+++ django/branches/releases/1.0.X/django/template/defaulttags.py   
2009-04-10 04:49:00 UTC (rev 10463)
@@ -1066,7 +1066,7 @@
 
 The URL will look like ``/clients/client/123/``.
 """
-bits = token.contents.split(' ')
+bits = token.split_contents()
 if len(bits) < 2:
 raise TemplateSyntaxError("'%s' takes at least one argument"
   " (path to a view)" % bits[0])

Modified: django/branches/releases/1.0.X/django/utils/text.py
===
--- django/branches/releases/1.0.X/django/utils/text.py 2009-04-10 04:13:27 UTC 
(rev 10462)
+++ django/branches/releases/1.0.X/django/utils/text.py 2009-04-10 04:49:00 UTC 
(rev 10463)
@@ -197,7 +197,13 @@
 return str(ustring_re.sub(fix, s))
 javascript_quote = allow_lazy(javascript_quote, unicode)
 
-smart_split_re = 
re.compile('("(?:[^"]*(?:.[^"]*)*)"|\'(?:[^\']*(?:.[^\']*)*)\'|[^\\s]+)')
+# Expression to match some_token and some_token="with spaces" (and similarly
+# for single-quoted strings).
+smart_split_re = re.compile(r"""
+([^\s"]*"(?:[^"\\]*(?:\\.[^"\\]*)*)"\S*|
+ [^\s']*'(?:[^'\\]*(?:\\.[^'\\]*)*)'\S*|
+ \S+)""", re.VERBOSE)
+
 def smart_split(text):
 r"""
 Generator that splits a string by spaces, leaving quoted phrases together.

Modified: 
django/branches/releases/1.0.X/tests/regressiontests/templates/tests.py
===
--- django/branches/releases/1.0.X/tests/regressiontests/templates/tests.py 
2009-04-10 04:13:27 UTC (rev 10462)
+++ django/branches/releases/1.0.X/tests/regressiontests/templates/tests.py 
2009-04-10 04:49:00 UTC (rev 10463)
@@ -947,6 +947,7 @@
 'url07': (u'{% url regressiontests.templates.views.client2 tag=v 
%}', {'v': u'Ω'}, '/url_tag/%D0%AE%D0%BD%D0%B8%D0%BA%D0%BE%D0%B4/%CE%A9/'),
 'url08': (u'{% url метка_оператора v %}', {'v': 'Ω'}, 
'/url_tag/%D0%AE%D0%BD%D0%B8%D0%BA%D0%BE%D0%B4/%CE%A9/'),
 'url09': (u'{% url метка_оператора_2 tag=v %}', {'v': 'Ω'}, 
'/url_tag/%D0%AE%D0%BD%D0%B8%D0%BA%D0%BE%D0%B4/%CE%A9/'),
+'url10': ('{% url regressiontests.templates.views.client_action 
id=client.id,action="two words" %}', {'client': {'id': 1}}, 
'/url_tag/client/1/two%20words/'),
 
 # Failures
 'url-fail01': ('{% url %}', {}, template.TemplateSyntaxError),

Modified: django/branches/releases/1.0.X/tests/regressiontests/text/tests.py
===
--- django/branches/releases/1.0.X/tests/regressiontests/text/tests.py  
2009-04-10 04:13:27 UTC (rev 10462)
+++ 

[Changeset] r10462 - in django/trunk: . django/template django/utils tests/regressiontests/templates tests/regressiontests/text

[noreply]

Author: mtredinnick
Date: 2009-04-09 23:13:27 -0500 (Thu, 09 Apr 2009)
New Revision: 10462

Modified:
   django/trunk/AUTHORS
   django/trunk/django/template/__init__.py
   django/trunk/django/template/defaulttags.py
   django/trunk/django/utils/text.py
   django/trunk/tests/regressiontests/templates/tests.py
   django/trunk/tests/regressiontests/text/tests.py
Log:
Fixed #9315 -- Handle spaces in URL tag arguments.

Thanks Natalia Bidart and Mat?\195?\173as Bordese for most of this patch.

Modified: django/trunk/AUTHORS
===
--- django/trunk/AUTHORS2009-04-10 01:13:29 UTC (rev 10461)
+++ django/trunk/AUTHORS2009-04-10 04:13:27 UTC (rev 10462)
@@ -63,11 +63,13 @@
 James Bennett
 Julian Bez
 Arvis Bickovskis 
+Natalia Bidart
 Paul Bissex 
 Simon Blanchard
 David Blewett 
 Matt Boersma 
 boo...@gmail.com
+Matías Bordese
 Andrew Brehaut 
 brut.a...@gmail.com
 bt...@bestweb.net

Modified: django/trunk/django/template/__init__.py
===
--- django/trunk/django/template/__init__.py2009-04-10 01:13:29 UTC (rev 
10461)
+++ django/trunk/django/template/__init__.py2009-04-10 04:13:27 UTC (rev 
10462)
@@ -480,8 +480,7 @@
 'arg_sep': re.escape(FILTER_ARGUMENT_SEPARATOR),
   }
 
-filter_raw_string = filter_raw_string.replace("\n", "").replace(" ", "")
-filter_re = re.compile(filter_raw_string, re.UNICODE)
+filter_re = re.compile(filter_raw_string, re.UNICODE|re.VERBOSE)
 
 class FilterExpression(object):
 r"""

Modified: django/trunk/django/template/defaulttags.py
===
--- django/trunk/django/template/defaulttags.py 2009-04-10 01:13:29 UTC (rev 
10461)
+++ django/trunk/django/template/defaulttags.py 2009-04-10 04:13:27 UTC (rev 
10462)
@@ -1100,7 +1100,7 @@
 
 The URL will look like ``/clients/client/123/``.
 """
-bits = token.contents.split(' ')
+bits = token.split_contents()
 if len(bits) < 2:
 raise TemplateSyntaxError("'%s' takes at least one argument"
   " (path to a view)" % bits[0])

Modified: django/trunk/django/utils/text.py
===
--- django/trunk/django/utils/text.py   2009-04-10 01:13:29 UTC (rev 10461)
+++ django/trunk/django/utils/text.py   2009-04-10 04:13:27 UTC (rev 10462)
@@ -197,7 +197,13 @@
 return str(ustring_re.sub(fix, s))
 javascript_quote = allow_lazy(javascript_quote, unicode)
 
-smart_split_re = 
re.compile('("(?:[^"]*(?:.[^"]*)*)"|\'(?:[^\']*(?:.[^\']*)*)\'|[^\\s]+)')
+# Expression to match some_token and some_token="with spaces" (and similarly
+# for single-quoted strings).
+smart_split_re = re.compile(r"""
+([^\s"]*"(?:[^"\\]*(?:\\.[^"\\]*)*)"\S*|
+ [^\s']*'(?:[^'\\]*(?:\\.[^'\\]*)*)'\S*|
+ \S+)""", re.VERBOSE)
+
 def smart_split(text):
 r"""
 Generator that splits a string by spaces, leaving quoted phrases together.

Modified: django/trunk/tests/regressiontests/templates/tests.py
===
--- django/trunk/tests/regressiontests/templates/tests.py   2009-04-10 
01:13:29 UTC (rev 10461)
+++ django/trunk/tests/regressiontests/templates/tests.py   2009-04-10 
04:13:27 UTC (rev 10462)
@@ -974,6 +974,7 @@
 'url07': (u'{% url regressiontests.templates.views.client2 tag=v 
%}', {'v': u'Ω'}, '/url_tag/%D0%AE%D0%BD%D0%B8%D0%BA%D0%BE%D0%B4/%CE%A9/'),
 'url08': (u'{% url метка_оператора v %}', {'v': 'Ω'}, 
'/url_tag/%D0%AE%D0%BD%D0%B8%D0%BA%D0%BE%D0%B4/%CE%A9/'),
 'url09': (u'{% url метка_оператора_2 tag=v %}', {'v': 'Ω'}, 
'/url_tag/%D0%AE%D0%BD%D0%B8%D0%BA%D0%BE%D0%B4/%CE%A9/'),
+'url10': ('{% url regressiontests.templates.views.client_action 
id=client.id,action="two words" %}', {'client': {'id': 1}}, 
'/url_tag/client/1/two%20words/'),
 
 # Failures
 'url-fail01': ('{% url %}', {}, template.TemplateSyntaxError),

Modified: django/trunk/tests/regressiontests/text/tests.py
===
--- django/trunk/tests/regressiontests/text/tests.py2009-04-10 01:13:29 UTC 
(rev 10461)
+++ django/trunk/tests/regressiontests/text/tests.py2009-04-10 04:13:27 UTC 
(rev 10462)
@@ -15,6 +15,18 @@
 [u'"a', u"'one"]
 >>> print list(smart_split(r'''all friends' tests'''))[1]
 friends'
+>>> list(smart_split(u'url search_page words="something else"'))
+[u'url', u'search_page', u'words="something else"']
+>>> list(smart_split(u"url search_page words='something else'"))
+[u'url', u'search_page', u"words='something else'"]
+>>> list(smart_split(u'url search_page words "something 

Re: [Django] #8104: IntegerField max_value & min_value errors require a %s

[Django]

#8104: IntegerField max_value & min_value errors require a %s
--+-
  Reporter:  Chris Jones   | Owner:  nobody  
  
Status:  new  | Milestone:  
  
 Component:  Forms|   Version:  
  
Resolution:   |  Keywords:  
IntegerField max_value min_value TypeError
 Stage:  Design decision needed   | Has_patch:  0   
  
Needs_docs:  0|   Needs_tests:  0   
  
Needs_better_patch:  0|  
--+-
Changes (by emonk):

  * version:  SVN =>

Comment:

 I agree, make a custom min_value or max_value error_messages with %s or
 whitout %s must be enable for forms.IntegerField

-- 
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] #10771: Add a transaction context manager

[Django]

#10771: Add a transaction context manager
---+
  Reporter:  obeattie  | Owner:  nobody 

Status:  new   | Milestone: 

 Component:  Database layer (models, ORM)  |   Version:  1.0

Resolution:|  Keywords:  
transaction, contextmanager
 Stage:  Design decision needed| Has_patch:  1  

Needs_docs:  0 |   Needs_tests:  0  

Needs_better_patch:  0 |  
---+
Comment (by ericholscher):

 Seems like something that couldn't be supported until 1.3 at least (or
 whenever we drop 2.4 support).

-- 
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] #9315: Keyword arguments with spaces and the url tag

[Django]

#9315: Keyword arguments with spaces and the url tag
--+-
  Reporter:  alexisbellido| Owner:  nessita 

Status:  assigned | Milestone:  1.1 

 Component:  Template system  |   Version:  1.0 

Resolution:   |  Keywords:  url, tplrf-fixed, 
pycamp2009
 Stage:  Accepted | Has_patch:  1   

Needs_docs:  0|   Needs_tests:  0   

Needs_better_patch:  0|  
--+-
Comment (by mtredinnick):

 I'm not going to apply the changes to the `split_contents()` portion,
 since they don't appear to fix an existing problem I'm not convinced they
 don't introduce a bug. We should fix on problem per ticket.

 If somebody wants to fix up that portion (and if it can be reduced to one
 line, that would be great), the patch should include test of the i18n
 pieces in that function. It's clearly looking at `_("...")` strings, but I
 don't see anything in the replacement code that handles that. It might
 well be being handled elsewhere automatically (so we're doing it twice
 now) and that will be demonstrated by the tests in the new ticket and
 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 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] #10675: escapejs doesn't handle U+2028 LINE SEPARATOR

[Django]

#10675: escapejs doesn't handle U+2028 LINE SEPARATOR
--+-
  Reporter:  olau | Owner:  rleland
Status:  new  | Milestone:  1.1
 Component:  Template system  |   Version:  1.0
Resolution:   |  Keywords: 
 Stage:  Accepted | Has_patch:  1  
Needs_docs:  0|   Needs_tests:  0  
Needs_better_patch:  0|  
--+-
Changes (by rleland):

  * has_patch:  0 => 1

Comment:

 After some research, JavaScript barfs on paragraph separator U+2029 as
 well. Patch supplies fix for both.

-- 
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] #4501: Coverage support for tests

[Django]

#4501: Coverage support for tests
+---
  Reporter:  b...@almad.net | Owner:  ericholscher
Status:  new| Milestone:  
 Component:  Testing framework  |   Version:  SVN 
Resolution: |  Keywords:  
 Stage:  Accepted   | Has_patch:  0   
Needs_docs:  0  |   Needs_tests:  0   
Needs_better_patch:  0  |  
+---
Changes (by nedbatchelder):

 * cc: n...@nedbatchelder.com (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
-~--~~~~--~~--~--~---

[Django] #10776: there should be a link from slugfield description to prepopulated field description

[Django]

#10776: there should be a link from slugfield description to prepopulated field
description
---+
 Reporter:  ernop  |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Documentation  | Version:  1.0   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 Right after adding slug fields to my models I spent a long time looking
 for how to prepopulate them, or source them from other fields.  I
 eventually just found prepopulated field randomly.

 The link should go from this paragraph

 http://docs.djangoproject.com/en/dev/ref/models/fields/#slugfield
 to
 http://docs.djangoproject.com/en/dev/ref/contrib/admin/#prepopulated-
 fields

 and i suggest text
 "If you want to use another field as the source of a slug in the admin
 system, use prepopulated_fields"

-- 
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] r10461 - in django/branches/releases/1.0.X: django/contrib/localflavor/pl tests/regressiontests/forms/localflavor

[noreply]

Author: mtredinnick
Date: 2009-04-09 20:13:29 -0500 (Thu, 09 Apr 2009)
New Revision: 10461

Modified:
   django/branches/releases/1.0.X/django/contrib/localflavor/pl/forms.py
   django/branches/releases/1.0.X/tests/regressiontests/forms/localflavor/pl.py
Log:
[1.0.X] Fixed #8515 -- Fixed validation of Polish REGON numbers.

Patch from Piotr Lewandowski.

Backport of r10460 from trunk.

Modified: django/branches/releases/1.0.X/django/contrib/localflavor/pl/forms.py
===
--- django/branches/releases/1.0.X/django/contrib/localflavor/pl/forms.py   
2009-04-10 01:03:44 UTC (rev 10460)
+++ django/branches/releases/1.0.X/django/contrib/localflavor/pl/forms.py   
2009-04-10 01:13:29 UTC (rev 10461)
@@ -100,20 +100,18 @@
 
 class PLREGONField(RegexField):
 """
-A form field that validated as Polish National Official Business Register
-Number (REGON). Valid numbers contain 7 or 9 digits.
+A form field that validates its input is a REGON number.
 
-More on the field: http://www.stat.gov.pl/bip/regon_ENG_HTML.htm
-
-The checksum algorithm is documented at 
http://wipos.p.lodz.pl/zylla/ut/nip-rego.html
+Valid regon number consists of 9 or 14 digits.
+See http://www.stat.gov.pl/bip/regon_ENG_HTML.htm for more information.
 """
 default_error_messages = {
-'invalid': _(u'National Business Register Number (REGON) consists of 7 
or 9 digits.'),
+'invalid': _(u'National Business Register Number (REGON) consists of 9 
or 14 digits.'),
 'checksum': _(u'Wrong checksum for the National Business Register 
Number (REGON).'),
 }
 
 def __init__(self, *args, **kwargs):
-super(PLREGONField, self).__init__(r'^\d{7,9}$',
+super(PLREGONField, self).__init__(r'^\d{9,14}$',
 max_length=None, min_length=None, *args, **kwargs)
 
 def clean(self,value):
@@ -126,25 +124,20 @@
 """
 Calculates a checksum with the provided algorithm.
 """
-multiple_table_7 = (2, 3, 4, 5, 6, 7)
-multiple_table_9 = (8, 9, 2, 3, 4, 5, 6, 7)
-result = 0
+weights = (
+(8, 9, 2, 3, 4, 5, 6, 7, -1),
+(2, 4, 8, 5, 0, 9, 7, 3, 6, 1, 2, 4, 8, -1),
+(8, 9, 2, 3, 4, 5, 6, 7, -1, 0, 0, 0, 0, 0),
+)
 
-if len(number) == 7:
-multiple_table = multiple_table_7
-else:
-multiple_table = multiple_table_9
+weights = [table for table in weights if len(table) == len(number)]
 
-for i in range(len(number)-1):
-result += int(number[i]) * multiple_table[i]
+for table in weights:
+checksum = sum([int(n) * w for n, w in zip(number, table)])
+if checksum % 11 % 10:
+return False
 
-result %= 11
-if result == 10:
-result = 0
-if result  == int(number[-1]):
-return True
-else:
-return False
+return bool(weights)
 
 class PLPostalCodeField(RegexField):
 """

Modified: 
django/branches/releases/1.0.X/tests/regressiontests/forms/localflavor/pl.py
===
--- 
django/branches/releases/1.0.X/tests/regressiontests/forms/localflavor/pl.py
2009-04-10 01:03:44 UTC (rev 10460)
+++ 
django/branches/releases/1.0.X/tests/regressiontests/forms/localflavor/pl.py
2009-04-10 01:13:29 UTC (rev 10461)
@@ -67,8 +67,18 @@
 
 >>> from django.contrib.localflavor.pl.forms import PLREGONField
 >>> f = PLREGONField()
+>>> f.clean('12345678512347')
+u'12345678512347'
 >>> f.clean('590096454')
 u'590096454'
+>>> f.clean('123456784')
+Traceback (most recent call last):
+...
+ValidationError: [u'Wrong checksum for the National Business Register Number 
(REGON).']
+>>> f.clean('12345678412342')
+Traceback (most recent call last):
+...
+ValidationError: [u'Wrong checksum for the National Business Register Number 
(REGON).']
 >>> f.clean('590096453')
 Traceback (most recent call last):
 ...
@@ -76,6 +86,6 @@
 >>> f.clean('590096')
 Traceback (most recent call last):
 ...
-ValidationError: [u'National Business Register Number (REGON) consists of 7 or 
9 digits.']
+ValidationError: [u'National Business Register Number (REGON) consists of 9 or 
14 digits.']
 
 """


--~--~-~--~~~---~--~~
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] #8515: PLREGONField incorrecly validates REGON numbers

[Django]

#8515: PLREGONField incorrecly validates REGON numbers
---+
  Reporter:  Piotr Lewandowski   | Owner: 
 nobody
Status:  closed| Milestone: 
 1.1   
 Component:  django.contrib.localflavor|   Version: 
 SVN   
Resolution:  fixed |  Keywords: 
   
 Stage:  Accepted  | Has_patch: 
 1 
Needs_docs:  0 |   Needs_tests: 
 0 
Needs_better_patch:  0 |  
---+
Changes (by Alex):

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

Comment:

 Fixed in r10460.

-- 
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] r10460 - in django/trunk: django/contrib/localflavor/pl tests/regressiontests/forms/localflavor

[noreply]

Author: mtredinnick
Date: 2009-04-09 20:03:44 -0500 (Thu, 09 Apr 2009)
New Revision: 10460

Modified:
   django/trunk/django/contrib/localflavor/pl/forms.py
   django/trunk/tests/regressiontests/forms/localflavor/pl.py
Log:
Fixed #8515 -- Fixed validation of Polish REGON numbers.

Patch from Piotr Lewandowski.

Modified: django/trunk/django/contrib/localflavor/pl/forms.py
===
--- django/trunk/django/contrib/localflavor/pl/forms.py 2009-04-09 15:28:41 UTC 
(rev 10459)
+++ django/trunk/django/contrib/localflavor/pl/forms.py 2009-04-10 01:03:44 UTC 
(rev 10460)
@@ -100,20 +100,18 @@
 
 class PLREGONField(RegexField):
 """
-A form field that validated as Polish National Official Business Register
-Number (REGON). Valid numbers contain 7 or 9 digits.
+A form field that validates its input is a REGON number.
 
-More on the field: http://www.stat.gov.pl/bip/regon_ENG_HTML.htm
-
-The checksum algorithm is documented at 
http://wipos.p.lodz.pl/zylla/ut/nip-rego.html
+Valid regon number consists of 9 or 14 digits.
+See http://www.stat.gov.pl/bip/regon_ENG_HTML.htm for more information.
 """
 default_error_messages = {
-'invalid': _(u'National Business Register Number (REGON) consists of 7 
or 9 digits.'),
+'invalid': _(u'National Business Register Number (REGON) consists of 9 
or 14 digits.'),
 'checksum': _(u'Wrong checksum for the National Business Register 
Number (REGON).'),
 }
 
 def __init__(self, *args, **kwargs):
-super(PLREGONField, self).__init__(r'^\d{7,9}$',
+super(PLREGONField, self).__init__(r'^\d{9,14}$',
 max_length=None, min_length=None, *args, **kwargs)
 
 def clean(self,value):
@@ -126,25 +124,20 @@
 """
 Calculates a checksum with the provided algorithm.
 """
-multiple_table_7 = (2, 3, 4, 5, 6, 7)
-multiple_table_9 = (8, 9, 2, 3, 4, 5, 6, 7)
-result = 0
+weights = (
+(8, 9, 2, 3, 4, 5, 6, 7, -1),
+(2, 4, 8, 5, 0, 9, 7, 3, 6, 1, 2, 4, 8, -1),
+(8, 9, 2, 3, 4, 5, 6, 7, -1, 0, 0, 0, 0, 0),
+)
 
-if len(number) == 7:
-multiple_table = multiple_table_7
-else:
-multiple_table = multiple_table_9
+weights = [table for table in weights if len(table) == len(number)]
 
-for i in range(len(number)-1):
-result += int(number[i]) * multiple_table[i]
+for table in weights:
+checksum = sum([int(n) * w for n, w in zip(number, table)])
+if checksum % 11 % 10:
+return False
 
-result %= 11
-if result == 10:
-result = 0
-if result  == int(number[-1]):
-return True
-else:
-return False
+return bool(weights)
 
 class PLPostalCodeField(RegexField):
 """

Modified: django/trunk/tests/regressiontests/forms/localflavor/pl.py
===
--- django/trunk/tests/regressiontests/forms/localflavor/pl.py  2009-04-09 
15:28:41 UTC (rev 10459)
+++ django/trunk/tests/regressiontests/forms/localflavor/pl.py  2009-04-10 
01:03:44 UTC (rev 10460)
@@ -67,8 +67,18 @@
 
 >>> from django.contrib.localflavor.pl.forms import PLREGONField
 >>> f = PLREGONField()
+>>> f.clean('12345678512347')
+u'12345678512347'
 >>> f.clean('590096454')
 u'590096454'
+>>> f.clean('123456784')
+Traceback (most recent call last):
+...
+ValidationError: [u'Wrong checksum for the National Business Register Number 
(REGON).']
+>>> f.clean('12345678412342')
+Traceback (most recent call last):
+...
+ValidationError: [u'Wrong checksum for the National Business Register Number 
(REGON).']
 >>> f.clean('590096453')
 Traceback (most recent call last):
 ...
@@ -76,6 +86,6 @@
 >>> f.clean('590096')
 Traceback (most recent call last):
 ...
-ValidationError: [u'National Business Register Number (REGON) consists of 7 or 
9 digits.']
+ValidationError: [u'National Business Register Number (REGON) consists of 9 or 
14 digits.']
 
 """


--~--~-~--~~~---~--~~
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] #10775: utils/version.py should not assume that it has access to the file system

[Django]

#10775: utils/version.py should not assume that it has access to the file system
---+
 Reporter:  mad|   Owner:  mad   
   Status:  new|   Milestone:
Component:  Uncategorized  | Version:  1.0   
 Keywords: |   Stage:  Unreviewed
Has_patch:  1  |  
---+
 When running a DJango app on a server without file access (like Google's
 AppEngine), the utils/version.py get_svn_revision method throws an
 exception and the app fails initializing.

-- 
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] #10773: 3 letters french translation of August use 4 chars

[Django]

#10773: 3 letters french translation of August use 4 chars
+---
  Reporter:  djoume | Owner:  nobody
Status:  new| Milestone:  1.1   
 Component:  Uncategorized  |   Version:  1.0   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by julien):

  * needs_better_patch:  => 0
  * needs_docs:  => 0
  * stage:  Unreviewed => Accepted
  * needs_tests:  => 0
  * milestone:  => 1.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 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] #6735: Class-based generic views

[Django]

#6735: Class-based generic views
+---
  Reporter:  jkocherhans| Owner:  telenieko
Status:  assigned   | Milestone:  1.2  
 Component:  Generic views  |   Version:  SVN  
Resolution: |  Keywords:   
 Stage:  Accepted   | Has_patch:  1
Needs_docs:  1  |   Needs_tests:  0
Needs_better_patch:  0  |  
+---
Changes (by mmalone):

 * cc: mjmal...@gmail.com (added)

Comment:

 I think documenting the use of class-based views and providing a simple
 implementation would be a great addition to Django, but I don't think this
 is the right approach.

 I've seen two methods of implementing class-based views, `__call__` based
 and `__init__` based. The attached patch uses the `__call__` approach.
 Here's a quick example of an `__init__` based class-view:


 {{{
 from django.http import HttpResponse

 class BaseView(HttpRespones):
 def __init__(self, request, *args, **kwargs):
 content = self.get(*args, **kwargs)
 super(MyView, self).__init__(content)

 def get(self):
 return 'Hello, world!'
 }}}

 The big gain here is that Django will instantiate a view instances per
 request, so you can actually store state in view objects. The `__call__`
 based approach can be misleading/dangerous/confusing in this respect since
 the view instance is a global object that will be retained between
 requests. Even if you reset the state of the object at the beginning of
 each request, it's process local so it isn't thread safe.

 The only thing the `__init__` approach complicates is passing default
 arguments in during instantiation (e.g., model and post_save_redirect in
 the attached patch), but the url() function already solves that problem
 for function-based views by providing the kwargs argument, which works
 equally well here.

 Unless anyone can think of some benefit to using the `__call__` approach,
 I'd suggest we use `__init__` instead.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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] #10774: Accessing form media subtypes ('js', 'css') in templates does not work

[Django]

#10774: Accessing form media subtypes ('js', 'css') in templates does not work
---+
  Reporter:  tarequeh  | Owner:  nobody  
Status:  new   | Milestone:  1.1 
 Component:  Forms |   Version:  SVN 
Resolution:|  Keywords:  form media typeerror
 Stage:  Accepted  | Has_patch:  1   
Needs_docs:  0 |   Needs_tests:  0   
Needs_better_patch:  0 |  
---+
Changes (by nbstrite):

  * 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 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] #10774: Accessing form media subtypes ('js', 'css') in templates does not work

[Django]

#10774: Accessing form media subtypes ('js', 'css') in templates does not work
---+
  Reporter:  tarequeh  | Owner:  nobody  
Status:  new   | Milestone:  1.1 
 Component:  Forms |   Version:  SVN 
Resolution:|  Keywords:  form media typeerror
 Stage:  Accepted  | Has_patch:  0   
Needs_docs:  0 |   Needs_tests:  0   
Needs_better_patch:  0 |  
---+
Changes (by Alex):

  * needs_better_patch:  => 0
  * needs_docs:  => 0
  * stage:  Unreviewed => Accepted
  * needs_tests:  => 0
  * milestone:  => 1.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 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] #10571: FakePayload Truncates Unicode Content

[Django]

#10571: FakePayload Truncates Unicode Content
---+
  Reporter:  rwag...@physics.ucsd.edu  | Owner:  nobody
Status:  reopened  | Milestone:  1.1   
 Component:  Testing framework |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by rwag...@physics.ucsd.edu):

  * has_patch:  0 => 1

Comment:

 Adding patch. I hope I don't end up doing this a bunch of times and
 spamming everyone and the RSS feed.

-- 
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] #10774: Accessing form media subtypes ('js', 'css') in templates does not work

[Django]

#10774: Accessing form media subtypes ('js', 'css') in templates does not work
--+-
 Reporter:  tarequeh  |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Forms | Version:  SVN   
 Keywords:  form media typeerror  |   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 Accessing form.media.js or form.media.css from templates does not work
 because the keys ('js', 'css') gets passed in as unicode strings. The
 {{{__getitem__}}} function for django form widget Media object
 [http://code.djangoproject.com/browser/django/trunk/django/forms/widgets.py#L78
 defined here] raises {{{TypeError: '__init__() keywords must be
 strings'}}} whenever name variable is a unicode string.

-- 
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] #10571: FakePayload Truncates Unicode Content

[Django]

#10571: FakePayload Truncates Unicode Content
---+
  Reporter:  rwag...@physics.ucsd.edu  | Owner:  nobody
Status:  reopened  | Milestone:  1.1   
 Component:  Testing framework |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by rwag...@physics.ucsd.edu):

 Replying to [comment:6 russellm]:
 > Rick - thanks so much for taking the trouble to work out such a complete
 set of demonstration cases.

 Gladly. I respect the time you put in developing and maintaining Django.

 > I'm going to qualify my comments with the following: I would not, on my
 best day, call Unicode handling one of my strengths. It's entirely
 possible I've got everything bass-ackwards here. I'll be the first to
 defer to anyone with superior knowledge in this case.

 I assure you, that would not be me. This has been one of those "learning
 experiences" we all appreciate.

 > So - to confirm whether or not I understand anything about unicode... if
 you do the following:
 >  1. Add the .encode() and .decode() calls to the FakePayload tests.
 >  2. Add the .encode('utf-8') to the post() method on the test client.
 >  3. Add the .decode('utf-8') to the response.content check in the
 payload tests.
 >
 > I believe that all your tests should pass. Can you confirm that this is
 the case? Or do I need to go back to the books and read up on unicode some
 more?

 You were correct in all cases. I went ahead and added the check for a
 charset on the content-type argument to set the encoding based on a user-
 supplied encoding. I also added a test using KOI8-R, just to step away
 from ASCII and UTF-8.

 The check for the charset is not the cleanest, but it's working:

 {{{
 #!python
 if content_type is MULTIPART_CONTENT:
 post_data = encode_multipart(BOUNDARY, data)
 else:
 # Encode the content so that the byte representation is
 correct.
 charset = settings.DEFAULT_CHARSET
 if 'charset=' in content_type:
 left, charset = content_type.split('charset=')
 post_data = data.encode(charset)
 }}}

 Likewise, I updated my test view to use the correct encoding when dumping
 the dict to JSON, and in the response:

 {{{
 #!python
 def return_json_file(request):
 "A view that parses and returns a JSON string as a file."
 charset = settings.DEFAULT_CHARSET
 if 'charset=' in request.META['CONTENT_TYPE']:
 left, charset = request.META['CONTENT_TYPE'].split('charset=')

 # This just checks that the uploaded data is JSON
 obj_dict = simplejson.loads(request.raw_post_data)
 obj_json = simplejson.dumps(obj_dict, encoding=charset,
 cls=DjangoJSONEncoder,
 ensure_ascii=False)
 response =  HttpResponse(obj_json, status=200,
  mimetype='application/json; charset=' +
 charset)
 response['Content-Disposition'] = 'attachment; filename=testfile.json'
 return response
 }}}

 Finally, I added your decode suggestions to the regression tests, and the
 new test using KOI-8.

 {{{
 #!python
 class UnicodePostTests(TestCase):
 # FakePayload is not intended to be externally accessible.
 # These are also exercised using the _payload_ tests.
 def test_simple_fakepayload(self):
 "Make sure that FakePayload returns what it gets"
 #Regression test for #10571
 json = u'{"english": "mountain pass"}'
 payload = FakePayload(json.encode('utf-8'))
 self.assertEqual(payload.read().decode('utf-8'), json)

 def test_fakepayload(self):
 "Make sure that FakePayload returns what it gets, outside of
 ASCII"
 #Regression test for #10571
 json = u'{"japanese": "\u5ce0 (\u3068\u3046\u3052 t\u014dge)"}'
 payload = FakePayload(json.encode('utf-8'))
 self.assertEqual(payload.read().decode('utf-8'), json)

 def test_simple_unicode_payload(self):
 "Test POSTing a simple JSON document"
 #Regression test for #10571
 json = u'{"english": "mountain pass"}'
 response =
 self.client.post("/test_client_regress/parse_unicode_json/", json,
 content_type="application/json")
 # N.B: This relys on the simplejson formatting
 self.assertEqual(response.content, json)

 def test_unicode_payload_utf8(self):
 "Test POSTing data outside of ASCII"
 #Regression test for #10571
 json = u'{"dog": "собака"}'
 response =
 

[Django] #10773: 3 letters french translation of August use 4 chars

[Django]

#10773: 3 letters french translation of August use 4 chars
---+
 Reporter:  djoume |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Uncategorized  | Version:  1.0   
 Keywords: |   Stage:  Unreviewed
Has_patch:  1  |  
---+
 According to the documentation:

 http://docs.djangoproject.com/en/dev/ref/templates/builtins/#now

 b Month, textual, 3 letters, lowercase.

 However the French translation for the month of August is currently "aout"
 (4 chars).

 This cause an url pattern like (?P\w\w\w) to throw a NoReverseMatch
 in French.

 The attached patch fix the issue.

-- 
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] #10765: Problem with translations when the settings module is a folder

[Django]

#10765: Problem with translations when the settings module is a folder
---+
  Reporter:  vbmendes  | Owner:  nobody 
  
Status:  new   | Milestone: 
  
 Component:  Internationalization  |   Version:  1.0
  
Resolution:|  Keywords:  translation 
settings project path
 Stage:  Unreviewed| Has_patch:  1  
  
Needs_docs:  0 |   Needs_tests:  0  
  
Needs_better_patch:  0 |  
---+
Changes (by anonymous):

  * 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 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] #9563: displaying comments docs lack attributes description

[Django]

#9563: displaying comments docs lack attributes description
+---
  Reporter:  mapleoin   | Owner:  jacob   
Status:  closed | Milestone:  1.1 
 Component:  Documentation  |   Version:  1.0 
Resolution:  fixed  |  Keywords:  comments
 Stage:  Accepted   | Has_patch:  1   
Needs_docs:  0  |   Needs_tests:  0   
Needs_better_patch:  0  |  
+---
Changes (by jacob):

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

Comment:

 This was fixed in the mega doc patch I checked in some time ago
 (http://docs.djangoproject.com/en/dev/ref/contrib/comments/models/).

-- 
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] #10772: Password Reset exposes non-trivial security vulnerability

[Django]

#10772: Password Reset exposes non-trivial security vulnerability
-+--
  Reporter:  fergusferrier   | Owner:  nobody  
Status:  closed  | Milestone:  
 Component:  Authentication  |   Version:  1.0 
Resolution:  invalid |  Keywords:  password reset token
 Stage:  Unreviewed  | Has_patch:  0   
Needs_docs:  0   |   Needs_tests:  0   
Needs_better_patch:  0   |  
-+--
Changes (by jacob):

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

Comment:

 Yeah. If an attacker has read access to your settings.py and your users
 table you've got a lot more to worry about than them changing your users'
 passwords.

-- 
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] #10771: Add a transaction context manager

[Django]

#10771: Add a transaction context manager
---+
  Reporter:  obeattie  | Owner:  nobody 

Status:  new   | Milestone: 

 Component:  Database layer (models, ORM)  |   Version:  1.0

Resolution:|  Keywords:  
transaction, contextmanager
 Stage:  Design decision needed| Has_patch:  1  

Needs_docs:  0 |   Needs_tests:  0  

Needs_better_patch:  0 |  
---+
Changes (by Alex):

  * needs_better_patch:  => 0
  * stage:  Unreviewed => Design decision needed
  * 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] #10154: allow the combination of an F expression with a timedelta

[Django]

#10154: allow the combination of an F expression with a timedelta
---+
  Reporter:  Koen Biermans   | 
Owner:  nobody 
Status:  new   | 
Milestone: 
 Component:  Database layer (models, ORM)  |   
Version:  SVN
Resolution:|  
Keywords:  expressions
 Stage:  Accepted  | 
Has_patch:  1  
Needs_docs:  1 |   
Needs_tests:  0  
Needs_better_patch:  1 |  
---+
Changes (by gt4329b):

 * cc: gt43...@pobox.com (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] #10154: allow the combination of an F expression with a timedelta

[Django]

#10154: allow the combination of an F expression with a timedelta
---+
  Reporter:  Koen Biermans   | 
Owner:  nobody 
Status:  new   | 
Milestone: 
 Component:  Database layer (models, ORM)  |   
Version:  SVN
Resolution:|  
Keywords:  expressions
 Stage:  Accepted  | 
Has_patch:  1  
Needs_docs:  1 |   
Needs_tests:  0  
Needs_better_patch:  1 |  
---+
Comment (by gt4329b):

 I'm definitely a big juicy +1 on this, as I need it right now for
 [http://www.realmwatcher.com one of my sites]

-- 
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] #10772: Password Reset exposes non-trivial security vulnerability

[Django]

#10772: Password Reset exposes non-trivial security vulnerability
--+-
 Reporter:  fergusferrier |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Authentication| Version:  1.0   
 Keywords:  password reset token  |   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 Assuming an attacker obtained:[[BR]]
 1) read access to your Users table[[BR]]
 2) read access to your settings.py file [presumably a good chance of this
 if they have 1)]

 Then they can set the password for any user, because the token that would
 have been created in password reset can be created knowing
 settings.SECRET_KEY and the User's data.

 {{{
 hash = sha_constructor(settings.SECRET_KEY + unicode(user.id) +
user.password + unicode(user.last_login) +
unicode(timestamp)).hexdigest()[::2]
 }}}

 Thus escalating read-access to certain data, to User-level write access.
 Or if a superuser account were compromised, full data-object-level write
 access.

 Two alternatives:

 1) A randomly-generated key is generated each time password reset
 requested, and stored in a Model. This only restricts the vulnerability to
 attackers who have real-time access to the User table, as they can effect
 the same vulnerability by requesting password reset for the user they
 wanted to 'become', and reading the key from the database. Though this
 leaves password reset emails in wake.

 2) The only possible better idea I can suggest would be some kind of
 system where part of the token information was sent with the email [maybe
 a random string] and part stored in the database [a hash of that random
 string]. So, even if you could read the database, you would need the
 information sent with the email to effect password reset. Though if you
 had access to comprehensive mail logs on the box, same problem.

 But maybe this isn't as dire as I'm making it out to be...

-- 
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] #10771: Add a transaction context manager

[Django]

#10771: Add a transaction context manager
--+-
 Reporter:  obeattie  |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Database layer (models, ORM)  | Version:  1.0   
 Keywords:  transaction, contextmanager   |   Stage:  Unreviewed
Has_patch:  1 |  
--+-
 For users who use transactions heavily, it is sometimes desirable to be
 able to wrap parts of a function (but not all of it) in a transaction of
 its own. Previously, the best way to do this was either to do it manually
 with a `try…except…else` block or creating a sub-function wrapped in
 `commit_on_success`, but context managers in Python 2.5+ can make this
 much cleaner by just saying…

 {{{
 with transaction:
 # do stuff
 }}}

 …which will handle committing and rolling back. Attached is a patch that
 I'd love to see implemented in Django :) The function is extremely similar
 to `commit_on_success` (the structure is identical).

-- 
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] #10768: Allow for Admin Actions to be applied to an empty QuerySet

[Django]

#10768: Allow for Admin Actions to be applied to an empty QuerySet
--+-
  Reporter:  andreplebl...@gmail.com  | Owner:  nobody 
Status:  closed   | Milestone: 
 Component:  django.contrib.admin |   Version:  SVN
Resolution:  wontfix  |  Keywords:  actions
 Stage:  Unreviewed   | Has_patch:  0  
Needs_docs:  0|   Needs_tests:  0  
Needs_better_patch:  0|  
--+-
Comment (by andreplebl...@gmail.com):

 at the risk of stepping on someone's toes, I'm going to push this issue
 just a little bit further.  The decision to NOT call the method when the
 selection is empty seems unnecessary.  Actions are there for an easy way
 for developers to add custom functionality to the admin, it should be up
 to the action itself to decide how to behave with an empty queryset, and
 any action that is written to work with a queryset will effectively be a
 no-op when given an empty queryset anyway.  what if all I wanted to do was
 add a message stating 'Please select at least one item to perform this
 action on' when passed an empty queryset, I dont even have that option
 because the admin app arbitrarily decides not to call my function, even
 though it can't have any negative side-effects to simply pass it an empty
 one.  object tools may be the more 'correct' place for a developer to add
 these types of functionality, but realistically, it's a LOT more work,
 urls and views need to be constructed to handle it all, templates need to
 be overridden, and it just feels hacky.

-- 
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] #7048: Support clearing FileFields with ModelForms

[Django]

#7048: Support clearing FileFields with ModelForms
---+
  Reporter:  jarrow| Owner:  brosner
Status:  assigned  | Milestone:  1.1
 Component:  django.contrib.admin  |   Version:  SVN
Resolution:|  Keywords: 
 Stage:  Accepted  | Has_patch:  1  
Needs_docs:  0 |   Needs_tests:  1  
Needs_better_patch:  0 |  
---+
Comment (by jarrow):

 The deletion of files from disk was already in the code that Brian gave
 me. So I thought that it was in scope for the ticket. I also wouldn't call
 the deletion of files and directories unrelated. I would expect the admin
 to be able to get rid of uploaded files if it has the option to clear the
 field. But we could of course disable this by default. Sure the delete
 directories feature sounds scary, that's why it is off by default.

 Brian wanted to review the ticket. I hope he finds the time to have a look
 at this (he seems to be rather busy at the moment ...).

-- 
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] #9289: Swedish (se) localflavor

[Django]

#9289: Swedish (se) localflavor
-+--
  Reporter:  peritus | Owner:   

Status:  new | Milestone:  1.2  

 Component:  django.contrib.localflavor  |   Version:  SVN  

Resolution:  |  Keywords:  
localflavor,sv,se
 Stage:  Accepted| Has_patch:  1

Needs_docs:  0   |   Needs_tests:  0

Needs_better_patch:  0   |  
-+--
Changes (by Alex):

  * milestone:  1.1 => 1.2

Comment:

 We're now past feature freeze, this will have to wait until 1.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] #9286: Starting other processes in a view gives me some weird results.

[Django]

#9286: Starting other processes in a view gives me some weird results.
+---
  Reporter:  namename12 | Owner:  nobody
Status:  closed | Milestone:  1.1   
 Component:  Uncategorized  |   Version:  1.0   
Resolution:  worksforme |  Keywords:
 Stage:  Accepted   | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by jacob):

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

Comment:

 I'm not sure this is a bug at all. That is, `Popen.communicate()` is
 supposed to block until stdin reaches EOF
 (http://docs.python.org/library/subprocess.html#subprocess.Popen.communicate).
 And that's exactly what happens when I spawn processes from a Django view:
 when the process completes, so does the view.

-- 
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] #9118: Unhelpful handling of UTF_8 encoding bugs in ModelForm field.help_text

[Django]

#9118: Unhelpful handling of UTF_8 encoding bugs in ModelForm field.help_text
---+
  Reporter:  jbl1  | Owner: 
Status:  closed| Milestone:  1.1
 Component:  Forms |   Version:  SVN
Resolution:  wontfix   |  Keywords: 
 Stage:  Accepted  | Has_patch:  0  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Changes (by jacob):

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

Comment:

 I'm not quite sure what Django can do better here; if you've got an
 invalid encoding in your source file, that's on you.

 The reason you're not getting an error in the template is because it's
 generally the policy that invalid data shouldn't cause the template
 rendering to break. That's mostly a good policy, and we can't change it
 even though in this particular case it's causing more harm than good.

-- 
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] #8538: Document when process_response and process_exception middleware is invoked

[Django]

#8538: Document when process_response and process_exception middleware is 
invoked
+---
  Reporter:  TP | Owner:  jacob 
Status:  closed | Milestone:  1.1   
 Component:  Documentation  |   Version:  SVN   
Resolution:  fixed  |  Keywords:  middleware
 Stage:  Accepted   | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by jacob):

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

Comment:

 This has been fixed for a bit; not exactly sure when it got checked in.

-- 
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] #10770: IntegrityError when creating multiple inline objects with ForeignKey and unique_together

[Django]

#10770: IntegrityError when creating multiple inline objects with ForeignKey and
unique_together
---+
  Reporter:  rutt  | Owner:  nobody
Status:  new   | Milestone:  1.1   
 Component:  django.contrib.admin  |   Version:  1.1-beta-1
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by rutt):

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

Comment:

 See also #10769

-- 
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] #10769: IntegrityError with generic relations, unique_together, and inline admin forms

[Django]

#10769: IntegrityError with generic relations, unique_together, and inline admin
forms
---+
  Reporter:  rutt  | Owner:  nobody
Status:  new   | Milestone:  1.1   
 Component:  django.contrib.admin  |   Version:  1.1-beta-1
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by rutt):

 See also #10770

-- 
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] #8356: The documentation for mod_python should state the permissions or ownership settings of the project files

[Django]

#8356: The documentation for mod_python should state the permissions or 
ownership
settings of the project files
+---
  Reporter:  anonymous  | Owner:  jacob 

Status:  closed | Milestone:  1.1   

 Component:  Documentation  |   Version:  0.96  

Resolution:  fixed  |  Keywords:  apache, mod_python, 
ownership, permissions, django
 Stage:  Accepted   | Has_patch:  0 

Needs_docs:  0  |   Needs_tests:  0 

Needs_better_patch:  0  |  
+---
Changes (by jacob):

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

Comment:

 This has been fixed for a bit; the docs now read:

   Make sure that your Python source files' permissions are set such that
 the Apache user (usually named apache or httpd on most systems) will have
 read access to the files.

 (http://docs.djangoproject.com/en/dev/howto/deployment/modpython/#basic-
 configuration)

-- 
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] r10459 - in django/branches/releases/1.0.X: . django/views/generic tests/regressiontests/views tests/regressiontests/views/tests/generic tests/templates/views

[noreply]

Author: jacob
Date: 2009-04-09 10:28:41 -0500 (Thu, 09 Apr 2009)
New Revision: 10459

Added:
   django/branches/releases/1.0.X/tests/templates/views/article_archive_day.html
Modified:
   django/branches/releases/1.0.X/AUTHORS
   django/branches/releases/1.0.X/django/views/generic/date_based.py
   
django/branches/releases/1.0.X/tests/regressiontests/views/tests/generic/date_based.py
   django/branches/releases/1.0.X/tests/regressiontests/views/urls.py
Log:
[1.0.X] Fixed #7944: date-based generic views no longer get confused with a 
numeric month format. Thanks to Justin Lilly and Alex Gaynor. Backport of 
r10457 and r10458 from trunk.

Modified: django/branches/releases/1.0.X/AUTHORS
===
--- django/branches/releases/1.0.X/AUTHORS  2009-04-09 15:26:15 UTC (rev 
10458)
+++ django/branches/releases/1.0.X/AUTHORS  2009-04-09 15:28:41 UTC (rev 
10459)
@@ -253,6 +253,7 @@
 Christopher Lenz 
 lero...@gmail.com
 Piotr Lewandowski 
+Justin Lilly 
 Waylan Limberg 
 limodou
 Philip Lindborg 

Modified: django/branches/releases/1.0.X/django/views/generic/date_based.py
===
--- django/branches/releases/1.0.X/django/views/generic/date_based.py   
2009-04-09 15:26:15 UTC (rev 10458)
+++ django/branches/releases/1.0.X/django/views/generic/date_based.py   
2009-04-09 15:28:41 UTC (rev 10459)
@@ -116,7 +116,8 @@
 """
 if extra_context is None: extra_context = {}
 try:
-date = datetime.date(*time.strptime(year+month, '%Y'+month_format)[:3])
+tt = time.strptime("%s-%s" % (year, month), '%s-%s' % ('%Y', 
month_format))
+date = datetime.date(*tt[:3])
 except ValueError:
 raise Http404
 
@@ -181,7 +182,8 @@
 """
 if extra_context is None: extra_context = {}
 try:
-date = datetime.date(*time.strptime(year+'-0-'+week, '%Y-%w-%U')[:3])
+tt = time.strptime(year+'-0-'+week, '%Y-%w-%U')
+date = datetime.date(*tt[:3])
 except ValueError:
 raise Http404
 
@@ -237,7 +239,9 @@
 """
 if extra_context is None: extra_context = {}
 try:
-date = datetime.date(*time.strptime(year+month+day, 
'%Y'+month_format+day_format)[:3])
+tt = time.strptime('%s-%s-%s' % (year, month, day), 
+   '%s-%s-%s' % ('%Y', month_format, day_format))
+date = datetime.date(*tt[:3])
 except ValueError:
 raise Http404
 
@@ -307,7 +311,9 @@
 """
 if extra_context is None: extra_context = {}
 try:
-date = datetime.date(*time.strptime(year+month+day, 
'%Y'+month_format+day_format)[:3])
+tt = time.strptime('%s-%s-%s' % (year, month, day), 
+   '%s-%s-%s' % ('%Y', month_format, day_format))
+date = datetime.date(*tt[:3])
 except ValueError:
 raise Http404
 

Modified: 
django/branches/releases/1.0.X/tests/regressiontests/views/tests/generic/date_based.py
===
--- 
django/branches/releases/1.0.X/tests/regressiontests/views/tests/generic/date_based.py
  2009-04-09 15:26:15 UTC (rev 10458)
+++ 
django/branches/releases/1.0.X/tests/regressiontests/views/tests/generic/date_based.py
  2009-04-09 15:28:41 UTC (rev 10459)
@@ -90,3 +90,14 @@
 response = 
self.client.get('/views/date_based/datefield/archive_month/2004/02/')
 self.assertEqual(response.status_code, 404)
 
+class DayArchiveTests(TestCase):
+
+def test_year_month_day_format(self):
+"""
+Make sure day views don't get confused with numeric month formats 
(#7944)
+"""
+author = Author.objects.create(name="John Smith")
+article = Article.objects.create(title="example", author=author, 
date_created=datetime(2004, 1, 21, 0, 0, 1))
+response = self.client.get('/views/date_based/archive_day/2004/1/21/')
+self.assertEqual(response.status_code, 200)
+self.assertEqual(response.context['object_list'][0], article)
\ No newline at end of file

Modified: django/branches/releases/1.0.X/tests/regressiontests/views/urls.py
===
--- django/branches/releases/1.0.X/tests/regressiontests/views/urls.py  
2009-04-09 15:26:15 UTC (rev 10458)
+++ django/branches/releases/1.0.X/tests/regressiontests/views/urls.py  
2009-04-09 15:28:41 UTC (rev 10459)
@@ -20,6 +20,8 @@
 'date_field': 'date_created',
 'month_format': '%m',
 }
+numeric_days_info_dict = dict(date_based_info_dict, day_format='%d')
+
 date_based_datefield_info_dict = dict(date_based_info_dict, 
queryset=DateArticle.objects.all())
 
 urlpatterns = patterns('',
@@ -46,6 +48,9 @@
 

[Django] #10770: IntegrityError when creating multiple inline objects with ForeignKey and unique_together

[Django]

#10770: IntegrityError when creating multiple inline objects with ForeignKey and
unique_together
--+-
 Reporter:  rutt  |   Owner:  nobody
   Status:  new   |   Milestone:  1.1   
Component:  django.contrib.admin  | Version:  1.1-beta-1
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 Using the models below, enter two Attachment objects with the same slug on
 the Parent change page, and then save.  The result is an IntegrityError
 where "columns parent_id, slug are not unique".  If the two Attachment
 objects are created and saved individually, the admin shows the expected
 form error: "Attachment with this Parent and Slug already exists."

 Models:

 {{{
 class Parent(models.Model):
 name = models.CharField(max_length=200)

 class Attachment(models.Model):
 name = models.CharField(max_length=200)
 parent = models.ForeignKey(Parent)
 slug = models.SlugField()

 class Meta:
 unique_together = ['parent', 'slug']
 }}}

 Admin:

 {{{
 class ParentAdmin(admin.ModelAdmin):
 inlines = [AttachmentInline]

 admin.site.register(Attachment, admin.ModelAdmin)
 admin.site.register(Parent, ParentAdmin)
 }}}

-- 
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] r10458 - django/trunk/tests/templates/views

[noreply]

Author: jacob
Date: 2009-04-09 10:26:15 -0500 (Thu, 09 Apr 2009)
New Revision: 10458

Added:
   django/trunk/tests/templates/views/article_archive_day.html
Log:
Added missing file from [10457].

Added: django/trunk/tests/templates/views/article_archive_day.html
===
--- django/trunk/tests/templates/views/article_archive_day.html 
(rev 0)
+++ django/trunk/tests/templates/views/article_archive_day.html 2009-04-09 
15:26:15 UTC (rev 10458)
@@ -0,0 +1 @@
+This template intentionally left blank


--~--~-~--~~~---~--~~
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] r10457 - in django/trunk: . django/views/generic tests/regressiontests/views tests/regressiontests/views/tests/generic

[noreply]

Author: jacob
Date: 2009-04-09 10:23:56 -0500 (Thu, 09 Apr 2009)
New Revision: 10457

Modified:
   django/trunk/AUTHORS
   django/trunk/django/views/generic/date_based.py
   django/trunk/tests/regressiontests/views/tests/generic/date_based.py
   django/trunk/tests/regressiontests/views/urls.py
Log:
Fixed #7944: date-based generic views no longer get confused with a numeric 
month format. Thanks to Justin Lilly and Alex Gaynor.

Modified: django/trunk/AUTHORS
===
--- django/trunk/AUTHORS2009-04-09 15:09:35 UTC (rev 10456)
+++ django/trunk/AUTHORS2009-04-09 15:23:56 UTC (rev 10457)
@@ -263,6 +263,7 @@
 Christopher Lenz 
 lero...@gmail.com
 Piotr Lewandowski 
+Justin Lilly 
 Waylan Limberg 
 limodou
 Philip Lindborg 

Modified: django/trunk/django/views/generic/date_based.py
===
--- django/trunk/django/views/generic/date_based.py 2009-04-09 15:09:35 UTC 
(rev 10456)
+++ django/trunk/django/views/generic/date_based.py 2009-04-09 15:23:56 UTC 
(rev 10457)
@@ -116,7 +116,8 @@
 """
 if extra_context is None: extra_context = {}
 try:
-date = datetime.date(*time.strptime(year+month, '%Y'+month_format)[:3])
+tt = time.strptime("%s-%s" % (year, month), '%s-%s' % ('%Y', 
month_format))
+date = datetime.date(*tt[:3])
 except ValueError:
 raise Http404
 
@@ -181,7 +182,8 @@
 """
 if extra_context is None: extra_context = {}
 try:
-date = datetime.date(*time.strptime(year+'-0-'+week, '%Y-%w-%U')[:3])
+tt = time.strptime(year+'-0-'+week, '%Y-%w-%U')
+date = datetime.date(*tt[:3])
 except ValueError:
 raise Http404
 
@@ -237,7 +239,9 @@
 """
 if extra_context is None: extra_context = {}
 try:
-date = datetime.date(*time.strptime(year+month+day, 
'%Y'+month_format+day_format)[:3])
+tt = time.strptime('%s-%s-%s' % (year, month, day), 
+   '%s-%s-%s' % ('%Y', month_format, day_format))
+date = datetime.date(*tt[:3])
 except ValueError:
 raise Http404
 
@@ -307,7 +311,9 @@
 """
 if extra_context is None: extra_context = {}
 try:
-date = datetime.date(*time.strptime(year+month+day, 
'%Y'+month_format+day_format)[:3])
+tt = time.strptime('%s-%s-%s' % (year, month, day), 
+   '%s-%s-%s' % ('%Y', month_format, day_format))
+date = datetime.date(*tt[:3])
 except ValueError:
 raise Http404
 

Modified: django/trunk/tests/regressiontests/views/tests/generic/date_based.py
===
--- django/trunk/tests/regressiontests/views/tests/generic/date_based.py
2009-04-09 15:09:35 UTC (rev 10456)
+++ django/trunk/tests/regressiontests/views/tests/generic/date_based.py
2009-04-09 15:23:56 UTC (rev 10457)
@@ -90,3 +90,14 @@
 response = 
self.client.get('/views/date_based/datefield/archive_month/2004/02/')
 self.assertEqual(response.status_code, 404)
 
+class DayArchiveTests(TestCase):
+
+def test_year_month_day_format(self):
+"""
+Make sure day views don't get confused with numeric month formats 
(#7944)
+"""
+author = Author.objects.create(name="John Smith")
+article = Article.objects.create(title="example", author=author, 
date_created=datetime(2004, 1, 21, 0, 0, 1))
+response = self.client.get('/views/date_based/archive_day/2004/1/21/')
+self.assertEqual(response.status_code, 200)
+self.assertEqual(response.context['object_list'][0], article)
\ No newline at end of file

Modified: django/trunk/tests/regressiontests/views/urls.py
===
--- django/trunk/tests/regressiontests/views/urls.py2009-04-09 15:09:35 UTC 
(rev 10456)
+++ django/trunk/tests/regressiontests/views/urls.py2009-04-09 15:23:56 UTC 
(rev 10457)
@@ -20,6 +20,8 @@
 'date_field': 'date_created',
 'month_format': '%m',
 }
+numeric_days_info_dict = dict(date_based_info_dict, day_format='%d')
+
 date_based_datefield_info_dict = dict(date_based_info_dict, 
queryset=DateArticle.objects.all())
 
 urlpatterns = patterns('',
@@ -46,6 +48,9 @@
 
(r'^date_based/object_detail/(?P\d{4})/(?P\d{1,2})/(?P\d{1,2})/(?P[-\w]+)/allow_future/$',
 'object_detail',
 dict(allow_future=True, slug_field='slug', **date_based_info_dict)),
+
(r'^date_based/archive_day/(?P\d{4})/(?P\d{1,2})/(?P\d{1,2})/$',
+'archive_day',
+numeric_days_info_dict),
 (r'^date_based/archive_month/(?P\d{4})/(?P\d{1,2})/$',
 'archive_month',
 date_based_info_dict),

Re: [Django] #10571: FakePayload Truncates Unicode Content

[Django]

#10571: FakePayload Truncates Unicode Content
---+
  Reporter:  rwag...@physics.ucsd.edu  | Owner:  nobody
Status:  reopened  | Milestone:  1.1   
 Component:  Testing framework |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by russellm):

 Rick - thanks so much for taking the trouble to work out such a complete
 set of demonstration cases.

 I'm going to qualify my comments with the following: I would not, on my
 best day, call Unicode handling one of my strengths. It's entirely
 possible I've got everything bass-ackwards here. I'll be the first to
 defer to anyone with superior knowledge in this case.

 That said, there appears to be several problems at play here.

  1. Firstly, FakePayload itself. FakePayload isn't really intended to be
 an externally visible container - it's an internal facility for storing
 file content so it can be passed to the WSGI input handler. This handler
 expects a byte stream, so it isn't really appropriate to be putting
 unencoded unicode data into the FakePayload. Instead, what you should be
 putting into the FakePayload is an encoded byte string; what you get back
 will be a similarly encoded string. Internally, the file handler uses the
 FakePayload to compose a wsgi input stream; unicode content isn't
 appropriate in this context. As a result, your payload tests should look
 more like:
 {{{
 def test_fakepayload(self):
 json = u'{"japanese": "\u5ce0 (\u3068\u3046\u3052 t\u014dge)"}'
 payload = FakePayload(json.encode('utf-8'))
 self.assertEqual(payload.read().decode('utf-8'), json)
 }}}
   I've used utf-8 here, but the actual encoding shouldn't matter (as long
 as it is symmetrical between encode and decode) - the point is that you
 need to explicitly encode from unicode to a byte string. On my machine,
 which uses a default charset of ascii, I don't need to make this
 modification to the simple_fakepayload test - I suspect that your default
 charset of utf-16 will mean that you will need to make the same change on
 both tests.

  2. However, that said, Django's test client should be doing this encoding
 for you when you provided unicode data as file content. This means that
 the post() method of the test client (django/test/client.py, line 285),
 which currently starts:
 {{{
 if content_type is MULTIPART_CONTENT:
 post_data = encode_multipart(BOUNDARY, data)
 else:
 post_data = data
 }}}
   should, in fact, read:
 {{{
 if content_type is MULTIPART_CONTENT:
 post_data = encode_multipart(BOUNDARY, data)
 else:
 post_data = data.encode('utf-8')
 }}}
   This encoding would match the Content-Type header that is transmitted
 with the POST; ideally, we should be checking for a user-provided Content-
 Type header so we can encode to a different charset if required.

  3. response.content holds the raw encoded byte stream from the response.
 If you want to compare against an original unicode input, you will need to
 encode that byte stream to the same encoding. This means your final
 assertion in the test_unicode_payload test should read
 {{{
 self.assertEqual(response.content.decode('utf-8'), json)
 }}}
   In this case, it needs to be utf-8, because that's the content type that
 is being returned in the response (again, this is the default Content-Type
 header on HTTP responses).

 You are correct that using StringIO rather than cStringIO makes problem
 (1) go away, but as far as I can make out, that is just hiding the deeper
 problems (2) and (3).

 So - to confirm whether or not I understand anything about unicode... if
 you do the following:
  1. Add the .encode() and .decode() calls to the FakePayload tests.
  2. Add the .encode('utf-8') to the post() method on the test client.
  3. Add the .decode('utf-8') to the response.content check in the payload
 tests.

 I believe that all your tests should pass. Can you confirm that this is
 the case? Or do I need to go back to the books and read up on unicode some
 more?

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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, 

Re: [Django] #10769: IntegrityError with generic relations, unique_together, and inline admin forms

[Django]

#10769: IntegrityError with generic relations, unique_together, and inline admin
forms
---+
  Reporter:  rutt  | Owner:  nobody
Status:  new   | Milestone:  1.1   
 Component:  django.contrib.admin  |   Version:  1.1-beta-1
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by rutt):

  * needs_better_patch:  => 0
  * component:  Uncategorized => django.contrib.admin
  * 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
-~--~~~~--~~--~--~---

[Django] #10769: IntegrityError with generic relations, unique_together, and inline admin forms

[Django]

#10769: IntegrityError with generic relations, unique_together, and inline admin
forms
---+
 Reporter:  rutt   |   Owner:  nobody
   Status:  new|   Milestone:  1.1   
Component:  Uncategorized  | Version:  1.1-beta-1
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 Using the models and admin below, create a new !GenericAttachment object
 using the inline form on the Parent change page.  Then create another one
 with the same slug.  The result is an IntegrityError where "columns
 content_type_id, object_id, slug are not unique".  This works fine for
 Attachment objects.

 Models:

 {{{
 class Parent(models.Model):
 name = models.CharField(max_length=200)

 class Attachment(models.Model):
 name = models.CharField(max_length=200)
 parent = models.ForeignKey(Parent)
 slug = models.SlugField()

 class Meta:
 unique_together = ['parent', 'slug']

 class GenericAttachment(models.Model):
 name = models.CharField(max_length=200)
 content_type = models.ForeignKey(ContentType)
 object_id = models.PositiveIntegerField()
 parent = generic.GenericForeignKey()
 slug = models.SlugField()

 class Meta:
 unique_together = ['content_type', 'object_id', 'slug']
 }}}

 Admin:

 {{{
 class GenericAttachmentInline(generic.GenericTabularInline):
 model = GenericAttachment

 class ParentAdmin(admin.ModelAdmin):
 inlines = [AttachmentInline, GenericAttachmentInline]

 admin.site.register(Attachment, admin.ModelAdmin)
 admin.site.register(GenericAttachment, admin.ModelAdmin)
 admin.site.register(Parent, ParentAdmin)
 }}}

-- 
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] #7048: Support clearing FileFields with ModelForms

[Django]

#7048: Support clearing FileFields with ModelForms
---+
  Reporter:  jarrow| Owner:  brosner
Status:  assigned  | Milestone:  1.1
 Component:  django.contrib.admin  |   Version:  SVN
Resolution:|  Keywords: 
 Stage:  Accepted  | Has_patch:  1  
Needs_docs:  0 |   Needs_tests:  1  
Needs_better_patch:  0 |  
---+
Comment (by jacob):

 It looks like this patch metastasized and grew some unrelated features --
 to wit, nothing about this ticket has anything to do with deleting files
 (?) and directories (!) as a side-effect of clearing a file field. That's
 a separate discussion that we haven't had yet, and we're certainly not
 sneaking in new behavior like that this late in the release cycle.

-- 
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] #10768: Allow for Admin Actions to be applied to an empty QuerySet

[Django]

#10768: Allow for Admin Actions to be applied to an empty QuerySet
--+-
  Reporter:  andreplebl...@gmail.com  | Owner:  nobody 
Status:  closed   | Milestone: 
 Component:  django.contrib.admin |   Version:  SVN
Resolution:  wontfix  |  Keywords:  actions
 Stage:  Unreviewed   | Has_patch:  0  
Needs_docs:  0|   Needs_tests:  0  
Needs_better_patch:  0|  
--+-
Changes (by Alex):

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

Comment:

 This is an intentional design decision.  Actions that don't act on
 specific items are a fundamentally different and representing them in the
 same UI is bad practice.  You can add links to the object-tools portion of
 the page to have non-item specific actions.

-- 
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] #10768: Allow for Admin Actions to be applied to an empty QuerySet

[Django]

#10768: Allow for Admin Actions to be applied to an empty QuerySet
-+--
 Reporter:  andreplebl...@gmail.com  |   Owner:  nobody
   Status:  new  |   Milestone:
Component:  django.contrib.admin | Version:  SVN   
 Keywords:  actions  |   Stage:  Unreviewed
Has_patch:  0|  
-+--
 Currently if you perform an Admin Action without selecting any rows on the
 change-list, the action's method doesn't get called at all.  I think there
 are many use cases for actions which do not require an explicit
 collection. for example if the items are pulled from some external source
 there could be an action for updating the data, or perhaps various options
 for exporting the entire list.  in this way, an action which gets an empty
 queryset can be applied to either "ALL" items (which currently isn't
 possible if the items span more than 1 page) or can apply some generic
 operation which doesn't pertain to a collection of items.  As far as I can
 tell this has no negative repercussions because any potentially
 destructive actions, like Delete, will simply attempt to perform their
 action on an empty queryset, which should do nothing at all.

 I haven't created a patch, but the solution is as simple as removing 2
 lines (688, 689) from admin/options.py

-- 
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] r10455 - in django/trunk: django/db/backends docs/ref/models tests/modeltests/unmanaged_models

[noreply]

Author: jacob
Date: 2009-04-09 10:03:31 -0500 (Thu, 09 Apr 2009)
New Revision: 10455

Added:
   django/trunk/tests/modeltests/unmanaged_models/tests.py
Modified:
   django/trunk/django/db/backends/creation.py
   django/trunk/docs/ref/models/options.txt
   django/trunk/tests/modeltests/unmanaged_models/models.py
Log:
Fixed #10647: intermediary tables between two umanaged models are no longer 
created.

Modified: django/trunk/django/db/backends/creation.py
===
--- django/trunk/django/db/backends/creation.py 2009-04-08 20:25:56 UTC (rev 
10454)
+++ django/trunk/django/db/backends/creation.py 2009-04-09 15:03:31 UTC (rev 
10455)
@@ -140,7 +140,8 @@
 "Return the CREATE TABLE statments for all the many-to-many tables 
defined on a model"
 output = []
 for f in model._meta.local_many_to_many:
-output.extend(self.sql_for_many_to_many_field(model, f, style))
+if model._meta.managed or f.rel.to._meta.managed:
+output.extend(self.sql_for_many_to_many_field(model, f, style))
 return output
 
 def sql_for_many_to_many_field(self, model, f, style):

Modified: django/trunk/docs/ref/models/options.txt
===
--- django/trunk/docs/ref/models/options.txt2009-04-08 20:25:56 UTC (rev 
10454)
+++ django/trunk/docs/ref/models/options.txt2009-04-09 15:03:31 UTC (rev 
10455)
@@ -98,11 +98,16 @@
specify all the columns from the database table you are modeling when
using unmanaged models.
 
-2. If a model contains a :class:`~django.db.models.ManyToManyField` and
-   has ``managed=False``, the intermediate table for the many-to-many join
-   will also not be created. Should you require the intermediate table to
-   be created, set it up as an explicit model and use the
-   :attr:`ManyToManyField.through` attribute.
+2. If a model with ``managed=False`` contains a
+   :class:`~django.db.models.ManyToManyField` that points to another
+   unmanaged model, then the intermediate table for the many-to-many join
+   will also not be created. However, a the intermediary table between one
+   managed and one unmanaged model *will* be created.
+   
+   If you need to change this default behavior, create the intermediary
+   table as an explicit model (with ``managed`` set as needed) and use the
+   :attr:`ManyToManyField.through` attribute to make the relation use your
+   custom model.
 
 For tests involving models with ``managed=False``, it's up to you to ensure
 the correct tables are created as part of the test setup.

Modified: django/trunk/tests/modeltests/unmanaged_models/models.py
===
--- django/trunk/tests/modeltests/unmanaged_models/models.py2009-04-08 
20:25:56 UTC (rev 10454)
+++ django/trunk/tests/modeltests/unmanaged_models/models.py2009-04-09 
15:03:31 UTC (rev 10455)
@@ -89,6 +89,27 @@
 db_table = 'D01'
 managed = False
 
+#
+# These next models test the creation (or not) of many to many join tables
+# between managed and unmanaged models. A join table between two unmanaged 
+# models shouldn't be automatically created (see #10647). 
+#
+class Unmanaged1(models.Model):
+class Meta:
+managed = False
+
+# Unmanged with an m2m to unmanaged: the intermediary table won't be created.
+class Unmanaged2(models.Model):
+mm = models.ManyToManyField(Unmanaged1)
+
+class Meta:
+managed = False
+
+# Here's an unmanaged model with an m2m to a managed one; the intermediary
+# table *will* be created (unless given a custom `through` as for C02 above).
+class Managed1(models.Model):
+mm = models.ManyToManyField(Unmanaged1)
+
 __test__ = {'API_TESTS':"""
 The main test here is that the all the models can be created without any
 database errors. We can also do some more simple insertion and lookup tests

Added: django/trunk/tests/modeltests/unmanaged_models/tests.py
===
--- django/trunk/tests/modeltests/unmanaged_models/tests.py 
(rev 0)
+++ django/trunk/tests/modeltests/unmanaged_models/tests.py 2009-04-09 
15:03:31 UTC (rev 10455)
@@ -0,0 +1,22 @@
+from django.test import TestCase
+from django.db import connection
+from models import Unmanaged1, Unmanaged2, Managed1
+
+class ManyToManyUnmanagedTests(TestCase):
+
+def test_many_to_many_between_unmanaged(self):
+"""
+The intermediary table between two unmanaged models should not be 
created.
+"""
+table = Unmanaged2._meta.get_field('mm').m2m_db_table()
+tables = connection.introspection.table_names()
+self.assert_(table not in tables, "Table '%s' should not exist, but it 
does." % table)
+
+def 

Re: [Django] #10767: SQL flush statements are generated for through many to many tables set managed = False

[Django]

#10767: SQL flush statements are generated for through many to many tables set
managed = False
---+
  Reporter:  trevor| Owner:  nobody
Status:  closed| Milestone:
 Component:  Database layer (models, ORM)  |   Version:  1.0   
Resolution:  duplicate |  Keywords:
 Stage:  Unreviewed| Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by jacob):

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

Comment:

 Duplicate of #10647

-- 
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] #7140: Errors in escaping fieldnames in Oracle

[Django]

#7140: Errors in escaping fieldnames in Oracle
---+
  Reporter:  her...@snt.utwente.nl | Owner:  mboersma   
   
Status:  assigned  | Milestone: 
   
 Component:  Database layer (models, ORM)  |   Version:  SVN
   
Resolution:|  Keywords:  
qsrf-cleanup oracle, quote, escape
 Stage:  Accepted  | Has_patch:  1  
   
Needs_docs:  0 |   Needs_tests:  1  
   
Needs_better_patch:  0 |  
---+
Comment (by aprilmay):

 The proposed patch works fine here (with a legacy database, using
 db_table). Since it does not break anything and #6148 is still pending, is
 there any chance to have this patch for 1.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 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] #10767: SQL flush statements are generated for through many to many tables set managed = False

[Django]

#10767: SQL flush statements are generated for through many to many tables set
managed = False
--+-
 Reporter:  trevor|   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Database layer (models, ORM)  | Version:  1.0   
 Keywords:|   Stage:  Unreviewed
Has_patch:  1 |  
--+-
 SQL flush statements (those output by `./manage.py sqlflush`) correctly do
 not include statements truncating django models marked as `managed =
 False`, except for those which are used as the through model for many to
 many relations (`ManyToManyField(through=...)`).

 I have attached a patch which fixes the issue by excluding through models
 marked `managed = False` when creating the list of tables and sequences to
 flush.

-- 
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] #9308: Django fails to set nullable foreign key field to NULL before deleting the referenced record

[Django]

#9308: Django fails to set nullable foreign key field to NULL before deleting 
the
referenced record
---+
  Reporter:  egenix_viktor | Owner:  nobody 
   
Status:  new   | Milestone:  1.1
   
 Component:  Database layer (models, ORM)  |   Version:  1.0
   
Resolution:|  Keywords:  delete 
record foreign key constraint check NULL nullable field
 Stage:  Accepted  | Has_patch:  1  
   
Needs_docs:  0 |   Needs_tests:  0  
   
Needs_better_patch:  0 |  
---+
Changes (by guettli):

 * cc: h...@tbz-pariv.de (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
-~--~~~~--~~--~--~---