Re: [Django] #14497: ModelAdmin.readonly_fields isn't graceful with filefields.

[Django]

#14497: ModelAdmin.readonly_fields isn't graceful with filefields.
-+-
 Reporter:  Keryn Knight |Owner:
    |  paulcollins
 Type:  New feature  |   Status:  new
Component:  contrib.admin|  Version:  1.2
 Severity:  Normal   |   Resolution:
 Keywords:  feature admin| Triage Stage:  Accepted
  readonly filefield |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  1
Easy pickings:  0|
-+-

Comment (by paulcollins):

 Updated because julien was getting a unit test failure on his osx machine.
 Is there a bug with assertContains(html=True)?
 If this passes on his machine then there might be an issue in there. More
 when I hear back from julien.

-- 
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] #17837: Markdown filter "safe" mode is vulnerable to e.g. 'onclick' attributes

[Django]

#17837: Markdown filter "safe" mode is vulnerable to e.g. 'onclick' attributes
-+-
 Reporter:  nomulous |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.markup   |  Version:  SVN
 Severity:  Release blocker  |   Resolution:
 Keywords:  javascript,  | Triage Stage:  Accepted
  injection, xss, markdown   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by Fandekasp):

 * cc: lemaire.adrien@… (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] #17837: Markdown filter "safe" mode is vulnerable to e.g. 'onclick' attributes

[Django]

#17837: Markdown filter "safe" mode is vulnerable to e.g. 'onclick' attributes
-+-
 Reporter:  nomulous |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.markup   |  Version:  SVN
 Severity:  Release blocker  |   Resolution:
 Keywords:  javascript,  | Triage Stage:  Accepted
  injection, xss, markdown   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by Fandekasp):

 At least the Django doc warns the users about that in
 https://docs.djangoproject.com/en/dev/ref/contrib/markup/:

 Warning
 The output of markup filters is marked “safe” and will not be escaped when
 rendered in a template. Always be careful to sanitize your inputs and make
 sure you are not leaving yourself vulnerable to cross-site scripting or
 other types of attacks.

 We could complete this doc by referring some 3rd-part apps such as bleach
 maybe ?
 This shouldn't be a release blocker anymore.

-- 
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] #14051: Signals for transaction commit/rollback

[Django]

#14051: Signals for transaction commit/rollback
-+-
 Reporter:  Ask Solem |Owner:  nobody
 Type:  New feature  |   Status:  reopened
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Design
 Keywords:   |  decision needed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by danny.adair@…):

 Sorry scratch that previous comment of mine - the existing handlers would
 just need to be wrapped in a defer() like Dave Hughes is doing:
 https://github.com/davehughes/django-transaction-signals

-- 
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] #12753: Fixture loading can fails on second syncdb when auto_now_add field is ommitted

[Django]

#12753: Fixture loading can fails on second syncdb when auto_now_add field is
ommitted
-+-
 Reporter:  russellm |Owner:  kmtracey
 Type:  Bug  |   Status:  closed
Component:  Core |  Version:
  (Serialization)|  1.4-beta-1
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by vsafronovich):

 Оk, so I need to explicitly set date to some fixed time.
 What will I do with tests, that tested some objects was created near `now`
 time and change behavior for this objects?

 I think more you should deprecate using of `auto_now` and `auto_now_add`
 in `DateTimeField` constructor. And simply add link to wiki, where was
 described how to set datetime field in `save` method of the model object.

-- 
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] #17864: Add localflavor for Hong Kong, starting with a phone number field

[Django]

#17864: Add localflavor for Hong Kong, starting with a phone number field
-+-
 Reporter:  mrkschan@…   |Owner:  mrkschan
 Type:  New feature  |   Status:  assigned
Component:  contrib.localflavor  |  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:  localflavor hk   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  1|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by Fandekasp):

 Done, glad to be of help.

 I also modified the invalid error message to inform about all acceptable
 inputs.

-- 
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] #6585: admin foreignkey dropdown does not adhere to model's admin ordering

[Django]

#6585: admin foreignkey dropdown does not adhere to model's admin ordering
---+--
 Reporter:  gwilson|Owner:  thauber
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  newforms-admin
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  1
  Needs tests:  1  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by thauber):

 * status:  reopened => new
 * owner:  nobody => thauber


-- 
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] #17877: query.extra(where=...) lack parenthesis

[Django]

#17877: query.extra(where=...) lack parenthesis
-+-
 Reporter:  Marek Brzóska|Owner:  Fandekasp
     |   Status:  new
 Type:  Bug  |  Version:  1.3
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  1|
-+-
Changes (by Fandekasp):

 * needs_tests:  1 => 0


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

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

Re: [Django] #10498: Passing ugettext_lazy to related object's create() doesn't work

[Django]

#10498: Passing ugettext_lazy to related object's create() doesn't work
-+-
 Reporter:  mtredinnick  |Owner:  ojii
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:  fixed
 Severity:  Release blocker  | Triage Stage:  Design
 Keywords:  dceu2011 |  decision needed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by jezdez):

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


Comment:

 In [17698]:
 {{{
 #!CommitTicketReference repository="" revision="17698"
 Fixed #10498 (again) -- Made sure the improvements done in r17641 have a
 smaller impact on speed. Thanks to Anssi Kääriäinen for the patch and
 Jonas Obrist for reviewing.
 }}}

-- 
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] r17698 - in django/trunk: django/db/models django/db/models/sql tests/modeltests/basic

[noreply]

Author: jezdez
Date: 2012-03-12 20:48:20 -0700 (Mon, 12 Mar 2012)
New Revision: 17698

Modified:
   django/trunk/django/db/models/base.py
   django/trunk/django/db/models/sql/subqueries.py
   django/trunk/tests/modeltests/basic/tests.py
Log:
Fixed #10498 (again) -- Made sure the improvements done in r17641 have a 
smaller impact on speed. Thanks to Anssi K?\195?\164?\195?\164ri?\195?\164inen 
for the patch and Jonas Obrist for reviewing.

Modified: django/trunk/django/db/models/base.py
===
--- django/trunk/django/db/models/base.py   2012-03-13 03:48:11 UTC (rev 
17697)
+++ django/trunk/django/db/models/base.py   2012-03-13 03:48:20 UTC (rev 
17698)
@@ -20,7 +20,7 @@
 from django.db.models import signals
 from django.db.models.loading import register_models, get_model
 from django.utils.translation import ugettext_lazy as _
-from django.utils.functional import curry, Promise
+from django.utils.functional import curry
 from django.utils.encoding import smart_str, force_unicode
 from django.utils.text import get_text_list, capfirst
 
@@ -297,14 +297,10 @@
 # is *not* consumed. We rely on this, so don't change the order
 # without changing the logic.
 for val, field in izip(args, fields_iter):
-if isinstance(val, Promise):
-val = force_unicode(val)
 setattr(self, field.attname, val)
 else:
 # Slower, kwargs-ready version.
 for val, field in izip(args, fields_iter):
-if isinstance(val, Promise):
-val = force_unicode(val)
 setattr(self, field.attname, val)
 kwargs.pop(field.name, None)
 # Maintain compatibility with existing calls.
@@ -358,8 +354,6 @@
 # checked) by the RelatedObjectDescriptor.
 setattr(self, field.name, rel_obj)
 else:
-if isinstance(val, Promise):
-val = force_unicode(val)
 setattr(self, field.attname, val)
 
 if kwargs:

Modified: django/trunk/django/db/models/sql/subqueries.py
===
--- django/trunk/django/db/models/sql/subqueries.py 2012-03-13 03:48:11 UTC 
(rev 17697)
+++ django/trunk/django/db/models/sql/subqueries.py 2012-03-13 03:48:20 UTC 
(rev 17698)
@@ -8,6 +8,8 @@
 from django.db.models.sql.datastructures import Date
 from django.db.models.sql.query import Query
 from django.db.models.sql.where import AND, Constraint
+from django.utils.functional import Promise
+from django.utils.encoding import force_unicode
 
 
 __all__ = ['DeleteQuery', 'UpdateQuery', 'InsertQuery', 'DateQuery',
@@ -38,7 +40,7 @@
 for offset in range(0, len(pk_list), GET_ITERATOR_CHUNK_SIZE):
 where = self.where_class()
 where.add((Constraint(None, field.column, field), 'in',
-pk_list[offset : offset + GET_ITERATOR_CHUNK_SIZE]), AND)
+pk_list[offset:offset + GET_ITERATOR_CHUNK_SIZE]), AND)
 self.do_query(self.model._meta.db_table, where, using=using)
 
 class UpdateQuery(Query):
@@ -67,14 +69,13 @@
 return super(UpdateQuery, self).clone(klass,
 related_updates=self.related_updates.copy(), **kwargs)
 
-
 def update_batch(self, pk_list, values, using):
 pk_field = self.model._meta.pk
 self.add_update_values(values)
 for offset in range(0, len(pk_list), GET_ITERATOR_CHUNK_SIZE):
 self.where = self.where_class()
 self.where.add((Constraint(None, pk_field.column, pk_field), 'in',
-pk_list[offset : offset + GET_ITERATOR_CHUNK_SIZE]),
+pk_list[offset:offset + GET_ITERATOR_CHUNK_SIZE]),
 AND)
 self.get_compiler(using).execute_sql(None)
 
@@ -101,6 +102,10 @@
 Used by add_update_values() as well as the "fast" update path when
 saving models.
 """
+# Check that no Promise object passes to the query. Refs #10498.
+values_seq = [(value[0], value[1], force_unicode(value[2]))
+  if isinstance(value[2], Promise) else value
+  for value in values_seq]
 self.values.extend(values_seq)
 
 def add_related_update(self, model, field, value):
@@ -159,6 +164,12 @@
 into the query, for example.
 """
 self.fields = fields
+# Check that no Promise object reaches the DB. Refs #10498.
+for field in fields:
+for obj in objs:
+value = getattr(obj, field.attname)
+if isinstance(value, Promise):
+setattr(obj, field.attname, force_unicode(value))
 self.objs = objs
 self.raw = raw
 

Modified: django/trunk/tests/modeltests/basic/tests.py

Re: [Django] #17857: CachedFilesMixin url_converter creates unnecessarily absolute urls

[Django]

#17857: CachedFilesMixin url_converter creates unnecessarily absolute urls
-+-
 Reporter:  tgecho   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.staticfiles  |  Version:  SVN
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:
Has patch:  1|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by jezdez):

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


Comment:

 In [17697]:
 {{{
 #!CommitTicketReference repository="" revision="17697"
 Fixed #17857 -- Stopped CachedStaticFilesStorage from creating absolute
 URLs unnecessarily. Thanks, tgecho.
 }}}

-- 
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] r17697 - in django/trunk: django/contrib/staticfiles docs/ref/contrib tests/regressiontests/staticfiles_tests

[noreply]

Author: jezdez
Date: 2012-03-12 20:48:11 -0700 (Mon, 12 Mar 2012)
New Revision: 17697

Modified:
   django/trunk/django/contrib/staticfiles/storage.py
   django/trunk/docs/ref/contrib/staticfiles.txt
   django/trunk/tests/regressiontests/staticfiles_tests/tests.py
Log:
Fixed #17857 -- Stopped CachedStaticFilesStorage from creating absolute URLs 
unnecessarily. Thanks, tgecho.

Modified: django/trunk/django/contrib/staticfiles/storage.py
===
--- django/trunk/django/contrib/staticfiles/storage.py  2012-03-13 03:48:03 UTC 
(rev 17696)
+++ django/trunk/django/contrib/staticfiles/storage.py  2012-03-13 03:48:11 UTC 
(rev 17697)
@@ -165,9 +165,11 @@
 start, end = 1, sub_level - 1
 joined_result = '/'.join(name_parts[:-start] + url_parts[end:])
 hashed_url = self.url(unquote(joined_result), force=True)
+file_name = hashed_url.split('/')[-1:]
+relative_url = '/'.join(url.split('/')[:-1] + file_name)
 
-# Return the hashed and normalized version to the file
-return 'url("%s")' % unquote(hashed_url)
+# Return the hashed version to the file
+return 'url("%s")' % unquote(relative_url)
 return converter
 
 def post_process(self, paths, dry_run=False, **options):

Modified: django/trunk/docs/ref/contrib/staticfiles.txt
===
--- django/trunk/docs/ref/contrib/staticfiles.txt   2012-03-13 03:48:03 UTC 
(rev 17696)
+++ django/trunk/docs/ref/contrib/staticfiles.txt   2012-03-13 03:48:11 UTC 
(rev 17697)
@@ -327,7 +327,7 @@
 
 .. code-block:: css+django
 
-@import url("/static/admin/css/base.27e20196a850.css");
+@import url("../admin/css/base.27e20196a850.css");
 
 To enable the ``CachedStaticFilesStorage`` you have to make sure the
 following requirements are met:

Modified: django/trunk/tests/regressiontests/staticfiles_tests/tests.py
===
--- django/trunk/tests/regressiontests/staticfiles_tests/tests.py   
2012-03-13 03:48:03 UTC (rev 17696)
+++ django/trunk/tests/regressiontests/staticfiles_tests/tests.py   
2012-03-13 03:48:11 UTC (rev 17697)
@@ -385,7 +385,7 @@
 with storage.staticfiles_storage.open(relpath) as relfile:
 content = relfile.read()
 self.assertNotIn("cached/other.css", content)
-self.assertIn("/static/cached/other.d41d8cd98f00.css", content)
+self.assertIn("other.d41d8cd98f00.css", content)
 
 def test_path_with_querystring(self):
 relpath = self.cached_file_path("cached/styles.css?spam=eggs")
@@ -395,7 +395,7 @@
 "cached/styles.93b1147e8552.css") as relfile:
 content = relfile.read()
 self.assertNotIn("cached/other.css", content)
-self.assertIn("/static/cached/other.d41d8cd98f00.css", content)
+self.assertIn("other.d41d8cd98f00.css", content)
 
 def test_path_with_fragment(self):
 relpath = self.cached_file_path("cached/styles.css#eggs")
@@ -404,15 +404,15 @@
 "cached/styles.93b1147e8552.css") as relfile:
 content = relfile.read()
 self.assertNotIn("cached/other.css", content)
-self.assertIn("/static/cached/other.d41d8cd98f00.css", content)
+self.assertIn("other.d41d8cd98f00.css", content)
 
 def test_path_with_querystring_and_fragment(self):
 relpath = self.cached_file_path("cached/css/fragments.css")
 self.assertEqual(relpath, "cached/css/fragments.75433540b096.css")
 with storage.staticfiles_storage.open(relpath) as relfile:
 content = relfile.read()
-
self.assertIn('/static/cached/css/fonts/font.a4b0478549d0.eot?#iefix', content)
-
self.assertIn('/static/cached/css/fonts/font.b8d603e42714.svg#webfontIyfZbseF', 
content)
+self.assertIn('fonts/font.a4b0478549d0.eot?#iefix', content)
+self.assertIn('fonts/font.b8d603e42714.svg#webfontIyfZbseF', 
content)
 
self.assertIn('data:font/woff;charset=utf-8;base64,d09GRgABADJoAA0AR2QAAQA',
 content)
 self.assertIn('#default#VML', content)
 
@@ -431,21 +431,20 @@
 with storage.staticfiles_storage.open(relpath) as relfile:
 content = relfile.read()
 self.assertNotIn("..//cached///styles.css", content)
-self.assertIn("/static/cached/styles.93b1147e8552.css", content)
+self.assertIn("../cached/styles.93b1147e8552.css", content)
 self.assertNotIn("url(img/relative.png )", content)
-self.assertIn("/static/cached/img/relative.acae32e4532b.png", 
content)
+self.assertIn('url("img/relative.acae32e4532b.png', content)
 
 def test_template_tag_relative(self):
 relpath = 

[Changeset] r17696 - in django/trunk: django/contrib/staticfiles tests/regressiontests/staticfiles_tests tests/regressiontests/staticfiles_tests/project/documents/cached

[noreply]

Author: jezdez
Date: 2012-03-12 20:48:03 -0700 (Mon, 12 Mar 2012)
New Revision: 17696

Modified:
   django/trunk/django/contrib/staticfiles/storage.py
   
django/trunk/tests/regressiontests/staticfiles_tests/project/documents/cached/denorm.css
   django/trunk/tests/regressiontests/staticfiles_tests/tests.py
Log:
Fixed #17865 -- Strip whitespaces from the paths when using the 
CachedStaticFilesStorage backend.

Modified: django/trunk/django/contrib/staticfiles/storage.py
===
--- django/trunk/django/contrib/staticfiles/storage.py  2012-03-13 01:01:22 UTC 
(rev 17695)
+++ django/trunk/django/contrib/staticfiles/storage.py  2012-03-13 03:48:03 UTC 
(rev 17696)
@@ -67,7 +67,7 @@
 
 def hashed_name(self, name, content=None):
 parsed_name = urlsplit(unquote(name))
-clean_name = parsed_name.path
+clean_name = parsed_name.path.strip()
 if content is None:
 if not self.exists(clean_name):
 raise ValueError("The file '%s' could not be found with %r." %

Modified: 
django/trunk/tests/regressiontests/staticfiles_tests/project/documents/cached/denorm.css
===
--- 
django/trunk/tests/regressiontests/staticfiles_tests/project/documents/cached/denorm.css
2012-03-13 01:01:22 UTC (rev 17695)
+++ 
django/trunk/tests/regressiontests/staticfiles_tests/project/documents/cached/denorm.css
2012-03-13 03:48:03 UTC (rev 17696)
@@ -1 +1,4 @@
 @import url("..//cached///styles.css");
+body {
+background: #d3d6d8 url(img/relative.png );
+}

Modified: django/trunk/tests/regressiontests/staticfiles_tests/tests.py
===
--- django/trunk/tests/regressiontests/staticfiles_tests/tests.py   
2012-03-13 01:01:22 UTC (rev 17695)
+++ django/trunk/tests/regressiontests/staticfiles_tests/tests.py   
2012-03-13 03:48:03 UTC (rev 17696)
@@ -427,11 +427,13 @@
 
 def test_template_tag_denorm(self):
 relpath = self.cached_file_path("cached/denorm.css")
-self.assertEqual(relpath, "cached/denorm.363de96e9b4b.css")
+self.assertEqual(relpath, "cached/denorm.c5bd139ad821.css")
 with storage.staticfiles_storage.open(relpath) as relfile:
 content = relfile.read()
 self.assertNotIn("..//cached///styles.css", content)
 self.assertIn("/static/cached/styles.93b1147e8552.css", content)
+self.assertNotIn("url(img/relative.png )", content)
+self.assertIn("/static/cached/img/relative.acae32e4532b.png", 
content)
 
 def test_template_tag_relative(self):
 relpath = self.cached_file_path("cached/relative.css")

-- 
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] #17865: CachedStaticFilesStorage css rewriter should strip whitespaces from urls

[Django]

#17865: CachedStaticFilesStorage css rewriter should strip whitespaces from urls
-+-
 Reporter:  kmike|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.staticfiles  |  Version:
 Severity:  Normal   |  1.4-beta-1
 Keywords:   |   Resolution:  fixed
Has patch:  0| Triage Stage:  Accepted
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by jezdez):

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


Comment:

 In [17696]:
 {{{
 #!CommitTicketReference repository="" revision="17696"
 Fixed #17865 -- Strip whitespaces from the paths when using the
 CachedStaticFilesStorage backend.
 }}}

-- 
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] #17877: query.extra(where=...) lack parenthesis

[Django]

#17877: query.extra(where=...) lack parenthesis
-+-
 Reporter:  Marek Brzóska|Owner:  Fandekasp
     |   Status:  new
 Type:  Bug  |  Version:  1.3
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  1|
Easy pickings:  1|
-+-
Changes (by Fandekasp):

 * cc: lemaire.adrien@… (added)
 * has_patch:  0 => 1
 * needs_tests:  0 => 1


Comment:

 Easy fix, I just wrapped each element with parenthesis.
 Doc updated with eleather example.
 Just realize that it needs tests, will work on it now

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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] #17877: query.extra(where=...) lack parenthesis

[Django]

#17877: query.extra(where=...) lack parenthesis
-+-
 Reporter:  Marek Brzóska|Owner:  Fandekasp
     |   Status:  new
 Type:  Bug  |  Version:  1.3
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  1|
-+-

Comment (by Fandekasp):

 hmmm I can see 2 options:

  1. where becomes a string, and we force the user to write :
 {{{
 Thing.objects.extra(where="(foo='a' OR bar = 'a') AND baz = 'a'")
 }}}

  2. Add a bit of code that look for the string ' OR ' in each element of
 the where list, and wrap the element if the string is present:
 {{{
 Thing.objects.extra(where=["foo='a' OR bar = 'a'", "baz = 'a'")
 }}}
 will become:
 {{{
 Thing.objects.extra(where=["(foo='a' OR bar = 'a')", "baz = 'a'")
 }}}
 in ExtraWhere.as_sql() (sql/where.py)


 The first solution would be simplest, but backward-incompatible. I'll
 start working on the 2nd solution

-- 
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] #17864: Add localflavor for Hong Kong, starting with a phone number field

[Django]

#17864: Add localflavor for Hong Kong, starting with a phone number field
-+-
 Reporter:  mrkschan@…   |Owner:  mrkschan
 Type:  New feature  |   Status:  assigned
Component:  contrib.localflavor  |  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:  localflavor hk   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  1|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by mrkschan):

 Replying to [comment:8 Fandekasp]:

 Missed a valid testcase -


 {{{
 '8529111': '9111-',
 }}}

 Missed a invalid testcase -

 {{{
 '2111--': [error_msgs['invalid'], ]
 }}}

 i have prepared a set of comprehensive test cases - see
 http://is.gd/QE13Zs

-- 
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] #14051: Signals for transaction commit/rollback

[Django]

#14051: Signals for transaction commit/rollback
-+-
 Reporter:  Ask Solem |Owner:  nobody
 Type:  New feature  |   Status:  reopened
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Design
 Keywords:   |  decision needed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by danny.adair@…):

 How would you identify the sender(s), given that a transaction can contain
 changes to all kinds of models?

 I'm currently connecting to post_save for sender=!MyModel - when !MyModel
 is changed I want to reindex it in the background using celery.
 Unfortunately, celery tries to do that before the transaction is
 committed, and indexes the old data (finally I know what's been
 happening).

 I don't see how I could solve this if there was a simple post_commit
 signal - I need to identify the instance that was saved.
 All save()'s and delete()'s would have to collect their instances so that
 at the end post_commit can be emitted for each one, no?

 Regarding manual committing: I have lots of models with a FK and some with
 m2m to the model I want to index (so my signal handler first figures out
 which ones are affected, then spawns an indexation task each), and this
 needs to work in admin. Looks like 100 overrides of save() and delete()
 would be needed, and I better not miss any...

-- 
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] #17877: query.extra(where=...) lack parenthesis

[Django]

#17877: query.extra(where=...) lack parenthesis
-+-
 Reporter:  Marek Brzóska|Owner:  Fandekasp
     |   Status:  new
 Type:  Bug  |  Version:  1.3
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  1|
-+-
Changes (by Fandekasp):

 * owner:  nobody => Fandekasp


Comment:

 I'm looking at it. We should look at a better example for this '''where'''
 case, because it might incite people who read the doc fast to start using
 {{{Entry.objects.extra(where=['id IN (3, 4, 5, 20)'])}}}
 instead of {{{Entry.objects.filter(id__in=[3, 4, 5, 20])}}}

-- 
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] #17884: Distance lookups using ST_Distance_Sphere fails with PostGis 1.5.3

[Django]

#17884: Distance lookups using ST_Distance_Sphere fails with PostGis 1.5.3
-+--
 Reporter:  ogirardot@…  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  GIS  |  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by jezdez):

 * severity:  Release blocker => Normal


Comment:

 Removing the release blocker label, in that case.

-- 
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] #17700: Django formset documentation missing Class Based View Docs

[Django]

#17700: Django formset documentation missing Class Based View Docs
-+-
 Reporter:  rh0dium  |Owner:  Fandekasp
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.3
Component:  Documentation|   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by Fandekasp):

 * cc: lemaire.adrien@… (added)
 * has_patch:  0 => 1


Comment:

 Please review and test my example.

-- 
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] #17700: Django formset documentation missing Class Based View Docs

[Django]

#17700: Django formset documentation missing Class Based View Docs
-+-
 Reporter:  rh0dium  |Owner:  Fandekasp
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.3
Component:  Documentation|   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by Fandekasp):

 * owner:  nobody => Fandekasp


-- 
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] #3011: Allow for extendable auth_user module

[Django]

#3011: Allow for extendable auth_user module
---+
 Reporter:  nowell strite  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  contrib.auth   |  Version:
 Severity:  Normal |   Resolution:
 Keywords:  auth_user  | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  1
  Needs tests:  1  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+
Changes (by clay):

 * cc: clay (added)


Comment:

 Here's a fork of 1.4rc1 that allows for pluggable auth apps using the
 strategy some have already suggested in this ticket, namely, defining User
 at run-time to be either the default implementation or a user-provided
 implementation:

 https://github.com/claymation/django/compare/pluggable-auth-apps

 In addition to User, all of the companion models, forms, backends,
 decorators, and middleware classes that depend on User are similarly
 defined at run-time. The complete set of objects defined in this manner
 represents what I consider to be the public interface to the existing
 auth.User model:

 {{{
models:  User, UserManager, AnonymousUser, Group, Permission,
 SiteProfileNotAvailable
admin:   UserAdmin, GroupAdmin
backends:ModelBackend, RemoteUserBackend
decorators:  user_passes_test, login_required, permission_required
middleware:  RemoteUserMiddleware
forms:   AuthenticationForm, UserCreationForm, UserChangeForm,
 AdminPasswordChangeForm, PasswordChangeForm,
 PasswordResetForm, SetPasswordForm
 }}}

 Developers are free to define their own pluggable auth apps, by setting
 AUTH_APP and adding the app to INSTALLED_APPS, following the COMMENTS_APP
 pattern. Here is one such pluggable auth app, which provides a User model
 with no username field and forms/backends/middleware that allow users to
 login with their email address:

 https://github.com/claymation/django_email_auth

 Is this the same approach that has been rejected for inclusion in core
 previously, and if so, why?

-- 
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] #17768: Explain the expected failure on UpdateViewTests.test_update_put

[Django]

#17768: Explain the expected failure on UpdateViewTests.test_update_put
-+-
 Reporter:  claudep  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  SVN
Component:  Generic views|   Resolution:
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Fandekasp):

 * cc: Fandekasp (added)
 * stage:  Accepted => Ready for checkin


Comment:

 Comment is correct

-- 
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] #17762: Multi-db apps (no Django test suite) testing fails to create in-memory sqlite DBs

[Django]

#17762: Multi-db apps (no Django test suite) testing fails to create in-memory
sqlite DBs
-+-
 Reporter:  agriffis |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:  duplicate
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  1|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by agriffis):

 Replying to [comment:7 ramiro]:
 > I understand that part. I was talking about the fact that the `name`
 variable is used without being defined before so the code is broken.

 How embarrassing. You're right of course. I made final changes to the
 patch to make it more presentable and goofed it. :-(

 > Now I realise you are using ":memory:" for the NAME keys in DATABASES.
 That's an odd setup it means all your production databases are no
 persistent.

 Actually they're test-specific settings. In production that project had
 real databases...

 Regarding ticket #16329 I agree this is a duplicate of that ticket. Sorry
 I didn't find that one when I looked. I think the patch in this ticket,
 once unbroken, might be the most correct way to fix the problem. Let me
 know if you'd like me to repair it and attach it over there.

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

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

Re: [Django] #14497: ModelAdmin.readonly_fields isn't graceful with filefields.

[Django]

#14497: ModelAdmin.readonly_fields isn't graceful with filefields.
-+-
 Reporter:  Keryn Knight |Owner:
    |  paulcollins
 Type:  New feature  |   Status:  new
Component:  contrib.admin|  Version:  1.2
 Severity:  Normal   |   Resolution:
 Keywords:  feature admin| Triage Stage:  Accepted
  readonly filefield |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  1
Easy pickings:  0|
-+-

Comment (by paulcollins):

 After some discussion with Julian I removed the Selenium tests and did
 basically the same thing with the django.test.client

-- 
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] r17695 - django/trunk/tests/modeltests/defer

[noreply]

Author: kmtracey
Date: 2012-03-12 18:01:22 -0700 (Mon, 12 Mar 2012)
New Revision: 17695

Modified:
   django/trunk/tests/modeltests/defer/tests.py
Log:
Refs #17876: enhanced new test to actually test underlying function, not just 
ensure trying to use it does not raise an exception. Thanks Przemek Lewandowski.


Modified: django/trunk/tests/modeltests/defer/tests.py
===
--- django/trunk/tests/modeltests/defer/tests.py2012-03-13 00:15:43 UTC 
(rev 17694)
+++ django/trunk/tests/modeltests/defer/tests.py2012-03-13 01:01:22 UTC 
(rev 17695)
@@ -146,6 +146,15 @@
 obj.save()
 
 def test_defer_proxy(self):
-# using select related and only should not result in Exception
-for obj in ChildProxy.objects.all().select_related().only('id'):
-continue
+"""
+Ensure select_related together with only on a proxy model behaves
+as expected. See #17876.
+"""
+related = Secondary.objects.create(first='x1', second='x2')
+ChildProxy.objects.create(name='p1', value='xx', related=related)
+children = ChildProxy.objects.all().select_related().only('id', 'name')
+self.assertEqual(len(children), 1)
+child = children[0]
+self.assert_delayed(child, 1)
+self.assertEqual(child.name, 'p1')
+self.assertEqual(child.value, 'xx')

-- 
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] #17876: get_klass_info should handle proxy models and with select_related

[Django]

#17876: get_klass_info should handle proxy models and with select_related
-+-
 Reporter:  milosu   |Owner:  kmtracey
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:
  (models, ORM)  |  1.4-beta-1
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  proxy| Triage Stage:  Accepted
  select_related get_klass_info  |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by kmtracey):

 In [17695]:
 {{{
 #!CommitTicketReference repository="" revision="17695"
 Refs #17876: enhanced new test to actually test underlying function, not
 just ensure trying to use it does not raise an exception. Thanks Przemek
 Lewandowski.
 }}}

-- 
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] #17864: Add localflavor for Hong Kong, starting with a phone number field

[Django]

#17864: Add localflavor for Hong Kong, starting with a phone number field
-+-
 Reporter:  mrkschan@…   |Owner:  mrkschan
 Type:  New feature  |   Status:  assigned
Component:  contrib.localflavor  |  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:  localflavor hk   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  1|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by julien):

 * stage:  Accepted => Ready for checkin


Comment:

 Thanks!

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

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

Re: [Django] #12753: Fixture loading can fails on second syncdb when auto_now_add field is ommitted

[Django]

#12753: Fixture loading can fails on second syncdb when auto_now_add field is
ommitted
-+-
 Reporter:  russellm |Owner:  kmtracey
 Type:  Bug  |   Status:  closed
Component:  Core |  Version:
  (Serialization)|  1.4-beta-1
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by kmtracey):

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


Comment:

 So strictly speaking the bug of the 1st syncdb working for fixtures with
 missing values for auto_now and auto_now_add fields was fixed by r16739.
 The backwards-incompatible implicatoins of that fix have now been
 documented in the release notes (r17694), so I'm closing this ticket as
 fixed.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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] r17694 - django/trunk/docs/releases

[noreply]

Author: kmtracey
Date: 2012-03-12 17:15:43 -0700 (Mon, 12 Mar 2012)
New Revision: 17694

Modified:
   django/trunk/docs/releases/1.4.txt
Log:
Add a note to the backwards-incompatible changes section of 1.4 release notes 
about the change related to loading fixtures with incomplete data for auto_now 
and auto_now_add fields. Refs #12753. Thanks ptone.


Modified: django/trunk/docs/releases/1.4.txt
===
--- django/trunk/docs/releases/1.4.txt  2012-03-12 23:05:16 UTC (rev 17693)
+++ django/trunk/docs/releases/1.4.txt  2012-03-13 00:15:43 UTC (rev 17694)
@@ -1078,6 +1078,16 @@
 interests of full disclosure, the ``ExtendsNode.__init__`` definition has
 changed, which may break any custom tags that use this class.
 
+Loading some incomplete fixtures no longer works
+
+
+Prior to 1.4, a default value was inserted for fixture objects that were 
missing
+a specific date or datetime value when auto_now or auto_now_add was set for the
+field. This was something that should not have worked, and in 1.4 loading such
+incomplete fixtures will fail. Because fixtures are a raw import, they should
+explicitly specify all field values, regardless of field options on the model.
+
+
 Features deprecated in 1.4
 ==
 

-- 
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] #12753: Fixture loading can fails on second syncdb when auto_now_add field is ommitted

[Django]

#12753: Fixture loading can fails on second syncdb when auto_now_add field is
ommitted
-+-
 Reporter:  russellm |Owner:  kmtracey
 Type:  Bug  |   Status:  new
Component:  Core |  Version:
  (Serialization)|  1.4-beta-1
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by kmtracey):

 In [17694]:
 {{{
 #!CommitTicketReference repository="" revision="17694"
 Add a note to the backwards-incompatible changes section of 1.4 release
 notes about the change related to loading fixtures with incomplete data
 for auto_now and auto_now_add fields. Refs #12753. Thanks ptone.
 }}}

-- 
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] #12753: Fixture loading can fails on second syncdb when auto_now_add field is ommitted

[Django]

#12753: Fixture loading can fails on second syncdb when auto_now_add field is
ommitted
-+-
 Reporter:  russellm |Owner:  kmtracey
 Type:  Bug  |   Status:  new
Component:  Core |  Version:
  (Serialization)|  1.4-beta-1
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by kmtracey):

 * owner:  dmedvinsky => kmtracey


-- 
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] #17864: Add localflavor for Hong Kong, starting with a phone number field

[Django]

#17864: Add localflavor for Hong Kong, starting with a phone number field
-+
 Reporter:  mrkschan@…   |Owner:  mrkschan
 Type:  New feature  |   Status:  assigned
Component:  contrib.localflavor  |  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:  localflavor hk   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+
Changes (by Fandekasp):

 * cc: Fandekasp (added)
 * needs_docs:  1 => 0


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

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

Re: [Django] #17864: Add localflavor for Hong Kong, starting with a phone number field

[Django]

#17864: Add localflavor for Hong Kong, starting with a phone number field
-+
 Reporter:  mrkschan@…   |Owner:  mrkschan
 Type:  New feature  |   Status:  assigned
Component:  contrib.localflavor  |  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:  localflavor hk   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+
Changes (by Fandekasp):

 * needs_better_patch:  1 => 0
 * needs_tests:  1 => 0


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

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

[Changeset] r17693 - django/trunk/docs/internals/contributing

[noreply]

Author: adrian
Date: 2012-03-12 16:05:16 -0700 (Mon, 12 Mar 2012)
New Revision: 17693

Modified:
   django/trunk/docs/internals/contributing/localizing.txt
Log:
Made some small edits to localization docs from [17690]

Modified: django/trunk/docs/internals/contributing/localizing.txt
===
--- django/trunk/docs/internals/contributing/localizing.txt 2012-03-12 
22:33:18 UTC (rev 17692)
+++ django/trunk/docs/internals/contributing/localizing.txt 2012-03-12 
23:05:16 UTC (rev 17693)
@@ -14,7 +14,7 @@
 Translations are contributed by Django users worldwide. The translation work is
 coordinated at `Transifex`_.
 
-If you find an incorrect translation or want to discuss specific translations
+If you find an incorrect translation or want to discuss specific translations,
 go to the `Django project page`_. If you would like to help out with
 translating or add a language that isn't yet translated, here's what to do:
 
@@ -27,7 +27,7 @@
 * On the `Django project page`_, choose the language you want to work on,
   **or** -- in case the language doesn't exist yet --
   request a new language team by clicking on the "Request language" link
-  and select the appropriate language.
+  and selecting the appropriate language.
 
 * Then, click the "Join this Team" button to become a member of this team.
   Every team has at least one coordinator who is responsible to review

-- 
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] #12753: Fixture loading can fails on second syncdb when auto_now_add field is ommitted

[Django]

#12753: Fixture loading can fails on second syncdb when auto_now_add field is
ommitted
-+-
 Reporter:  russellm |Owner:
 Type:  Bug  |  dmedvinsky
Component:  Core |   Status:  new
  (Serialization)|  Version:
 Severity:  Release blocker  |  1.4-beta-1
 Keywords:   |   Resolution:
Has patch:  1| Triage Stage:  Accepted
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by ptone):

 From discussion at the sprints with Karen, Paul and jezdez, the consensus
 was that this was in fact fixed by r16739, as Russ implies in the original
 mail thread that the fact that the fixture loading the first time was a
 bug.

 I've attached a draft release note about this backwards incompatibility.

-- 
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] #16605: Can't client.login() in tests if contrib.SessionMiddleware is not in MIDDLEWARE_CLASSES

[Django]

#16605: Can't client.login() in tests if contrib.SessionMiddleware is not in
MIDDLEWARE_CLASSES
---+
 Reporter:  jbalogh|Owner:  ramiro
 Type:  Bug|   Status:  assigned
Component:  Testing framework  |  Version:  1.3
 Severity:  Release blocker|   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by jezdez):

 To clarify, we do have settings that can have a empty string as a valid
 value, just don't use that state to disable a feature.

-- 
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] #16605: Can't client.login() in tests if contrib.SessionMiddleware is not in MIDDLEWARE_CLASSES

[Django]

#16605: Can't client.login() in tests if contrib.SessionMiddleware is not in
MIDDLEWARE_CLASSES
---+
 Reporter:  jbalogh|Owner:  ramiro
 Type:  Bug|   Status:  assigned
Component:  Testing framework  |  Version:  1.3
 Severity:  Release blocker|   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by jezdez):

 We don't have any other setting that can be set to an empty string, so
 this is definitely something I wouldn't prefer for this.

 I'd be in favor of reverting r16386, too.

-- 
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] #14497: ModelAdmin.readonly_fields isn't graceful with filefields.

[Django]

#14497: ModelAdmin.readonly_fields isn't graceful with filefields.
-+-
 Reporter:  Keryn Knight |Owner:
    |  paulcollins
 Type:  New feature  |   Status:  new
Component:  contrib.admin|  Version:  1.2
 Severity:  Normal   |   Resolution:
 Keywords:  feature admin| Triage Stage:  Accepted
  readonly filefield |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  1
Easy pickings:  0|
-+-
Changes (by paulcollins):

 * status:  assigned => new
 * owner:  adamjforster => paulcollins
 * needs_tests:  1 => 0


Comment:

 @adamjforster I'm grabbing this ticket since you called out for some help
 writing tests. Please feel free to grab it back if you'd like. I removed
 your check on for value.file, because it causes an IO exception (no such
 file) during the unittests. I figured that testing for the actual
 existence of the file wasn't really needed to generate the link to the
 file.

 @akaariai I've added the Selenium tests, but I'm not sure if that's the
 fastest way to test that the field is rendering correctly in the admin.
 Suggestions?

 @javiersanchez I can update the patch for this but that would make this
 particular interface inconsistent with the read/write interface. In the
 current version the link is rendered the same way, though it's rendered by
 different code.

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

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

Re: [Django] #12753: Fixture loading can fails on second syncdb when auto_now_add field is ommitted

[Django]

#12753: Fixture loading can fails on second syncdb when auto_now_add field is
ommitted
-+-
 Reporter:  russellm |Owner:
 Type:  Bug  |  dmedvinsky
Component:  Core |   Status:  new
  (Serialization)|  Version:
 Severity:  Release blocker  |  1.4-beta-1
 Keywords:   |   Resolution:
Has patch:  1| Triage Stage:  Accepted
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by ptone):

 For reference, further discussion here; http://groups.google.com/group
 /django-users/browse_thread/thread/65fab1fa4104dae6/d9107358d9cb0404

-- 
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] #17882: regressiontests.admin_filters fails with pyscopg2 when USE_TZ is False

[Django]

#17882: regressiontests.admin_filters fails with pyscopg2 when USE_TZ is False
-+-
 Reporter:  brodie   |Owner:  aaugustin
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:
 Severity:  Release blocker  | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by jezdez):

 * stage:  Design decision needed => Ready for checkin


Comment:

 I think this ticket is clearly a great use case for the signal, let's use
 the second 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.

[Changeset] r17692 - in django/trunk: django/db/models tests/modeltests/defer

[noreply]

Author: kmtracey
Date: 2012-03-12 15:33:18 -0700 (Mon, 12 Mar 2012)
New Revision: 17692

Modified:
   django/trunk/django/db/models/query.py
   django/trunk/tests/modeltests/defer/models.py
   django/trunk/tests/modeltests/defer/tests.py
Log:
Fix #17876: Corrected an exception (regression) raised where select_realted and 
only is used on a proxy model. Thanks milosu and charettes.


Modified: django/trunk/django/db/models/query.py
===
--- django/trunk/django/db/models/query.py  2012-03-12 22:13:34 UTC (rev 
17691)
+++ django/trunk/django/db/models/query.py  2012-03-12 22:33:18 UTC (rev 
17692)
@@ -1266,7 +1266,7 @@
 return None
 
 if only_load:
-load_fields = only_load.get(klass)
+load_fields = only_load.get(klass) or set()
 # When we create the object, we will also be creating populating
 # all the parent classes, so traverse the parent classes looking
 # for fields that must be included on load.

Modified: django/trunk/tests/modeltests/defer/models.py
===
--- django/trunk/tests/modeltests/defer/models.py   2012-03-12 22:13:34 UTC 
(rev 17691)
+++ django/trunk/tests/modeltests/defer/models.py   2012-03-12 22:33:18 UTC 
(rev 17692)
@@ -22,3 +22,7 @@
 
 class BigChild(Primary):
 other = models.CharField(max_length=50)
+
+class ChildProxy(Child):
+class Meta:
+proxy=True

Modified: django/trunk/tests/modeltests/defer/tests.py
===
--- django/trunk/tests/modeltests/defer/tests.py2012-03-12 22:13:34 UTC 
(rev 17691)
+++ django/trunk/tests/modeltests/defer/tests.py2012-03-12 22:33:18 UTC 
(rev 17692)
@@ -3,7 +3,7 @@
 from django.db.models.query_utils import DeferredAttribute
 from django.test import TestCase
 
-from .models import Secondary, Primary, Child, BigChild
+from .models import Secondary, Primary, Child, BigChild, ChildProxy
 
 
 class DeferTests(TestCase):
@@ -145,3 +145,7 @@
 obj.name = "bb"
 obj.save()
 
+def test_defer_proxy(self):
+# using select related and only should not result in Exception
+for obj in ChildProxy.objects.all().select_related().only('id'):
+continue

-- 
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] #17876: get_klass_info should handle proxy models and with select_related

[Django]

#17876: get_klass_info should handle proxy models and with select_related
-+-
 Reporter:  milosu   |Owner:  kmtracey
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:
  (models, ORM)  |  1.4-beta-1
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  proxy| Triage Stage:  Accepted
  select_related get_klass_info  |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by kmtracey):

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


Comment:

 In [17692]:
 {{{
 #!CommitTicketReference repository="" revision="17692"
 Fix #17876: Corrected an exception (regression) raised where
 select_realted and only is used on a proxy model. Thanks milosu and
 charettes.
 }}}

-- 
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] #17876: get_klass_info should handle proxy models and with select_related

[Django]

#17876: get_klass_info should handle proxy models and with select_related
-+-
 Reporter:  milosu   |Owner:  kmtracey
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:
  (models, ORM)  |  1.4-beta-1
 Severity:  Release blocker  |   Resolution:
 Keywords:  proxy| Triage Stage:  Accepted
  select_related get_klass_info  |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by kmtracey):

 * owner:  anonymous => kmtracey


-- 
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] #17707: Docs for URL namespaces should explain the motivation and use cases

[Django]

#17707: Docs for URL namespaces should explain the motivation and use cases
--+
 Reporter:  aaugustin |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  reopened
Component:  Documentation |  Version:  SVN
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Fandekasp):

 ok sorry

-- 
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] r17691 - django/branches/releases/1.3.X/docs/internals

[noreply]

Author: jezdez
Date: 2012-03-12 15:13:34 -0700 (Mon, 12 Mar 2012)
New Revision: 17691

Modified:
   django/branches/releases/1.3.X/docs/internals/contributing.txt
Log:
[1.3.X] Fixed the localization docs a little to point to the correct Transifex 
URL. Also reworded it a bit to follow the site's new UI.

Backport from trunk (r17690).

Modified: django/branches/releases/1.3.X/docs/internals/contributing.txt
===
--- django/branches/releases/1.3.X/docs/internals/contributing.txt  
2012-03-12 22:00:44 UTC (rev 17690)
+++ django/branches/releases/1.3.X/docs/internals/contributing.txt  
2012-03-12 22:13:34 UTC (rev 17691)
@@ -454,9 +454,8 @@
 
 These translations are contributed by Django users worldwide. If you find an
 incorrect translation or want to discuss specific translations, go to the
-`translation team`_ page for that language. If you would like to help out
-with translating or add a language that isn't yet translated, here's what
-to do:
+`Django project page`_ on `Transifex`_. If you would like to help out with
+translating or add a language that isn't yet translated, here's what to do:
 
 * Join the `Django i18n mailing list`_ and introduce yourself.
 
@@ -464,12 +463,12 @@
 
 * Signup at `Transifex`_ and visit the `Django project page`_.
 
-* On the "`Translation Teams`_" page, choose the language team you want
-  to work with, **or** -- in case the language team doesn't exist yet --
-  request a new team by clicking on the "Request a new team" button
-  and select the appropriate language.
+* On the `Django project page`_ page, choose the language you want
+  to work on, **or** -- in case the language doesn't exist yet --
+  request a new language team by clicking on the "Request language"
+  link and select the appropriate language.
 
-* Then, click the "Join this Team" button to become a member of this team.
+* Then, click the "Join Team" button to become a member of this team.
   Every team has at least one coordinator who is responsible to review
   your membership request. You can of course also contact the team
   coordinator to clarify procedural problems and handle the actual
@@ -499,8 +498,6 @@
 .. _Django i18n mailing list: http://groups.google.com/group/django-i18n/
 .. _Transifex: http://www.transifex.net/
 .. _Django project page: http://www.transifex.net/projects/p/django/
-.. _translation teams: http://www.transifex.net/projects/p/django/teams/
-.. _translation team: http://www.transifex.net/projects/p/django/teams/
 .. _Transifex Help: http://help.transifex.net/
 
 Submitting javascript patches

-- 
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] #16329: Django doesn't initialize two databases with the same name, port and host

[Django]

#16329: Django doesn't initialize two databases with the same name, port and 
host
-+-
 Reporter:  canassa  |Owner:  nobody
 Type:  Bug  |   Status:  reopened
Component:  Testing framework|  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Design
Has patch:  0|  decision needed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by ramiro):

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


Comment:

 I'm reopening this because whay I suggested in comment:2 (explicitly use
 the `'TEST_NAME'` `DATABASES` inner option  with a `':memory:'` value)
 doesn't work. Sorry for the confusion.

-- 
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] r17690 - django/trunk/docs/internals/contributing

[noreply]

Author: jezdez
Date: 2012-03-12 15:00:44 -0700 (Mon, 12 Mar 2012)
New Revision: 17690

Modified:
   django/trunk/docs/internals/contributing/localizing.txt
Log:
Fixed the localization docs a little to point to the correct Transifex URL. 
Also reworded it a bit to follow the site's new UI.

Modified: django/trunk/docs/internals/contributing/localizing.txt
===
--- django/trunk/docs/internals/contributing/localizing.txt 2012-03-12 
21:58:07 UTC (rev 17689)
+++ django/trunk/docs/internals/contributing/localizing.txt 2012-03-12 
22:00:44 UTC (rev 17690)
@@ -14,10 +14,9 @@
 Translations are contributed by Django users worldwide. The translation work is
 coordinated at `Transifex`_.
 
-If you find an incorrect translation or want to discuss specific translations,
-go to the `translation team`_ page for that language. If you would like to help
-out with translating or add a language that isn't yet translated, here's what 
to
-do:
+If you find an incorrect translation or want to discuss specific translations
+go to the `Django project page`_. If you would like to help out with
+translating or add a language that isn't yet translated, here's what to do:
 
 * Join the `Django i18n mailing list`_ and introduce yourself.
 
@@ -25,9 +24,9 @@
 
 * Signup at `Transifex`_ and visit the `Django project page`_.
 
-* On the `translation teams`_ page, choose the language team you want
-  to work with, **or** -- in case the language team doesn't exist yet --
-  request a new team by clicking on the "Request a new team" button
+* On the `Django project page`_, choose the language you want to work on,
+  **or** -- in case the language doesn't exist yet --
+  request a new language team by clicking on the "Request language" link
   and select the appropriate language.
 
 * Then, click the "Join this Team" button to become a member of this team.
@@ -53,16 +52,15 @@
 :ref:`format-localization` for details.
 
 The format files aren't managed by the use of Transifex. To change them, you
-must :doc:`create a patch` against the Django 
source tree, as for any code change:
+must :doc:`create a patch` against the
+Django source tree, as for any code change:
 
 * Create a diff against the current Subversion trunk.
 
 * Open a ticket in Django's ticket system, set its ``Component`` field to
   ``Translations``, and attach the patch to it.
 
-.. _Transifex: http://www.transifex.net/
+.. _Transifex: https://www.transifex.net/
 .. _Django i18n mailing list: http://groups.google.com/group/django-i18n/
-.. _Django project page: http://www.transifex.net/projects/p/django/
-.. _translation team: http://www.transifex.net/projects/p/django/teams/
-.. _translation teams: http://www.transifex.net/projects/p/django/teams/
+.. _Django project page: https://www.transifex.net/projects/p/django/
 .. _Transifex User Guide: http://help.transifex.net/

-- 
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] #17876: get_klass_info should handle proxy models and with select_related

[Django]

#17876: get_klass_info should handle proxy models and with select_related
-+-
 Reporter:  milosu   |Owner:  anonymous
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:
  (models, ORM)  |  1.4-beta-1
 Severity:  Release blocker  |   Resolution:
 Keywords:  proxy| Triage Stage:  Accepted
  select_related get_klass_info  |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by anonymous):

 * owner:  nobody => anonymous


-- 
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] #17883: Better Error messages for 1.2 deprecations

[Django]

#17883: Better Error messages for 1.2 deprecations
-+--
 Reporter:  PaulM|Owner:  jezdez
 Type:  Bug  |   Status:  closed
Component:  Core (Other) |  Version:  1.4-beta-1
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by PaulM):

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


Comment:

 In [17689]:
 {{{
 #!CommitTicketReference repository="" revision="17689"
 Fixed #17883. Improved error message for old-style database backends.
 }}}

-- 
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] r17689 - django/trunk/django/db/backends/dummy

[noreply]

Author: PaulM
Date: 2012-03-12 14:58:07 -0700 (Mon, 12 Mar 2012)
New Revision: 17689

Modified:
   django/trunk/django/db/backends/dummy/base.py
Log:
Fixed #17883. Improved error message for old-style database backends.


Modified: django/trunk/django/db/backends/dummy/base.py
===
--- django/trunk/django/db/backends/dummy/base.py   2012-03-12 20:28:09 UTC 
(rev 17688)
+++ django/trunk/django/db/backends/dummy/base.py   2012-03-12 21:58:07 UTC 
(rev 17689)
@@ -12,7 +12,9 @@
 from django.db.backends.creation import BaseDatabaseCreation
 
 def complain(*args, **kwargs):
-raise ImproperlyConfigured("You haven't set the database ENGINE setting 
yet.")
+raise ImproperlyConfigured("settings.DATABASES is improperly configured. "
+   "Please supply the ENGINE value. Check "
+   "settings documentation for more details.")
 
 def ignore(*args, **kwargs):
 pass

-- 
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] #17888: CheckboxInput.render() shouldn't catch exceptions from check_test

[Django]

#17888: CheckboxInput.render() shouldn't catch exceptions from check_test
--+
 Reporter:  brutasse  |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Forms |Version:  SVN
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  1
Easy pickings:  0 |  UI/UX:  0
--+
 https://github.com/django/django/blob/master/django/forms/widgets.py#L502-505

 As the docs state, `check_test` is a callable that returns `True` if the
 checkbox should be checked for a specific value. The default
 implementation doesn't do anything complicated and shouldn't raise
 exceptions. If user-provided callables break, it django shouldn't catch
 the error silently.

 My proposal is to simply remove that bare except and let `check_test`
 raise exceptions.

 The current behaviour is actually expected and tested:

 
https://github.com/django/django/blob/master/tests/regressiontests/forms/tests/widgets.py#L218-224

 I still think it's quite a bad API and should be changed. Since that
 exception-swallowing behaviour isn't documented (although tested),
 backwards compatibility isn't that much of a concern.

-- 
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] #17854: Problem with DecimalField and big vlues of max_digits, decimal_places, sqlite3 backend

[Django]

#17854: Problem with DecimalField and big vlues of max_digits, decimal_places,
sqlite3 backend
-+-
 Reporter:  anonymous|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  DecimalField bug |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by tmitchell):

 * stage:  Unreviewed => Accepted


Comment:

 This is not specific to the admin, as the attached patch shows.  This
 patch works under postgres but fails under sqlite3.

-- 
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] #16329: Django doesn't initialize two databases with the same name, port and host

[Django]

#16329: Django doesn't initialize two databases with the same name, port and 
host
-+-
 Reporter:  canassa  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Testing framework|  Version:  1.3
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:  Design
Has patch:  0|  decision needed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by ramiro):

 #17762 reported this again, namely a setup with sqwlit3 where all the
 `NAME` keys in `DATABASES` have `':memory:'` as value, was closed as
 duplicate of this ticket.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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] #17762: Multi-db apps (no Django test suite) testing fails to create in-memory sqlite DBs

[Django]

#17762: Multi-db apps (no Django test suite) testing fails to create in-memory
sqlite DBs
-+-
 Reporter:  agriffis |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:  duplicate
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  1|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by ramiro):

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


Comment:

 Now I realise you are using `":memory:"` for the `NAME` keys in
 `DATABASES`. That's an odd setup it means all your production databases
 are no persistent.

 Something similar was reported in #16329 and I made a
 [https://code.djangoproject.com/ticket/16329#comment:2 comment] about that
 setup there and how to achieve creating in-memory test databases that led
 to the closing of that ticket.

 I will close this ticket as a duplicate but I will try to revisit the
 issue and ask other developers' opinions about this topic.

-- 
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] #17887: postgresql_psycopg2 sometimes leaves connections "idle in transaction"

[Django]

#17887: postgresql_psycopg2 sometimes leaves connections "idle in transaction"
--+
 Reporter:  brodie|  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.3
 Severity:  Normal|   Keywords:  psycopg2
 Triage Stage:  Unreviewed|  transactions
Easy pickings:  0 |  Has patch:  0
  |  UI/UX:  0
--+
 When using the postgresql_psycopg2 backend with DB-level autocommit
 ''disabled'', long-running Django processes (e.g., under Gunicorn) can
 leave around idle connections stuck in transactions, making things like
 schema migrations difficult to impossible to do without killing those
 connections.

 This happens because by default (with autocommit disabled), psycopg2
 issues a `BEGIN` before the connection's first query is run. If the
 connection is committed or rolled back, it'll issue another `BEGIN` before
 the next query. Unless you commit or roll back the connection, it'll stick
 around in that transaction indefinitely.

 To make matters worse, if the connection is closed while it's in this idle
 state, it can cause problems with pgbouncer. pgbouncer will see there's a
 transaction in progress but that the client disconnected. The only way it
 can recover the connection safely is to disconnect from the server
 (issuing an "unclean server" error message).

 By default, the ORM issues a commit after every `INSERT` or `UPDATE` made
 through the ORM. If the very last thing the Django process does before
 disconnecting is an `INSERT` or an `UPDATE`, it won't run into the
 pgbouncer "unclean server" problem, and the connection won't be idle in
 transaction (as long as another query isn't run). But not every request
 makes a modification to the database as its last query, so most of the
 time you'll run into this issue.

 One workaround is to use the `TransactionMiddleware`, but that won't help
 if you're using the ORM outside of the request framework (e.g., in cron
 jobs, standalone scripts, or Celery tasks).

 I'm not sure what a proper fix would look like (or if this even warrants a
 fix). I think ideally, Django would by default issue a `ROLLBACK` after
 every request. It could also issue a `ROLLBACK` when disconnecting from
 the database. At very the least, this issue should be documented.

 Also note that while this is related to #16047, the fix for that issue
 won't resolve this one.

-- 
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] #17884: Distance lookups using ST_Distance_Sphere fails with PostGis 1.5.3

[Django]

#17884: Distance lookups using ST_Distance_Sphere fails with PostGis 1.5.3
-+--
 Reporter:  ogirardot@…  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  GIS  |  Version:  SVN
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by ogirardot@…):

 yes, i have a production machine, and a dev machine (debian/mac os) that
 used to work properly with the same code, using django 1.3.1,

  PostgreSQL 9.0.5 on x86_64-pc-linux-gnu, compiled by GCC gcc-4.4.real
 (Debian 4.4.5-8) 4.4.5, 64-bit
 and
  POSTGIS="1.5.2" GEOS="3.2.0-CAPI-1.6.0" PROJ="Rel. 4.7.1, 23 September
 2009" LIBXML="2.7.8" USE_STATS

 The problem for me seems to come form whether Postgresql 9.1 or Postgis
 1.5.3

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

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

[Django] #17886: LOUTER join not promoted across filter expression

[Django]

#17886: LOUTER join not promoted across filter expression
--+
 Reporter:  milosu|  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.4-beta-1
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  1
Easy pickings:  0 |  UI/UX:  0
--+
 In my database I have a little bit complicated relations. The attached
 test case fails without applied patch.

 The core of the problem is actually something like:

 {{{
 ModelA <-- ModelB ---0--> Model C --> Model D
   <--0--> Model C --> Model D

 }}}

 When I put ModelA into django.contrib.admin changelist and try to search -
 the search fields containing fields from all above outlined models, the
 resulting queryset contains one INNER JOIN for the link between the second
 relation of Model C and Model D which removes from the result set those
 models for which the many2many link is empty - which I guess should not
 happen.

 I think that the LEFT OUTER JOIN should propagage in this case across
 relations. Maybe this patch solves also other ORM OR-queries related
 problems present or already patched earlier..

 The attached patch solves this problem and I hope it passes the whole
 Django test suite - although due to the time limitations I tried it only
 with "queries" and "aggregation_regress tests". With this patch I was
 running my app in production for 2 years now, so I expect it *should*
 work.

 This bug was present in the Django ORM since the qs refactor branch was
 merged a few years ago so I think it does not need to be marked as 1.4
 release bloker. But anyway..

-- 
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] #17884: Distance lookups using ST_Distance_Sphere fails with PostGis 1.5.3

[Django]

#17884: Distance lookups using ST_Distance_Sphere fails with PostGis 1.5.3
-+--
 Reporter:  ogirardot@…  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  GIS  |  Version:  SVN
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by kmtracey):

 Actually reading closer I think above it says the same problem exists in
 both 1.3 and 1.4? That would mean it's not a release blocker.

-- 
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] #17884: Distance lookups using ST_Distance_Sphere fails with PostGis 1.5.3

[Django]

#17884: Distance lookups using ST_Distance_Sphere fails with PostGis 1.5.3
-+--
 Reporter:  ogirardot@…  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  GIS  |  Version:  SVN
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by kmtracey):

 If it used to work in 1.3 but now fails with current trunk Django code,
 the release blocker label is appropriate. I'm still not sure if that is
 the case based on what's been said so far.

-- 
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] #17207: create_template_postgis-debian.sh cant use UTF8 on PostgreSQL 8.4

[Django]

#17207: create_template_postgis-debian.sh cant use UTF8 on PostgreSQL 8.4
-+
 Reporter:  artur@…  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  GIS  |  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:  postgis  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by jpaulett):

 * cc: john@… (added)
 * needs_better_patch:  1 => 0


Comment:

 I agree with aaugustin.  I have occasionally encountered this bug if the
 OS's locale is not en-us.UTF8 (or similar).  Vagrant seems to only use
 "en-us" in their lucid base boxes.

 Attached is a patch with adds a troubleshooting note to the documentation
 and links to Jacob's workaround.

-- 
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] #17884: Distance lookups using ST_Distance_Sphere fails with PostGis 1.5.3

[Django]

#17884: Distance lookups using ST_Distance_Sphere fails with PostGis 1.5.3
-+--
 Reporter:  ogirardot@…  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  GIS  |  Version:  SVN
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by anonymous):

 it makes at least 1.3 and the trunk of 1.4 fail (and crash in my case but
 that may be something else) at distance lookups for Postgresql 9.1 and
 Postgis 1.5.3 (latest version).[[BR]]

 As a matter of fact i can't say that i will be able to put django 1.4 in
 production without a proper interaction with postgis...

 But i'm not that much familiar with what tags should be on what tickets in
 django's trac, if you think that may not be a suitable tag, i can
 understand that i just put the tag according to what i think.

 But you're right, i don't think it's a regression in Django code, but
 evidence points to the fact that the ewkb used and transmitted to
 ST_Distance_Sphere does not contain SRID informations. So the oldest
 versions of ST_Distance_Sphere (according to the documentation) just
 assumed the SRID was 4326, but it seems now it's enforcing it.
 So it may not be a regression as the change of behavior comes from
 Postgis, but it's not that innocent either to create an EWKB without the
 SRID infos.

 Regards and sorry for the formatting i couldn't fix it afterwards,

 Olivier.

-- 
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] #17762: Multi-db apps (no Django test suite) testing fails to create in-memory sqlite DBs

[Django]

#17762: Multi-db apps (no Django test suite) testing fails to create in-memory
sqlite DBs
-+-
 Reporter:  agriffis |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  1|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by ramiro):

 Replying to [comment:4 agriffis]:
 > Replying to [comment:3 ramiro]:
 > > Could you give us more details how are you getting the ''"Django fails
 to create multiple in-memory SQLite databases, instead it creates only one
 (which is populated only with the table definitions for the default DB)"''
 failure you describe so others can reproduce it?
 >
 > Thanks for the time you've put into this, and the instructions for
 creating the mdb app! I wasn't sure how to quickly make an isolated test
 case for this. I see the problem using
 > [...]
 >
 > which results in:
 >
 > {{{
 > $ ./manage.py test -v2 mdb 2>&1 | grep Creating
 > Creating test database for alias 'default' (':memory:')...
 > Creating tables ...
 > [...]
 >

 That's weird will try to reproduce it.

 > Regarding:
 > > The patch doesn't seem to make any sense, though.
 >
 > The base `test_db_signature()` distinguishes unique databases by the
 combination of `ENGINE`, `NAME`, etc.  SQLite databases are distinguished
 by `NAME` except for `':memory:'` and `''` (on-disk temporary DB) which
 are unique per-connection even if the `NAME` is the same as another
 connection. I figured `id(self.connection)` accurately identifies unique
 databases in this case.  Does it make sense with that explanation?

 I understand that part. I was talking about the fact that the `name`
 variable is used without being defined before so the code broken.

-- 
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] #2550: [patch] Allow a Backend to Globally Fail Authentication

[Django]

#2550: [patch] Allow a Backend to Globally Fail Authentication
-+-
 Reporter:  umbrae@… |Owner:
 Type:  New feature  |  aashu_dwivedi
Component:  contrib.auth |   Status:  reopened
 Severity:  Normal   |  Version:  SVN
 Keywords:  authentication   |   Resolution:
  backends easy-pickings | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  1|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by danielr):

 * stage:  Accepted => Ready for checkin


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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] #17884: Distance lookups using ST_Distance_Sphere fails with PostGis 1.5.3

[Django]

#17884: Distance lookups using ST_Distance_Sphere fails with PostGis 1.5.3
-+--
 Reporter:  ogirardot@…  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  GIS  |  Version:  SVN
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Old description:

> Hi,
> i've worked a lot to make this work, and i just can't figure it out right
> now, so i'm opening a ticket. This is related to #16778 and my point of
> view right now is that it's a problem about how the EWKB Binary object
> gets created.
> My problem is that, i've CommentAddress objects with PointField
> (srid=4326) and an Address with a PointField (srid=4326 too), i do a
> simple distance lookup request :
>
> CommentAddress.objects.distance(Address.objects.get(pk=).geopoint)
>
> And it fails with :
>   File ".../django/db/backends/postgresql_psycopg2/base.py", line 53, in
> execute
> return self.cursor.execute(query, args)
> DatabaseError: geometry_distance_spheroid: Operation on two GEOMETRIES
> with different SRIDs
>
> But both are the proper srids, the problem is that the query that gets
> created is :
>

>  select St_Distance_Sphere(geopoint,
> ST_GeomFromEWKB('\x0101001f7932dea0670240486469f173704840'::bytea))
> from frontend_commentaddress;
>
> But when i do myself the ST_AsEWKB on the same precise object i get a
> very different EWKB and the query - works :
>
> select St_Distance_Sphere(geopoint, ST_GeomFromEWKB('\001\001\000\000
> \346\020\000\000\037y1\336\240g\002@Hdi\361spH@'::bytea)) from
> frontend_commentaddress;
>
> I tried to use self._adapter.adapted (which looks really better with a H@
> at the end) instead of self._adapter.getquoted() into the postgis adapter
> but it doesn't work as it's unicode translated into bytes... Anyway i'm
> missing something there and can't get it working.
>
> This is a real blocker, and it seems that this is crashing my local
> runserver (no stacktrace no log, just crashed).
> Thank you for your help.
>
> Here are my versions and what i tried :
> Python 2.7.1
> Django 1.4 trunk (as of today)
> "POSTGIS="1.5.3" GEOS="3.3.2-CAPI-1.7.2" PROJ="Rel. 4.7.1, 23 September
> 2009" LIBXML="2.7.3" USE_STATS (procs from 1.5 r5976 need upgrade)"
> "PostgreSQL 9.1.3 on x86_64-apple-darwin10.8.0, compiled by i686-apple-
> darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5664), 64-bit"
> both installed with homebrew. (on mac os lion)

New description:

 Hi,
 i've worked a lot to make this work, and i just can't figure it out right
 now, so i'm opening a ticket. This is related to #16778 and my point of
 view right now is that it's a problem about how the EWKB Binary object
 gets created.
 My problem is that, i've CommentAddress objects with PointField
 (srid=4326) and an Address with a PointField (srid=4326 too), i do a
 simple distance lookup request :
 {{{
 #!python
 CommentAddress.objects.distance(Address.objects.get(pk=).geopoint)
 }}}

 And it fails with :
 {{{
   File ".../django/db/backends/postgresql_psycopg2/base.py", line 53, in
 execute
 return self.cursor.execute(query, args)
 DatabaseError: geometry_distance_spheroid: Operation on two GEOMETRIES
 with different SRIDs
 }}}
 But both are the proper srids, the problem is that the query that gets
 created is :

 {{{
  select St_Distance_Sphere(geopoint,
 ST_GeomFromEWKB('\x0101001f7932dea0670240486469f173704840'::bytea))
 from frontend_commentaddress;
 }}}
 But when i do myself the ST_AsEWKB on the same precise object i get a very
 different EWKB and the query - works :
 {{{
 select St_Distance_Sphere(geopoint, ST_GeomFromEWKB('\001\001\000\000
 \346\020\000\000\037y1\336\240g\002@Hdi\361spH@'::bytea)) from
 frontend_commentaddress;
 }}}
 I tried to use self._adapter.adapted (which looks really better with a H@
 at the end) instead of self._adapter.getquoted() into the postgis adapter
 but it doesn't work as it's unicode translated into bytes... Anyway i'm
 missing something there and can't get it working.

 This is a real blocker, and it seems that this is crashing my local
 runserver (no stacktrace no log, just crashed).
 Thank you for your help.

 Here are my versions and what i tried :

 Python 2.7.1

 Django 1.4 trunk (as of today)

 "POSTGIS="1.5.3" GEOS="3.3.2-CAPI-1.7.2" PROJ="Rel. 4.7.1, 23 September
 2009" LIBXML="2.7.3" USE_STATS (procs from 1.5 r5976 need upgrade)"

 "PostgreSQL 9.1.3 on x86_64-apple-darwin10.8.0, compiled by i686-apple-
 darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5664), 64-bit"

 both installed 

Re: [Django] #15220: replace SelectFilter2.js with a jQuery plugin

[Django]

#15220: replace SelectFilter2.js with a jQuery plugin
-+-
 Reporter:  slurms   |Owner:  dbunskoek
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  SVN
Component:  contrib.admin|   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  1
Easy pickings:  0|
-+-

Comment (by julien):

 We'll do this shortly after 1.4 gets released, based on the patch in
 #13614.

-- 
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] #15220: replace SelectFilter2.js with a jQuery plugin

[Django]

#15220: replace SelectFilter2.js with a jQuery plugin
-+-
 Reporter:  slurms   |Owner:  dbunskoek
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  SVN
Component:  contrib.admin|   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  1
Easy pickings:  0|
-+-
Changes (by julien):

 * needs_better_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] #17882: regressiontests.admin_filters fails with pyscopg2 when USE_TZ is False

[Django]

#17882: regressiontests.admin_filters fails with pyscopg2 when USE_TZ is False
-+-
 Reporter:  brodie   |Owner:  aaugustin
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:
 Severity:  Release blocker  | Triage Stage:  Design
 Keywords:   |  decision needed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by aaugustin):

 * stage:  Accepted => Design decision needed


Comment:

 I have a preference for the second patch, but I'm not sure how we want to
 use `setting_changed` in 1.4 exactly -- see #17787. DDN until this is
 clarified.

-- 
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] #17843: new contrib.admin userstyle template block in base.html

[Django]

#17843: new contrib.admin userstyle template block in base.html
---+--
 Reporter:  miked@…|Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  contrib.admin  |  Version:  SVN
 Severity:  Normal |   Resolution:  wontfix
 Keywords:  user css   | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  1
---+--
Changes (by julien):

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


Comment:

 Thank you for the suggestion, however I think it would be confusing to
 have multiple blocks in the admin's built-in templates for appending CSS
 rules. If you really need to do that, then you should already be able to
 achieve this by providing a custom `base_site.html`template and adding
 extra blocks to it.

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

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

Re: [Django] #17787: Clear setting-dependant caches when settings are overridden (in tests)

[Django]

#17787: Clear setting-dependant caches when settings are overridden (in tests)
---+--
 Reporter:  aaugustin  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  Version:  1.4-beta-1
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by aaugustin):

 #17882 has another use case.

-- 
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] #17707: Docs for URL namespaces should explain the motivation and use cases

[Django]

#17707: Docs for URL namespaces should explain the motivation and use cases
--+
 Reporter:  aaugustin |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  reopened
Component:  Documentation |  Version:  SVN
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by aaugustin):

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


Comment:

 As explained in the
 [https://docs.djangoproject.com/en/dev/internals/contributing/triaging-
 tickets/ triage guidelines] please dont close tickets as wontfix.

 This was discussed with other members of the core team and they agreed
 there's room for improvement.

-- 
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] #17864: Add localflavor for Hong Kong, starting with a phone number field

[Django]

#17864: Add localflavor for Hong Kong, starting with a phone number field
-+
 Reporter:  mrkschan@…   |Owner:  mrkschan
 Type:  New feature  |   Status:  assigned
Component:  contrib.localflavor  |  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:  localflavor hk   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  0
-+

Comment (by Fandekasp):

 mrkschan, look at
 https://docs.djangoproject.com/en/1.3/internals/documentation/ for django-
 specific markup

-- 
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] #16047: postgresql_psycopg2 never restores autocommit mode when leaving transaction management

[Django]

#16047: postgresql_psycopg2 never restores autocommit mode when leaving 
transaction
management
-+-
 Reporter:  brodie   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  psycopg2 autocommit  |  Needs documentation:  0
  transactions   |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by brodie):

 OK, I agree that your fix is the right approach.

 I have a new patch series that incorporates your changes. The first patch
 fixes the `supports_transactions` DB feature being `False` when the test
 databases are using autocommit mode. The second patch is based on your
 patch, but I've moved database creation/deletion into setUp/tearDown
 methods and made more fine-grained tests in the test case. The entire test
 case is skipped if we aren't using psycopg2.

 I also ran into an issue with your hardcoded isolation level constants. I
 think they might've changed across psycopg2 releases, so to be safe, I
 import them from psycopg2.

 The patch series is based against trunk (at [17688]).

-- 
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] #17811: Connection object is no passed to the EmailMessage constructor when called from send_mass_mail

[Django]

#17811: Connection object is no passed to the EmailMessage constructor when 
called
from send_mass_mail
-+-
 Reporter:  fed239   |Owner:  danielr
 Type:  Bug  |   Status:  assigned
Component:  Core (Mail)  |  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:  mail, connection,| Triage Stage:  Ready for
  email  |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by danielr):

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


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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] #17707: Docs for URL namespaces should explain the motivation and use cases

[Django]

#17707: Docs for URL namespaces should explain the motivation and use cases
-+-
 Reporter:  aaugustin|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  SVN
Component:  Documentation|   Resolution:
 Severity:  Normal   |  worksforme
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Fandekasp):

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


Comment:

 I don't see any problem with the docs. Maybe you missed
 https://docs.djangoproject.com/en/dev/topics/http/urls/#defining-url-
 namespaces ?

 The ticket you're refering to is quite old (django 1.1 milestone), same
 with the questions I can find on google for "django url namespaces"
 (2009/2010).

 I guess we can close that ticket

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

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

Re: [Django] #17811: Connection object is no passed to the EmailMessage constructor when called from send_mass_mail

[Django]

#17811: Connection object is no passed to the EmailMessage constructor when 
called
from send_mass_mail
-+-
 Reporter:  fed239   |Owner:  danielr
 Type:  Bug  |   Status:  assigned
Component:  Core (Mail)  |  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:  mail, connection,| Triage Stage:  Accepted
  email  |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  1|
-+-
Changes (by danielr):

 * owner:  nobody => danielr
 * status:  new => assigned


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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] #17838: prefetch_related fails for GenericForeignKeys when related object id is not a CharField/TextField

[Django]

#17838: prefetch_related fails for GenericForeignKeys when related object id is 
not
a CharField/TextField
--+
 Reporter:  mkai  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.contenttypes  |  Version:  SVN
 Severity:  Release blocker   |   Resolution:
 Keywords:  prefetch_related  | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+
Changes (by tmitchell):

 * needs_better_patch:   => 1
 * needs_docs:   => 0
 * needs_tests:   => 0
 * stage:  Unreviewed => Accepted


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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] r17688 - in django/trunk: django/contrib/staticfiles tests/regressiontests/staticfiles_tests

[noreply]

Author: jezdez
Date: 2012-03-12 13:28:09 -0700 (Mon, 12 Mar 2012)
New Revision: 17688

Modified:
   django/trunk/django/contrib/staticfiles/storage.py
   django/trunk/tests/regressiontests/staticfiles_tests/tests.py
Log:
Fixed #17861 -- Took care of special characters when creating the staticfiles 
storage cache keys. Many thanks to Preston Holmes.

Modified: django/trunk/django/contrib/staticfiles/storage.py
===
--- django/trunk/django/contrib/staticfiles/storage.py  2012-03-12 20:14:58 UTC 
(rev 17687)
+++ django/trunk/django/contrib/staticfiles/storage.py  2012-03-12 20:28:09 UTC 
(rev 17688)
@@ -95,7 +95,7 @@
 return urlunsplit(unparsed_name)
 
 def cache_key(self, name):
-return u'staticfiles:cache:%s' % name
+return u'staticfiles:%s' % hashlib.md5(smart_str(name)).hexdigest()
 
 def url(self, name, force=False):
 """

Modified: django/trunk/tests/regressiontests/staticfiles_tests/tests.py
===
--- django/trunk/tests/regressiontests/staticfiles_tests/tests.py   
2012-03-12 20:14:58 UTC (rev 17687)
+++ django/trunk/tests/regressiontests/staticfiles_tests/tests.py   
2012-03-12 20:28:09 UTC (rev 17688)
@@ -7,10 +7,12 @@
 import shutil
 import sys
 import tempfile
+import warnings
 from StringIO import StringIO
 
 from django.template import loader, Context
 from django.conf import settings
+from django.core.cache.backends.base import BaseCache, CacheKeyWarning
 from django.core.exceptions import ImproperlyConfigured
 from django.core.files.storage import default_storage
 from django.core.management import call_command
@@ -498,6 +500,20 @@
 self.assertTrue(os.path.join('cached', 'css', 'window.css') in 
stats['post_processed'])
 self.assertTrue(os.path.join('cached', 'css', 'img', 'window.png') in 
stats['unmodified'])
 
+def test_cache_key_memcache_validation(self):
+"""
+Handle cache key creation correctly, see #17861.
+"""
+name = "/some crazy/long filename/ with spaces Here and 
?#%#$/other/stuff/some crazy/long filename/ with spaces Here and 
?#%#$/other/stuff/some crazy/long filename/ with spaces Here and 
?#%#$/other/stuff/some crazy/long filename/ with spaces Here and 
?#%#$/other/stuff/some crazy/long filename/ with spaces Here and 
?#%#$/other/stuff/some crazy/" + chr(22) + chr(180)
+cache_key = storage.staticfiles_storage.cache_key(name)
+self.save_warnings_state()
+cache_validator = BaseCache({})
+warnings.filterwarnings('error', category=CacheKeyWarning)
+cache_validator.validate_key(cache_key)
+self.restore_warnings_state()
+self.assertEqual(cache_key, 
'staticfiles:e95bbc36387084582df2a70750d7b351')
+
+
 # we set DEBUG to False here since the template tag wouldn't work otherwise
 TestCollectionCachedStorage = override_settings(**dict(TEST_SETTINGS,
 
STATICFILES_STORAGE='django.contrib.staticfiles.storage.CachedStaticFilesStorage',

-- 
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] #17861: Static files cache_key should handle spaces in filenames

[Django]

#17861: Static files cache_key should handle spaces in filenames
-+-
 Reporter:  milosu   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.staticfiles  |  Version:
 Severity:  Release blocker  |  1.4-beta-1
 Keywords:   |   Resolution:  fixed
Has patch:  1| Triage Stage:  Accepted
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by jezdez):

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


Comment:

 In [17688]:
 {{{
 #!CommitTicketReference repository="" revision="17688"
 Fixed #17861 -- Took care of special characters when creating the
 staticfiles storage cache keys. Many thanks to Preston Holmes.
 }}}

-- 
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] #17841: Clarify authentication backend documentation

[Django]

#17841: Clarify authentication backend documentation
-+-
 Reporter:  auzigog  |Owner:  lukegb
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.3
Component:  Documentation|   Resolution:
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by julien):

 * type:  Uncategorized => Cleanup/optimization
 * component:  Uncategorized => Documentation
 * stage:  Unreviewed => Ready for checkin


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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] #10498: Passing ugettext_lazy to related object's create() doesn't work

[Django]

#10498: Passing ugettext_lazy to related object's create() doesn't work
-+-
 Reporter:  mtredinnick  |Owner:  ojii
 Type:  Bug  |   Status:  reopened
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:
 Severity:  Release blocker  | Triage Stage:  Design
 Keywords:  dceu2011 |  decision needed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by ojii):

 The new patch looks good to me. Seems reasonable and djangobench reports
 it fixes the performance regression.

-- 
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] #17881: Implement BaseModelAdmin.get_raw_id_fields, similar to get_readonly_fields

[Django]

#17881: Implement BaseModelAdmin.get_raw_id_fields, similar to 
get_readonly_fields
---+--
 Reporter:  aaugustin  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  contrib.admin  |  Version:  1.4-beta-1
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  1
  Needs tests:  1  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by julien):

 * needs_docs:  0 => 1
 * needs_tests:  0 => 1
 * stage:  Unreviewed => Accepted


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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] #17885: Note password hashing incompatibility in the upgrade notes for 1.4

[Django]

#17885: Note password hashing incompatibility in the upgrade notes for 1.4
---+--
 Reporter:  ericholscher   |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Documentation  |  Version:  1.3
 Severity:  Normal |   Resolution:  fixed
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by adrian):

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


Comment:

 Fixed in #17687.

-- 
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] #17882: regressiontests.admin_filters fails with pyscopg2 when USE_TZ is False

[Django]

#17882: regressiontests.admin_filters fails with pyscopg2 when USE_TZ is False
-+-
 Reporter:  brodie   |Owner:  aaugustin
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:
 Severity:  Release blocker  | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by aaugustin):

 * has_patch:  0 => 1


Comment:

 That's a quick fix. I'm now looking at what it would take to use the
 settings_changed signal.

-- 
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] r17687 - django/trunk/docs/releases

[noreply]

Author: adrian
Date: 2012-03-12 13:14:58 -0700 (Mon, 12 Mar 2012)
New Revision: 17687

Modified:
   django/trunk/docs/releases/1.4.txt
Log:
Added note to releases/1.4.txt about contrib.auth user password hash-upgrade 
sequence. Thanks, ericholscher

Modified: django/trunk/docs/releases/1.4.txt
===
--- django/trunk/docs/releases/1.4.txt  2012-03-12 20:05:48 UTC (rev 17686)
+++ django/trunk/docs/releases/1.4.txt  2012-03-12 20:14:58 UTC (rev 17687)
@@ -777,7 +777,18 @@
   * Time period: The amount of time you expect user to take filling out
 such forms.
 
+* ``contrib.auth`` user password hash-upgrade sequence
 
+  * Consequences: Each user's password will be updated to a stronger password
+hash when it's written to the database in 1.4. This means that if you
+upgrade to 1.4 and then need to downgrade to 1.3, version 1.3 won't be able
+to read the updated passwords.
+
+  * Remedy: Set :setting:`PASSWORD_HASHERS` to use your original password
+hashing when you initially upgrade to 1.4. After you confirm your app works
+well with Django 1.4 and you won't have to roll back to 1.3, enable the new
+password hashes.
+
 django.contrib.flatpages
 
 

-- 
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] #17871: Broken: GenericInlineModelAdmin and two ForeignKey

[Django]

#17871: Broken: GenericInlineModelAdmin and two ForeignKey
---+--
 Reporter:  danny.adair@…  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  Version:  1.3
 Severity:  Normal |   Resolution:  worksforme
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--
Changes (by ramiro):

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


Comment:

 Replying to [ticket:17871 danny.adair@…]:
 > [...]
 >
 > That throws the exception
 >
 > {{{
 >  has more than 1 ForeignKey
 to 
 > }}}
 >
 > This happens in admin.validation.validate_inline() triggered by
 "admin.site.register(Whatever, !WhateverAdmin)".

 Can't reproduce this. Tested with 1.3 and trunk. I used your models
 removing the !DateField's in Action.

-- 
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] #17882: regressiontests.admin_filters fails with pyscopg2 when USE_TZ is False

[Django]

#17882: regressiontests.admin_filters fails with pyscopg2 when USE_TZ is False
-+-
 Reporter:  brodie   |Owner:  aaugustin
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:
 Severity:  Release blocker  | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by aaugustin):

 Surprisingly, this failure doesn't show up
 [http://ci.djangoproject.com/job/Django/database=postgres,python=python2.6/
 on the CI server].

 However, I can reproduce it locally. It's probably just a matter of
 closing the connection so it gets reestablished with the proper "SET TIME
 ZONE" command.

-- 
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] #17884: Distance lookups using ST_Distance_Sphere fails with PostGis 1.5.3

[Django]

#17884: Distance lookups using ST_Distance_Sphere fails with PostGis 1.5.3
-+--
 Reporter:  ogirardot@…  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  GIS  |  Version:  SVN
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by anonymous):

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


Comment:

 extracted from postgresql logs the query :

 {{{

 STATEMENT:  SELECT
 
(ST_distance_sphere("frontend_commentaddress"."geopoint",ST_GeomFromEWKB(E'\\x0101001f7931dea0670240486469f173704840'::bytea)))
 AS "distance", "frontend_commentaddress"."id",
 "frontend_commentaddress"."address_id",
 "frontend_commentaddress"."user_id",
 "frontend_commentaddress"."positive_comment",
 "frontend_commentaddress"."negative_comment",
 "frontend_commentaddress"."role_name", "frontend_commentaddress"."date",
 "frontend_commentaddress"."is_visible",
 "frontend_commentaddress"."created_at",
 "frontend_commentaddress"."modified_at",
 "frontend_commentaddress"."geopoint" FROM "frontend_commentaddress" LIMIT
 21

 }}}

-- 
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] r17686 - in django/trunk: django/contrib/auth/management/commands docs/ref docs/ref/models docs/releases docs/topics docs/topics/i18n tests/regressiontests/delete_regress

[noreply]

Author: adrian
Date: 2012-03-12 13:05:48 -0700 (Mon, 12 Mar 2012)
New Revision: 17686

Modified:
   django/trunk/django/contrib/auth/management/commands/changepassword.py
   django/trunk/django/contrib/auth/management/commands/createsuperuser.py
   django/trunk/docs/ref/django-admin.txt
   django/trunk/docs/ref/models/querysets.txt
   django/trunk/docs/releases/1.4.txt
   django/trunk/docs/topics/i18n/timezones.txt
   django/trunk/docs/topics/install.txt
   django/trunk/tests/regressiontests/delete_regress/tests.py
Log:
Edited some docs and docstrings until [17685]

Modified: django/trunk/django/contrib/auth/management/commands/changepassword.py
===
--- django/trunk/django/contrib/auth/management/commands/changepassword.py  
2012-03-12 19:41:31 UTC (rev 17685)
+++ django/trunk/django/contrib/auth/management/commands/changepassword.py  
2012-03-12 20:05:48 UTC (rev 17686)
@@ -9,8 +9,7 @@
 class Command(BaseCommand):
 option_list = BaseCommand.option_list + (
 make_option('--database', action='store', dest='database',
-default=DEFAULT_DB_ALIAS, help='Nominates a database to query for 
the user. '
-'Defaults to the "default" database.'),
+default=DEFAULT_DB_ALIAS, help='Specifies the database to use. 
Default is "default".'),
 )
 help = "Change a user's password for django.contrib.auth."
 

Modified: 
django/trunk/django/contrib/auth/management/commands/createsuperuser.py
===
--- django/trunk/django/contrib/auth/management/commands/createsuperuser.py 
2012-03-12 19:41:31 UTC (rev 17685)
+++ django/trunk/django/contrib/auth/management/commands/createsuperuser.py 
2012-03-12 20:05:48 UTC (rev 17686)
@@ -39,8 +39,7 @@
   'superusers created with --noinput will not be able to log '
   'in until they\'re given a valid password.')),
 make_option('--database', action='store', dest='database',
-default=DEFAULT_DB_ALIAS, help='Nominates a database to save the 
user to. '
-'Defaults to the "default" database.'),
+default=DEFAULT_DB_ALIAS, help='Specifies the database to use. 
Default is "default".'),
 )
 help = 'Used to create a superuser.'
 

Modified: django/trunk/docs/ref/django-admin.txt
===
--- django/trunk/docs/ref/django-admin.txt  2012-03-12 19:41:31 UTC (rev 
17685)
+++ django/trunk/docs/ref/django-admin.txt  2012-03-12 20:05:48 UTC (rev 
17686)
@@ -1199,8 +1199,8 @@
 
 .. versionadded:: 1.4
 
-The ``--database`` option can be used to specify the database to query for the
-user. If it is not supplied the ``default`` database will be used.
+Use the ``--database`` option to specify the database to query for the user. If
+it's not supplied, Django will use the ``default`` database.
 
 Example usage::
 
@@ -1234,8 +1234,8 @@
 
 .. versionadded:: 1.4
 
-The ``--database`` option can be used to specify the database into which the
-superuser object will be saved.
+Use the ``--database`` option to specify the database into which the superuser
+object will be saved.
 
 ``django.contrib.gis``
 --

Modified: django/trunk/docs/ref/models/querysets.txt
===
--- django/trunk/docs/ref/models/querysets.txt  2012-03-12 19:41:31 UTC (rev 
17685)
+++ django/trunk/docs/ref/models/querysets.txt  2012-03-12 20:05:48 UTC (rev 
17686)
@@ -1377,7 +1377,7 @@
 maximum is defined by the SQLITE_MAX_VARIABLE_NUMBER_ compilation option,
 which defaults to 999. For instance, if your model has 8 fields (including
 the primary key), you cannot create more than 999 // 8 = 124 instances at
-a time. If you exceed this limit, you will get an exception::
+a time. If you exceed this limit, you'll get an exception::
 
 django.db.utils.DatabaseError: too many SQL variables
 

Modified: django/trunk/docs/releases/1.4.txt
===
--- django/trunk/docs/releases/1.4.txt  2012-03-12 19:41:31 UTC (rev 17685)
+++ django/trunk/docs/releases/1.4.txt  2012-03-12 20:05:48 UTC (rev 17686)
@@ -617,9 +617,9 @@
 
 * A new :class:`django.test.SimpleTestCase` subclass of
   :class:`unittest.TestCase`
-  that is comparatively lighter than :class:`django.test.TestCase` and
-  company. It can be useful in testing scenarios where e.g. no database
-  interaction is needed. See :ref:`testcase_hierarchy_diagram`.
+  that's lighter than :class:`django.test.TestCase` and company. It can be
+  useful in tests that don't need to hit a database. See
+  :ref:`testcase_hierarchy_diagram`.
 
 Backwards incompatible changes in 1.4
 =

Modified: django/trunk/docs/topics/i18n/timezones.txt

[Django] #17885: Note password hashing incompatibility in the upgrade notes for 1.4

[Django]

#17885: Note password hashing incompatibility in the upgrade notes for 1.4
---+
 Reporter:  ericholscher   |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Documentation  |Version:  1.3
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  1
Easy pickings:  0  |  UI/UX:  0
---+
 https://github.com/django/django/pull/122

 Talked with Paul M about upgrading Read the Docs to 1.4, and came up with
 this caveat. The wording around how the hashes get written should probably
 be changed a bit, but just putting this here so people don't forget.

-- 
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] #17884: Distance lookups using ST_Distance_Sphere fails with PostGis 1.5.3

[Django]

#17884: Distance lookups using ST_Distance_Sphere fails with PostGis 1.5.3
-+
 Reporter:  ogirardot@…  |  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  GIS  |Version:  SVN
 Severity:  Release blocker  |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 Hi,
 i've worked a lot to make this work, and i just can't figure it out right
 now, so i'm opening a ticket. This is related to #16778 and my point of
 view right now is that it's a problem about how the EWKB Binary object
 gets created.
 My problem is that, i've CommentAddress objects with PointField
 (srid=4326) and an Address with a PointField (srid=4326 too), i do a
 simple distance lookup request :

 CommentAddress.objects.distance(Address.objects.get(pk=).geopoint)

 And it fails with :
   File ".../django/db/backends/postgresql_psycopg2/base.py", line 53, in
 execute
 return self.cursor.execute(query, args)
 DatabaseError: geometry_distance_spheroid: Operation on two GEOMETRIES
 with different SRIDs

 But both are the proper srids, the problem is that the query that gets
 created is :


  select St_Distance_Sphere(geopoint,
 ST_GeomFromEWKB('\x0101001f7932dea0670240486469f173704840'::bytea))
 from frontend_commentaddress;

 But when i do myself the ST_AsEWKB on the same precise object i get a very
 different EWKB and the query - works :

 select St_Distance_Sphere(geopoint, ST_GeomFromEWKB('\001\001\000\000
 \346\020\000\000\037y1\336\240g\002@Hdi\361spH@'::bytea)) from
 frontend_commentaddress;

 I tried to use self._adapter.adapted (which looks really better with a H@
 at the end) instead of self._adapter.getquoted() into the postgis adapter
 but it doesn't work as it's unicode translated into bytes... Anyway i'm
 missing something there and can't get it working.

 This is a real blocker, and it seems that this is crashing my local
 runserver (no stacktrace no log, just crashed).
 Thank you for your help.

 Here are my versions and what i tried :
 Python 2.7.1
 Django 1.4 trunk (as of today)
 "POSTGIS="1.5.3" GEOS="3.3.2-CAPI-1.7.2" PROJ="Rel. 4.7.1, 23 September
 2009" LIBXML="2.7.3" USE_STATS (procs from 1.5 r5976 need upgrade)"
 "PostgreSQL 9.1.3 on x86_64-apple-darwin10.8.0, compiled by i686-apple-
 darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5664), 64-bit"
 both installed with homebrew. (on mac os lion)

-- 
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] #17880: "post_save" signal should not be emitted when using manage.py "loaddata"

[Django]

#17880: "post_save" signal should not be emitted when using manage.py "loaddata"
-+-
 Reporter:  danielfeng   |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Uncategorized|  Version:  1.3
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  loaddata,| Triage Stage:
  post_save, signal, management  |  Unreviewed
  commands   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by danielfeng):

 Great, thanks for the links. The "raw" argument check works.

-- 
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] #17861: Static files cache_key should handle spaces in filenames

[Django]

#17861: Static files cache_key should handle spaces in filenames
-+-
 Reporter:  milosu   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.staticfiles  |  Version:
 Severity:  Release blocker  |  1.4-beta-1
 Keywords:   |   Resolution:
Has patch:  1| Triage Stage:  Accepted
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by ptone):

 * has_patch:  0 => 1


Comment:

 After talking with jezdez at the sprints - determined most straightforward
 fix is the md5 that path

 https://github.com/django/django/pull/123

-- 
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] #17883: Better Error messages for 1.2 deprecations

[Django]

#17883: Better Error messages for 1.2 deprecations
-+--
 Reporter:  PaulM|Owner:  jezdez
 Type:  Bug  |   Status:  new
Component:  Core (Other) |  Version:  1.4-beta-1
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by PaulM):

 * version:  1.3 => 1.4-beta-1
 * component:  Uncategorized => Core (Other)


-- 
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] #17883: Better Error messages for 1.2 deprecations

[Django]

#17883: Better Error messages for 1.2 deprecations
---+
   Reporter:  PaulM|  Owner:  jezdez
   Type:  Bug  | Status:  new
  Component:  Uncategorized|Version:  1.3
   Severity:  Release blocker  |   Keywords:
   Triage Stage:  Accepted |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+
 As we move to 1.4 and change the required settings file format
 significantly, we need to provide better error messages for deprecated
 methods we've actually removed. In particular, both the database and cache
 settings provide opaque "backend not found" when a settings file uses the
 old style settings. This is incredibly frustrating to people who are not
 deeply familiar with Django settings files, or who didn't read the release
 notes for 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] #17882: regressiontests.admin_filters fails with pyscopg2 when USE_TZ is False

[Django]

#17882: regressiontests.admin_filters fails with pyscopg2 when USE_TZ is False
-+-
 Reporter:  brodie   |Owner:  aaugustin
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:
 Severity:  Release blocker  | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by aaugustin):

 * owner:  nobody => aaugustin


-- 
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] #17882: regressiontests.admin_filters fails with pyscopg2 when USE_TZ is False

[Django]

#17882: regressiontests.admin_filters fails with pyscopg2 when USE_TZ is False
-+-
 Reporter:  brodie   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:
 Severity:  Release blocker  | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by julien):

 This problem occurs after the changes in [17670].

-- 
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] #17882: regressiontests.admin_filters fails with pyscopg2 when USE_TZ is False

[Django]

#17882: regressiontests.admin_filters fails with pyscopg2 when USE_TZ is False
-+-
 Reporter:  brodie   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:
 Severity:  Release blocker  | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by jezdez):

 * needs_better_patch:   => 0
 * stage:  Unreviewed => Accepted
 * severity:  Normal => Release blocker
 * 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.

[Changeset] r17685 - in django/trunk: . django/core/serializers tests/regressiontests/serializers_regress

[noreply]

Author: kmtracey
Date: 2012-03-12 12:41:31 -0700 (Mon, 12 Mar 2012)
New Revision: 17685

Modified:
   django/trunk/AUTHORS
   django/trunk/django/core/serializers/python.py
   django/trunk/tests/regressiontests/serializers_regress/models.py
   django/trunk/tests/regressiontests/serializers_regress/tests.py
Log:
Fix #17879: Corrected regression in python (inherited by yaml and json) 
serializer that prevented serializing model instances with null FK ref to a 
model when serializing with natural keys. Thanks danfairs and tmitchell.


Modified: django/trunk/AUTHORS
===
--- django/trunk/AUTHORS2012-03-12 18:51:48 UTC (rev 17684)
+++ django/trunk/AUTHORS2012-03-12 19:41:31 UTC (rev 17685)
@@ -369,6 +369,7 @@
 Slawek Mikula 
 Shawn Milochik 
 mitakum...@gmail.com
+Taylor Mitchell 
 mmarshall
 Andreas Mock 
 Reza Mohammadi 

Modified: django/trunk/django/core/serializers/python.py
===
--- django/trunk/django/core/serializers/python.py  2012-03-12 18:51:48 UTC 
(rev 17684)
+++ django/trunk/django/core/serializers/python.py  2012-03-12 19:41:31 UTC 
(rev 17685)
@@ -47,7 +47,10 @@
 def handle_fk_field(self, obj, field):
 if self.use_natural_keys and hasattr(field.rel.to, 'natural_key'):
 related = getattr(obj, field.name)
-value = related.natural_key()
+if related:
+value = related.natural_key()
+else:
+value = None
 else:
 value = getattr(obj, field.get_attname())
 self._current[field.name] = value

Modified: django/trunk/tests/regressiontests/serializers_regress/models.py
===
--- django/trunk/tests/regressiontests/serializers_regress/models.py
2012-03-12 18:51:48 UTC (rev 17684)
+++ django/trunk/tests/regressiontests/serializers_regress/models.py
2012-03-12 19:41:31 UTC (rev 17685)
@@ -111,6 +111,18 @@
 class Meta:
 ordering = ('id',)
 
+class NaturalKeyAnchorManager(models.Manager):
+def get_by_natural_key(self, data):
+return self.get(data=data)
+
+class NaturalKeyAnchor(models.Model):
+objects = NaturalKeyAnchorManager()
+
+data = models.CharField(max_length=100, unique=True)
+
+def natural_key(self):
+return (self.data,)
+
 class UniqueAnchor(models.Model):
 """This is a model that can be used as
 something for other models to point at"""
@@ -120,6 +132,9 @@
 class FKData(models.Model):
 data = models.ForeignKey(Anchor, null=True)
 
+class FKDataNaturalKey(models.Model):
+data = models.ForeignKey(NaturalKeyAnchor, null=True)
+
 class M2MData(models.Model):
 data = models.ManyToManyField(Anchor, null=True)
 
@@ -272,3 +287,4 @@
 
 def __len__(self):
 return self.data
+

Modified: django/trunk/tests/regressiontests/serializers_regress/tests.py
===
--- django/trunk/tests/regressiontests/serializers_regress/tests.py 
2012-03-12 18:51:48 UTC (rev 17684)
+++ django/trunk/tests/regressiontests/serializers_regress/tests.py 
2012-03-12 19:41:31 UTC (rev 17685)
@@ -42,7 +42,8 @@
 PositiveSmallIntegerPKData, SlugPKData, SmallPKData, USStatePKData,
 AutoNowDateTimeData, ModifyingSaveData, InheritAbstractModel, BaseModel,
 ExplicitInheritBaseModel, InheritBaseModel, ProxyBaseModel,
-ProxyProxyBaseModel, BigIntegerData, LengthModel, Tag, ComplexModel)
+ProxyProxyBaseModel, BigIntegerData, LengthModel, Tag, ComplexModel,
+NaturalKeyAnchor, FKDataNaturalKey)
 
 # A set of functions that can be used to recreate
 # test data objects of various kinds.
@@ -353,6 +354,12 @@
 (data_obj, 1005, LengthModel, 1),
 ]
 
+natural_key_test_data = [
+(data_obj, 1100, NaturalKeyAnchor, "Natural Key Anghor"),
+(fk_obj, 1101, FKDataNaturalKey, 1100),
+(fk_obj, 1102, FKDataNaturalKey, None),
+]
+
 # Because Oracle treats the empty string as NULL, Oracle is expected to fail
 # when field.empty_strings_allowed is True and the value is None; skip these
 # tests.
@@ -452,6 +459,35 @@
 for klass, count in instance_count.items():
 self.assertEqual(count, klass.objects.count())
 
+def naturalKeySerializerTest(format, self):
+# Create all the objects defined in the test data
+objects = []
+instance_count = {}
+for (func, pk, klass, datum) in natural_key_test_data:
+with connection.constraint_checks_disabled():
+objects.extend(func[0](pk, klass, datum))
+
+# Get a count of the number of objects created for each class
+for klass in instance_count:
+instance_count[klass] = klass.objects.count()
+
+# Serialize the test database
+serialized_data =