Re: [Django] #15164: Filtering queryset via ForeignKey to legacy model with OneToOneField as primary doesn't evaluate primary key

[Django]

#15164: Filtering queryset via ForeignKey to legacy model with OneToOneField as
primary doesn't evaluate primary key
---+
  Reporter:  GDorn | Owner:  nobody
Status:  closed| Milestone:
 Component:  Database layer (models, ORM)  |   Version:  1.2   
Resolution:  worksforme|  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by carljm):

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

Comment:

 Using the provided models and queries, I can't replicate this problem in
 either trunk or 1.2, on SQLite, MySQL, or Postgres. The first query (by
 my_user) generates the correct SQL for me in every case.

 Thanks for the report. Please reopen if you can demonstrate the problem as
 a patch against Django's own test suite with a failing test case, or in a
 brand-new simplest-case project running on Django trunk.

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

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

Re: [Django] #13224: style of m2m readonly_fields in admin change_form

[Django]

#13224: style of m2m readonly_fields in admin change_form
-+--
  Reporter:  benc| Owner:   
  
Status:  new | Milestone:   
  
 Component:  User Experience |   Version:  1.2-beta 
  
Resolution:  |  Keywords:  admin, 
readonly_fields, m2m
 Stage:  Design decision needed  | Has_patch:  0
  
Needs_docs:  0   |   Needs_tests:  0
  
Needs_better_patch:  0   |  
-+--
Changes (by julien):

  * milestone:  1.3 =>

Comment:

 This would be a nice feature but it is too late now for 1.3.

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

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

Re: [Django] #12534: django.contrib.auth.views.login refuses to redirect to urls with spaces

[Django]

#12534: django.contrib.auth.views.login refuses to redirect to urls with spaces
-+--
  Reporter:  sharky  | Owner:  nobody
Status:  reopened| Milestone:  1.3   
 Component:  Authentication  |   Version:  1.1   
Resolution:  |  Keywords:
 Stage:  Accepted| Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Comment (by sontek):

 I looked in the history and it has been that way as long as Django has
 been public, I don't think there is any true security reason for having
 that check.

-- 
Ticket URL: 
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] #15130: Model.validate_unique method doesn't take in account multi-db

[Django]

#15130: Model.validate_unique method doesn't take in account multi-db
--+-
  Reporter:  t2y  | Owner:  
Status:  reopened | Milestone:  1.3 
 Component:  ORM aggregation  |   Version:  1.2 
Resolution:   |  Keywords:  multi-db
 Stage:  Accepted | Has_patch:  1   
Needs_docs:  0|   Needs_tests:  0   
Needs_better_patch:  0|  
--+-
Comment (by t2y):

 Replying to [comment:9 ramiro]:

 I tested my application(AdminSite) which found this problem originally
 after it applied Alex's patch. It's OK. Thank you Alex.

-- 
Ticket URL: 
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] #13756: File upload not working under Tomcat

[Django]

#13756: File upload not working under Tomcat
+---
  Reporter:  SvenKlemm  | Owner:  nobody
Status:  new| Milestone:
 Component:  HTTP handling  |   Version:  1.2   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by Jeff250):

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

Comment:

 It looks like Jython/modjy in
 
[http://jython.svn.sourceforge.net/viewvc/jython/trunk/jython/Lib/modjy/modjy_wsgi.py?revision=7022=markup
 modjy_wsgi.py] is calling
 
[http://download.oracle.com/javaee/5/api/javax/servlet/ServletRequest.html#getInputStream%28%29
 ServletRequest.getInputStream()] and thinly wrapping it with a Python
 file-like object before passing it to Django as environ!['wsgi.input'].
 The problem is that
 
[http://download.oracle.com/javase/1.5.0/docs/api/java/io/InputStream.html#read%28byte%5B%5D%29
 InputStream.read(...)] has the semantics that, if given a `length` and if
 there are no exceptional conditions or EOF, then it will fill anywhere
 ''between'' 1 and `length` many bytes inclusive before unblocking and
 returning, whereas django is expecting it to block until ''exactly''
 `length` many bytes are returned.

 This explains why the patch works, but it's not clear to me if the bug is
 actually in Jython/modjy or in Django?  Does WSGI require you to pass in a
 'wsgi.input' file object that blocks on reads until a buffer of
 ''exactly'' the requested length is returned?

-- 
Ticket URL: 
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] #14303: admin inline form id attribute numbering order and uniqueness is lost

[Django]

#14303: admin inline form id attribute numbering order and uniqueness is lost
---+
  Reporter:  m0nonoke  | Owner:  nobody 
 
Status:  new   | Milestone:  1.3
 
 Component:  django.contrib.admin  |   Version:  SVN
 
Resolution:|  Keywords:  inline javascript, 
sprintdec2010
 Stage:  Accepted  | Has_patch:  1  
 
Needs_docs:  0 |   Needs_tests:  0  
 
Needs_better_patch:  0 |  
---+
Comment (by julien):

 See #13674 for a related (but different) bug.

-- 
Ticket URL: 
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] #13674: Javascript for adding inline fields doesn't update "for" attribute in label

[Django]

#13674: Javascript for adding inline fields doesn't update "for" attribute in 
label
---+
  Reporter:  Jonas | Owner:  rctay
Status:  new   | Milestone:  1.3  
 Component:  django.contrib.admin  |   Version:  1.2  
Resolution:|  Keywords:  admin
 Stage:  Ready for checkin | Has_patch:  1
Needs_docs:  0 |   Needs_tests:  0
Needs_better_patch:  0 |  
---+
Changes (by julien):

  * stage:  Accepted => Ready for checkin

Comment:

 The patch applies and fixes this bug. See also #14303 for a related (but
 different) bug.

-- 
Ticket URL: 
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] r15320 - in django/branches/releases/1.2.X: django/db/models tests/modeltests/model_inheritance

[noreply]

Author: Alex
Date: 2011-01-25 21:52:52 -0600 (Tue, 25 Jan 2011)
New Revision: 15320

Modified:
   django/branches/releases/1.2.X/django/db/models/base.py
   django/branches/releases/1.2.X/tests/modeltests/model_inheritance/models.py
   django/branches/releases/1.2.X/tests/modeltests/model_inheritance/tests.py
Log:
[1.2.X] Fixed #13206 -- call super().__init__() in Model.__init__ to allow 
mixins to do things there.  Backport of [15317].

Modified: django/branches/releases/1.2.X/django/db/models/base.py
===
--- django/branches/releases/1.2.X/django/db/models/base.py 2011-01-26 
03:52:41 UTC (rev 15319)
+++ django/branches/releases/1.2.X/django/db/models/base.py 2011-01-26 
03:52:52 UTC (rev 15320)
@@ -1,6 +1,7 @@
 import types
 import sys
 from itertools import izip
+
 import django.db.models.manager # Imported to register signal handler.
 from django.core.exceptions import ObjectDoesNotExist, 
MultipleObjectsReturned, FieldError, ValidationError, NON_FIELD_ERRORS
 from django.core import validators
@@ -359,6 +360,7 @@
 pass
 if kwargs:
 raise TypeError("'%s' is an invalid keyword argument for this 
function" % kwargs.keys()[0])
+super(Model, self).__init__()
 signals.post_init.send(sender=self.__class__, instance=self)
 
 def __repr__(self):

Modified: 
django/branches/releases/1.2.X/tests/modeltests/model_inheritance/models.py
===
--- django/branches/releases/1.2.X/tests/modeltests/model_inheritance/models.py 
2011-01-26 03:52:41 UTC (rev 15319)
+++ django/branches/releases/1.2.X/tests/modeltests/model_inheritance/models.py 
2011-01-26 03:52:52 UTC (rev 15320)
@@ -143,3 +143,11 @@
 
 def __unicode__(self):
 return self.content
+
+class Mixin(object):
+def __init__(self):
+self.other_attr = 1
+super(Mixin, self).__init__()
+
+class MixinModel(models.Model, Mixin):
+pass

Modified: 
django/branches/releases/1.2.X/tests/modeltests/model_inheritance/tests.py
===
--- django/branches/releases/1.2.X/tests/modeltests/model_inheritance/tests.py  
2011-01-26 03:52:41 UTC (rev 15319)
+++ django/branches/releases/1.2.X/tests/modeltests/model_inheritance/tests.py  
2011-01-26 03:52:52 UTC (rev 15320)
@@ -6,7 +6,7 @@
 from django.test import TestCase
 
 from models import (Chef, CommonInfo, ItalianRestaurant, ParkingLot, Place,
-Post, Restaurant, Student, StudentWorker, Supplier, Worker)
+Post, Restaurant, Student, StudentWorker, Supplier, Worker, MixinModel)
 
 
 class ModelInheritanceTests(TestCase):
@@ -278,4 +278,6 @@
 finally:
 settings.DEBUG = old_DEBUG
 
-
+def test_mixin_init(self):
+m = MixinModel()
+self.assertEqual(m.other_attr, 1)

-- 
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] r15319 - in django/branches/releases/1.2.X: django/db/models/sql tests/regressiontests/aggregation_regress

[noreply]

Author: Alex
Date: 2011-01-25 21:52:41 -0600 (Tue, 25 Jan 2011)
New Revision: 15319

Modified:
   django/branches/releases/1.2.X/django/db/models/sql/compiler.py
   
django/branches/releases/1.2.X/tests/regressiontests/aggregation_regress/tests.py
Log:
[1.2.X] Fixed #13159 -- properly quote aggregates in order_by.  Backport of 
[15318].

Modified: django/branches/releases/1.2.X/django/db/models/sql/compiler.py
===
--- django/branches/releases/1.2.X/django/db/models/sql/compiler.py 
2011-01-26 03:48:15 UTC (rev 15318)
+++ django/branches/releases/1.2.X/django/db/models/sql/compiler.py 
2011-01-26 03:52:41 UTC (rev 15319)
@@ -327,7 +327,7 @@
 continue
 col, order = get_order_dir(field, asc)
 if col in self.query.aggregate_select:
-result.append('%s %s' % (col, order))
+result.append('%s %s' % (qn(col), order))
 continue
 if '.' in field:
 # This came in through an extra(order_by=...) addition. Pass it

Modified: 
django/branches/releases/1.2.X/tests/regressiontests/aggregation_regress/tests.py
===
--- 
django/branches/releases/1.2.X/tests/regressiontests/aggregation_regress/tests.py
   2011-01-26 03:48:15 UTC (rev 15318)
+++ 
django/branches/releases/1.2.X/tests/regressiontests/aggregation_regress/tests.py
   2011-01-26 03:52:41 UTC (rev 15319)
@@ -768,6 +768,18 @@
 attrgetter("name")
 )
 
+def test_quoting_aggregate_order_by(self):
+qs = Book.objects.filter(
+name="Python Web Development with Django"
+).annotate(
+authorCount=Count("authors")
+).order_by("authorCount")
+self.assertQuerysetEqual(
+qs, [
+("Python Web Development with Django", 3),
+],
+lambda b: (b.name, b.authorCount)
+)
 
 if run_stddev_tests():
 def test_stddev(self):

-- 
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] #897: Bi-Directional ManyToMany in Admin

[Django]

#897: Bi-Directional ManyToMany in Admin
---+
  Reporter:  anonymous | Owner:  nobody
Status:  new   | Milestone:
 Component:  django.contrib.admin  |   Version:
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by anonymous):

 Replying to [comment:21 anonymous]:
 > Replying to [comment:17 ericholscher]:
 > > Just ran into this bug as well. I'll probably take a stab at fixing it
 in the next couple of days, as it is rather annoying. Though I'm curious
 if it might break expectations of people in existing setups.
 >
 > To fix it for 1.2, all needed is to change:
 >
 > {{{
 > self.creates_table = False
 > }}}
 >

 Forget this solution, it doesn't work. Sorry for the noise.
 > to:
 >
 > {{{
 > self.auto_created = False
 > }}}

-- 
Ticket URL: 
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] r15318 - in django/trunk: django/db/models/sql tests/regressiontests/aggregation_regress

[noreply]

Author: Alex
Date: 2011-01-25 21:48:15 -0600 (Tue, 25 Jan 2011)
New Revision: 15318

Modified:
   django/trunk/django/db/models/sql/compiler.py
   django/trunk/tests/regressiontests/aggregation_regress/tests.py
Log:
Fixed #13159 -- properly quote aggregates in order_by.

Modified: django/trunk/django/db/models/sql/compiler.py
===
--- django/trunk/django/db/models/sql/compiler.py   2011-01-26 03:42:31 UTC 
(rev 15317)
+++ django/trunk/django/db/models/sql/compiler.py   2011-01-26 03:48:15 UTC 
(rev 15318)
@@ -330,7 +330,7 @@
 continue
 col, order = get_order_dir(field, asc)
 if col in self.query.aggregate_select:
-result.append('%s %s' % (col, order))
+result.append('%s %s' % (qn(col), order))
 continue
 if '.' in field:
 # This came in through an extra(order_by=...) addition. Pass it

Modified: django/trunk/tests/regressiontests/aggregation_regress/tests.py
===
--- django/trunk/tests/regressiontests/aggregation_regress/tests.py 
2011-01-26 03:42:31 UTC (rev 15317)
+++ django/trunk/tests/regressiontests/aggregation_regress/tests.py 
2011-01-26 03:48:15 UTC (rev 15318)
@@ -747,6 +747,19 @@
 attrgetter("name")
 )
 
+def test_quoting_aggregate_order_by(self):
+qs = Book.objects.filter(
+name="Python Web Development with Django"
+).annotate(
+authorCount=Count("authors")
+).order_by("authorCount")
+self.assertQuerysetEqual(
+qs, [
+("Python Web Development with Django", 3),
+],
+lambda b: (b.name, b.authorCount)
+)
+
 @skipUnlessDBFeature('supports_stddev')
 def test_stddev(self):
 self.assertEqual(

-- 
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] #15159: createsuperuser can't be interrupted or suspended

[Django]

#15159: createsuperuser can't be interrupted or suspended
--+-
  Reporter:  slinkp   | Owner:  nobody
Status:  new  | Milestone:
 Component:  django-admin.py  |   Version:  1.2   
Resolution:   |  Keywords:
 Stage:  Unreviewed   | Has_patch:  0 
Needs_docs:  0|   Needs_tests:  0 
Needs_better_patch:  0|  
--+-
Changes (by sontek):

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

Comment:

 You can use Ctrl+d to interrupt this prompt. Ctrl+d sends EOF. This is the
 only way to interrupt it since the special way getpass has to modify the
 terminal to disable echo. This isn't a bug.

-- 
Ticket URL: 
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] r15317 - in django/trunk: django/db/models tests/modeltests/model_inheritance

[noreply]

Author: Alex
Date: 2011-01-25 21:42:31 -0600 (Tue, 25 Jan 2011)
New Revision: 15317

Modified:
   django/trunk/django/db/models/base.py
   django/trunk/tests/modeltests/model_inheritance/models.py
   django/trunk/tests/modeltests/model_inheritance/tests.py
Log:
Fixed #13206 -- call super().__init__() in Model.__init__ to allow mixins to do 
things there.

Modified: django/trunk/django/db/models/base.py
===
--- django/trunk/django/db/models/base.py   2011-01-26 03:34:16 UTC (rev 
15316)
+++ django/trunk/django/db/models/base.py   2011-01-26 03:42:31 UTC (rev 
15317)
@@ -1,6 +1,7 @@
 import types
 import sys
 from itertools import izip
+
 import django.db.models.manager # Imported to register signal handler.
 from django.core.exceptions import ObjectDoesNotExist, 
MultipleObjectsReturned, FieldError, ValidationError, NON_FIELD_ERRORS
 from django.core import validators
@@ -361,6 +362,7 @@
 pass
 if kwargs:
 raise TypeError("'%s' is an invalid keyword argument for this 
function" % kwargs.keys()[0])
+super(Model, self).__init__()
 signals.post_init.send(sender=self.__class__, instance=self)
 
 def __repr__(self):

Modified: django/trunk/tests/modeltests/model_inheritance/models.py
===
--- django/trunk/tests/modeltests/model_inheritance/models.py   2011-01-26 
03:34:16 UTC (rev 15316)
+++ django/trunk/tests/modeltests/model_inheritance/models.py   2011-01-26 
03:42:31 UTC (rev 15317)
@@ -143,3 +143,11 @@
 
 def __unicode__(self):
 return self.content
+
+class Mixin(object):
+def __init__(self):
+self.other_attr = 1
+super(Mixin, self).__init__()
+
+class MixinModel(models.Model, Mixin):
+pass

Modified: django/trunk/tests/modeltests/model_inheritance/tests.py
===
--- django/trunk/tests/modeltests/model_inheritance/tests.py2011-01-26 
03:34:16 UTC (rev 15316)
+++ django/trunk/tests/modeltests/model_inheritance/tests.py2011-01-26 
03:42:31 UTC (rev 15317)
@@ -4,7 +4,7 @@
 from django.test import TestCase
 
 from models import (Chef, CommonInfo, ItalianRestaurant, ParkingLot, Place,
-Post, Restaurant, Student, StudentWorker, Supplier, Worker)
+Post, Restaurant, Student, StudentWorker, Supplier, Worker, MixinModel)
 
 
 class ModelInheritanceTests(TestCase):
@@ -269,3 +269,7 @@
 self.assertNumQueries(1,
 lambda: ItalianRestaurant.objects.select_related("chef")[0].chef
 )
+
+def test_mixin_init(self):
+m = MixinModel()
+self.assertEqual(m.other_attr, 1)

-- 
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] r15316 - django/trunk/django/template

[noreply]

Author: Alex
Date: 2011-01-25 21:34:16 -0600 (Tue, 25 Jan 2011)
New Revision: 15316

Modified:
   django/trunk/django/template/defaultfilters.py
Log:
Fixed #13828 -- DRY'd up the dictsort(reversed) filters, will speed them up as 
well.

Modified: django/trunk/django/template/defaultfilters.py
===
--- django/trunk/django/template/defaultfilters.py  2011-01-26 03:23:59 UTC 
(rev 15315)
+++ django/trunk/django/template/defaultfilters.py  2011-01-26 03:34:16 UTC 
(rev 15316)
@@ -460,10 +460,7 @@
 Takes a list of dicts, returns that list sorted by the property given in
 the argument.
 """
-var_resolve = Variable(arg).resolve
-decorated = [(var_resolve(item), item) for item in value]
-decorated.sort()
-return [item[1] for item in decorated]
+return sorted(value, key=Variable(arg).resolve)
 dictsort.is_safe = False
 
 def dictsortreversed(value, arg):
@@ -471,11 +468,7 @@
 Takes a list of dicts, returns that list sorted in reverse order by the
 property given in the argument.
 """
-var_resolve = Variable(arg).resolve
-decorated = [(var_resolve(item), item) for item in value]
-decorated.sort()
-decorated.reverse()
-return [item[1] for item in decorated]
+return sorted(value, key=Variable(arg).resolve, reverse=True)
 dictsortreversed.is_safe = False
 
 def first(value):

-- 
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] #13875: cannot customize admin submit_row

[Django]

#13875: cannot customize admin submit_row
---+
  Reporter:  drul  | Owner:  nobody
Status:  new   | Milestone:
 Component:  django.contrib.admin  |   Version:  1.2   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by julien):

  * milestone:  1.3 =>

Comment:

 This is technically a new feature and therefore I'm removing the 1.3
 milestone since we're in beta stage right now. Passing the whole context
 to the template is a good thing, however the general context should not be
 modified with the `{% submit_row %}`'s specific variables (as done in
 drul's patch). Instead a disposable specific new context should be passed
 through (as done in my suggested patch).

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

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

Re: [Django] #14955: URLField validation should use HEAD requet instead of GET

[Django]

#14955: URLField validation should use HEAD requet instead of GET
-+--
  Reporter:  claudep | Owner: 
Status:  new | Milestone:  1.3
 Component:  Core framework  |   Version:  SVN
Resolution:  |  Keywords: 
 Stage:  Accepted| Has_patch:  1  
Needs_docs:  0   |   Needs_tests:  0  
Needs_better_patch:  0   |  
-+--
Comment (by Alex):

 Class should not be created inside the method; classes are some of the
 most expensive (memorywise) objects in CPython, and can be slow to gc.

-- 
Ticket URL: 
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] #897: Bi-Directional ManyToMany in Admin

[Django]

#897: Bi-Directional ManyToMany in Admin
---+
  Reporter:  anonymous | Owner:  nobody
Status:  new   | Milestone:
 Component:  django.contrib.admin  |   Version:
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by anonymous):

 Replying to [comment:17 ericholscher]:
 > Just ran into this bug as well. I'll probably take a stab at fixing it
 in the next couple of days, as it is rather annoying. Though I'm curious
 if it might break expectations of people in existing setups.

 To fix it for 1.2, all needed is to change:

 {{{
 self.creates_table = False
 }}}

 to:

 {{{
 self.auto_created = False
 }}}

-- 
Ticket URL: 
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] r15315 - django/trunk/django/views/generic

[noreply]

Author: Alex
Date: 2011-01-25 21:23:59 -0600 (Tue, 25 Jan 2011)
New Revision: 15315

Modified:
   django/trunk/django/views/generic/dates.py
Log:
Fixed #15052 -- corrected an innacurate docstring in the generic views.

Modified: django/trunk/django/views/generic/dates.py
===
--- django/trunk/django/views/generic/dates.py  2011-01-26 03:22:16 UTC (rev 
15314)
+++ django/trunk/django/views/generic/dates.py  2011-01-26 03:23:59 UTC (rev 
15315)
@@ -80,8 +80,8 @@
 
 def get_day_format(self):
 """
-Get a month format string in strptime syntax to be used to parse the
-month from url variables.
+Get a day format string in strptime syntax to be used to parse the day
+from url variables.
 """
 return self.day_format
 

-- 
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] r15314 - django/trunk/django/conf/app_template

[noreply]

Author: Alex
Date: 2011-01-25 21:22:16 -0600 (Tue, 25 Jan 2011)
New Revision: 15314

Modified:
   django/trunk/django/conf/app_template/tests.py
Log:
Fixed #15154 -- removed doctests from the tests.py generated with createapp.

Modified: django/trunk/django/conf/app_template/tests.py
===
--- django/trunk/django/conf/app_template/tests.py  2011-01-26 00:58:41 UTC 
(rev 15313)
+++ django/trunk/django/conf/app_template/tests.py  2011-01-26 03:22:16 UTC 
(rev 15314)
@@ -1,23 +1,16 @@
 """
-This file demonstrates two different styles of tests (one doctest and one
-unittest). These will both pass when you run "manage.py test".
+This file demonstrates writing tests using the unittest module. These will pass
+when you run "manage.py test".
 
-Replace these with more appropriate tests for your application.
+Replace this with more appropriate tests for your application.
 """
 
 from django.test import TestCase
 
+
 class SimpleTest(TestCase):
 def test_basic_addition(self):
 """
 Tests that 1 + 1 always equals 2.
 """
-self.failUnlessEqual(1 + 1, 2)
-
-__test__ = {"doctest": """
-Another way to test that 1 + 1 is equal to 2.
-
->>> 1 + 1 == 2
-True
-"""}
-
+self.assertEqual(1 + 1, 2)

-- 
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] #12464: Empty PATH_INFO causes blank SCRIPT_NAME

[Django]

#12464: Empty PATH_INFO causes blank SCRIPT_NAME
+---
  Reporter:  chrisw | Owner:  wogan
Status:  assigned   | Milestone:  1.3  
 Component:  HTTP handling  |   Version:  SVN  
Resolution: |  Keywords:   
 Stage:  Accepted   | Has_patch:  1
Needs_docs:  0  |   Needs_tests:  0
Needs_better_patch:  0  |  
+---
Changes (by grahamd):

 * cc: graham.dumple...@gmail.com (added)

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

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

Re: [Django] #12464: Empty PATH_INFO causes blank SCRIPT_NAME

[Django]

#12464: Empty PATH_INFO causes blank SCRIPT_NAME
+---
  Reporter:  chrisw | Owner:  wogan
Status:  assigned   | Milestone:  1.3  
 Component:  HTTP handling  |   Version:  SVN  
Resolution: |  Keywords:   
 Stage:  Accepted   | Has_patch:  1
Needs_docs:  0  |   Needs_tests:  0
Needs_better_patch:  0  |  
+---
Comment (by grahamd):

 The code as it is technically will also only work if there is at most one
 internal redirect undertaken within Apache. In the case where there is
 more than one, Apache will prefix environment variables with 'REDIRECT_'
 at each iteration. This is where 'REDIRECT_SCRIPT_URL' comes from that
 mod_rewrite code internally checks for. Thus a robust implementation, to
 get hold of the very original URL should find the variant of SCRIPT_URL
 with the longest sequence of 'REDIRECT_' prefixes. Ie.,
 'REDIRECT_REDIRECT_SCRIPT_URL' takes precedence over 'REDIRECT_SCRIPT_URL'
 takes precedence of 'SCRIPT_URL'.

 A further case which presents a problem and where the code may not work is
 when an internal redirect is performed, it is possible that PATH_INFO from
 the parent isn't simply passed through but is modified in the process.
 This could result in the final PATH_INFO not even matching what is present
 in tail of 'SCRIPT_URL' and so simply dropping off 'SCRIPT_URL' the number
 of characters present in 'PATH_INFO' may give incorrect results.

 Take for example the convoluted example:

 {{{
 WSGIScriptAlias /myapp
 /Library/WebServer/Sites/hello-1/htdocs/environ.wsgi

 RewriteEngine On
 RewriteRule ^/welcome(/.*)$ /myapp/about/$1 [QSA,PT,L]
 }}}

 The variables which go through to the app are:

 {{{
 PATH_INFO: '/about/index'
 QUERY_STRING: ''
 REQUEST_URI: '/welcome/index'
 SCRIPT_FILENAME: '/Library/WebServer/Sites/hello-1/htdocs/environ.wsgi'
 SCRIPT_NAME: '/myapp'
 SCRIPT_URI: 'http://hello-1.example.com/welcome/index'
 SCRIPT_URL: '/welcome/index'
 }}}

 For code:

 {{{
 script_url = environ.get('SCRIPT_URL', u'')
 if not script_url:
 script_url = environ.get('REDIRECT_URL', u'')
 if script_url:
 return force_unicode(script_url[:-len(environ.get('PATH_INFO',
 ''))])
 }}}

 Pass this through the current algorithm and you get:

 {{{
 >>> '/welcome/index'[:-len('/about/index')]
 '/w'
 }}}

 which isn't right.

 It is because of this latter issue that mod_wsgi hasn't in the past tried
 to do fixups to SCRIPT_NAME on internal redirects in Apache, as it can't
 know exactly what the nature of any URL manipulations are. This is why
 manual fixups in the WSGi script file have been suggested, where people
 can tailor it the specifics of the sort of redirect performed. Thus any
 automatic fixup in Apache/mod_wsgi seems unlikely.

-- 
Ticket URL: 
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] r15313 - django/trunk/docs/intro

[noreply]

Author: timo
Date: 2011-01-25 18:58:41 -0600 (Tue, 25 Jan 2011)
New Revision: 15313

Modified:
   django/trunk/docs/intro/tutorial04.txt
Log:
Fixed #15153 - removed obsolete sentence in tutorial; thanks LeSphinx for the 
report.

Modified: django/trunk/docs/intro/tutorial04.txt
===
--- django/trunk/docs/intro/tutorial04.txt  2011-01-26 00:37:55 UTC (rev 
15312)
+++ django/trunk/docs/intro/tutorial04.txt  2011-01-26 00:58:41 UTC (rev 
15313)
@@ -306,11 +306,6 @@
 views from ``polls/views.py``. We don't need them anymore -- they have
 been replaced by generic views.
 
-The ``vote()`` view is still required. However, it must be modified to
-match the new context variables. In the
-:func:`~django.shortcuts.render_to_response` call, rename the ``poll``
-context variable to ``object``.
-
 The last thing to do is fix the URL handling to account for the use of
 generic views. In the vote view above, we used the
 :func:`~django.core.urlresolvers.reverse` function to avoid

-- 
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] #15130: Model.validate_unique method doesn't take in account multi-db

[Django]

#15130: Model.validate_unique method doesn't take in account multi-db
--+-
  Reporter:  t2y  | Owner:  
Status:  reopened | Milestone:  1.3 
 Component:  ORM aggregation  |   Version:  1.2 
Resolution:   |  Keywords:  multi-db
 Stage:  Accepted | Has_patch:  1   
Needs_docs:  0|   Needs_tests:  0   
Needs_better_patch:  0|  
--+-
Changes (by ramiro):

  * 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] #12464: Empty PATH_INFO causes blank SCRIPT_NAME

[Django]

#12464: Empty PATH_INFO causes blank SCRIPT_NAME
+---
  Reporter:  chrisw | Owner:  wogan
Status:  assigned   | Milestone:  1.3  
 Component:  HTTP handling  |   Version:  SVN  
Resolution: |  Keywords:   
 Stage:  Accepted   | Has_patch:  1
Needs_docs:  0  |   Needs_tests:  0
Needs_better_patch:  0  |  
+---
Comment (by grahamd):

 The REDIRECT_URL variable is actually setup for CGI environment by Apache
 and not my mod_rewrite. Because mod_wsgi gets Apache to build the CGI
 environment but passes it as part of WSGI environment, that is where it is
 coming. FASTCGI and SCGI etc would similarly inherit REDIRECT_URL in that
 way.

 Thus, although the code in Django doing this fixups is documented as being
 related to mod_rewrite, it is actually using information from other
 sources besides that.

-- 
Ticket URL: 
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] r15312 - django/branches/releases/1.2.X/docs/topics

[noreply]

Author: timo
Date: 2011-01-25 18:37:55 -0600 (Tue, 25 Jan 2011)
New Revision: 15312

Modified:
   django/branches/releases/1.2.X/docs/topics/email.txt
Log:
[1.2.X] Fixed #15163 - typo in email docs; thanks metal for the report.

Backport of r15311 from trunk.

Modified: django/branches/releases/1.2.X/docs/topics/email.txt
===
--- django/branches/releases/1.2.X/docs/topics/email.txt2011-01-26 
00:37:08 UTC (rev 15311)
+++ django/branches/releases/1.2.X/docs/topics/email.txt2011-01-26 
00:37:55 UTC (rev 15312)
@@ -92,7 +92,7 @@
 two different sets of recipients; however, only one connection to the
 mail server would be opened::
 
-message1 = ('Subject here', 'Here is the message', 'f...@example.com, 
['fi...@example.com', 'ot...@example.com'])
+message1 = ('Subject here', 'Here is the message', 'f...@example.com', 
['fi...@example.com', 'ot...@example.com'])
 message2 = ('Another Subject', 'Here is another message', 
'f...@example.com', ['sec...@test.com'])
 send_mass_mail((message1, message2), fail_silently=False)
 

-- 
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] r15311 - django/trunk/docs/topics

[noreply]

Author: timo
Date: 2011-01-25 18:37:08 -0600 (Tue, 25 Jan 2011)
New Revision: 15311

Modified:
   django/trunk/docs/topics/email.txt
Log:
Fixed #15163 - typo in email docs; thanks metal for the report.

Modified: django/trunk/docs/topics/email.txt
===
--- django/trunk/docs/topics/email.txt  2011-01-25 15:44:41 UTC (rev 15310)
+++ django/trunk/docs/topics/email.txt  2011-01-26 00:37:08 UTC (rev 15311)
@@ -92,7 +92,7 @@
 two different sets of recipients; however, only one connection to the
 mail server would be opened::
 
-message1 = ('Subject here', 'Here is the message', 'f...@example.com, 
['fi...@example.com', 'ot...@example.com'])
+message1 = ('Subject here', 'Here is the message', 'f...@example.com', 
['fi...@example.com', 'ot...@example.com'])
 message2 = ('Another Subject', 'Here is another message', 
'f...@example.com', ['sec...@test.com'])
 send_mass_mail((message1, message2), fail_silently=False)
 

-- 
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] #12464: Empty PATH_INFO causes blank SCRIPT_NAME

[Django]

#12464: Empty PATH_INFO causes blank SCRIPT_NAME
+---
  Reporter:  chrisw | Owner:  wogan
Status:  assigned   | Milestone:  1.3  
 Component:  HTTP handling  |   Version:  SVN  
Resolution: |  Keywords:   
 Stage:  Accepted   | Has_patch:  1
Needs_docs:  0  |   Needs_tests:  0
Needs_better_patch:  0  |  
+---
Comment (by grahamd):

 Anyone know what server sets REDIRECT_URL. The Apache/mod_rewrite module
 doesn't. It sets SCRIPT_URL and REDIRECT_SCRIPT_URL. So, don't know if
 REDIRECT_URL is for a different server such as lighttpd, nginx or
 cherokee, or whether the code as been wrong as far as what variable it is
 checking for.

 It also may be arguable that Apache/mod_wsgi itself should use SCRIPT_URL
 and REDIRECT_SCRIPT_URL to automatically rewrite SCRIPT_NAME back to the
 original value when rewrites occur. This had been considered albeit would
 have used internal Apache C request structures to derive it rather than
 relying of the SetEnv variables set by mod_rewrite internally. In doing
 that, would be necessary to clear SCRIPT_URL and REDIRECT_SCRIPT_URL
 though so something like Django would try and then fix it up a second time
 and potentially muck up the fixup.

 If such a fixup were added to Apache/mod_wsgi, would be on by default, but
 able to be turned off.

-- 
Ticket URL: 
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] #15165: GeoQuerySet.perimeter returns invalid results on geometry fields with geodetic coordinate systems

[Django]

#15165: GeoQuerySet.perimeter returns invalid results on geometry fields with
geodetic coordinate systems
-+--
  Reporter:  jbronn  | Owner:  jbronn   
Status:  assigned| Milestone:   
 Component:  GIS |   Version:  1.2  
Resolution:  |  Keywords:  perimeter
 Stage:  Unreviewed  | Has_patch:  0
Needs_docs:  0   |   Needs_tests:  0
Needs_better_patch:  0   |  
-+--
Changes (by jbronn):

  * owner:  nobody => jbronn
  * needs_better_patch:  => 0
  * status:  new => assigned
  * needs_tests:  => 0
  * needs_docs:  => 0

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

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

[Django] #15165: GeoQuerySet.perimeter returns invalid results on geometry fields with geodetic coordinate systems

[Django]

#15165: GeoQuerySet.perimeter returns invalid results on geometry fields with
geodetic coordinate systems
---+
 Reporter:  jbronn |   Owner:  nobody
   Status:  new|   Milestone:
Component:  GIS| Version:  1.2   
 Keywords:  perimeter  |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 The method `GeoQuerySet.perimeter` returns `Distance` objects with
 erroneous values when called on a geometry field that has a geodetic
 coordinate system (e.g., `srid=4326`).  The values in the returned
 distance objects are really perimeter measurements in degrees of
 latitude/longitude, rather than meters.

 Here's an example using the models and data from the
 [http://docs.djangoproject.com/en/dev/ref/contrib/gis/tutorial/ GeoDjango
 tutorial]:
 {{{
 #!python
 >>> from world.models import WorldBorders
 >>> us = WorldBorders.objects.perimeter().get(name='United States')
 >>> print us.perimeter
 771.493229562 m
 }}}

 Obviously, the perimeter of the United States is greater than a kilometer.
 To fix, the helper method `GeoQuerySet._distance_attribute` needs to be
 modified to raise an exception  or return a raw numeric value when
 attempting to calculate perimeters on geodetic coordinate systems.

-- 
Ticket URL: 
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] #7712: UploadedFile missing readline method

[Django]

#7712: UploadedFile missing readline method
---+
  Reporter:  artagnon  | Owner:  nobody 
Status:  closed| Milestone: 
 Component:  File uploads/storage  |   Version:  SVN
Resolution:  fixed |  Keywords:  upload uploadedfile
 Stage:  Accepted  | Has_patch:  0  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Comment (by jb0t):

 immortalized

 [http://www.djangowoodies.com]

-- 
Ticket URL: 
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] #15164: Filtering queryset via ForeignKey to legacy model with OneToOneField as primary doesn't evaluate primary key

[Django]

#15164: Filtering queryset via ForeignKey to legacy model with OneToOneField as
primary doesn't evaluate primary key
--+-
 Reporter:  GDorn |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Database layer (models, ORM)  | Version:  1.2   
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 If you have one model with a OneToOneField as primary_key and also specify
 a db_column and another model with a foreign key to the first, like this:
 {{{
 class UserProfile(models.Model):
 user = models.OneToOneField(User, primary_key=True, db_column='uid')
 email = models.CharField(max_length=255, unique=True)
 username = models.CharField(unique=True, max_length=150)
 class Meta:
 db_table = u'legacy_user'

 class OtherModel(models.Model):
 user = models.ForeignKey('my_app.UserProfile', db_column='uid')
 some_data = models.IntegerField()
 another_model = models.ForeignKey('other_app.AnotherModel',
 db_column='related')
 class Meta:
 db_table = u'legacy_other_model'
 }}}

 When you perform this queryset you get weird SQL:

 {{{
 my_user = UserProfile.objects.get(username='foo')
 count = OtherModel.objects.filter(user=my_user).count()
 SELECT COUNT(*) FROM `legacy_other_model` WHERE `legacy_other_model`.`uid`
 = None
 }}}

 But if you explicitly filter on the object's pk, it works:

 {{{
 count = OtherModel.objects.filter(user=my_user.pk).count()
 SELECT COUNT(*) FROM `legacy_other_model` WHERE `legacy_other_model`.`uid`
 = 12345
 }}}

 This doesn't seem to be the expected behavior, looking at:
 http://docs.djangoproject.com/en/dev/topics/db/queries/#queries-over-
 related-objects

-- 
Ticket URL: 
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] #15163: The send-mass-mail section contains a wrong example

[Django]

#15163: The send-mass-mail section contains a wrong example
+---
 Reporter:  metal   |   Owner:  nobody
   Status:  new |   Milestone:
Component:  Documentation   | Version:  1.2   
 Keywords:  send-mass-mail  |   Stage:  Unreviewed
Has_patch:  1   |  
+---
 Hi!

 I found one bug in the send-mass-mail section.
 http://docs.djangoproject.com/en/dev/topics/email/#send-mass-mail

 The 'from' element is a bad string.

 Bad:

 {{{
 message1 = ('Subject here', 'Here is the message', 'f...@example.com,
 ['fi...@example.com', 'ot...@example.com'])
 }}}

 Correct:

 {{{
 message1 = ('Subject here', 'Here is the message', 'f...@example.com',
 ['fi...@example.com', 'ot...@example.com'])
 }}}

 Cheers.

-- 
Ticket URL: 
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] #15130: Model.validate_unique method doesn't take in account multi-db

[Django]

#15130: Model.validate_unique method doesn't take in account multi-db
--+-
  Reporter:  t2y  | Owner:  
Status:  reopened | Milestone:  1.3 
 Component:  ORM aggregation  |   Version:  1.2 
Resolution:   |  Keywords:  multi-db
 Stage:  Accepted | Has_patch:  1   
Needs_docs:  0|   Needs_tests:  1   
Needs_better_patch:  0|  
--+-
Comment (by ramiro):

 Thanks for showing my tests were wrong. I didn't take in account
 Model.save() doesn't do validation by default.

-- 
Ticket URL: 
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] #15162: syncdb fails when creating super user - Django: v 1.2.4 Python: 2.6 MySQL Server: 5.5 Windows 7 Extra: MySQL-Python v1.2.3

[Django]

#15162: syncdb fails when creating super user - Django: v 1.2.4 Python: 2.6 
MySQL
Server: 5.5 Windows 7 Extra: MySQL-Python v1.2.3
---+
  Reporter:  david_heagney | Owner:  nobody 
 
Status:  new   | Milestone:  1.3
 
 Component:  Database layer (models, ORM)  |   Version:  1.2
 
Resolution:|  Keywords:  syncdb 
mysql
 Stage:  Unreviewed| Has_patch:  0  
 
Needs_docs:  0 |   Needs_tests:  0  
 
Needs_better_patch:  0 |  
---+
Old description:

> syncdb fails when creating super user - Django: v 1.2.4 Python: 2.6 MySQL
> Server: 5.5 Windows 7 Extra: MySQL-Python v1.2.3
>
> What steps will reproduce the problem? 1. install the above programs
> 2. create a project 3. run syncdb
>
> Note: I have installed mySQL to support UTF 8. I also create the
> mysite_db database using CREATE DTABASE mysite_db CHARACTER SET =
> UTF8;
>
> What is the expected output? What do you see instead?
>
> syncdb create the required tables as follows:
>
> -
>
> C:\DjangoProjects\mysite>python manage.py syncdb
> Creating table auth_permission
> Creating table auth_group_permissions
> Creating table auth_group
> Creating table auth_user_user_permissions
> Creating table auth_user_groups
> Creating table auth_user
> Creating table auth_message
> Creating table django_content_type
> Creating table django_session
> Creating table django_site
>
> You just installed Django's auth system, which means you don't have
> any superuse
> rs defined.
> Would you like to create one now? (yes/no):
>
> -
>
> I select 'YES' and get the following error:
>
> -
>
> Traceback (most recent call last):
>  File "manage.py", line 11, in 
>execute_manager(settings)
>  File "C:\Python26\lib\site-packages\django\core\management
> \__init__.py", line
> 438, in execute_manager
>utility.execute()
>  File "C:\Python26\lib\site-packages\django\core\management
> \__init__.py", line
> 379, in execute
>self.fetch_command(subcommand).run_from_argv(self.argv)
>  File "C:\Python26\lib\site-packages\django\core\management\base.py",
> line 191,
>  in run_from_argv
>self.execute(*args, **options.__dict__)
>  File "C:\Python26\lib\site-packages\django\core\management\base.py",
> line 220,
>  in execute
>output = self.handle(*args, **options)
>  File "C:\Python26\lib\site-packages\django\core\management\base.py",
> line 351,
>  in handle
>return self.handle_noargs(**options)
>  File "C:\Python26\lib\site-packages\django\core\management\commands
> \syncdb.py"
> , line 103, in handle_noargs
>emit_post_sync_signal(created_models, verbosity, interactive, db)
>  File "C:\Python26\lib\site-packages\django\core\management\sql.py",
> line 182,
> in emit_post_sync_signal
>interactive=interactive, db=db)
>  File "C:\Python26\lib\site-packages\django\dispatch\dispatcher.py",
> line 172,
> in send
>response = receiver(signal=self, sender=sender, **named)
>  File "C:\Python26\lib\site-packages\django\contrib\auth\management
> \__init__.py
> ", line 44, in create_superuser
>call_command("createsuperuser", interactive=True)
>  File "C:\Python26\lib\site-packages\django\core\management
> \__init__.py", line
> 166, in call_command
>return klass.execute(*args, **defaults)
>  File "C:\Python26\lib\site-packages\django\core\management\base.py",
> line 220,
>  in execute
>output = self.handle(*args, **options)
>  File "C:\Python26\lib\site-packages\django\contrib\auth\management
> \commands\cr
> eatesuperuser.py", line 71, in handle
>User.objects.get(username=default_username)
>  File "C:\Python26\lib\site-packages\django\db\models\manager.py",
> line 132, in
>  get
>return self.get_query_set().get(*args, **kwargs)
>  File "C:\Python26\lib\site-packages\django\db\models\query.py", line
> 342, in g
> et
>num = len(clone)
>  File "C:\Python26\lib\site-packages\django\db\models\query.py", line
> 80, in __
> len__
>self._result_cache = list(self.iterator())
>  File "C:\Python26\lib\site-packages\django\db\models\query.py", line
> 271, in i
> terator
>for row in compiler.results_iter():
>  File "C:\Python26\lib\site-packages\django\db\models\sql
> \compiler.py", line 67
> 7, in results_iter
>for rows in self.execute_sql(MULTI):
>  File "C:\Python26\lib\site-packages\django\db\models\sql
> 

Re: [Django] #9532: min_num on formsets

[Django]

#9532: min_num on formsets
-+--
  Reporter:  gsf | Owner:  nobody
Status:  new | Milestone:
 Component:  Forms   |   Version:  SVN   
Resolution:  |  Keywords:
 Stage:  Design decision needed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by dokterbob):

 * cc: math...@mathijsfietst.nl (added)

Comment:

 Bump! It would make a lot of sense to have this kind of functionality
 built into Django, and the effort would not be gigantic.

-- 
Ticket URL: 
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] #15162: syncdb fails when creating super user - Django: v 1.2.4 Python: 2.6 MySQL Server: 5.5 Windows 7 Extra: MySQL-Python v1.2.3

[Django]

#15162: syncdb fails when creating super user - Django: v 1.2.4 Python: 2.6 
MySQL
Server: 5.5 Windows 7 Extra: MySQL-Python v1.2.3
---+
  Reporter:  david_heagney | Owner:  nobody 
 
Status:  new   | Milestone:  1.3
 
 Component:  Database layer (models, ORM)  |   Version:  1.2
 
Resolution:|  Keywords:  syncdb 
mysql
 Stage:  Unreviewed| Has_patch:  0  
 
Needs_docs:  0 |   Needs_tests:  0  
 
Needs_better_patch:  0 |  
---+
Changes (by david_heagney):

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

Comment:

 Note: I have confirmed the mySQL DB is UTF-8. I deleted and recreated
 using <  CREATE DATABASE mysite_db DEFAULT CHARACTER SET utf8 DEFAULT
 COLLATE utf8_general_ci;> and got the same error. 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.

[Django] #15162: syncdb fails when creating super user - Django: v 1.2.4 Python: 2.6 MySQL Server: 5.5 Windows 7 Extra: MySQL-Python v1.2.3

[Django]

#15162: syncdb fails when creating super user - Django: v 1.2.4 Python: 2.6 
MySQL
Server: 5.5 Windows 7 Extra: MySQL-Python v1.2.3
--+-
 Reporter:  david_heagney |   Owner:  nobody
   Status:  new   |   Milestone:  1.3   
Component:  Database layer (models, ORM)  | Version:  1.2   
 Keywords:  syncdb mysql  |   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 syncdb fails when creating super user - Django: v 1.2.4 Python: 2.6 MySQL
 Server: 5.5 Windows 7 Extra: MySQL-Python v1.2.3

 What steps will reproduce the problem? 1. install the above programs
 2. create a project 3. run syncdb

 Note: I have installed mySQL to support UTF 8. I also create the
 mysite_db database using CREATE DTABASE mysite_db CHARACTER SET =
 UTF8;

 What is the expected output? What do you see instead?

 syncdb create the required tables as follows:

 
-

 C:\DjangoProjects\mysite>python manage.py syncdb
 Creating table auth_permission
 Creating table auth_group_permissions
 Creating table auth_group
 Creating table auth_user_user_permissions
 Creating table auth_user_groups
 Creating table auth_user
 Creating table auth_message
 Creating table django_content_type
 Creating table django_session
 Creating table django_site

 You just installed Django's auth system, which means you don't have
 any superuse
 rs defined.
 Would you like to create one now? (yes/no):

 
-

 I select 'YES' and get the following error:

 
-

 Traceback (most recent call last):
  File "manage.py", line 11, in 
execute_manager(settings)
  File "C:\Python26\lib\site-packages\django\core\management
 \__init__.py", line
 438, in execute_manager
utility.execute()
  File "C:\Python26\lib\site-packages\django\core\management
 \__init__.py", line
 379, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
  File "C:\Python26\lib\site-packages\django\core\management\base.py",
 line 191,
  in run_from_argv
self.execute(*args, **options.__dict__)
  File "C:\Python26\lib\site-packages\django\core\management\base.py",
 line 220,
  in execute
output = self.handle(*args, **options)
  File "C:\Python26\lib\site-packages\django\core\management\base.py",
 line 351,
  in handle
return self.handle_noargs(**options)
  File "C:\Python26\lib\site-packages\django\core\management\commands
 \syncdb.py"
 , line 103, in handle_noargs
emit_post_sync_signal(created_models, verbosity, interactive, db)
  File "C:\Python26\lib\site-packages\django\core\management\sql.py",
 line 182,
 in emit_post_sync_signal
interactive=interactive, db=db)
  File "C:\Python26\lib\site-packages\django\dispatch\dispatcher.py",
 line 172,
 in send
response = receiver(signal=self, sender=sender, **named)
  File "C:\Python26\lib\site-packages\django\contrib\auth\management
 \__init__.py
 ", line 44, in create_superuser
call_command("createsuperuser", interactive=True)
  File "C:\Python26\lib\site-packages\django\core\management
 \__init__.py", line
 166, in call_command
return klass.execute(*args, **defaults)
  File "C:\Python26\lib\site-packages\django\core\management\base.py",
 line 220,
  in execute
output = self.handle(*args, **options)
  File "C:\Python26\lib\site-packages\django\contrib\auth\management
 \commands\cr
 eatesuperuser.py", line 71, in handle
User.objects.get(username=default_username)
  File "C:\Python26\lib\site-packages\django\db\models\manager.py",
 line 132, in
  get
return self.get_query_set().get(*args, **kwargs)
  File "C:\Python26\lib\site-packages\django\db\models\query.py", line
 342, in g
 et
num = len(clone)
  File "C:\Python26\lib\site-packages\django\db\models\query.py", line
 80, in __
 len__
self._result_cache = list(self.iterator())
  File "C:\Python26\lib\site-packages\django\db\models\query.py", line
 271, in i
 terator
for row in compiler.results_iter():
  File "C:\Python26\lib\site-packages\django\db\models\sql
 \compiler.py", line 67
 7, in results_iter
for rows in self.execute_sql(MULTI):
  File "C:\Python26\lib\site-packages\django\db\models\sql
 \compiler.py", line 73
 2, in execute_sql
cursor.execute(sql, params)
  File "C:\Python26\lib\site-packages\django\db\backends\util.py",
 line 15, in e
 xecute
return self.cursor.execute(sql, params)
  File "C:\Python26\lib\site-packages\django\db\backends\mysql
 \base.py", line 86
 , in execute
return self.cursor.execute(query, args)
  File 

Re: [Django] #12464: Empty PATH_INFO causes blank SCRIPT_NAME

[Django]

#12464: Empty PATH_INFO causes blank SCRIPT_NAME
+---
  Reporter:  chrisw | Owner:  wogan
Status:  assigned   | Milestone:  1.3  
 Component:  HTTP handling  |   Version:  SVN  
Resolution: |  Keywords:   
 Stage:  Accepted   | Has_patch:  1
Needs_docs:  0  |   Needs_tests:  0
Needs_better_patch:  0  |  
+---
Comment (by dchandek):

 What needs to be done here to move the stage back to "ready for checkin"?

 Now, it appears that the currently available Django solution to this issue
 is to set FORCE_SCRIPT_NAME, e.g.:

 {{{
 FORCE_SCRIPT_NAME = '/project'
 }}}

 Nevertheless, although the origin of this problem (i.e., inconsistent
 setting of SCRIPT_URL) lies outside of Django, it seems to me basic sanity
 to avoid whacking a string by slicing it with `[:-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] #11868: Multiple sort in admin changelist

[Django]

#11868: Multiple sort in admin changelist
-+--
  Reporter:  bendavis78  | Owner:  bendavis78   
  
Status:  assigned| Milestone:   
  
 Component:  django.contrib.admin|   Version:  SVN  
  
Resolution:  |  Keywords:  admin sort 
multisort ordering order
 Stage:  Design decision needed  | Has_patch:  1
  
Needs_docs:  0   |   Needs_tests:  0
  
Needs_better_patch:  0   |  
-+--
Changes (by andybak):

 * cc: a...@andybak.net (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.

[Changeset] r15310 - in django/branches/releases/1.2.X/docs: ref ref/templates releases

[noreply]

Author: ramiro
Date: 2011-01-25 09:44:41 -0600 (Tue, 25 Jan 2011)
New Revision: 15310

Modified:
   django/branches/releases/1.2.X/docs/ref/settings.txt
   django/branches/releases/1.2.X/docs/ref/templates/api.txt
   django/branches/releases/1.2.X/docs/releases/1.2.txt
Log:
[1.2.X] Fixed #14038 -- Added information to release notes and version 
changed|added markers to documentation additions for the new template loeaders 
API introduced in version 1.2. Thanks 3point2 for the report.

Backport of [15309] from trunk

Modified: django/branches/releases/1.2.X/docs/ref/settings.txt
===
--- django/branches/releases/1.2.X/docs/ref/settings.txt2011-01-25 
15:42:24 UTC (rev 15309)
+++ django/branches/releases/1.2.X/docs/ref/settings.txt2011-01-25 
15:44:41 UTC (rev 15310)
@@ -1504,6 +1504,12 @@
 module, subsequent items are passed to the ``Loader`` during initialization. 
See
 :doc:`/ref/templates/api`.
 
+.. versionchanged:: 1.2
+The class-based API for template loaders was introduced in Django 1.2
+although  the ``TEMPLATE_LOADERS`` setting will accept strings that specify
+function-based loaders until compatibility with them is completely removed 
in
+Django 1.4.
+
 .. setting:: TEMPLATE_STRING_IF_INVALID
 
 TEMPLATE_STRING_IF_INVALID

Modified: django/branches/releases/1.2.X/docs/ref/templates/api.txt
===
--- django/branches/releases/1.2.X/docs/ref/templates/api.txt   2011-01-25 
15:42:24 UTC (rev 15309)
+++ django/branches/releases/1.2.X/docs/ref/templates/api.txt   2011-01-25 
15:44:41 UTC (rev 15310)
@@ -613,9 +613,14 @@
 
 Some of these other loaders are disabled by default, but you can activate them
 by editing your :setting:`TEMPLATE_LOADERS` setting. 
:setting:`TEMPLATE_LOADERS`
-should be a tuple of strings, where each string represents a template loader.
-Here are the template loaders that come with Django:
+should be a tuple of strings, where each string represents a template loader
+class. Here are the template loaders that come with Django:
 
+.. versionchanged:: 1.2
+Template loaders were based on callables (usually functions) before Django
+1.2, starting with the 1.2 release there is a new class-based API, all the
+loaders described below implement this new API.
+
 ``django.template.loaders.filesystem.Loader``
 Loads templates from the filesystem, according to :setting:`TEMPLATE_DIRS`.
 This loader is enabled by default.

Modified: django/branches/releases/1.2.X/docs/releases/1.2.txt
===
--- django/branches/releases/1.2.X/docs/releases/1.2.txt2011-01-25 
15:42:24 UTC (rev 15309)
+++ django/branches/releases/1.2.X/docs/releases/1.2.txt2011-01-25 
15:44:41 UTC (rev 15310)
@@ -256,6 +256,29 @@
 languages. For more details, see the :ref:`notes on supporting
 non-Django template languages`.
 
+Class-based template loaders
+
+
+As part of the changes made to introduce `Template caching`_  and following
+a general trend in Django, the template loaders API has been modified
+to use template loading mechanisms that are encapsulated in Python classes as
+opposed to functions, the only method available until Django 1.1.
+
+All the template loaders :ref:`shipped with Django ` have
+been ported to the new API but they still implement the function-based API and
+the template core machinery still accepts function-based loaders (builtin or
+third party) so there is no immediate need to modify your
+:setting:`TEMPLATE_LOADERS` setting in existing projects, things will keep
+working if you leave it untouched up to and including the Django 1.3 release.
+
+If you have developed your own custom template loaders we suggest to consider
+porting them to a class-based implementation because the code for backwards
+compatibility with function-based loaders starts its deprecation process in
+Django 1.2 and will be removed in Django 1.4.  There is a description of the
+API these loader classes must implement :ref:`here
+` and you can also examine the source code
+of the loaders shipped with Django.
+
 Natural keys in fixtures
 
 
@@ -1137,3 +1160,10 @@
 The currently used language code for Norwegian Bokmål ``no`` is being
 replaced by the more common language code ``nb``.
 
+Function-based template loaders
+---
+
+Django 1.2 changes the template loading mechanism to use a class-based
+approach. Old style function-based template loaders will still work, but should
+be updated to use the new :ref:`class-based template loaders
+`.

-- 
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.

[Changeset] r15309 - in django/trunk/docs: ref ref/templates releases

[noreply]

Author: ramiro
Date: 2011-01-25 09:42:24 -0600 (Tue, 25 Jan 2011)
New Revision: 15309

Modified:
   django/trunk/docs/ref/settings.txt
   django/trunk/docs/ref/templates/api.txt
   django/trunk/docs/releases/1.2.txt
Log:
Fixed #14038 -- Added information to release notes and version changed|added 
markers to documentation additions for the new template loeaders API introduced 
in version 1.2. Thanks 3point2 for the report.

Modified: django/trunk/docs/ref/settings.txt
===
--- django/trunk/docs/ref/settings.txt  2011-01-25 08:37:35 UTC (rev 15308)
+++ django/trunk/docs/ref/settings.txt  2011-01-25 15:42:24 UTC (rev 15309)
@@ -1743,6 +1743,12 @@
 module, subsequent items are passed to the ``Loader`` during initialization. 
See
 :doc:`/ref/templates/api`.
 
+.. versionchanged:: 1.2
+The class-based API for template loaders was introduced in Django 1.2
+although  the ``TEMPLATE_LOADERS`` setting will accept strings that specify
+function-based loaders until compatibility with them is completely removed 
in
+Django 1.4.
+
 .. setting:: TEMPLATE_STRING_IF_INVALID
 
 TEMPLATE_STRING_IF_INVALID

Modified: django/trunk/docs/ref/templates/api.txt
===
--- django/trunk/docs/ref/templates/api.txt 2011-01-25 08:37:35 UTC (rev 
15308)
+++ django/trunk/docs/ref/templates/api.txt 2011-01-25 15:42:24 UTC (rev 
15309)
@@ -630,9 +630,14 @@
 
 Some of these other loaders are disabled by default, but you can activate them
 by editing your :setting:`TEMPLATE_LOADERS` setting. 
:setting:`TEMPLATE_LOADERS`
-should be a tuple of strings, where each string represents a template loader.
-Here are the template loaders that come with Django:
+should be a tuple of strings, where each string represents a template loader
+class. Here are the template loaders that come with Django:
 
+.. versionchanged:: 1.2
+Template loaders were based on callables (usually functions) before Django
+1.2, starting with the 1.2 release there is a new class-based API, all the
+loaders described below implement this new API.
+
 ``django.template.loaders.filesystem.Loader``
 Loads templates from the filesystem, according to :setting:`TEMPLATE_DIRS`.
 This loader is enabled by default.

Modified: django/trunk/docs/releases/1.2.txt
===
--- django/trunk/docs/releases/1.2.txt  2011-01-25 08:37:35 UTC (rev 15308)
+++ django/trunk/docs/releases/1.2.txt  2011-01-25 15:42:24 UTC (rev 15309)
@@ -256,6 +256,29 @@
 languages. For more details, see the :ref:`notes on supporting
 non-Django template languages`.
 
+Class-based template loaders
+
+
+As part of the changes made to introduce `Template caching`_  and following
+a general trend in Django, the template loaders API has been modified
+to use template loading mechanisms that are encapsulated in Python classes as
+opposed to functions, the only method available until Django 1.1.
+
+All the template loaders :ref:`shipped with Django ` have
+been ported to the new API but they still implement the function-based API and
+the template core machinery still accepts function-based loaders (builtin or
+third party) so there is no immediate need to modify your
+:setting:`TEMPLATE_LOADERS` setting in existing projects, things will keep
+working if you leave it untouched up to and including the Django 1.3 release.
+
+If you have developed your own custom template loaders we suggest to consider
+porting them to a class-based implementation because the code for backwards
+compatibility with function-based loaders starts its deprecation process in
+Django 1.2 and will be removed in Django 1.4.  There is a description of the
+API these loader classes must implement :ref:`here
+` and you can also examine the source code
+of the loaders shipped with Django.
+
 Natural keys in fixtures
 
 
@@ -1137,3 +1160,10 @@
 The currently used language code for Norwegian Bokmål ``no`` is being
 replaced by the more common language code ``nb``.
 
+Function-based template loaders
+---
+
+Django 1.2 changes the template loading mechanism to use a class-based
+approach. Old style function-based template loaders will still work, but should
+be updated to use the new :ref:`class-based template loaders
+`.

-- 
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] #15089: contrib.sites and multitenancy

[Django]

#15089: contrib.sites and multitenancy
-+--
  Reporter:  legutierr   | Owner:  nobody  
Status:  new | Milestone:  
 Component:  Contrib apps|   Version:  1.3-beta
Resolution:  |  Keywords:  
 Stage:  Design decision needed  | Has_patch:  1   
Needs_docs:  0   |   Needs_tests:  0   
Needs_better_patch:  1   |  
-+--
Changes (by Ciantic):

 * cc: Ciantic (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] #15152: Common middleware raises UnicodeDecodeError if receives specially formatted unicode-like query string

[Django]

#15152: Common middleware raises UnicodeDecodeError if receives specially 
formatted
unicode-like query string
-+--
  Reporter:  Loststylus  | Owner:  nobody   
Status:  new | Milestone:  1.3  
 Component:  Core framework  |   Version:  1.2  
Resolution:  |  Keywords:  common middleware
 Stage:  Unreviewed  | Has_patch:  0
Needs_docs:  0   |   Needs_tests:  0
Needs_better_patch:  0   |  
-+--
Comment (by Loststylus):

 Temporary workaround (middleware should be added befor common middleware):
 {{{
 #!python
 class RequestCheckMiddleware(object):

 def process_request(self, request):

 try:
 u'%s' % request.META.get('QUERY_STRING','')
 except UnicodeDecodeError:
 response = HttpResponse()
 response.status_code = 400  #Bad Request
 return response

 return None
 }}}

-- 
Ticket URL: 
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] #15161: ManyToManyField with a through model with to_field set returns no results

[Django]

#15161: ManyToManyField with a through model with to_field set returns no 
results
---+
  Reporter:  adehnert  | Owner:  carljm
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  1.2   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by carljm):

  * owner:  nobody => carljm
  * needs_better_patch:  => 0
  * stage:  Unreviewed => Accepted
  * needs_tests:  => 0
  * needs_docs:  => 0

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

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

Re: [Django] #15151: i18n tests failing

[Django]

#15151: i18n tests failing
---+
  Reporter:  Alex  | Owner:  nobody
Status:  closed| Milestone:  1.3   
 Component:  Internationalization  |   Version:  SVN   
Resolution:  fixed |  Keywords:
 Stage:  Accepted  | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by Alex):

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

Comment:

 fixed in [15308]

-- 
Ticket URL: 
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] #15161: ManyToManyField with a through model with to_field set returns no results

[Django]

#15161: ManyToManyField with a through model with to_field set returns no 
results
--+-
 Reporter:  adehnert  |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Database layer (models, ORM)  | Version:  1.2   
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 If you create a model that has a ManyToManyField with
 through=IntermediateModel, and you set to_field on one of the ForeignKeys
 in the IntermediateModel, the ManyToManyField won't properly produce the
 right set of results.

 For example, using the attached set of models, I get:
 {{{
 >>> import manytomany.models
 >>> foobar = manytomany.models.FooBar.objects.all()[0]
 >>> foobar
 
 >>> manytomany.models.FooBar.objects.filter(foo=foobar.foo)
 []
 >>> foobar.foo.bars.all()
 []
 >>> foobar2 = manytomany.models.FooBar2.objects.all()[0]
 >>> foobar2
 
 >>> manytomany.models.FooBar2.objects.filter(foo=foobar2.foo)
 []
 >>> foobar2.foo.bars.all()
 []
 }}}

 I would expect filter(foo=foo) to produce basically the same set of
 results as foo.bars (except with the FooBar objects instead of the Bar
 objects). However, while the former produces results, the latter does not.

 I suspect this is related to the behavior experienced in http://www.mail-
 archive.com/django-us...@googlegroups.com/msg105967.html. However, while
 that seems like arguably not a bug, this behavior does seem to clearly
 qualify (or, at least, should be better-documented than I was finding it
 to be).

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

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

Re: [Django] #14677: tests.py cannot be split to package always

[Django]

#14677: tests.py cannot be split to package always
+---
  Reporter:  Ciantic| Owner:  nobody
Status:  closed | Milestone:
 Component:  Testing framework  |   Version:  SVN   
Resolution:  wontfix|  Keywords:
 Stage:  Accepted   | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by russellm):

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

Comment:

 @carljm makes a fair point. Django's test suite puts models in tests.py,
 but that isn't a documented capability, and it has some fairly nasty side
 effects (not the least of which is dirtying of the content types and app
 cache).

 I'm going to marking this closed wontfix; it's an undocumented capability,
 and rather than paper over the problem, we should be focussing on #7835 to
 provide the "real" 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] #15103: Django 1.2.4 breaks limit_choices_to for raw_id_fields

[Django]

#15103: Django 1.2.4 breaks limit_choices_to for raw_id_fields
---+
  Reporter:  natrius   | Owner:  nobody 
   
Status:  new   | Milestone:  1.3
   
 Component:  django.contrib.admin  |   Version:  1.2
   
Resolution:|  Keywords:  blocker regression 
send_mail email
 Stage:  Accepted  | Has_patch:  0  
   
Needs_docs:  0 |   Needs_tests:  0  
   
Needs_better_patch:  0 |  
---+
Comment (by russellm):

 @luke,

 Fair point about being explicit, but (using the Holiday/Tour/Person models
 as an example):

 This whole filtering issue arises because a HolidayAdmin with
 raw_id_fields=('tour',) requires the ability to filter Tours based on
 leader!__status. However, the existence of the raw_id_fields clause
 requires that there is a registered TourAdmin anyway... which means that
 the user that you're restricting access to can already see *all* the Tour
 data. Ok, they may not be able to filter based on leader status, but data
 access is hardly a concern.

 I haven't been able to construct an example case where an implied
 limit_choices_to filter is required, where the data visibility implied by
 that filter exceeds that already required in order to make the admin work.

 The only way I can see that the value *might* be important (and this is
 looking longer term) is with per-object permissions -- especially if we
 start looking at "view" permissions. However, my gut tells me that this is
 something that should be handled as at the queryset level of the
 ModelAdmin, not as a 'allowed filter' check.

-- 
Ticket URL: 
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] #15129: Invalid order of applying formats

[Django]

#15129: Invalid order of applying formats
---+
  Reporter:  tonnzor   | Owner:  nobody
Status:  new   | Milestone:  1.3   
 Component:  Internationalization  |   Version:  1.2   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  1 |  
---+
Comment (by tonnzor):

 Replying to [comment:8 ramiro]:
 > I'e attached a version of tonnzor's patch with tests integrated with our
 test suite.

 Thanks for patch, ramiro!

 Please replace
 {{{
 return reversed(modules)
 }}}
 with
 {{{
 return list(reversed(modules))
 }}}

 because:
  * `reversed` function returns iterator, not a list as described in
 docstring
  * as `reversed` return iterator - that would lead to crash in
 `django/views/i18n.py` file on this line:
 {{{
 for module in [settings] + get_format_modules(reverse=True):
 }}}

-- 
Ticket URL: 
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] #3591: add support for custom app_label and verbose_name

[Django]

#3591: add support for custom app_label and verbose_name
+---
  Reporter:  jkocherhans| Owner:  adrian
Status:  reopened   | Milestone:
 Component:  Core framework |   Version:  SVN   
Resolution: |  Keywords:
 Stage:  Fixed on a branch  | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Comment (by Ciantic):

 Okay I think I found something from the branch. There will be App class
 for each app. This is a good thing, the verbose_name and app_label will be
 defined ''inside the app'', which is the right thing to do. See the
 [http://code.djangoproject.com/browser/django/branches/soc2010/app-
 loading/django/core/apps.py apps.py in GSoC 2010 branch] which allowes one
 to define verbose_name etc. Basically like defining new App class for each
 app in `__init__.py` or anywhere for that matter. After which the
 INSTALLED_APPS is just list of App classes.

 Btw it would be helpful if there were a README or something considering
 the branch, so one would know what and how the branch proposes to
 implement the feautre. Now I just "luckily" guessed the place for this
 `apps.py`.

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

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

Re: [Django] #15158: Server-crashing error: local variable 'loader_name' referenced before assignment

[Django]

#15158: Server-crashing error: local variable 'loader_name' referenced before
assignment
+---
  Reporter:  gsf| Owner:  ramiro
Status:  assigned   | Milestone:  1.3   
 Component:  Core framework |   Version:  SVN   
Resolution: |  Keywords:  regression
 Stage:  Ready for checkin  | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  1 
Needs_better_patch:  0  |  
+---
Changes (by jezdez):

  * 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.