date:20110112

Re: [Django] #14948: Broken routers in 1.2.4: type object 'ModelBase' has no attribute '_meta'

2011-01-12 Thread Django

#14948: Broken routers in 1.2.4: type object 'ModelBase' has no attribute 
'_meta'
---+
  Reporter:  shell_dweller | Owner:  nobody 
 
Status:  new   | Milestone:  1.3
 
 Component:  Database layer (models, ORM)  |   Version:  1.2
 
Resolution:|  Keywords:  router, 
ManyToManyField, blocker, regression
 Stage:  Accepted  | Has_patch:  1  
 
Needs_docs:  0 |   Needs_tests:  0  
 
Needs_better_patch:  1 |  
---+
Changes (by ramiro):

  * needs_better_patch:  0 => 1

Comment:

 Actually the fix for #13668 is a subset of the fixes proposed here. What
 would be needed to close this ticket is a test case for the
 django/db/models/base.py modifications, currently the tests proposed in
 the patch attached to this ticket, passes irrespective of if the changes
 to that file are present.

-- 
Ticket URL: 
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] #14948: Broken routers in 1.2.4: type object 'ModelBase' has no attribute '_meta'

2011-01-12 Thread Django

#14948: Broken routers in 1.2.4: type object 'ModelBase' has no attribute 
'_meta'
---+
  Reporter:  shell_dweller | Owner:  nobody 
 
Status:  new   | Milestone:  1.3
 
 Component:  Database layer (models, ORM)  |   Version:  1.2
 
Resolution:|  Keywords:  router, 
ManyToManyField, blocker, regression
 Stage:  Accepted  | Has_patch:  1  
 
Needs_docs:  0 |   Needs_tests:  0  
 
Needs_better_patch:  0 |  
---+
Comment (by ramiro):

 See also #13668 that reported a similar problem for M2M relationships that
 *don't* specify a ''through'' model. It was fixed in r15185 (and r15186
 for the 1.2.X branch). The tests modification might clash with the ones
 included in this patch and can be unified (!FaultyRouter and
 !AttributeErrorRouter).

-- 
Ticket URL: 
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] r15186 - in django/branches/releases/1.2.X: django/db/models/fields tests/regressiontests/multiple_database

2011-01-12 Thread noreply

Author: ramiro
Date: 2011-01-12 22:59:31 -0600 (Wed, 12 Jan 2011)
New Revision: 15186

Modified:
   django/branches/releases/1.2.X/django/db/models/fields/related.py
   
django/branches/releases/1.2.X/tests/regressiontests/multiple_database/tests.py
Log:
[1.2.X] Fixed #13668 -- Corrected database router methods invocation for 
ManyToMany fields without through models. Thanks craig.kimerer for the report 
and David Gouldin for the fix.

This also adds tests for r14857.

Backport of [15185] from trunk.

Modified: django/branches/releases/1.2.X/django/db/models/fields/related.py
===
--- django/branches/releases/1.2.X/django/db/models/fields/related.py   
2011-01-13 04:11:41 UTC (rev 15185)
+++ django/branches/releases/1.2.X/django/db/models/fields/related.py   
2011-01-13 04:59:31 UTC (rev 15186)
@@ -553,7 +553,7 @@
 raise TypeError("'%s' instance expected" % 
self.model._meta.object_name)
 else:
 new_ids.add(obj)
-db = router.db_for_write(self.through.__class__, 
instance=self.instance)
+db = router.db_for_write(self.through, instance=self.instance)
 vals = 
self.through._default_manager.using(db).values_list(target_field_name, 
flat=True)
 vals = vals.filter(**{
 source_field_name: self._pk_val,
@@ -601,7 +601,7 @@
 instance=self.instance, reverse=self.reverse,
 model=self.model, pk_set=old_ids)
 # Remove the specified objects from the join table
-db = router.db_for_write(self.through.__class__, 
instance=self.instance)
+db = router.db_for_write(self.through, instance=self.instance)
 self.through._default_manager.using(db).filter(**{
 source_field_name: self._pk_val,
 '%s__in' % target_field_name: old_ids
@@ -621,7 +621,7 @@
 signals.m2m_changed.send(sender=rel.through, 
action="pre_clear",
 instance=self.instance, reverse=self.reverse,
 model=self.model, pk_set=None)
-db = router.db_for_write(self.through.__class__, 
instance=self.instance)
+db = router.db_for_write(self.through, instance=self.instance)
 self.through._default_manager.using(db).filter(**{
 source_field_name: self._pk_val
 }).delete()

Modified: 
django/branches/releases/1.2.X/tests/regressiontests/multiple_database/tests.py
===
--- 
django/branches/releases/1.2.X/tests/regressiontests/multiple_database/tests.py 
2011-01-13 04:11:41 UTC (rev 15185)
+++ 
django/branches/releases/1.2.X/tests/regressiontests/multiple_database/tests.py 
2011-01-13 04:59:31 UTC (rev 15186)
@@ -1679,3 +1679,56 @@
 Book.objects.using(db).create(title='Dive into Python', 
published=datetime.date(2009, 5, 4))
 qs = Book.objects.all()
 self.assertEqual(qs.db, pickle.loads(pickle.dumps(qs)).db)
+
+class AttributeErrorRouter(object):
+"A router to test the exception handling of ConnectionRouter"
+def db_for_read(self, model, **hints):
+raise AttributeError
+
+def db_for_write(self, model, **hints):
+raise AttributeError
+
+class RouterAttributeErrorTestCase(TestCase):
+multi_db = True
+
+def setUp(self):
+self.old_routers = router.routers
+router.routers = [AttributeErrorRouter()]
+
+def tearDown(self):
+router.routers = self.old_routers
+
+def test_attribute_error(self):
+"Check that the AttributeError from AttributeErrorRouter bubbles up"
+dive = Book()
+dive.title="Dive into Python"
+dive.published = datetime.date(2009, 5, 4)
+self.assertRaises(AttributeError, dive.save)
+
+class ModelMetaRouter(object):
+"A router to ensure model arguments are real model classes"
+def db_for_write(self, model, **hints):
+if not hasattr(model, '_meta'):
+raise ValueError
+
+class RouterM2MThroughTestCase(TestCase):
+multi_db = True
+
+def setUp(self):
+self.old_routers = router.routers
+router.routers = [ModelMetaRouter()]
+
+def tearDown(self):
+router.routers = self.old_routers
+
+def test_m2m_through(self):
+b = Book.objects.create(title="Pro Django",
+published=datetime.date(2008, 12, 16))
+
+p = Person.objects.create(name="Marty Alchin")
+# test add
+b.authors.add(p)
+# test remove
+b.authors.remove(p)
+# test clear
+b.authors.clear()

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

[Changeset] r15185 - in django/trunk: django/db/models/fields tests/regressiontests/multiple_database

2011-01-12 Thread noreply

Author: ramiro
Date: 2011-01-12 22:11:41 -0600 (Wed, 12 Jan 2011)
New Revision: 15185

Modified:
   django/trunk/django/db/models/fields/related.py
   django/trunk/tests/regressiontests/multiple_database/tests.py
Log:
Fixed #13668 -- Corrected database router methods invocation for ManyToMany 
fields without through models. Thanks craig.kimerer for the report and David 
Gouldin for the fix.

This also adds tests for r14857.

Modified: django/trunk/django/db/models/fields/related.py
===
--- django/trunk/django/db/models/fields/related.py 2011-01-13 03:13:39 UTC 
(rev 15184)
+++ django/trunk/django/db/models/fields/related.py 2011-01-13 04:11:41 UTC 
(rev 15185)
@@ -555,7 +555,7 @@
 raise TypeError("'%s' instance expected" % 
self.model._meta.object_name)
 else:
 new_ids.add(obj)
-db = router.db_for_write(self.through.__class__, 
instance=self.instance)
+db = router.db_for_write(self.through, instance=self.instance)
 vals = 
self.through._default_manager.using(db).values_list(target_field_name, 
flat=True)
 vals = vals.filter(**{
 source_field_name: self._pk_val,
@@ -597,7 +597,7 @@
 else:
 old_ids.add(obj)
 # Work out what DB we're operating on
-db = router.db_for_write(self.through.__class__, 
instance=self.instance)
+db = router.db_for_write(self.through, instance=self.instance)
 # Send a signal to the other end if need be.
 if self.reverse or source_field_name == self.source_field_name:
 # Don't send the signal when we are deleting the
@@ -618,7 +618,7 @@
 model=self.model, pk_set=old_ids, using=db)
 
 def _clear_items(self, source_field_name):
-db = router.db_for_write(self.through.__class__, 
instance=self.instance)
+db = router.db_for_write(self.through, instance=self.instance)
 # source_col_name: the PK colname in join_table for the source 
object
 if self.reverse or source_field_name == self.source_field_name:
 # Don't send the signal when we are clearing the

Modified: django/trunk/tests/regressiontests/multiple_database/tests.py
===
--- django/trunk/tests/regressiontests/multiple_database/tests.py   
2011-01-13 03:13:39 UTC (rev 15184)
+++ django/trunk/tests/regressiontests/multiple_database/tests.py   
2011-01-13 04:11:41 UTC (rev 15185)
@@ -1791,3 +1791,56 @@
 b.authors.clear()
 self._write_to_default()
 self.assertEqual(receiver._database, "other")
+
+class AttributeErrorRouter(object):
+"A router to test the exception handling of ConnectionRouter"
+def db_for_read(self, model, **hints):
+raise AttributeError
+
+def db_for_write(self, model, **hints):
+raise AttributeError
+
+class RouterAttributeErrorTestCase(TestCase):
+multi_db = True
+
+def setUp(self):
+self.old_routers = router.routers
+router.routers = [AttributeErrorRouter()]
+
+def tearDown(self):
+router.routers = self.old_routers
+
+def test_attribute_error(self):
+"Check that the AttributeError from AttributeErrorRouter bubbles up"
+dive = Book()
+dive.title="Dive into Python"
+dive.published = datetime.date(2009, 5, 4)
+self.assertRaises(AttributeError, dive.save)
+
+class ModelMetaRouter(object):
+"A router to ensure model arguments are real model classes"
+def db_for_write(self, model, **hints):
+if not hasattr(model, '_meta'):
+raise ValueError
+
+class RouterM2MThroughTestCase(TestCase):
+multi_db = True
+
+def setUp(self):
+self.old_routers = router.routers
+router.routers = [ModelMetaRouter()]
+
+def tearDown(self):
+router.routers = self.old_routers
+
+def test_m2m_through(self):
+b = Book.objects.create(title="Pro Django",
+published=datetime.date(2008, 12, 16))
+
+p = Person.objects.create(name="Marty Alchin")
+# test add
+b.authors.add(p)
+# test remove
+b.authors.remove(p)
+# test clear
+b.authors.clear()

-- 
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] #15069: ValidationError message isn't helpful in tracking down the field that fails validation

2011-01-12 Thread Django

#15069: ValidationError message isn't helpful in tracking down the field that 
fails
validation
--+-
  Reporter:  Steve Steiner   | Owner:  
nobody   
Status:  new  | Milestone:  1.3 
 
 Component:  Core framework   |   Version:  1.2 
 
Resolution:   |  Keywords:  
ValidationError, exception, error message
 Stage:  Unreviewed   | Has_patch:  0   
 
Needs_docs:  0|   Needs_tests:  0   
 
Needs_better_patch:  0|  
--+-
Changes (by Steve Steiner ):

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

Comment:

 Sorry, the error is in:

  File "/xxx/django/db/models/fields/__init__.py", line
 710, in to_python

-- 
Ticket URL: 
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-upda...@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] #15069: ValidationError message isn't helpful in tracking down the field that fails validation

2011-01-12 Thread Django

#15069: ValidationError message isn't helpful in tracking down the field that 
fails
validation
---+
 Reporter:  Steve Steiner |   Owner:  nobody   
 
   Status:  new|   Milestone:  1.3  
 
Component:  Core framework | Version:  1.2  
 
 Keywords:  ValidationError, exception, error message  |   Stage:  
Unreviewed
Has_patch:  0  |  
---+
 raise exceptions.ValidationError(self.error_messages['invalid'])
 [Wed Jan 12 21:59:58 2011] [error] [client 10.177.133.202]
 ValidationError: [u'Enter a valid date/time in -MM-DD
 HH:MM[:ss[.uu]] format.']

 If the error message contained the invalid data, and, especially the name
 of the field that was being validated, that would be way more helpful.

 I'm going to go look for this in the source, but someone more familiar
 with this piece of code could probably make this change in pretty short
 order.

-- 
Ticket URL: 
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-upda...@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] r15184 - in django/branches/releases/1.2.X: django/utils tests/regressiontests/i18n

2011-01-12 Thread noreply

Author: ramiro
Date: 2011-01-12 21:13:39 -0600 (Wed, 12 Jan 2011)
New Revision: 15184

Modified:
   django/branches/releases/1.2.X/django/utils/formats.py
   django/branches/releases/1.2.X/tests/regressiontests/i18n/tests.py
Log:
[1.2.X] Fixed #15024 -- Ensure that choice of L10N format module used is stable 
given a stable setup of format modules in ll/ and ll_CC/ dirs. Thanks David 
Reynolds for the report and suggestions leading to the solution.

Backport of [15183] from trunk.

Modified: django/branches/releases/1.2.X/django/utils/formats.py
===
--- django/branches/releases/1.2.X/django/utils/formats.py  2011-01-13 
03:02:32 UTC (rev 15183)
+++ django/branches/releases/1.2.X/django/utils/formats.py  2011-01-13 
03:13:39 UTC (rev 15184)
@@ -24,7 +24,9 @@
 format_locations.append(settings.FORMAT_MODULE_PATH + '.%s')
 format_locations.reverse()
 locale = to_locale(lang)
-locales = set((locale, locale.split('_')[0]))
+locales = [locale]
+if '_' in locale:
+locales.append(locale.split('_')[0])
 for location in format_locations:
 for loc in locales:
 try:

Modified: django/branches/releases/1.2.X/tests/regressiontests/i18n/tests.py
===
--- django/branches/releases/1.2.X/tests/regressiontests/i18n/tests.py  
2011-01-13 03:02:32 UTC (rev 15183)
+++ django/branches/releases/1.2.X/tests/regressiontests/i18n/tests.py  
2011-01-13 03:13:39 UTC (rev 15184)
@@ -452,7 +452,20 @@
 settings.FORMAT_MODULE_PATH = old_format_module_path
 deactivate()
 
+def test_iter_format_modules_stability(self):
+"""
+Tests the iter_format_modules function always yields format modules in
+a stable and correct order in presence of both base ll and ll_CC 
formats.
+"""
+try:
+old_l10n, settings.USE_L10N = settings.USE_L10N, True
+en_format_mod = import_module('django.conf.locale.en.formats')
+en_gb_format_mod = 
import_module('django.conf.locale.en_GB.formats')
+self.assertEqual(list(iter_format_modules('en-gb')), 
[en_gb_format_mod, en_format_mod])
+finally:
+settings.USE_L10N = old_l10n
 
+
 class MiscTests(TestCase):
 
 def test_parse_spec_http_header(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-upda...@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] r15183 - in django/trunk: django/utils tests/regressiontests/i18n

2011-01-12 Thread noreply

Author: ramiro
Date: 2011-01-12 21:02:32 -0600 (Wed, 12 Jan 2011)
New Revision: 15183

Modified:
   django/trunk/django/utils/formats.py
   django/trunk/tests/regressiontests/i18n/tests.py
Log:
Fixed #15024 -- Ensure that choice of L10N format module used is stable given a 
stable setup of format modules in ll/ and ll_CC/ dirs. Thanks David Reynolds 
for the report and suggestions leading to the solution.

Modified: django/trunk/django/utils/formats.py
===
--- django/trunk/django/utils/formats.py2011-01-13 00:15:31 UTC (rev 
15182)
+++ django/trunk/django/utils/formats.py2011-01-13 03:02:32 UTC (rev 
15183)
@@ -24,7 +24,9 @@
 format_locations.append(settings.FORMAT_MODULE_PATH + '.%s')
 format_locations.reverse()
 locale = to_locale(lang)
-locales = set((locale, locale.split('_')[0]))
+locales = [locale]
+if '_' in locale:
+locales.append(locale.split('_')[0])
 for location in format_locations:
 for loc in locales:
 try:

Modified: django/trunk/tests/regressiontests/i18n/tests.py
===
--- django/trunk/tests/regressiontests/i18n/tests.py2011-01-13 00:15:31 UTC 
(rev 15182)
+++ django/trunk/tests/regressiontests/i18n/tests.py2011-01-13 03:02:32 UTC 
(rev 15183)
@@ -480,6 +480,19 @@
 settings.FORMAT_MODULE_PATH = old_format_module_path
 deactivate()
 
+def test_iter_format_modules_stability(self):
+"""
+Tests the iter_format_modules function always yields format modules in
+a stable and correct order in presence of both base ll and ll_CC 
formats.
+"""
+try:
+old_l10n, settings.USE_L10N = settings.USE_L10N, True
+en_format_mod = import_module('django.conf.locale.en.formats')
+en_gb_format_mod = 
import_module('django.conf.locale.en_GB.formats')
+self.assertEqual(list(iter_format_modules('en-gb')), 
[en_gb_format_mod, en_format_mod])
+finally:
+settings.USE_L10N = old_l10n
+
 def test_localize_templatetag_and_filter(self):
 """
 Tests the {% localize %} templatetag

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@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] #14880: raw_id_fields in admin does not work when limit_choices_to dictionary has value=False

2011-01-12 Thread Django

#14880: raw_id_fields in admin does not work when limit_choices_to dictionary 
has
value=False
---+
  Reporter:  smallm...@gmail.com   | Owner:  nobody 
Status:  new   | Milestone:  1.3
 Component:  django.contrib.admin  |   Version:  1.2
Resolution:|  Keywords:  blocker, regression
 Stage:  Accepted  | Has_patch:  0  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Comment (by lukeplant):

 I don't think this was ever working. I have tried with a real life
 project, and with tests, and I get failure on 1.2.3.  On 1.2.4 I get the
 suspicious operation thing. The original reporter was using 1.2.1
 apparently, so this doesn't look like a regression.

 I will attach patches for the tests - against 1.2.3, 1.2.4, most recent
 1.2.X and most recent trunk, all slightly different.

-- 
Ticket URL: 
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-upda...@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] #15068: initial_data fixtures using natural keys fail in tests with multiple databases

2011-01-12 Thread Django

#15068: initial_data fixtures using natural keys fail in tests with multiple
databases
+---
  Reporter:  dcramer| Owner:  nobody
Status:  new| Milestone:
 Component:  Uncategorized  |   Version:  1.2   
Resolution: |  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by dcramer):

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

Comment:

 A resolution which may help with some other bad behavior would be to
 create all databases and then process fixtures. This would also stop the
 additional unnecessary parsing of the fixtures files repeatedly (N
 databases).

-- 
Ticket URL: 
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-upda...@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] #15024: The order of the list returned by django.utils.formats.get_format_modules changes since version 1.2.4

2011-01-12 Thread Django

#15024: The order of the list returned by 
django.utils.formats.get_format_modules
changes since version 1.2.4
---+
  Reporter:  DavidReynolds | Owner:  nobody 
Status:  reopened  | Milestone:  1.3
 Component:  Internationalization  |   Version:  1.2
Resolution:|  Keywords:  blocker, regression
 Stage:  Accepted  | Has_patch:  1  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Changes (by ramiro):

  * has_patch:  0 => 1

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@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] #15068: initial_data fixtures using natural keys fail in tests with multiple databases

2011-01-12 Thread Django

#15068: initial_data fixtures using natural keys fail in tests with multiple
databases
---+
 Reporter:  dcramer|   Owner:  nobody
   Status:  new|   Milestone:
Component:  Uncategorized  | Version:  1.2   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 If a fixture using natural keys is referenced before that database is
 created (in tests), then the fixture fails to load due to a "table does
 not exist" error (though may also throw database does not exist, since it
 may not have been created yet).

 The reason for this is that objects are instantiated before they are
 actually created in the database, but they mapper only does this if
 they're not using natural keys. In the case where they are, it attempts to
 look them up from the database, rather than the existing in-memory
 instances.

-- 
Ticket URL: 
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-upda...@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] #15067: base36_to_int returns a long in certain situations

2011-01-12 Thread Django

#15067: base36_to_int returns a long in certain situations
+---
 Reporter:  Garthex |   Owner:  nobody
   Status:  new |   Milestone:
Component:  Core framework  | Version:  1.2   
 Keywords:  |   Stage:  Unreviewed
Has_patch:  0   |  
+---
 {{{django.utils.http.base36_to_int}}} uses the {{{int()}}} cast, which
 returns a {{{long}}} if it can't fit within an {{{int}}}. The input is
 truncated to 13 characters before calling {{{int()}}}, but if you supply
 13 Z's you receive a {{{long}}} instead of an {{{int}}}.

 {{{
 >>> type(int('z', 36))
 
 }}}

 This causes an {{{OverflowError}}} with
 {{{django.contrib.auth.views.password_reset_done}}} if you supply
 {{{uidb36='z'}}} and {{{token='123'}}}

 Note: testing of the {{{password_reset_done}}} was done on version 1.2.3
 and testing of {{{base36_to_int}}} was done on 1.2.3 and the 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-upda...@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] #15025: Different template rendering semantics since r14992

2011-01-12 Thread Django

#15025: Different template rendering semantics since r14992
--+-
  Reporter:  donspaulding | Owner:  nobody 
Status:  new  | Milestone:  1.3
 Component:  Template system  |   Version:  SVN
Resolution:   |  Keywords:  blocker, regression
 Stage:  Accepted | Has_patch:  1  
Needs_docs:  0|   Needs_tests:  0  
Needs_better_patch:  0|  
--+-
Comment (by ambv):

 I encountered this bug as well (on improperly configured inlines for the
 admin) and the patch fixed it for me. Now it correctly shows a debug
 screen.

-- 
Ticket URL: 
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-upda...@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] r15182 - in django/branches/releases/1.2.X: django/db/models tests/modeltests/model_forms tests/modeltests/validation

2011-01-12 Thread noreply

Author: ramiro
Date: 2011-01-12 18:15:31 -0600 (Wed, 12 Jan 2011)
New Revision: 15182

Modified:
   django/branches/releases/1.2.X/django/db/models/base.py
   django/branches/releases/1.2.X/tests/modeltests/model_forms/mforms.py
   django/branches/releases/1.2.X/tests/modeltests/model_forms/models.py
   django/branches/releases/1.2.X/tests/modeltests/model_forms/tests.py
   django/branches/releases/1.2.X/tests/modeltests/validation/models.py
   django/branches/releases/1.2.X/tests/modeltests/validation/test_unique.py
Log:
[1.2.X] Fixed #14951 -- Made the unique_for_{date,month,year} model field 
constraints to not fail when the related DateField is empty.

Existing modelforms tests were extended to cover this case and an equivalent 
set of tests was added for the model functionality.

Backport of [15167] from trunk.

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-12 
23:59:49 UTC (rev 15181)
+++ django/branches/releases/1.2.X/django/db/models/base.py 2011-01-13 
00:15:31 UTC (rev 15182)
@@ -730,7 +730,7 @@
 called from a ModelForm, some fields may have been excluded; we can't
 perform a unique check on a model that is missing fields involved
 in that check.
-Fields that did not validate should also be exluded, but they need
+Fields that did not validate should also be excluded, but they need
 to be passed in via the exclude argument.
 """
 if exclude is None:
@@ -822,6 +822,8 @@
 # there's a ticket to add a date lookup, we can remove this special
 # case if that makes it's way in
 date = getattr(self, unique_for)
+if date is None:
+continue
 if lookup_type == 'date':
 lookup_kwargs['%s__day' % unique_for] = date.day
 lookup_kwargs['%s__month' % unique_for] = date.month

Modified: django/branches/releases/1.2.X/tests/modeltests/model_forms/mforms.py
===
--- django/branches/releases/1.2.X/tests/modeltests/model_forms/mforms.py   
2011-01-12 23:59:49 UTC (rev 15181)
+++ django/branches/releases/1.2.X/tests/modeltests/model_forms/mforms.py   
2011-01-13 00:15:31 UTC (rev 15182)
@@ -1,7 +1,8 @@
 from django import forms
 from django.forms import ModelForm
 
-from models import Product, Price, Book, DerivedBook, ExplicitPK, Post, 
DerivedPost, Writer
+from models import (Product, Price, Book, DerivedBook, ExplicitPK, Post,
+DerivedPost, Writer, FlexibleDatePost)
 
 class ProductForm(ModelForm):
 class Meta:
@@ -37,3 +38,7 @@
 
class Meta:
model = Writer
+
+class FlexDatePostForm(ModelForm):
+class Meta:
+model = FlexibleDatePost

Modified: django/branches/releases/1.2.X/tests/modeltests/model_forms/models.py
===
--- django/branches/releases/1.2.X/tests/modeltests/model_forms/models.py   
2011-01-12 23:59:49 UTC (rev 15181)
+++ django/branches/releases/1.2.X/tests/modeltests/model_forms/models.py   
2011-01-13 00:15:31 UTC (rev 15182)
@@ -236,6 +236,12 @@
 name = models.CharField(max_length=10)
 markup = MarkupField()
 
+class FlexibleDatePost(models.Model):
+title = models.CharField(max_length=50, unique_for_date='posted', 
blank=True)
+slug = models.CharField(max_length=50, unique_for_year='posted', 
blank=True)
+subtitle = models.CharField(max_length=50, unique_for_month='posted', 
blank=True)
+posted = models.DateField(blank=True, null=True)
+
 __test__ = {'API_TESTS': """
 >>> from django import forms
 >>> from django.forms.models import ModelForm, model_to_dict

Modified: django/branches/releases/1.2.X/tests/modeltests/model_forms/tests.py
===
--- django/branches/releases/1.2.X/tests/modeltests/model_forms/tests.py
2011-01-12 23:59:49 UTC (rev 15181)
+++ django/branches/releases/1.2.X/tests/modeltests/model_forms/tests.py
2011-01-13 00:15:31 UTC (rev 15182)
@@ -1,9 +1,10 @@
 import datetime
 from django.test import TestCase
 from django import forms
-from models import Category, Writer, Book, DerivedBook, Post
-from mforms import (ProductForm, PriceForm, BookForm, DerivedBookForm, 
-   ExplicitPKForm, PostForm, DerivedPostForm, CustomWriterForm)
+from models import Category, Writer, Book, DerivedBook, Post, FlexibleDatePost
+from mforms import (ProductForm, PriceForm, BookForm, DerivedBookForm,
+   ExplicitPKForm, PostForm, DerivedPostForm, CustomWriterForm,
+   FlexDatePostForm)
 
 
 class IncompleteCategoryFormWithFields(forms.ModelForm):
@@ -183,3 +184,16 @@
 "slug": "Django 1.0", 'posted': '2008-09-03'}, instance=p)
 self.assertT

Re: [Django] #15062: r14389 breaks getattr on Manager subclasses

2011-01-12 Thread Django

#15062: r14389 breaks getattr on Manager subclasses
---+
  Reporter:  clelland  | Owner:  nobody
Status:  closed| Milestone:  1.3   
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:  worksforme|  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by lukeplant):

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

Comment:

 I have followed this as exactly as I could, with a new project, and cannot
 reproduce it. For reference, I put the snippet directly in a single
 models.py, like this, just in case it makes a difference:
 {{{
 #!python
 from django.db import models
 from django.contrib.auth.models import User

 class QuerySetManager(models.Manager):
 def get_query_set(self):
 return self.model.QuerySet(self.model)

 class TestModel(models.Model):
user = models.ForeignKey(User)
string = models.CharField(max_length=64, null=True, blank=True)
objects = QuerySetManager()
class QuerySet(models.query.QuerySet):
pass
 }}}

 I tried the example code both using "./manage.py shell", and using
 DJANGO_SETTINGS_MODULE and normal path stuff (I thought this might be
 relevant, given the points below) and both ways worked fine.

 I notice 2 very strange things in your stacktrace:

 1) You have django/db/models/fields/related.py from two different places
 - /Users/ian/.virtualenvs/'''testcode'''/lib/python2.6/site-packages/ and
 /Users/ian/.virtualenvs/'''egather'''/lib/python2.6/site-packages/

 2) The maximum recursion depth exception appears to come after a section
 of stracktrace which doesn't seem to be exhibiting the mutual recursion
 that is displayed earlier.

 It seems like something very funny is going on.  So I'm going to close
 WORKSFORME - please re-open if you can provide more details that would
 allow us to reproduce this.

-- 
Ticket URL: 
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-upda...@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] r15181 - django/branches/releases/1.2.X/django/contrib/admin/media/css

2011-01-12 Thread noreply

Author: ramiro
Date: 2011-01-12 17:59:49 -0600 (Wed, 12 Jan 2011)
New Revision: 15181

Modified:
   django/branches/releases/1.2.X/django/contrib/admin/media/css/widgets.css
Log:
[1.2.X] Fixed #11434 -- Corrected style of arrow buttons located at the center 
of filter_{horizontal|vertical} m2m widgets to not give them focus borders that 
span from the left page border. Thanks defaultwombat for the report and patch.

Backport of [15144] from trunk.

Modified: 
django/branches/releases/1.2.X/django/contrib/admin/media/css/widgets.css
===
--- django/branches/releases/1.2.X/django/contrib/admin/media/css/widgets.css   
2011-01-12 23:57:45 UTC (rev 15180)
+++ django/branches/releases/1.2.X/django/contrib/admin/media/css/widgets.css   
2011-01-12 23:59:49 UTC (rev 15181)
@@ -70,6 +70,7 @@
 height: 16px;
 display: block;
 text-indent: -3000px;
+overflow: hidden;
 }
 
 .selector-add {

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@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] r15180 - django/branches/releases/1.2.X/django/contrib/admin/media/js/admin

2011-01-12 Thread noreply

Author: ramiro
Date: 2011-01-12 17:57:45 -0600 (Wed, 12 Jan 2011)
New Revision: 15180

Modified:
   
django/branches/releases/1.2.X/django/contrib/admin/media/js/admin/DateTimeShortcuts.js
Log:
[1.2.X] Fixed #11414 -- Made sure the calendar and clock popup windows in the 
admin don't have a negative vertical position. Thanks uipko for the report and 
fix.

Backport of [15143] from trunk.

Modified: 
django/branches/releases/1.2.X/django/contrib/admin/media/js/admin/DateTimeShortcuts.js
===
--- 
django/branches/releases/1.2.X/django/contrib/admin/media/js/admin/DateTimeShortcuts.js
 2011-01-12 23:54:17 UTC (rev 15179)
+++ 
django/branches/releases/1.2.X/django/contrib/admin/media/js/admin/DateTimeShortcuts.js
 2011-01-12 23:57:45 UTC (rev 15180)
@@ -94,7 +94,7 @@
 openClock: function(num) {
 var clock_box = 
document.getElementById(DateTimeShortcuts.clockDivName+num)
 var clock_link = 
document.getElementById(DateTimeShortcuts.clockLinkName+num)
-
+
 // Recalculate the clockbox position
 // is it left-to-right or right-to-left layout ?
 if (getStyle(document.body,'direction')!='rtl') {
@@ -107,8 +107,8 @@
 //   (it returns as it was left aligned), needs to be fixed.
 clock_box.style.left = findPosX(clock_link) - 110 + 'px';
 }
-clock_box.style.top = findPosY(clock_link) - 30 + 'px';
-
+clock_box.style.top = Math.max(0, findPosY(clock_link) - 30) + 'px';
+
 // Show the clock box
 clock_box.style.display = 'block';
 addEvent(window.document, 'click', function() { 
DateTimeShortcuts.dismissClock(num); return true; });
@@ -224,8 +224,8 @@
 //   (it returns as it was left aligned), needs to be fixed.
 cal_box.style.left = findPosX(cal_link) - 180 + 'px';
 }
-cal_box.style.top = findPosY(cal_link) - 75 + 'px';
-
+cal_box.style.top = Math.max(0, findPosY(cal_link) - 75) + 'px';
+
 cal_box.style.display = 'block';
 addEvent(window.document, 'click', function() { 
DateTimeShortcuts.dismissCalendar(num); return true; });
 },

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@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] r15179 - django/branches/releases/1.2.X/django/contrib/admin

2011-01-12 Thread noreply

Author: ramiro
Date: 2011-01-12 17:54:17 -0600 (Wed, 12 Jan 2011)
New Revision: 15179

Modified:
   django/branches/releases/1.2.X/django/contrib/admin/options.py
Log:
[1.2.X] Fixed #11124 -- Expanded docstrings of the ModelAdmin 
has_{change|delete}_permission methods to make it clear they can be overriden 
to implement per-instance permission checks. Refs #12642.

Backport of [15126] from trunk.

Modified: django/branches/releases/1.2.X/django/contrib/admin/options.py
===
--- django/branches/releases/1.2.X/django/contrib/admin/options.py  
2011-01-12 23:30:47 UTC (rev 15178)
+++ django/branches/releases/1.2.X/django/contrib/admin/options.py  
2011-01-12 23:54:17 UTC (rev 15179)
@@ -322,17 +322,23 @@
 media = property(_media)
 
 def has_add_permission(self, request):
-"Returns True if the given request has permission to add an object."
+"""
+Returns True if the given request has permission to add an object.
+Can be overriden by the user in subclasses.
+"""
 opts = self.opts
 return request.user.has_perm(opts.app_label + '.' + 
opts.get_add_permission())
 
 def has_change_permission(self, request, obj=None):
 """
 Returns True if the given request has permission to change the given
-Django model instance.
+Django model instance, the default implementation doesn't examine the
+`obj` parameter.
 
-If `obj` is None, this should return True if the given request has
-permission to change *any* object of the given type.
+Can be overriden by the user in subclasses. In such case it should
+return True if the given request has permission to change the `obj`
+model instance. If `obj` is None, this should return True if the given
+request has permission to change *any* object of the given type.
 """
 opts = self.opts
 return request.user.has_perm(opts.app_label + '.' + 
opts.get_change_permission())
@@ -340,10 +346,13 @@
 def has_delete_permission(self, request, obj=None):
 """
 Returns True if the given request has permission to change the given
-Django model instance.
+Django model instance, the default implementation doesn't examine the
+`obj` parameter.
 
-If `obj` is None, this should return True if the given request has
-permission to delete *any* object of the given type.
+Can be overriden by the user in subclasses. In such case it should
+return True if the given request has permission to delete the `obj`
+model instance. If `obj` is None, this should return True if the given
+request has permission to delete *any* object of the given type.
 """
 opts = self.opts
 return request.user.has_perm(opts.app_label + '.' + 
opts.get_delete_permission())

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@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] r15178 - django/trunk/tests/regressiontests/admin_views

2011-01-12 Thread noreply

Author: ramiro
Date: 2011-01-12 17:30:47 -0600 (Wed, 12 Jan 2011)
New Revision: 15178

Modified:
   django/trunk/tests/regressiontests/admin_views/models.py
   django/trunk/tests/regressiontests/admin_views/tests.py
Log:
Added tests demonstrating that filtering lookup expression that involve model 
with inheritance schemes aren't incorrectly blacklisted by the r15031 security 
fix. Refs. #15032.

Modified: django/trunk/tests/regressiontests/admin_views/models.py
===
--- django/trunk/tests/regressiontests/admin_views/models.py2011-01-12 
23:25:33 UTC (rev 15177)
+++ django/trunk/tests/regressiontests/admin_views/models.py2011-01-12 
23:30:47 UTC (rev 15178)
@@ -615,6 +615,17 @@
 class AlbumAdmin(admin.ModelAdmin):
 list_filter = ['title']
 
+class Employee(Person):
+code = models.CharField(max_length=20)
+
+class WorkHour(models.Model):
+datum = models.DateField()
+employee = models.ForeignKey(Employee)
+
+class WorkHourAdmin(admin.ModelAdmin):
+list_display = ('datum', 'employee')
+list_filter = ('employee',)
+
 admin.site.register(Article, ArticleAdmin)
 admin.site.register(CustomArticle, CustomArticleAdmin)
 admin.site.register(Section, save_as=True, inlines=[ArticleInline])
@@ -646,6 +657,7 @@
 admin.site.register(PlotDetails)
 admin.site.register(CyclicOne)
 admin.site.register(CyclicTwo)
+admin.site.register(WorkHour, WorkHourAdmin)
 
 # We intentionally register Promo and ChapterXtra1 but not Chapter nor 
ChapterXtra2.
 # That way we cover all four cases:

Modified: django/trunk/tests/regressiontests/admin_views/tests.py
===
--- django/trunk/tests/regressiontests/admin_views/tests.py 2011-01-12 
23:25:33 UTC (rev 15177)
+++ django/trunk/tests/regressiontests/admin_views/tests.py 2011-01-12 
23:30:47 UTC (rev 15178)
@@ -33,7 +33,7 @@
 FooAccount, Gallery, ModelWithStringPrimaryKey, \
 Person, Persona, Picture, Podcast, Section, Subscriber, Vodcast, \
 Language, Collector, Widget, Grommet, DooHickey, FancyDoodad, Whatsit, \
-Category, Post, Plot, FunkyTag, Chapter, Book, Promo
+Category, Post, Plot, FunkyTag, Chapter, Book, Promo, WorkHour, Employee
 
 
 class AdminViewBasicTest(TestCase):
@@ -382,6 +382,16 @@
 except SuspiciousOperation:
 self.fail("Filters should be allowed if they involve a local field 
without the need to whitelist them in list_filter or date_hierarchy.")
 
+e1 = Employee.objects.create(name='Anonymous', gender=1, age=22, 
alive=True, code='123')
+e2 = Employee.objects.create(name='Visitor', gender=2, age=19, 
alive=True, code='124')
+WorkHour.objects.create(datum=datetime.datetime.now(), employee=e1)
+WorkHour.objects.create(datum=datetime.datetime.now(), employee=e2)
+response = self.client.get("/test_admin/admin/admin_views/workhour/")
+self.assertEqual(response.status_code, 200)
+self.assertContains(response, 'employee__person_ptr__exact')
+response = 
self.client.get("/test_admin/admin/admin_views/workhour/?employee__person_ptr__exact=%d"
 % e1.pk)
+self.assertEqual(response.status_code, 200)
+
 class SaveAsTests(TestCase):
 fixtures = ['admin-views-users.xml','admin-views-person.xml']
 

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@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] r15177 - in django/branches/releases/1.2.X: django/contrib/admin tests/regressiontests/admin_views

2011-01-12 Thread noreply

Author: ramiro
Date: 2011-01-12 17:25:33 -0600 (Wed, 12 Jan 2011)
New Revision: 15177

Modified:
   django/branches/releases/1.2.X/django/contrib/admin/options.py
   django/branches/releases/1.2.X/tests/regressiontests/admin_views/models.py
   django/branches/releases/1.2.X/tests/regressiontests/admin_views/tests.py
Log:
[1.2.X] Fixed #15032 -- Replaced 1.2.X implementation of admin changelist 
filtering security fix (r15031/r15033) with the one from trunk so another valid 
filter usage scenario (using model inheritance) is still possible. Thanks rene 
for reporting this.

Modified: django/branches/releases/1.2.X/django/contrib/admin/options.py
===
--- django/branches/releases/1.2.X/django/contrib/admin/options.py  
2011-01-12 20:45:01 UTC (rev 15176)
+++ django/branches/releases/1.2.X/django/contrib/admin/options.py  
2011-01-12 23:25:33 UTC (rev 15177)
@@ -195,8 +195,21 @@
 
 # Special case -- foo__id__exact and foo__id queries are implied
 # if foo has been specificially included in the lookup list; so
-# drop __id if it is the last part.
-if len(parts) > 1 and parts[-1] == self.model._meta.pk.name:
+# drop __id if it is the last part. However, first we need to find
+# the pk attribute name.
+model = self.model
+pk_attr_name = None
+for part in parts[:-1]:
+field, _, _, _ = model._meta.get_field_by_name(part)
+if hasattr(field, 'rel'):
+model = field.rel.to
+pk_attr_name = model._meta.pk.name
+elif isinstance(field, RelatedObject):
+model = field.model
+pk_attr_name = model._meta.pk.name
+else:
+pk_attr_name = None
+if pk_attr_name and len(parts) > 1 and parts[-1] == pk_attr_name:
 parts.pop()
 
 try:

Modified: 
django/branches/releases/1.2.X/tests/regressiontests/admin_views/models.py
===
--- django/branches/releases/1.2.X/tests/regressiontests/admin_views/models.py  
2011-01-12 20:45:01 UTC (rev 15176)
+++ django/branches/releases/1.2.X/tests/regressiontests/admin_views/models.py  
2011-01-12 23:25:33 UTC (rev 15177)
@@ -588,6 +588,17 @@
 class AlbumAdmin(admin.ModelAdmin):
 list_filter = ['title']
 
+class Employee(Person):
+code = models.CharField(max_length=20)
+
+class WorkHour(models.Model):
+datum = models.DateField()
+employee = models.ForeignKey(Employee)
+
+class WorkHourAdmin(admin.ModelAdmin):
+list_display = ('datum', 'employee')
+list_filter = ('employee',)
+
 admin.site.register(Article, ArticleAdmin)
 admin.site.register(CustomArticle, CustomArticleAdmin)
 admin.site.register(Section, save_as=True, inlines=[ArticleInline])
@@ -619,6 +630,7 @@
 admin.site.register(PlotDetails)
 admin.site.register(CyclicOne)
 admin.site.register(CyclicTwo)
+admin.site.register(WorkHour, WorkHourAdmin)
 
 # We intentionally register Promo and ChapterXtra1 but not Chapter nor 
ChapterXtra2.
 # That way we cover all four cases:

Modified: 
django/branches/releases/1.2.X/tests/regressiontests/admin_views/tests.py
===
--- django/branches/releases/1.2.X/tests/regressiontests/admin_views/tests.py   
2011-01-12 20:45:01 UTC (rev 15176)
+++ django/branches/releases/1.2.X/tests/regressiontests/admin_views/tests.py   
2011-01-12 23:25:33 UTC (rev 15177)
@@ -28,7 +28,7 @@
 FooAccount, Gallery, ModelWithStringPrimaryKey, \
 Person, Persona, Picture, Podcast, Section, Subscriber, Vodcast, \
 Language, Collector, Widget, Grommet, DooHickey, FancyDoodad, Whatsit, \
-Category, Post, Plot, FunkyTag
+Category, Post, Plot, FunkyTag, WorkHour, Employee
 
 
 class AdminViewBasicTest(TestCase):
@@ -311,6 +311,16 @@
 except SuspiciousOperation:
 self.fail("Filters should be allowed if they involve a local field 
without the need to whitelist them in list_filter or date_hierarchy.")
 
+e1 = Employee.objects.create(name='Anonymous', gender=1, age=22, 
alive=True, code='123')
+e2 = Employee.objects.create(name='Visitor', gender=2, age=19, 
alive=True, code='124')
+WorkHour.objects.create(datum=datetime.datetime.now(), employee=e1)
+WorkHour.objects.create(datum=datetime.datetime.now(), employee=e2)
+response = self.client.get("/test_admin/admin/admin_views/workhour/")
+self.assertEqual(response.status_code, 200)
+self.assertContains(response, 'employee__person_ptr__exact')
+response = 
self.client.get("/test_admin/admin/admin_views/workhour/?employee__person_ptr__exact=%d"
 % e1.pk)
+self.assertEqual(response.status_code, 200)
+
 class SaveAsTests(TestCase):
 fixtures = ['admin-views-users.xml','admin-views-person.xml']
 

-- 
You received this message because you are subs

[Django] #15066: GzipMiddleware does not work with generator-created responses

2011-01-12 Thread Django

#15066: GzipMiddleware does not work with generator-created responses
-+--
 Reporter:  Andreas Sommer   |   Owner:  nobody
   Status:  new  |   Milestone:
Component:  Uncategorized| Version:  SVN   
 Keywords:  gzip |   Stage:  Unreviewed
Has_patch:  1|  
-+--
 With a response like

 {{{
 def gen():
 yield "something"
 return HttpResponse(gen())
 }}}

 and a HTTP 200 status code, the `GzipMiddleware` will always return an
 empty response because it accesses the `response.content` property twice.
 That means the `_get_content` getter applies `''.join` twice to the
 generator, but a generator can only be iterated once.

 See patch proposal.

-- 
Ticket URL: 
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-upda...@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] #11572: Very high memory usage by big sitemaps

2011-01-12 Thread Django

#11572: Very high memory usage by big sitemaps
---+
  Reporter:  riklaunim | Owner:  nobody
Status:  closed| Milestone:
 Component:  Contrib apps  |   Version:  1.0   
Resolution:  invalid   |  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by EmilStenstrom):

 @ubernostrum: This issue took down our site and we've been debugging it
 for a week straight. Who thought a sitemap could make the apache process
 consume too much memory and finally get the process killed?

 Anyway. I believe two things should be done to prevent this from happening
 to sites that grow:

 1) Lower the default number of elements that get inserted into a sitemap.
 Let people up this value with an override to be the old one.

 2) The memory is not released after the sitemap has been generated (I
 think). Tested on Windows by looking at the memory used with python.exe
 before and after generating the sitemap (13 Mb before, 87 Mb after). Also
 looking at the RSS memory on an ununtu server, it jumps 90 Mb when
 accessing the sitemap, and does not go down when it's done.

 I think this bug should be opened again.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@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] #14705: Model Field Order not influenced by MRO of superclasses

2011-01-12 Thread Django

#14705: Model Field Order not influenced by MRO of superclasses
-+--
  Reporter:  vanschelven | Owner:  nobody
Status:  new | Milestone:
 Component:  Core framework  |   Version:  1.2   
Resolution:  |  Keywords:
 Stage:  Accepted| Has_patch:  1 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by anonymous):

  * has_patch:  0 => 1
  * component:  Uncategorized => Core framework

-- 
Ticket URL: 
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-upda...@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] #15065: Installing django.contrib.gis causes all configured databases to use spatial DB engine

2011-01-12 Thread Django

#15065: Installing django.contrib.gis causes all configured databases to use
spatial DB engine
---+
  Reporter:  clay  | Owner:  nobody 
Status:  closed| Milestone: 
 Component:  Database layer (models, ORM)  |   Version:  1.2
Resolution:  invalid   |  Keywords:  postgis
 Stage:  Unreviewed| Has_patch:  0  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Changes (by clay):

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

Comment:

 User error: we were using the short form engine (postgresql_psycopg2)
 instead of the long form (django.db.backends.postgresql_psycopg2) in our
 settings module. Changing that to the long form allows us to use mixed
 spatial and non-spatial dbs.

-- 
Ticket URL: 
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-upda...@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] r15176 - in django/branches/releases/1.1.X: django/contrib/admin tests/regressiontests/admin_views

2011-01-12 Thread noreply

Author: ramiro
Date: 2011-01-12 14:45:01 -0600 (Wed, 12 Jan 2011)
New Revision: 15176

Modified:
   django/branches/releases/1.1.X/django/contrib/admin/options.py
   django/branches/releases/1.1.X/tests/regressiontests/admin_views/models.py
   django/branches/releases/1.1.X/tests/regressiontests/admin_views/tests.py
Log:
[1.1.X] Fixed #14999 -- Ensure that filters on local fields are allowed, and 
aren't caught as a security problem. Thanks to medhat for the report.

Backport of r15139 from trunk.

Modified: django/branches/releases/1.1.X/django/contrib/admin/options.py
===
--- django/branches/releases/1.1.X/django/contrib/admin/options.py  
2011-01-12 13:39:31 UTC (rev 15175)
+++ django/branches/releases/1.1.X/django/contrib/admin/options.py  
2011-01-12 20:45:01 UTC (rev 15176)
@@ -194,6 +194,8 @@
 # later.
 return True
 else:
+if len(parts) == 1:
+return True
 clean_lookup = LOOKUP_SEP.join(parts)
 return clean_lookup in self.list_filter or clean_lookup == 
self.date_hierarchy
 

Modified: 
django/branches/releases/1.1.X/tests/regressiontests/admin_views/models.py
===
--- django/branches/releases/1.1.X/tests/regressiontests/admin_views/models.py  
2011-01-12 13:39:31 UTC (rev 15175)
+++ django/branches/releases/1.1.X/tests/regressiontests/admin_views/models.py  
2011-01-12 20:45:01 UTC (rev 15176)
@@ -168,6 +168,7 @@
 )
 name = models.CharField(max_length=100)
 gender = models.IntegerField(choices=GENDER_CHOICES)
+age = models.IntegerField(default=21)
 alive = models.BooleanField()
 
 def __unicode__(self):

Modified: 
django/branches/releases/1.1.X/tests/regressiontests/admin_views/tests.py
===
--- django/branches/releases/1.1.X/tests/regressiontests/admin_views/tests.py   
2011-01-12 13:39:31 UTC (rev 15175)
+++ django/branches/releases/1.1.X/tests/regressiontests/admin_views/tests.py   
2011-01-12 20:45:01 UTC (rev 15176)
@@ -295,6 +295,11 @@
 self.client.get, 
"/test_admin/admin/admin_views/album/?owner__email__startswith=fuzzy"
 )
 
+try:
+self.client.get("/test_admin/admin/admin_views/person/?age__gt=30")
+except SuspiciousOperation:
+self.fail("Filters should be allowed if they involve a local field 
without the need to whitelist them in list_filter or date_hierarchy.")
+
 class SaveAsTests(TestCase):
 fixtures = ['admin-views-users.xml','admin-views-person.xml']
 
@@ -306,7 +311,7 @@
 
 def test_save_as_duplication(self):
 """Ensure save as actually creates a new person"""
-post_data = {'_saveasnew':'', 'name':'John M', 'gender':1}
+post_data = {'_saveasnew':'', 'name':'John M', 'gender':1, 'age': 42}
 response = self.client.post('/test_admin/admin/admin_views/person/1/', 
post_data)
 self.assertEqual(len(Person.objects.filter(name='John M')), 1)
 self.assertEqual(len(Person.objects.filter(id=1)), 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-upda...@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] #15065: Installing django.contrib.gis causes all configured databases to use spatial DB engine

2011-01-12 Thread Django

#15065: Installing django.contrib.gis causes all configured databases to use
spatial DB engine
--+-
 Reporter:  clay  |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Database layer (models, ORM)  | Version:  1.2   
 Keywords:  postgis   |   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 When using multiple databases, it is sometimes desirable to configure some
 as spatial databases (e.g., using a django.contrib.gis.db.backends.*
 engine), while configuring others as non-spatial (e.g., using the
 postgresql_psycopg2 engine). However, if 'django.contrib.gis' is in
 INSTALLED_APPS, {{{django/db/__init__.py}}} subversively changes all
 configured non-spatial database engines to their spatial counterparts.

-- 
Ticket URL: 
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-upda...@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] #15064: DJANGO_SETTINGS_MODULE doesn't work with runserver

2011-01-12 Thread Django

#15064: DJANGO_SETTINGS_MODULE doesn't work with runserver
---+
 Reporter:  olau   |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Uncategorized  | Version:  1.2   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 The help for --settings claims that one can use DJANGO_SETTINGS_MODULE to
 specify the settings module as an alternative to --settings. This seems to
 be wrong on two accounts, first it works even without a
 DJANGO_SETTINGS_MODULE (since it guesses settings.py), second setting
 DJANGO_SETTINGS_MODULE doesn't seem to have any effect at all with
 runserver.

 If I try "DJANGO_SETTINGS_MODULE=alternative_settings python manage.py
 runserver" with a print in alternative_settings.py, I never get the print.
 The culprit seems to be setup_environ in django.core.__init__.py:
 {{{
 # Set DJANGO_SETTINGS_MODULE appropriately.
 if original_settings_path:
 os.environ['DJANGO_SETTINGS_MODULE'] = original_settings_path
 else:
 os.environ['DJANGO_SETTINGS_MODULE'] = '%s.%s' % (project_name,
 settings_name)
 }}}
 This always overwrites the environment variable; if I delete those lines,
 my alternative_settings.py are imported. I guess the correct fix is
 checking that DJANGO_SETTINGS_MODULE isn't set before overwriting 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-upda...@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] #14975: TransactionTestCases are broken by django.contrib.auth in 1.2.4

2011-01-12 Thread Django

#14975: TransactionTestCases are broken by django.contrib.auth in 1.2.4
+---
  Reporter:  rpbarlow   | Owner:  nobody 
Status:  new| Milestone:  1.3
 Component:  Testing framework  |   Version:  1.2
Resolution: |  Keywords:  blocker, regression
 Stage:  Accepted   | Has_patch:  0  
Needs_docs:  0  |   Needs_tests:  0  
Needs_better_patch:  0  |  
+---
Comment (by mkelley33 ):

 +1 for getting it into 1.2.5 Thanks rpbarlow and russellm!

-- 
Ticket URL: 
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-upda...@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] #2705: [patch] Add optional FOR UPDATE clause to QuerySets

2011-01-12 Thread Django

#2705: [patch] Add optional FOR UPDATE clause to QuerySets
---+
  Reporter:  Hawkeye   | Owner:  brunobraga
Status:  assigned  | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by danfairs):

 Apologies for the delay - holidays, sickness and the resultant backlog are
 responsible for that.

 While I was unable to reproduce the test failures Jacob saw directly, I
 did see that there was an error with the transaction setup. This caused an
 unintended commit, which explains why the `Person` created in `setUp()`
 persisted unexpectedly. Once I had fixed this problem, I then started
 seeing the traceback that Jacob saw.

 The newest version of the patch contains these changes, and also changes
 the `NOWAIT` behaviour on backends that do not support it by raising a
 `DatabaseError` when a query with NOWAIT is run, as Jacob commented.

 The docs have also been updated to reflect the new behaviour.

 I've tested this with MySQL, PostgreSQL and SQLite, and the tests pass -
 I'll test on Oracle in the next couple of days.

-- 
Ticket URL: 
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-upda...@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] #15063: multi_db flag on TestCase causes invalid error reporting

2011-01-12 Thread Django

#15063: multi_db flag on TestCase causes invalid error reporting
---+
 Reporter:  dcramer|   Owner:  nobody
   Status:  new|   Milestone:
Component:  Uncategorized  | Version:  1.2   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 When setting multi_db = True on a test case you may encounter aliases
 which do not allow synchronization with specific tables. Due to the
 behavior of the fixture loader, it sees that no objects were loaded for
 these specific aliases and prints an exception to stderr and runs a
 rollback command.

 The chunk of code in reference is here
 
http://code.djangoproject.com/browser/django/trunk/django/core/management/commands/loaddata.py#L196

 (For posterity, the 'if objects_in_fixture == 0:'  error assumption is
 what causes this behavior)

-- 
Ticket URL: 
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-upda...@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] #15062: r14389 breaks getattr on Manager subclasses

2011-01-12 Thread Django

#15062: r14389 breaks getattr on Manager subclasses
--+-
 Reporter:  clelland  |   Owner:  nobody
   Status:  new   |   Milestone:  1.3   
Component:  Database layer (models, ORM)  | Version:  SVN   
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 I've been using Simon Willison's [http://djangosnippets.org/snippets/734/
 QuerySetManager] pattern for a while now, and since upgrading to Django
 1.2.4, it has been breaking when I try to call a method on a
 !RelatedManager constructed from it.

 There was a change in r14389 (r14390 in the 1.2.X branch) which causes
 this code to break -- where there was a simple delegation before from the
 !RelatedManager to the !QuerySetManager to the model, there now appears to
 be an infinite recursion, with the !RelatedManager and !QuerySetManager
 trying to call each other's get_query_set methods.

 !QuerySetManager is just a simple subclass of `django.db.models.Manager`,
 which overrides `__getattr__` to proxy custom method calls on the manager
 to a class attached to the underlying model.

 The simplest test case I can get to reproduce this problem looks like
 this:

 {{{
 from django.db import models
 from django.contrib.auth.models import User
 from helpers import QuerySetManager

 class TestModel(models.Model):
user = models.ForeignKey(User)
string = models.CharField(max_length=64, null=True, blank=True)
objects = QuerySetManager()
class QuerySet(models.query.QuerySet):
pass
 }}}

 Using it gives a traceback like this:

 {{{
 >>> user = User.objects.get(username='testuser')
 >>> user.testmodel_set.create(string="test")
 Traceback (most recent call last):
  File "", line 1, in 
user.testmodel_set.create(string="test")
  File "/Users/ian/.virtualenvs/testcode/lib/python2.6/site-
 packages/django/db/models/fields/related.py", line 423, in create
return super(RelatedManager, self.db_manager(db)).create(**kwargs)
  File "/Users/ian/.virtualenvs/egather/lib/python2.6/site-
 packages/django/db/models/manager.py", line 138, in create
return self.get_query_set().create(**kwargs)
  File "/Users/ian/.virtualenvs/testcode/lib/python2.6/site-
 packages/django/db/models/fields/related.py", line 410, in get_query_set
return
 superclass.get_query_set(self).using(db).filter(**(self.core_filters))
  File "/Users/ian/Code/Tests/related_test/test_app/models.py", line 17, in
 __getattr__
return getattr(self.get_query_set(), attr, *args)
  File "/Users/ian/.virtualenvs/testcode/lib/python2.6/site-
 packages/django/db/models/fields/related.py", line 410, in get_query_set
return
 superclass.get_query_set(self).using(db).filter(**(self.core_filters))
  File "/Users/ian/Code/Tests/related_test/test_app/models.py", line 17, in
 __getattr__
return getattr(self.get_query_set(), attr, *args)
  File "/Users/ian/.virtualenvs/testcode/lib/python2.6/site-
 packages/django/db/models/fields/related.py", line 410, in get_query_set
return
 superclass.get_query_set(self).using(db).filter(**(self.core_filters))
  File "/Users/ian/Code/Tests/related_test/test_app/models.py", line 17, in
 __getattr__
return getattr(self.get_query_set(), attr, *args)
  File "/Users/ian/.virtualenvs/testcode/lib/python2.6/site-
 packages/django/db/models/fields/related.py", line 410, in get_query_set
return
 superclass.get_query_set(self).using(db).filter(**(self.core_filters))
  File "/Users/ian/Code/Tests/related_test/test_app/models.py", line 17, in
 __getattr__
return getattr(self.get_query_set(), attr, *args)
 ...
 Lots snipped
 ...
  File "/Users/ian/.virtualenvs/egather/lib/python2.6/site-
 packages/django/db/models/fields/related.py", line 410, in get_query_set
return
 superclass.get_query_set(self).using(db).filter(**(self.core_filters))
  File "/Users/ian/Code/Tests/related_test/test_app/models.py", line 14, in
 get_query_set
return self.model.QuerySet(self.model)
  File "/Users/ian/.virtualenvs/testcode/lib/python2.6/site-
 packages/django/db/models/query.py", line 33, in __init__
self.query = query or sql.Query(self.model)
  File "/Users/ian/.virtualenvs/testcode/lib/python2.6/site-
 packages/django/db/models/sql/query.py", line 138, in __init__
self.aggregates = SortedDict() # Maps alias -> SQL aggregate function
  File "/Users/ian/.virtualenvs/testcode/lib/python2.6/site-
 packages/django/utils/datastructures.py", line 97, in __init__
super(SortedDict, self).__init__(data)
 RuntimeError: maximum recursion depth exceeded while calling a Python
 object
 }}}

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

-- 
You received this message because you a

Re: [Django] #14948: Broken routers in 1.2.4: type object 'ModelBase' has no attribute '_meta'

2011-01-12 Thread Django

#14948: Broken routers in 1.2.4: type object 'ModelBase' has no attribute 
'_meta'
---+
  Reporter:  shell_dweller | Owner:  nobody 
 
Status:  new   | Milestone:  1.3
 
 Component:  Database layer (models, ORM)  |   Version:  1.2
 
Resolution:|  Keywords:  router, 
ManyToManyField, blocker, regression
 Stage:  Accepted  | Has_patch:  1  
 
Needs_docs:  0 |   Needs_tests:  0  
 
Needs_better_patch:  0 |  
---+
Changes (by Harm Geerts ):

  * has_patch:  0 => 1

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@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] #15047: missing the "%(sel)s of %(cnt)s selected" str on translate

2011-01-12 Thread Django

#15047: missing the "%(sel)s of %(cnt)s selected" str on translate
---+
  Reporter:  zodman| Owner:  nobody 
   
Status:  closed| Milestone:  1.3
   
 Component:  Internationalization  |   Version:  1.2
   
Resolution:  invalid   |  Keywords:  translate, 
gettext, plural
 Stage:  Unreviewed| Has_patch:  0  
   
Needs_docs:  0 |   Needs_tests:  0  
   
Needs_better_patch:  0 |  
---+
Changes (by zodman):

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

Comment:

 chatting with cramm ( es-AR translator) show the point the str not missing
 ... sorry for the ticket.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@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] #15061: Remove redundant code in ModelFormMixin

2011-01-12 Thread Django

#15061: Remove redundant code in ModelFormMixin
---+
 Reporter:  rasca  |   Owner:  nobody
   Status:  new|   Milestone:  1.3   
Component:  Generic views  | Version:  SVN   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 ModelFormMinix inherits from FormMinix, and overrides the form_invalid()
 method doing the same thing.

 I've ran all django tests and all of them passes when removing this method
 from ModelFormMixin.

-- 
Ticket URL: 
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-upda...@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] #15060: csrftoken cookie not being sent over SSL

2011-01-12 Thread Django

#15060: csrftoken cookie not being sent over SSL
-+--
  Reporter:  burhan  | Owner:  nobody
Status:  closed  | Milestone:
 Component:  Core framework  |   Version:  1.2   
Resolution:  worksforme  |  Keywords:  csrf ssl https
 Stage:  Unreviewed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by lukeplant):

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

Comment:

 SESSION_COOKIE_SECURE should not be used for CSRF cookies, since there is
 no link between CSRF and sessions.

 We do need a CSRF_COOKIE_SECURE setting, but that is covered by #14134,
 and the lack of this setting should not stop the cookie being sent over
 SSL. If your problem was the CSRF cookie, I'm pretty sure you wouldn't see
 the error you are reporting.

 In fact, I use Django on an HTTPS site, and it works fine for me. It has
 worked both when I used had both HTTP/HTTPS enabled, and when I switched
 to HTTPS only and `SESSION_COOKIE_SECURE = True`.

 I'll treat this bug according to the title ("csrftoken cookie not being
 sent over SSL"), rather than the other details, and mark as WORKSFORME
 accordingly. Please re-open if you can provide more details that would
 allow us to reproduce the problem, or a analysis that shows why this would
 happen.

 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-upda...@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] #14948: Broken routers in 1.2.4: type object 'ModelBase' has no attribute '_meta'

2011-01-12 Thread Django

#14948: Broken routers in 1.2.4: type object 'ModelBase' has no attribute 
'_meta'
---+
  Reporter:  shell_dweller | Owner:  nobody 
 
Status:  new   | Milestone:  1.3
 
 Component:  Database layer (models, ORM)  |   Version:  1.2
 
Resolution:|  Keywords:  router, 
ManyToManyField, blocker, regression
 Stage:  Accepted  | Has_patch:  0  
 
Needs_docs:  0 |   Needs_tests:  0  
 
Needs_better_patch:  0 |  
---+
Comment (by Harm Geerts ):

 The router check on rel.through may have been broken for some time but was
 hidden because the !ConnectionRouter catched it's !AttributeError[[br]]
 We can thank the following ticket for showing us this bug:
 http://code.djangoproject.com/ticket/14870 [[br]]
 The patch cannot be reverted since the router call is broken and needs to
 be fixed.[[br]]

 On my project the error was raised in a different code path.
 {{{
   File "/home/harm/django12/django/core/management/commands/loaddata.py",
 line 174, in handle
 obj.save(using=using)
   File "/home/harm/django12/django/core/serializers/base.py", line 168, in
 save
 setattr(self.object, accessor_name, object_list)
   File "/home/harm/django12/django/db/models/fields/related.py", line 730,
 in __set__
 manager.clear()
   File "/home/harm/django12/django/db/models/fields/related.py", line 506,
 in clear
 self._clear_items(self.source_field_name)
   File "/home/harm/django12/django/db/models/fields/related.py", line 624,
 in _clear_items
 db = router.db_for_write(self.through.__class__,
 instance=self.instance)
   File "/home/harm/django12/django/db/utils.py", line 134, in _route_db
 chosen_db = method(model, **hints)
   File "/home/harm/lascon/lascon/router.py", line 18, in db_for_write
 if model._meta.app_label == 'exact' and model._meta.object_name !=
 'ExactProfile':
 AttributeError: type object 'ModelBase' has no attribute '_meta'
 }}}

-- 
Ticket URL: 
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-upda...@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] #15056: 'NoneType' object is not callable (smart_unicode is None)

2011-01-12 Thread Django

#15056: 'NoneType' object is not callable (smart_unicode is None)
+---
  Reporter:  kenseehart | Owner:  nobody
Status:  new| Milestone:
 Component:  Uncategorized  |   Version:  1.2   
Resolution: |  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by kmtracey):

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

Old description:

> Running locally in debug mode
>
> When I add an object, I get this traceback:
>
> Environment:
>
> Request Method: POST
> Request URL: http://127.0.0.1:8000/admin/tc/client/add/
> Django Version: 1.2 beta 1
> Python Version: 2.6.5
> Installed Applications:
> ['django.contrib.auth',
>  'django.contrib.contenttypes',
>  'django.contrib.sessions',
>  'django.contrib.sites',
>  'django.contrib.messages',
>  'django.contrib.admin',
>  'tc']
> Installed Middleware:
> ('django.middleware.common.CommonMiddleware',
>  'django.contrib.sessions.middleware.SessionMiddleware',
>  'django.middleware.csrf.CsrfViewMiddleware',
>  'django.contrib.auth.middleware.AuthenticationMiddleware',
>  'django.contrib.messages.middleware.MessageMiddleware')
>

> Traceback:
> File "/usr/local/lib/python2.6/dist-
> packages/django/core/handlers/base.py" in get_response
>   101. response = callback(request, *callback_args,
> **callback_kwargs)
> File "/usr/local/lib/python2.6/dist-
> packages/django/contrib/admin/options.py" in wrapper
>   240. return self.admin_site.admin_view(view)(*args,
> **kwargs)
> File "/usr/local/lib/python2.6/dist-packages/django/utils/decorators.py"
> in _wrapped_view
>   68. response = view_func(request, *args, **kwargs)
> File "/usr/local/lib/python2.6/dist-
> packages/django/views/decorators/cache.py" in _wrapped_view_func
>   69. response = view_func(request, *args, **kwargs)
> File "/usr/local/lib/python2.6/dist-
> packages/django/contrib/admin/sites.py" in inner
>   194. return view(request, *args, **kwargs)
> File "/usr/local/lib/python2.6/dist-packages/django/utils/decorators.py"
> in _wrapper
>   21. return decorator(bound_func)(*args, **kwargs)
> File "/usr/local/lib/python2.6/dist-packages/django/utils/decorators.py"
> in _wrapped_view
>   68. response = view_func(request, *args, **kwargs)
> File "/usr/local/lib/python2.6/dist-packages/django/utils/decorators.py"
> in bound_func
>   17. return func(self, *args2, **kwargs2)
> File "/usr/local/lib/python2.6/dist-packages/django/db/transaction.py" in
> _commit_on_success
>   295. res = func(*args, **kw)
> File "/usr/local/lib/python2.6/dist-
> packages/django/contrib/admin/options.py" in add_view
>   801. self.log_addition(request, new_object)
> File "/usr/local/lib/python2.6/dist-
> packages/django/contrib/admin/options.py" in log_addition
>   428. action_flag = ADDITION
> File "/usr/local/lib/python2.6/dist-
> packages/django/contrib/admin/models.py" in log_action
>   19. e = self.model(None, None, user_id, content_type_id,
> smart_unicode(object_id), object_repr[:200], action_flag, change_message)
>
> Exception Type: TypeError at /admin/tc/client/add/
> Exception Value: 'NoneType' object is not callable
> 
>
> smart_unicode is None
>
> This seems to be some kind of magic import related bug, since there
> doesn't seem to be any natural way for the symbol 'smart_unicode' to be
> assigned the value None.
>
> A hack patch that fixes the problem follows (though it would be good to
> properly diagnose the problem)
>
> 14a15
> > from django.utils.encoding import smart_unicode

New description:

 Running locally in debug mode

 When I add an object, I get this traceback:
 {{{
 Environment:

 Request Method: POST
 Request URL: http://127.0.0.1:8000/admin/tc/client/add/
 Django Version: 1.2 beta 1
 Python Version: 2.6.5
 Installed Applications:
 ['django.contrib.auth',
  'django.contrib.contenttypes',
  'django.contrib.sessions',
  'django.contrib.sites',
  'django.contrib.messages',
  'django.contrib.admin',
  'tc']
 Installed Middleware:
 ('django.middleware.common.CommonMiddleware',
  'django.contrib.sessions.middleware.SessionMiddleware',
  'django.middleware.csrf.CsrfViewMiddleware',
  'django.contrib.auth.middleware.AuthenticationMiddleware',
  'django.contrib.messages.middleware.MessageMiddleware')


 Traceback:
 File "/usr/local/lib/python2.6/dist-packages/django/core/handlers/base.py"
 in get_response
   101. response = callback(request, *callback_args,
 **callback_kw

Re: [Django] #14948: Broken routers in 1.2.4: type object 'ModelBase' has no attribute '_meta'

2011-01-12 Thread Django

#14948: Broken routers in 1.2.4: type object 'ModelBase' has no attribute 
'_meta'
---+
  Reporter:  shell_dweller | Owner:  nobody 
 
Status:  new   | Milestone:  1.3
 
 Component:  Database layer (models, ORM)  |   Version:  1.2
 
Resolution:|  Keywords:  router, 
ManyToManyField, blocker, regression
 Stage:  Accepted  | Has_patch:  0  
 
Needs_docs:  0 |   Needs_tests:  0  
 
Needs_better_patch:  0 |  
---+
Changes (by Harm Geerts ):

 * cc: hgee...@osso.nl (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-upda...@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] r15175 - django/trunk/django/db/backends

2011-01-12 Thread noreply

Author: Alex
Date: 2011-01-12 07:39:31 -0600 (Wed, 12 Jan 2011)
New Revision: 15175

Modified:
   django/trunk/django/db/backends/__init__.py
Log:
2 small optimizations: a) move an import out of a function, b) remove a cache 
that did nothing, tiny tiny speed up on CPython, but a big one on PyPy

Modified: django/trunk/django/db/backends/__init__.py
===
--- django/trunk/django/db/backends/__init__.py 2011-01-11 01:03:08 UTC (rev 
15174)
+++ django/trunk/django/db/backends/__init__.py 2011-01-12 13:39:31 UTC (rev 
15175)
@@ -1,11 +1,13 @@
 import decimal
 from threading import local
 
+from django.conf import settings
 from django.db import DEFAULT_DB_ALIAS
 from django.db.backends import util
 from django.utils import datetime_safe
 from django.utils.importlib import import_module
 
+
 class BaseDatabaseWrapper(local):
 """
 Represents a database connection.
@@ -73,7 +75,6 @@
 self.connection = None
 
 def cursor(self):
-from django.conf import settings
 cursor = self._cursor()
 if (self.use_debug_cursor or
 (self.use_debug_cursor is None and settings.DEBUG)):
@@ -205,7 +206,7 @@
 compiler_module = "django.db.models.sql.compiler"
 
 def __init__(self):
-self._cache = {}
+self._cache = None
 
 def autoinc_sql(self, table, column):
 """
@@ -388,11 +389,9 @@
 in the namespace corresponding to the `compiler_module` attribute
 on this backend.
 """
-if compiler_name not in self._cache:
-self._cache[compiler_name] = getattr(
-import_module(self.compiler_module), compiler_name
-)
-return self._cache[compiler_name]
+if self._cache is None:
+self._cache = import_module(self.compiler_module)
+return getattr(self._cache, compiler_name)
 
 def quote_name(self, name):
 """

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-upda...@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] #15057: Improve docs regarding template variable lookups.

2011-01-12 Thread Django

#15057: Improve docs regarding template variable lookups.
+---
  Reporter:  mrmachine  | Owner:  nobody
   
Status:  new| Milestone:  1.3   
   
 Component:  Documentation  |   Version:  SVN   
   
Resolution: |  Keywords:  template variable 
lookups
 Stage:  Ready for checkin  | Has_patch:  1 
   
Needs_docs:  0  |   Needs_tests:  0 
   
Needs_better_patch:  0  |  
+---
Changes (by lukeplant):

  * 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-upda...@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] #15060: csrftoken cookie not being sent over SSL

2011-01-12 Thread Django

#15060: csrftoken cookie not being sent over SSL
+---
 Reporter:  burhan  |   Owner:  nobody
   Status:  new |   Milestone:
Component:  Core framework  | Version:  1.2   
 Keywords:  csrf ssl https  |   Stage:  Unreviewed
Has_patch:  0   |  
+---
 SESSION_COOKIE_SECURE setting is not being used for the csrftoken, causing
 it to be sent over HTTP. I believe this is the reason why I keep getting
 'Looks like your browser isn't configured to accept cookies. Please enable
 cookies, reload this page, and try again.' errors when trying to login on
 the django admin.

 Test environment:

 glassfishv3
 jython 2.5.2.rc2
 django-jython 1.1.2 (against Oracle backend)
 django 1.2.3
 Windows

 Note: no other servers are being used, glassfish is exclusively for django
 use (so no PHP mhash problems).

-- 
Ticket URL: 
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-upda...@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] #15059: Additional Documentation for the objects in the admin templates

2011-01-12 Thread Django

#15059: Additional Documentation for the objects in the admin templates
--+-
 Reporter:  mlakewood |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Uncategorized | Version:  1.2   
 Keywords:  admin templates override  |   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 Hi,

 I've being trying to override the admin template for change_list for the
 last couple of days. As I was working through it the documentation was
 great up until the point where I needed to access some data that was being
 displayed on the page. After that I really struggled on how and where to
 get the data from. In the end somebody mentioned that I could do
 {{cl.get_query_set()}}, and then just by chance I worked out that you
 could do {{cl.result_list}} to get the filtered list.

 It would be really helpful if in the documentation for over riding the
 admin templates there was an explanation of how to get at the data. As
 from my experience its one of the first things that I wanted to do to the
 admin interface.

 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-upda...@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] #14030: Use F() objects in aggregates(), annotates() and values()

2011-01-12 Thread Django

#14030: Use F() objects in aggregates(), annotates() and values()
--+-
  Reporter:  delfick  | Owner: 
Status:  new  | Milestone: 
 Component:  ORM aggregation  |   Version:  1.2
Resolution:   |  Keywords: 
 Stage:  Accepted | Has_patch:  0  
Needs_docs:  0|   Needs_tests:  0  
Needs_better_patch:  0|  
--+-
Changes (by robin):

 * cc: robin (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-upda...@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.

44 matches

Mail list logo