Re: [Django] #10829: QuerySet.delete() attempts to delete unmanaged models.

[Django]

#10829: QuerySet.delete() attempts to delete unmanaged models.
---+
  Reporter:  justinlilly   | Owner:  nobody
Status:  new   | Milestone:  1.1   
 Component:  Database layer (models, ORM)  |   Version:  1.1-beta-1
Resolution:|  Keywords:  unmanaged 
 Stage:  Design decision needed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by mtredinnick):

 Urgh. This is messy. The idea in comment:3 isn't a solution, since this
 isn't a property of the `delete()` call -- it's a property of the model
 definition (and cascading delete behaviour is the subject of another
 ticket and unresolved as yet because it's a hard problem to cover all use-
 cases). The current behaviour is correct (unmanaged refers to syncdb and
 other SQL-altering statements), but we should be able to handle Justin's
 case, too.

 Would be nice to have a solution for 1.1, so I'll give this some thought.

-- 
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] #10829: QuerySet.delete() attempts to delete unmanaged models.

[Django]

#10829: QuerySet.delete() attempts to delete unmanaged models.
---+
  Reporter:  justinlilly   | Owner:  nobody
Status:  new   | Milestone:  1.1   
 Component:  Database layer (models, ORM)  |   Version:  1.1-beta-1
Resolution:|  Keywords:  unmanaged 
 Stage:  Design decision needed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by anonymous):

 I would say that the proper way to handle this would be to have a kwarg
 for the delete method. QuerySet.delete(cascade=False) Seems reasonable, at
 least.

-- 
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] #10847: `QuerySet.values` doesn't remove extra selections.

[Django]

#10847: `QuerySet.values` doesn't remove extra selections.
+---
  Reporter:  mrmachine  | Owner:  nobody
  
Status:  new| Milestone:  1.1   
  
 Component:  Uncategorized  |   Version:  SVN   
  
Resolution: |  Keywords:  queryset extra select 
values sql
 Stage:  Unreviewed | Has_patch:  0 
  
Needs_docs:  0  |   Needs_tests:  0 
  
Needs_better_patch:  0  |  
+---
Changes (by mrmachine):

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

Comment:

 Keep in mind that any extra selections may also be referenced in
 `order_by` or extra `where`, etc. If we strip extra selections that are
 not specified in `values()`, we should also strip them from `order_by` and
 extra `where`, etc., or invalid SQL may be generated.

-- 
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] #10846: deployment typo + updated link

[Django]

#10846: deployment typo + updated link
+---
  Reporter:  timo   | Owner:  nobody 
Status:  new| Milestone: 
 Component:  Documentation  |   Version:  SVN
Resolution: |  Keywords:  typo deployment
 Stage:  Unreviewed | Has_patch:  1  
Needs_docs:  0  |   Needs_tests:  0  
Needs_better_patch:  0  |  
+---
Changes (by timo):

  * needs_better_patch:  => 0
  * version:  1.0 => SVN
  * 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] #10846: deployment typo + updated link

[Django]

#10846: deployment typo + updated link
-+--
 Reporter:  timo |   Owner:  nobody
   Status:  new  |   Milestone:
Component:  Documentation| Version:  1.0   
 Keywords:  typo deployment  |   Stage:  Unreviewed
Has_patch:  1|  
-+--
 typo in docs/howto/deployment/modwsgi.txt (missing space)

 update link to The Django Book to version 2.0 chapter on deployment

-- 
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] #10845: The use of "Instance" in "Creating Forms from Models" is confusing.

[Django]

#10845: The use of "Instance" in "Creating Forms from Models" is confusing.
---+
 Reporter:  ElfSternberg   |   Owner:  nobody
   Status:  new|   Milestone:  1.0.3 
Component:  Documentation  | Version:  1.0   
 Keywords:  grammar|   Stage:  Unreviewed
Has_patch:  0  |  
---+
 In the section "Using a subset of fields on a form," the example contains
 the text:

 `instance = Instance(required_field='value')`[[BR]]
 `form = InstanceForm(request.POST, instance=instance)`

 The use of "instance" here as the lvalue of Instance is a poor choice.
 For someone skimming through the article looking just for the syntax for a
 subset of fields on a form, and who may have missed the text earlier in
 the article about the instance keyword, this seems to imply that the
 keyword argument might be some lowercase variant of the Model name.  I
 strongly suggest an alternative example:

 `example = Example(required_field='value')`[[BR]]
 `form = ExampleForm(request.POST, instance=example)`

 Which would make it much more clear that "instance" is the kwarg, and the
 kwarg is not generated dynamically.

-- 
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] #10816: CsrfMiddleware false positive after session.flush()

[Django]

#10816: CsrfMiddleware false positive after session.flush()
---+
  Reporter:  Glenn | Owner:  nobody   
Status:  new   | Milestone:   
 Component:  Contrib apps  |   Version:  SVN  
Resolution:|  Keywords:  csrf sessions
 Stage:  Unreviewed| Has_patch:  1
Needs_docs:  0 |   Needs_tests:  0
Needs_better_patch:  0 |  
---+
Changes (by Glenn):

  * has_patch:  0 => 1

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

Re: [Django] #10816: CsrfMiddleware false positive after session.flush()

[Django]

#10816: CsrfMiddleware false positive after session.flush()
---+
  Reporter:  Glenn | Owner:  nobody   
Status:  new   | Milestone:   
 Component:  Contrib apps  |   Version:  SVN  
Resolution:|  Keywords:  csrf sessions
 Stage:  Unreviewed| Has_patch:  0
Needs_docs:  0 |   Needs_tests:  0
Needs_better_patch:  0 |  
---+
Comment (by Glenn):

 I've already implemented this (with tests and doc updates), since I keep
 hitting these false positives in development and I foresee it being real
 problem in production.

 #2: When there is no CSRF cookie, the session cookie is accepted as the
 CSRF cookie.  This should happen only once, the first time a user visits
 the site after an upgrade.  This can be removed eventually.

 #3: I don't think this is a problem.  If you're manually deleting security
 cookies, you lose security; we can't protect the user against his
 deliberately breaking CSRF verification for himself.  (If he deletes *all*
 cookies for a site, this isn't a problem--he'll also delete the session
 cookie, and goes back to #1.)

 > One slight issue with this method is that users who don't automatically
 allow cookies will be prompted to accept a cookie as soon as they come to
 a site, whether they will ever use a POST form or not.

 "Don't set cookies until you log in" isn't a reasonable user expectation.
 If you turn cookie prompting on, you'll be inundated on almost every site
 you visit.  The session cookie is always being set, too.

 For backwards-compatibility, the cookie name is derived from
 settings.SESSION_COOKIE_NAME, and SESSION_COOKIE_DOMAIN and
 SESSION_COOKIE_PATH are used.  These could be broken out into separate
 settings, but it'd just be options bloat unless anyone has a real need for
 it.  (Having generic COOKIE_DOMAIN and COOKIE_PATH settings that default
 for *all* cookies would be useful, though.)  The cookie expiry is
 arbitrarily one year.

 I think the patch in #9977 is doing too much at once.  I havn't merged any
 of that, but I've arranged things so it's possible to generate the token
 before the CsrfResponseMiddleware is run, and exposed
 get_csrf_token(request) to do so.  This should make adding a template tag
 for it much easier.

-- 
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] #10844: r10547 broke testing with Oracle

[Django]

#10844: r10547 broke testing with Oracle
---+
  Reporter:  jbronn| Owner:  ikelly 
Status:  new   | Milestone:  1.1
 Component:  Database layer (models, ORM)  |   Version:  SVN
Resolution:|  Keywords:  oracle test
 Stage:  Unreviewed| Has_patch:  0  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Comment (by ikelly):

 I'm agreed with Matt.  The change that was made in [10547] looks like it's
 just fixing some omissions, but it actually significantly changes the way
 testing works in Oracle (admittedly, oracle/creation.py is rather
 confusing in terms of where it pulls parameters from and how it applies
 them).  This should be reverted, and the changes made should only be
 considered for 1.2.

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

Re: [Django] #7732: Oracle Backend with SessionPool

[Django]

#7732: Oracle Backend with SessionPool
---+
  Reporter:  halturin  | Owner:  nobody 
  
Status:  new   | Milestone: 
  
 Component:  Database layer (models, ORM)  |   Version:  SVN
  
Resolution:|  Keywords:  
yandex-sprint oracle session pool
 Stage:  Design decision needed| Has_patch:  1  
  
Needs_docs:  1 |   Needs_tests:  0  
  
Needs_better_patch:  1 |  
---+
Changes (by anonymous):

 * cc: dberg...@juniper.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] r10580 - django/trunk/tests/regressiontests/introspection

[noreply]

Author: mboersma
Date: 2009-04-16 17:32:48 -0500 (Thu, 16 Apr 2009)
New Revision: 10580

Modified:
   django/trunk/tests/regressiontests/introspection/tests.py
Log:
Fixed introspection test case which caused "ORA-00972: identifier is too long" 
errors against Oracle.

Modified: django/trunk/tests/regressiontests/introspection/tests.py
===
--- django/trunk/tests/regressiontests/introspection/tests.py   2009-04-16 
22:25:01 UTC (rev 10579)
+++ django/trunk/tests/regressiontests/introspection/tests.py   2009-04-16 
22:32:48 UTC (rev 10580)
@@ -50,10 +50,10 @@
 
 def test_django_table_names(self):
 cursor = connection.cursor()
-cursor.execute('CREATE TABLE django_introspection_test_table (id 
INTEGER);');
+cursor.execute('CREATE TABLE django_ixn_test_table (id INTEGER);');
 tl = connection.introspection.django_table_names()
-cursor.execute("DROP TABLE django_introspection_test_table;")
-self.assert_('django_introspection_testcase_table' not in tl,
+cursor.execute("DROP TABLE django_ixn_test_table;")
+self.assert_('django_ixn_testcase_table' not in tl,
  "django_table_names() returned a non-Django table")
 
 def test_installed_models(self):
@@ -83,9 +83,9 @@
 if settings.DATABASE_ENGINE.startswith('postgresql'):
 def test_postgresql_real_type(self):
 cursor = connection.cursor()
-cursor.execute("CREATE TABLE django_introspection_real_test_table 
(number REAL);")
-desc = connection.introspection.get_table_description(cursor, 
'django_introspection_real_test_table')
-cursor.execute('DROP TABLE django_introspection_real_test_table;')
+cursor.execute("CREATE TABLE django_ixn_real_test_table (number 
REAL);")
+desc = connection.introspection.get_table_description(cursor, 
'django_ixn_real_test_table')
+cursor.execute('DROP TABLE django_ixn_real_test_table;')
 self.assertEqual(datatype(desc[0][1]), 'FloatField')
 
 def test_get_relations(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] #10844: r10547 broke testing with Oracle

[Django]

#10844: r10547 broke testing with Oracle
---+
  Reporter:  jbronn| Owner:  ikelly 
Status:  new   | Milestone:  1.1
 Component:  Database layer (models, ORM)  |   Version:  SVN
Resolution:|  Keywords:  oracle test
 Stage:  Unreviewed| Has_patch:  0  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Comment (by ramiro):

 Two things to remember, if the decision to revert the changes is finally
 made:

  * [10548] implemented the same changes to the 1.0.x branch
  * Maybe the fix for this obvious typo bug can be left out of the patch
 revert?:
 
http://code.djangoproject.com/browser/django/trunk/django/db/backends/oracle/creation.py?rev=10546#L247

-- 
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] #9806: GeometryField crashes contrib.gis.admin

[Django]

#9806: GeometryField crashes contrib.gis.admin
-+--
  Reporter:  ingenieroariel  | Owner:  jbronn   
Status:  assigned| Milestone:  1.2  
 Component:  GIS |   Version:  1.0  
Resolution:  |  Keywords:  admin, gis, GeometryField
 Stage:  Accepted| Has_patch:  1
Needs_docs:  0   |   Needs_tests:  0
Needs_better_patch:  1   |  
-+--
Changes (by jbronn):

  * milestone:  1.1 => 1.2

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

[Changeset] r10579 - in django/trunk/django/contrib/gis/db/backend: oracle postgis spatialite

[noreply]

Author: jbronn
Date: 2009-04-16 17:25:01 -0500 (Thu, 16 Apr 2009)
New Revision: 10579

Modified:
   django/trunk/django/contrib/gis/db/backend/oracle/models.py
   django/trunk/django/contrib/gis/db/backend/postgis/models.py
   django/trunk/django/contrib/gis/db/backend/spatialite/models.py
Log:
Fixed #9620 -- `GeometryColumns` and `SpatialRefSys` models now play nice with 
the `AppCache` routines.


Modified: django/trunk/django/contrib/gis/db/backend/oracle/models.py
===
--- django/trunk/django/contrib/gis/db/backend/oracle/models.py 2009-04-16 
15:02:33 UTC (rev 10578)
+++ django/trunk/django/contrib/gis/db/backend/oracle/models.py 2009-04-16 
22:25:01 UTC (rev 10579)
@@ -16,7 +16,9 @@
 srid = models.IntegerField(primary_key=True)
 # TODO: Add support for `diminfo` column (type MDSYS.SDO_DIM_ARRAY).
 class Meta:
+app_label = 'gis'
 db_table = 'USER_SDO_GEOM_METADATA'
+managed = False
 
 @classmethod
 def table_name_col(cls):
@@ -49,7 +51,7 @@
 class Meta:
 abstract = True
 db_table = 'CS_SRS'
-app_label = '_mdsys' # Hack so that syncdb won't try to create 
"CS_SRS" table.
+managed = False
 
 @property
 def wkt(self):

Modified: django/trunk/django/contrib/gis/db/backend/postgis/models.py
===
--- django/trunk/django/contrib/gis/db/backend/postgis/models.py
2009-04-16 15:02:33 UTC (rev 10578)
+++ django/trunk/django/contrib/gis/db/backend/postgis/models.py
2009-04-16 22:25:01 UTC (rev 10579)
@@ -17,7 +17,9 @@
 type = models.CharField(max_length=30)
 
 class Meta:
+app_label = 'gis'
 db_table = 'geometry_columns'
+managed = False
 
 @classmethod
 def table_name_col(cls):
@@ -54,6 +56,7 @@
 class Meta:
 abstract = True
 db_table = 'spatial_ref_sys'
+managed = False
 
 @property
 def wkt(self):

Modified: django/trunk/django/contrib/gis/db/backend/spatialite/models.py
===
--- django/trunk/django/contrib/gis/db/backend/spatialite/models.py 
2009-04-16 15:02:33 UTC (rev 10578)
+++ django/trunk/django/contrib/gis/db/backend/spatialite/models.py 
2009-04-16 22:25:01 UTC (rev 10579)
@@ -15,7 +15,9 @@
 spatial_index_enabled = models.IntegerField()
 
 class Meta:
+app_label = 'gis'
 db_table = 'geometry_columns'
+managed = False
 
 @classmethod
 def table_name_col(cls):
@@ -56,3 +58,4 @@
 class Meta:
 abstract = True
 db_table = 'spatial_ref_sys'
+managed = 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] #10844: r10547 broke testing with Oracle

[Django]

#10844: r10547 broke testing with Oracle
---+
  Reporter:  jbronn| Owner:  ikelly 
Status:  new   | Milestone:  1.1
 Component:  Database layer (models, ORM)  |   Version:  SVN
Resolution:|  Keywords:  oracle test
 Stage:  Unreviewed| Has_patch:  0  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Comment (by Alex):

 I understand the use of settings.TEST_* settings, what I don't understand
 is why [10547] would assign to settings.DATABASE_*.  The settings.TEST_*
 is something that's going to have to be dealt with as a part of multidb(my
 inclination is to move it to DATABASE_OPTIONS), but for now we should be
 keeping our hands off of settings.DATABASE_* as that's just a regression.

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

Re: [Django] #10839: Pickling queryset.query doesn't work for gis models on Oracle

[Django]

#10839: Pickling queryset.query doesn't work for gis models on Oracle
-+--
  Reporter:  jtiai   | Owner:  nobody
Status:  new | Milestone:
 Component:  GIS |   Version:  SVN   
Resolution:  |  Keywords:  oracle gis
 Stage:  Unreviewed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by jbronn):

  * keywords:  => oracle gis
  * summary:  Pickling queryset.query doesn't work for gis models =>
  Pickling queryset.query doesn't work for gis
  models on Oracle

-- 
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] #10844: r10547 broke testing with Oracle

[Django]

#10844: r10547 broke testing with Oracle
---+
  Reporter:  jbronn| Owner:  ikelly 
Status:  new   | Milestone:  1.1
 Component:  Database layer (models, ORM)  |   Version:  SVN
Resolution:|  Keywords:  oracle test
 Stage:  Unreviewed| Has_patch:  0  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Comment (by mboersma):

 It was commit [10547] that broke the tests for Oracle.  I agree the
 creation.py code is messy, but there was no actual reproducible bug
 described, no test case, and evidently it was checked in without actually
 running the tests against Oracle.  We're a bit past due on Django 1.1, so
 let's save the code beautification projects for later and just revert it.

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

Re: [Django] #10844: r10547 broke testing with Oracle

[Django]

#10844: r10547 broke testing with Oracle
---+
  Reporter:  jbronn| Owner:  ikelly 
Status:  new   | Milestone:  1.1
 Component:  Database layer (models, ORM)  |   Version:  SVN
Resolution:|  Keywords:  oracle test
 Stage:  Unreviewed| Has_patch:  0  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Comment (by ikelly):

 Replying to [comment:1 Alex]:
 > I'm not an expert, but why is the Oracle backend modifying the global
 settings, we specifically changed all the backends *not* to do that.

 I don't recall off-hand whether it's necessary or not, but the Oracle
 backend still modifies the global settings when running the test suite
 because that's what all the other backends do.  See
 
http://code.djangoproject.com/browser/django/trunk/django/db/backends/creation.py#L324

-- 
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] #10716: Syntax error and bug in db/backends/oracle/creation.py

[Django]

#10716: Syntax error and bug in db/backends/oracle/creation.py
---+
  Reporter:  canarix   | Owner:  nobody
Status:  reopened  | Milestone:  1.1   
 Component:  Database layer (models, ORM)  |   Version:  1.0   
Resolution:|  Keywords:  oracle
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by mboersma):

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

Comment:

 This "fix" actually prevents the test suite from running at all on Oracle
 here, and for Justin Bronn as well, so we're unable to know which tests
 are succeeding or failing any longer.

 At this late date, this should be reverted.

-- 
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] #10816: CsrfMiddleware false positive after session.flush()

[Django]

#10816: CsrfMiddleware false positive after session.flush()
---+
  Reporter:  Glenn | Owner:  nobody   
Status:  new   | Milestone:   
 Component:  Contrib apps  |   Version:  SVN  
Resolution:|  Keywords:  csrf sessions
 Stage:  Unreviewed| Has_patch:  0
Needs_docs:  0 |   Needs_tests:  0
Needs_better_patch:  0 |  
---+
Comment (by lukeplant):

 Ah ok, you are still using a hidden form field, I get it. (I was probably
 asleep or something when making my last comment...)

 Before you come up with a patch, note that this won't make it for 1.1, and
 post 1.1 ticket #9977 is the proposed method.  (At least I think it still
 is, the last I heard Jacob didn't like it, but I think his objections were
 misfounded -- see http://groups.google.com/group/django-
 developers/browse_thread/thread/c23f556b88cedbc7?pli=1 ).  I think the
 implication of this is that the new `CsrfViewMiddleware` will actually
 have a `process_response()` method that adds a persistent CSRF cookie
 whenever it is not present.

 An issue to think about:  Before, the middleware skipped the check if
 there was no session cookie, which will usually be the case if the user is
 not logged in, since there is no danger in that situation.  In this
 system, what happens if there is no CSRF cookie? One presumes that no CSRF
 cookie means:

  1. The user hasn't visited the site before
  2. Or the user visited the site before the new CSRF middleware was
 enabled - so they are authenticated but don't have the CSRF cookie.
  3. Or the user has manually deleted the CSRF cookie.

 If (1), we have no problem -- no possibility of CSRF attack (except login
 CSRF perhaps?).  But the others are more problematic - even though they
 are corner cases, we probably should be protecting against CSRF in this
 situation, which means that we have to require the CSRF cookie and
 corresponding token for all POST requests (apart from those exempted using
 {...@csrf_view_exempt}}} of course).  I don't know if that has
 implications, I'm just thinking out loud...

 More out loud thinking: One slight issue with this method is that users
 who don't automatically allow cookies will be prompted to accept a cookie
 as soon as they come to a site, whether they will ever use a POST form or
 not.

 BTW, if you are going to come up with a patch, please remember that the
 most valuable and important thing is the '''tests''' - in fact, a patch
 consisting of just tests and no implementation would be preferred over the
 inverse :-)  It's usually much better to write the tests first anyway...

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

Re: [Django] #10844: r10547 broke testing with Oracle

[Django]

#10844: r10547 broke testing with Oracle
---+
  Reporter:  jbronn| Owner:  ikelly 
Status:  new   | Milestone:  1.1
 Component:  Database layer (models, ORM)  |   Version:  SVN
Resolution:|  Keywords:  oracle test
 Stage:  Unreviewed| Has_patch:  0  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Changes (by Alex):

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

Comment:

 I'm not an expert, but why is the Oracle backend modifying the global
 settings, we specifically changed all the backends *not* to do 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
-~--~~~~--~~--~--~---

[Django] #10844: r10547 broke testing with Oracle

[Django]

#10844: r10547 broke testing with Oracle
--+-
 Reporter:  jbronn|   Owner:  ikelly
   Status:  new   |   Milestone:  1.1   
Component:  Database layer (models, ORM)  | Version:  SVN   
 Keywords:  oracle test   |   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 More than typos were fixed in r10547, as I can no longer run any part of
 the test suite.  I haven't figured out why (nor have I looked too deeply)
 -- if a fix can't be found I propose just reverting back to r10032.

 {{{
 C:\django\trunk\tests>python runtests.py --settings=settings --verbosity=2
 aggregation
 Importing model aggregation
 Creating test database...
 Creating test database...
 _create_test_db(): dbname = test_orcl
 CREATE TABLESPACE test_orcl
DATAFILE 'test_orcl.dbf' SIZE 20M
REUSE AUTOEXTEND ON NEXT 10M MAXSIZE 100M

 CREATE TEMPORARY TABLESPACE test_orcl_temp
TEMPFILE 'test_orcl_temp.dbf' SIZE 20M
REUSE AUTOEXTEND ON NEXT 10M MAXSIZE 100M

 Creating test user...
 _create_test_user(): username = test_geo
 CREATE USER test_geo
IDENTIFIED BY Im_a_lumberjack
DEFAULT TABLESPACE test_orcl
TEMPORARY TABLESPACE test_orcl_temp

 GRANT CONNECT, RESOURCE TO test_geo
 Traceback (most recent call last):
   File "runtests.py", line 191, in 
 django_tests(int(options.verbosity), options.interactive, args)
   File "runtests.py", line 161, in django_tests
 failures = test_runner(test_labels, verbosity=verbosity,
 interactive=interactive, extra_tests=extra_tests)
   File "C:\django\trunk\django\test\simple.py", line 191, in run_tests
 connection.creation.create_test_db(verbosity, autoclobber=not
 interactive)
   File "C:\django\trunk\django\db\backends\creation.py", line 326, in
 create_test_db
 can_rollback = self._rollback_works()
   File "C:\django\trunk\django\db\backends\creation.py", line 383, in
 _rollback_works
 cursor = self.connection.cursor()
   File "C:\django\trunk\django\db\backends\__init__.py", line 81, in
 cursor
 cursor = self._cursor()
   File "C:\django\trunk\django\db\backends\oracle\base.py", line 307, in
 _cursor
 self.connection = Database.connect(conn_string,
 **self.settings_dict['DATABASE_OPTIONS'])
 cx_Oracle.DatabaseError: ORA-12154: TNS:could not resolve the connect
 identifier specified
 }}}

-- 
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] #6094: core handlers do not catch middleware exceptions

[Django]

#6094: core handlers do not catch middleware exceptions
+---
  Reporter:  gwilson| Owner:  gwilson
Status:  assigned   | Milestone: 
 Component:  HTTP handling  |   Version:  SVN
Resolution: |  Keywords: 
 Stage:  Accepted   | Has_patch:  1  
Needs_docs:  0  |   Needs_tests:  0  
Needs_better_patch:  0  |  
+---
Changes (by jdunck):

 * cc: jdu...@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] #10843: django.contrib.markup.tests.Templates test_textile fails with python textile 2.1.3 and Django 1.0.2 final

[Django]

#10843: django.contrib.markup.tests.Templates test_textile fails with python
textile 2.1.3 and Django 1.0.2 final
+---
  Reporter:  ntoll  | Owner:  nobody 
Status:  new| Milestone: 
 Component:  Testing framework  |   Version: 
Resolution: |  Keywords:  Textile
 Stage:  Unreviewed | Has_patch:  0  
Needs_docs:  0  |   Needs_tests:  0  
Needs_better_patch:  0  |  
+---
Changes (by Alex):

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

Old description:

> Getting the following message:
>
> ==
> FAIL: test_textile (django.contrib.markup.tests.Templates)
> --
> Traceback (most recent call last):
>   File "/Library/Python/2.5/site-
> packages/django/contrib/markup/tests.py", line 27, in test_textile
> Paragraph 2 with quotes and
> code""")
> AssertionError: u'Paragraph 1\n\n\tParagraph 2 with
> quotes and code' != 'Paragraph
> 1\n\nParagraph 2 with quotes and
> code'
>
> --
>
> Looks like there is an extra "\t" in there before the "Paragraph 2" 
> element.

New description:

 Getting the following message:
 {{{
 ==
 FAIL: test_textile (django.contrib.markup.tests.Templates)
 --
 Traceback (most recent call last):
   File "/Library/Python/2.5/site-packages/django/contrib/markup/tests.py",
 line 27, in test_textile
 Paragraph 2 with quotes and code""")
 AssertionError: u'Paragraph 1\n\n\tParagraph 2 with
 quotes and code' != 'Paragraph
 1\n\nParagraph 2 with quotes and
 code'

 --
 }}}
 Looks like there is an extra "\t" in there before the "Paragraph 2" 
 element.

Comment:

 Please use preview.

-- 
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] #10843: django.contrib.markup.tests.Templates test_textile fails with python textile 2.1.3 and Django 1.0.2 final

[Django]

#10843: django.contrib.markup.tests.Templates test_textile fails with python
textile 2.1.3 and Django 1.0.2 final
---+
 Reporter:  ntoll  |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Testing framework  | Version:
 Keywords:  Textile|   Stage:  Unreviewed
Has_patch:  0  |  
---+
 Getting the following message:

 ==
 FAIL: test_textile (django.contrib.markup.tests.Templates)
 --
 Traceback (most recent call last):
   File "/Library/Python/2.5/site-packages/django/contrib/markup/tests.py",
 line 27, in test_textile
 Paragraph 2 with quotes and code""")
 AssertionError: u'Paragraph 1\n\n\tParagraph 2 with
 quotes and code' != 'Paragraph
 1\n\nParagraph 2 with quotes and
 code'

 --

 Looks like there is an extra "\t" in there before the "Paragraph 2" 
 element.

-- 
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] #10841: Better 500 template for AJAX calls

[Django]

#10841: Better 500 template for AJAX calls
--+-
  Reporter:  Riz   | Owner:  nobody
Status:  new  | Milestone:
 Component:  Core framework   |   Version:  1.0   
Resolution:   |  Keywords:
 Stage:  Unreviewed   | Has_patch:  0 
Needs_docs:  0|   Needs_tests:  0 
Needs_better_patch:  0|  
--+-
Comment (by Michail Sychev ):

 I don't think that DEBUG_PROPAGATE_EXCEPTIONS will help. I want django to
 handle exceptions and provide all info like GET\POST vars, just do it
 differently in ajax and non ajax cases. And I want to have normal 500 page
 for non ajax calls.

-- 
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] #10841: Better 500 template for AJAX calls

[Django]

#10841: Better 500 template for AJAX calls
--+-
  Reporter:  Riz   | Owner:  nobody
Status:  new  | Milestone:
 Component:  Core framework   |   Version:  1.0   
Resolution:   |  Keywords:
 Stage:  Unreviewed   | Has_patch:  0 
Needs_docs:  0|   Needs_tests:  0 
Needs_better_patch:  0|  
--+-
Changes (by dc):

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

Comment:

 Note that you can use [http://docs.djangoproject.com/en/dev/ref/settings
 /#debug-propagate-exceptions DEBUG_PROPAGATE_EXCEPTIONS] to get simple
 traceback.

-- 
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] #10842: Django 1.0.2 generates AttributeError with PostgreSql 8.4beta1

[Django]

#10842: Django 1.0.2 generates AttributeError with PostgreSql 8.4beta1
--+-
 Reporter:  hgdeoro   |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Database layer (models, ORM)  | Version:  1.0   
 Keywords:  postgresql|   Stage:  Unreviewed
Has_patch:  1 |  
--+-
 I get this exception with Django 1.0.2 + PostgrsSql 8.4 beta1 (compiled
 from source):
 {{{
   File "/path/to/project/Django-1.0.2/django/db/backends/__init__.py",
 line 56, in cursor
 cursor = self._cursor(settings)
   File
 "/path/to/project/Django-1.0.2/django/db/backends/postgresql_psycopg2/base.py",
 line 92, in _cursor
 self.__class__._version = get_version(cursor)
   File
 "/path/to/project/Django-1.0.2/django/db/backends/postgresql/version.py",
 line 16, in get_version
 major, minor = VERSION_RE.search(version).groups()
 AttributeError: 'NoneType' object has no attribute 'groups'
 }}}

 The problem is the RE used on django/db/backends/postgresql/version.py
 (django-1.0.2):
 {{{
 VERSION_RE = re.compile(r'PostgreSQL (\d+)\.(\d+)\.')
 }}}

 When asked for the version, PostgreSql 8.4beta1 returns:
 '''PostgreSQL 8.4beta1 on i686-pc-linux-gnu, compiled by GCC gcc (Ubuntu
 4.3.2-1ubuntu12) 4.3.2, 32-bit'''

 The RE used in Django 1.1 works OK:
 {{{
 VERSION_RE = re.compile(r'\S+ (\d+)\.(\d+)')
 }}}

 (the '\S+' is used to support EnterpriseDB, see ticket #8737).

 I think django/db/backends/postgresql/operations.py (django-1.0.2) should
 be modifyed too to make it compatible with EnterpriseDB.

 Both files (version.py and operations.py) could be patched with
 fix_re_django-1.0.2.diff.
 I've also attached fix_re_django-1.1-dev.diff that changes operations.py
 to support EnterpriseDB.

 Other tickets (already closed) related to this are: #6433 #9931 #9953

 I've tested that the patches are working against PostgreSQL 8.3 (Ubuntu
 8.10) and PostgreSQL 8.4beta1 (from sources) but haven't check that those
 changes works well with EnterpriseDB.

 Thanks!

 Horacio

 Related post: http://groups.google.com/group/django-
 developers/browse_thread/thread/7826f83429487a07

-- 
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] #6094: core handlers do not catch middleware exceptions

[Django]

#6094: core handlers do not catch middleware exceptions
+---
  Reporter:  gwilson| Owner:  gwilson
Status:  assigned   | Milestone: 
 Component:  HTTP handling  |   Version:  SVN
Resolution: |  Keywords: 
 Stage:  Accepted   | Has_patch:  1  
Needs_docs:  0  |   Needs_tests:  0  
Needs_better_patch:  0  |  
+---
Changes (by gonz):

 * cc: gonz (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] #6460: New feature : Multilingual Content

[Django]

#6460: New feature : Multilingual Content
---+
  Reporter:  g00fy | Owner:  nobody 
 
Status:  new   | Milestone: 
 
 Component:  Internationalization  |   Version: 
 
Resolution:|  Keywords:  multilingual 
content i18n-rf
 Stage:  Someday/Maybe | Has_patch:  0  
 
Needs_docs:  0 |   Needs_tests:  0  
 
Needs_better_patch:  0 |  
---+
Comment (by tomgruner):

 It seems like for complex models you can use django-multilingual-model
 http://code.google.com/p/django-multilingual-model/

 This is not the same as django-multilingual. It´s much simpler.

 You have to create the translation models yourself, but it is very easy to
 use and doesn´t limit the model complexity in any way as it not trying to
 be overly magical.

 By not moving multilingual fields into the core, I think Django can remain
 flexible to different multilingual solutions, as it´s hard to come up with
 a one size fits all solution. I´ve developed an app with django-
 multilingual-model and have had no problems, since it´s based on the
 normal ways models are related in Django anyway. I am just a user of
 django, not on the dev team, but I would prefer django as is with respect
 to multilingual content.

 Also you can see a list of current solutions here:
 http://and-other-things.blogspot.com/2009/04/list-of-django-multilingual-
 model.html

-- 
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] #7052: auth fixture fails to import when running test server

[Django]

#7052: auth  fixture fails to import when running test server
+---
  Reporter:  jb0t   | Owner:  nobody
 
Status:  new| Milestone:
 
 Component:  Serialization  |   Version:  SVN   
 
Resolution: |  Keywords:  auth_permission 
auth_content fixture import
 Stage:  Accepted   | Has_patch:  0 
 
Needs_docs:  0  |   Needs_tests:  0 
 
Needs_better_patch:  0  |  
+---
Comment (by adamnelson):

 Here's the ticket regarding the lack of error handling in
 django_extensions runscript:

 http://code.google.com/p/django-command-extensions/issues/detail?id=93

 Note that the traceback in comment 2 is only visible when manually running
 the Python script line by line - not when using the traceback tag or when
 running runscript generally.

 As for continuing after data errors, I think it's reasonable to at least
 have an option to do that.  INSERT IGNORE or REPLACE INTO would be the
 relevant commands in MySQL.  Postgres has no equivalent except DELETE and
 then INSERT.  A duplicate key error really isn't as bad as a table does
 not exist error or something like that.  Even so, having the option to
 continue a script through even significant errors would be valuable for
 development based on real data sets, as long as the errors are reported.
 Keep in mind these aren't syntax errors or fatal errors, but data errors
 that could be handled with other methods - if there were an option to get
 through this part.

-- 
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] #10841: Better 500 template for AJAX calls

[Django]

#10841: Better 500 template for AJAX calls
-+--
 Reporter:  Riz   |   Owner:  nobody
   Status:  new  |   Milestone:
Component:  Core framework   | Version:  1.0   
 Keywords:   |   Stage:  Unreviewed
Has_patch:  0|  
-+--
 Currently it's quite hard to debug errors raised during ajax calls because
 of full 500 page being returned. This diff adds simple 500 page, it's
 pretty close to code for pasting to dpaste but with additional
 GET\POST\META\FILES\Settings lists and error summary moved to top. Simple
 check to self.request.is_ajax() is made to select template to use.

 As for me, it's much easier to use tools like Firebug with this 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] #3011: Allow for extendable auth_user module

[Django]

#3011: Allow for extendable auth_user module
+---
  Reporter:  nowell strite  | Owner:  seocam   
Status:  assigned   | Milestone:   
 Component:  Contrib apps   |   Version:   
Resolution: |  Keywords:  auth_user
 Stage:  Accepted   | Has_patch:  1
Needs_docs:  1  |   Needs_tests:  1
Needs_better_patch:  1  |  
+---
-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #10803: dbshell should try 'mysql5' as well for executable name

[Django]

#10803: dbshell should try 'mysql5' as well for executable name
---+
  Reporter:  hwa...@gmail.com  | Owner:  hakanw
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by hakanw):

  * owner:  anonymous => hakanw
  * status:  assigned => new

-- 
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] #10803: dbshell should try 'mysql5' as well for executable name

[Django]

#10803: dbshell should try 'mysql5' as well for executable name
---+
  Reporter:  hwa...@gmail.com  | Owner:  anonymous
Status:  assigned  | Milestone:   
 Component:  Database layer (models, ORM)  |   Version:  SVN  
Resolution:|  Keywords:   
 Stage:  Unreviewed| Has_patch:  1
Needs_docs:  0 |   Needs_tests:  0
Needs_better_patch:  0 |  
---+
Changes (by hakanw):

  * owner:  nobody => anonymous
  * status:  new => assigned
  * has_patch:  0 => 1

Comment:

 New patch coming up.

-- 
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] #10803: dbshell should try 'mysql5' as well for executable name

[Django]

#10803: dbshell should try 'mysql5' as well for executable name
---+
  Reporter:  hwa...@gmail.com  | Owner:  nobody
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by Alex):

 Please create diffs relative to the root of the Django source tree, not
 your filesystem.

-- 
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] #10156: ModelMultipleChoiceField does O(n) queries where O(1) will suffice

[Django]

#10156: ModelMultipleChoiceField does O(n) queries where O(1) will suffice
+---
  Reporter:  Alex   | Owner:  Alex
Status:  assigned   | Milestone:  1.1 
 Component:  Forms  |   Version:  1.0 
Resolution: |  Keywords:  
 Stage:  Ready for checkin  | Has_patch:  1   
Needs_docs:  0  |   Needs_tests:  0   
Needs_better_patch:  0  |  
+---
Changes (by Alex):

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

Comment:

 Jacob's complaint was not accurate as the tests found here:

 
http://code.djangoproject.com/browser/django/trunk/tests/modeltests/model_forms/models.py#L827

 Still pass, and they obviously rely on that ValueError logic being
 correct(the reason this works is get_db_prep_lookup is called on the
 object being added to the QuerySet, not on the Query being executed).

-- 
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] #10156: ModelMultipleChoiceField does O(n) queries where O(1) will suffice

[Django]

#10156: ModelMultipleChoiceField does O(n) queries where O(1) will suffice
---+
  Reporter:  Alex  | Owner:  Alex
Status:  assigned  | Milestone:  1.1 
 Component:  Forms |   Version:  1.0 
Resolution:|  Keywords:  
 Stage:  Accepted  | Has_patch:  1   
Needs_docs:  0 |   Needs_tests:  0   
Needs_better_patch:  1 |  
---+
Changes (by russellm):

  * needs_better_patch:  0 => 1

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

[Django] #10840: URL fetching for AJAX libraries

[Django]

#10840: URL fetching for AJAX libraries
+---
 Reporter:  mathijs |   Owner:  nobody
   Status:  new |   Milestone:  1.2   
Component:  Generic views   | Version:  SVN   
 Keywords:  ajax url generic fetch  |   Stage:  Unreviewed
Has_patch:  0   |  
+---
 When developing AJAX add-ons for my Django apps, they often need to post
 data on a specific url. Most of the time I'm forced to hard code this url
 into my scripts. However, if it would be possible to have a single url
 (read: view) that fetches the url for a given view name + variables, or
 returns an array of the sort: ["view_name" => "/user_%(id)/...", ...] (the
 %(id) part should than be replaced with the correct parameters), AJAX
 scripts can become more url-abstract.

 My request is a generic view that works as explained above, you could then
 enable it by adding one more URL to your url.py file pointing to this
 generic view. Comparable to what we have for i18n for AJAX. Some generic
 javascript code would also be needed to handle the parsing of the array
 (using caching etc).

 If you are interested in including such a feauture in trunk, I'd even be
 willing to write up some code.

 regards,
 Mathijs

-- 
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] r10578 - django/branches/releases/1.0.X

[noreply]

Author: russellm
Date: 2009-04-16 10:02:33 -0500 (Thu, 16 Apr 2009)
New Revision: 10578

Modified:
   django/branches/releases/1.0.X/
Log:
Updated svnmerge properties for 1.0.X branch


Property changes on: django/branches/releases/1.0.X
___
Name: svnmerge-blocked
   - 
/django/trunk:9098,9103,9110,9112,9145,9152,9157,9160,9188,9248,9263,9278,9299-9300,9303-9304,9332,9344,9346,9348-9349,9353-9354,9397-9398,9463-9465,9470,9489-9490,9527-9528,9530-9532,9537-9538,9551-9555,9558,9561,9569,9592-9594,9620,9625,9637,9643,9646,9690,9700-9702,9707-9708,9714-9715,9724,9727-9729,9739,9742-9749,9752-9756,9759-9760,9763-9766,9769,9781,9785-9788,9791-9792,9799-9800,9803-9805,9808,9814-9820,9838-9841,9844-9846,9860,9862,9876,9882,9888-9898,9904-9905,9910-9911,9913,9915,9918,9921,9928,9930,9938,9940-9941,9944,9951-9952,9955,9963-9965,9978,9985,9989,10002,10005-10006,10008,10011-10012,10018,10021,10026-10030,10032-10035,10042-10048,10053,10062-10065,10070,10077,10080-10084,10088-10103,10105,10107-10124,10128-10135,10137,10141-10142,10144,10148,10161-10162,10168-10169,10171-10172,10174,10177-10179,10181-10184,10186-10188,10190-10191,10197,10222,10229,10235,10248-10249,10258,10271-10272,10275,10281,10315,10317-10318,10323-10324,10326-10327,10330-10332,10345-10347,10352-10353,10357,10364,10369-10370,10381-10385,10408-10410,10412,10428,10438-10439,10443,10446,10451,10454-10456,10465,10468,10481,10486-10488,10493-10494,10498,10506-10507,10521-10523
   + 
/django/trunk:9098,9103,9110,9112,9145,9152,9157,9160,9188,9248,9263,9278,9299-9300,9303-9304,9332,9344,9346,9348-9349,9353-9354,9397-9398,9463-9465,9470,9489-9490,9527-9528,9530-9532,9537-9538,9551-9555,9558,9561,9569,9592-9594,9620,9625,9637,9643,9646,9690,9700-9702,9707-9708,9714-9715,9724,9727-9729,9739,9742-9749,9752-9756,9759-9760,9763-9766,9769,9781,9785-9788,9791-9792,9799-9800,9803-9805,9808,9814-9820,9838-9841,9844-9846,9860,9862,9876,9882,9888-9898,9904-9905,9910-9911,9913,9915,9918,9921,9928,9930,9938,9940-9941,9944,9951-9952,9955,9963-9965,9978,9985,9989,10002,10005-10006,10008,10011-10012,10018,10021,10026-10030,10032-10035,10042-10048,10053,10062-10065,10070,10077,10080-10084,10088-10103,10105,10107-10124,10128-10135,10137,10141-10142,10144,10148,10161-10162,10168-10169,10171-10172,10174,10177-10179,10181-10184,10186-10188,10190-10191,10197,10222,10229,10235,10248-10249,10258,10271-10272,10275,10281,10315,10317-10318,10323-10324,10326-10327,10330-10332,10345-10347,10352-10353,10357,10364,10369-10370,10381-10385,10408-10410,10412,10428,10438-10439,10443,10446,10451,10454-10456,10465,10468,10481,10486-10488,10493-10494,10498,10506-10507,10521-10523,10560,10562,10565-10566,10575
Name: svnmerge-integrated
   - 
/django/trunk:1-9097,9099-9102,9104-9109,9111,9113-9144,9146-9151,9153-9156,9158-9159,9161-9187,9189-9247,9249-9262,9264-9277,9279-9298,9301-9302,9305-9331,9333-9343,9345,9347,9350-9352,9355-9396,9399-9462,9466-9469,9471-9488,9491-9526,9529,9533-9536,9539-9550,9556-9557,9559-9560,9562-9568,9570-9591,9595-9619,9621-9624,9626-9636,9638-9642,9644-9645,9647-9689,9691-9699,9703-9706,9709-9713,9716-9723,9725-9726,9730-9738,9740-9741,9750-9751,9757-9758,9761-9762,9767-9768,9770-9780,9782-9784,9789-9790,9793-9798,9801-9802,9806-9807,9809-9813,9821-9837,9842-9843,9847-9859,9861,9863-9875,9877-9881,9883-9887,9899-9903,9906-9909,9912,9914,9916-9917,9919-9920,9922-9927,9929,9931-9937,9939,9942-9943,9945-9950,9953-9954,9956-9962,9966-9977,9979-9984,9986-9988,9990-10001,10003-10004,10007,10009-10010,10013-10017,10019-10020,10022-10025,10031,10036-10041,10049-10052,10054-10061,10066-10069,10071-10076,10078-10079,10085-10087,10104,10106,10125-10127,10136,10138-10140,10143,10145-10147,10149-10160,10163-10167,10170,10173,10175-10176,10180,10185,10189,10192-10196,10198-10221,10223-10228,10230-10234,10236-10247,10250-10257,10259-10270,10273-10274,10276-10280,10282-10314,10316,10319-10322,10325,10328-10329,10333-10344,10348-10351,10354-10356,10358-10363,10365-10368,10371-10380,10386-10406,10411,10413-10414,10418-10427,10429-10437,10440,10444-10445,10447-10450,10452-10453,10457-10464,10466-10467,10469-10480,10482-10485,10489-10492,10495-10497,10499-10500,10508,10511,10513,10517,10519,10550,10552,10554,10556
   + 

Re: [Django] #10836: FieldDoesNotExist import in gis.db.models.sql.query should be in gis.db.models.sql.where

[Django]

#10836: FieldDoesNotExist import in gis.db.models.sql.query should be in
gis.db.models.sql.where
-+--
  Reporter:  seanl   | Owner:  nobody
Status:  closed  | Milestone:
 Component:  GIS |   Version:  SVN   
Resolution:  fixed   |  Keywords:
 Stage:  Unreviewed  | Has_patch:  1 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by Alex):

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

Comment:

 Fixed in r10572.

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

[noreply]

Author: russellm
Date: 2009-04-16 10:00:20 -0500 (Thu, 16 Apr 2009)
New Revision: 10577

Modified:
   django/branches/releases/1.0.X/django/forms/fields.py
   django/branches/releases/1.0.X/tests/regressiontests/forms/fields.py
Log:
[1.0.X] Fixed #9948 -- Corrected URLField validation to match RFC1035 (URL 
analog of #9890). Thanks to kratorius for the report and fix.

Merge of r10574 from trunk.

Modified: django/branches/releases/1.0.X/django/forms/fields.py
===
--- django/branches/releases/1.0.X/django/forms/fields.py   2009-04-16 
14:59:37 UTC (rev 10576)
+++ django/branches/releases/1.0.X/django/forms/fields.py   2009-04-16 
15:00:20 UTC (rev 10577)
@@ -532,7 +532,7 @@
 
 url_re = re.compile(
 r'^https?://' # http:// or https://
-r'(?:(?:[A-Z0-9-]+\.)+[A-Z]{2,6}|' #domain...
+r'(?:(?:[A-Z0-9]+(?:-*[A-Z0-9]+)*\.)+[A-Z]{2,6}|' #domain...
 r'localhost|' #localhost...
 r'\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})' # ...or ip
 r'(?::\d+)?' # optional port

Modified: django/branches/releases/1.0.X/tests/regressiontests/forms/fields.py
===
--- django/branches/releases/1.0.X/tests/regressiontests/forms/fields.py
2009-04-16 14:59:37 UTC (rev 10576)
+++ django/branches/releases/1.0.X/tests/regressiontests/forms/fields.py
2009-04-16 15:00:20 UTC (rev 10577)
@@ -900,6 +900,10 @@
 u'http://www.example.com/'
 >>> f.clean('http://www.example.com:8000/test')
 u'http://www.example.com:8000/test'
+>>> f.clean('valid-with-hyphens.com')
+u'http://valid-with-hyphens.com/'
+>>> f.clean('subdomain.domain.com')
+u'http://subdomain.domain.com/'
 >>> f.clean('http://200.8.9.10')
 u'http://200.8.9.10/'
 >>> f.clean('http://200.8.9.10:8000/test')
@@ -924,6 +928,24 @@
 Traceback (most recent call last):
 ...
 ValidationError: [u'Enter a valid URL.']
+>>> f.clean('http://invalid-.com')
+Traceback (most recent call last):
+...
+ValidationError: [u'Enter a valid URL.']
+>>> f.clean('http://-invalid.com')
+Traceback (most recent call last):
+...
+ValidationError: [u'Enter a valid URL.']
+>>> f.clean('http://inv-.alid-.com')
+Traceback (most recent call last):
+...
+ValidationError: [u'Enter a valid URL.']
+>>> f.clean('http://inv-.-alid.com')
+Traceback (most recent call last):
+...
+ValidationError: [u'Enter a valid URL.']
+>>> f.clean('http://valid-hyphens.com')
+u'http://valid-hyphens.com/'
 
 >>> f = URLField(required=False)
 >>> f.clean('')


--~--~-~--~~~---~--~~
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] r10576 - in django/branches/releases/1.0.X: django/forms tests/regressiontests/forms

[noreply]

Author: russellm
Date: 2009-04-16 09:59:37 -0500 (Thu, 16 Apr 2009)
New Revision: 10576

Modified:
   django/branches/releases/1.0.X/django/forms/fields.py
   django/branches/releases/1.0.X/tests/regressiontests/forms/fields.py
Log:
[1.0.X] Fixed #9890 -- Modified the regex validation for email addresses to 
match RFC822/1035. Thanks to ozgur for the report, and kratorius for the patch.

Merge of 10573 from trunk.

Modified: django/branches/releases/1.0.X/django/forms/fields.py
===
--- django/branches/releases/1.0.X/django/forms/fields.py   2009-04-16 
14:26:08 UTC (rev 10575)
+++ django/branches/releases/1.0.X/django/forms/fields.py   2009-04-16 
14:59:37 UTC (rev 10576)
@@ -256,8 +256,8 @@
 digits = len(digittuple)
 if decimals > digits:
 # We have leading zeros up to or past the decimal point.  Count
-# everything past the decimal point as a digit.  We do not count 
-# 0 before the decimal point as a digit since that would mean 
+# everything past the decimal point as a digit.  We do not count
+# 0 before the decimal point as a digit since that would mean
 # we would not allow max_digits = decimal_places.
 digits = decimals
 whole_digits = digits - decimals
@@ -421,7 +421,7 @@
 email_re = re.compile(
 r"(^[-!#$%&'*+/=?^_`{}|~0-9A-Z]+(\.[-!#$%&'*+/=?^_`{}|~0-9A-Z]+)*"  # 
dot-atom
 
r'|^"([\001-\010\013\014\016-\037!#-\[\]-\177]|\\[\001-011\013\014\016-\177])*"'
 # quoted-string
-r')@(?:[A-Z0-9-]+\.)+[A-Z]{2,6}$', re.IGNORECASE)  # domain
+r')@(?:[A-Z0-9]+(?:-*[A-Z0-9]+)*\.)+[A-Z]{2,6}$', re.IGNORECASE)  # domain
 
 class EmailField(RegexField):
 default_error_messages = {
@@ -828,7 +828,7 @@
 super(FilePathField, self).__init__(choices=(), required=required,
 widget=widget, label=label, initial=initial, help_text=help_text,
 *args, **kwargs)
-
+
 if self.required:
 self.choices = []
 else:

Modified: django/branches/releases/1.0.X/tests/regressiontests/forms/fields.py
===
--- django/branches/releases/1.0.X/tests/regressiontests/forms/fields.py
2009-04-16 14:26:08 UTC (rev 10575)
+++ django/branches/releases/1.0.X/tests/regressiontests/forms/fields.py
2009-04-16 14:59:37 UTC (rev 10576)
@@ -745,7 +745,28 @@
 Traceback (most recent call last):
 ...
 ValidationError: [u'Enter a valid e-mail address.']
+>>> f.clean('exam...@invalid-.com')
+Traceback (most recent call last):
+...
+ValidationError: [u'Enter a valid e-mail address.']
+>>> f.clean('exam...@-invalid.com')
+Traceback (most recent call last):
+...
+ValidationError: [u'Enter a valid e-mail address.']
+>>> f.clean('exam...@inv-.alid-.com')
+Traceback (most recent call last):
+...
+ValidationError: [u'Enter a valid e-mail address.']
+>>> f.clean('exam...@inv-.-alid.com')
+Traceback (most recent call last):
+...
+ValidationError: [u'Enter a valid e-mail address.']
+>>> f.clean('exam...@valid-hyphens.com')
+u'exam...@valid-hyphens.com'
 
+>>> f.clean('exam...@valid-with-hyphens.com')
+u'exam...@valid-with-hyphens.com'
+
 >>> f = EmailField(required=False)
 >>> f.clean('')
 u''
@@ -1104,7 +1125,7 @@
 
 # TypedChoiceField 
 
-# TypedChoiceField is just like ChoiceField, except that coerced types will 
+# TypedChoiceField is just like ChoiceField, except that coerced types will
 # be returned:
 >>> f = TypedChoiceField(choices=[(1, "+1"), (-1, "-1")], coerce=int)
 >>> f.clean('1')
@@ -1122,7 +1143,7 @@
 
 # This can also cause weirdness: be careful (bool(-1) == True, remember)
 >>> f.coerce = bool
->>> f.clean('-1') 
+>>> f.clean('-1')
 True
 
 # Even more weirdness: if you have a valid choice but your coercion function


--~--~-~--~~~---~--~~
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] #10363: ModelForm excluded field can still be updated

[Django]

#10363: ModelForm excluded field can still be updated
+---
  Reporter:  jgoldberg  | Owner:  nobody
Status:  closed | Milestone:  1.1   
 Component:  Forms  |   Version:  1.0   
Resolution:  fixed  |  Keywords:
 Stage:  Ready for checkin  | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by russellm):

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

Comment:

 (In [10575]) Fixed #10363 -- Modified ModelForm? handling to ensure that
 excluded fields can't be saved onto the model. Thanks to jgoldberg for the
 report, an Alex Gaynor for the fix.

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

Re: [Django] #9948: URLField accepts invalid domains

[Django]

#9948: URLField accepts invalid domains
+---
  Reporter:  kratorius  | Owner:  nobody 
Status:  closed | Milestone:  1.1
 Component:  Forms  |   Version:  1.0
Resolution:  fixed  |  Keywords:  urlfield hyphen
 Stage:  Accepted   | Has_patch:  1  
Needs_docs:  0  |   Needs_tests:  0  
Needs_better_patch:  0  |  
+---
Changes (by russellm):

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

Comment:

 (In [10574]) Fixed #9948 -- Corrected URLField validation to match RFC1035
 (URL analog of #9890). Thanks to kratorius for the report and fix.

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

[Changeset] r10575 - in django/trunk: django/forms tests/regressiontests/forms

[noreply]

Author: russellm
Date: 2009-04-16 09:26:08 -0500 (Thu, 16 Apr 2009)
New Revision: 10575

Modified:
   django/trunk/django/forms/models.py
   django/trunk/tests/regressiontests/forms/models.py
Log:
Fixed #10363 -- Modified ModelForm handling to ensure that excluded fields 
can't be saved onto the model. Thanks to jgoldberg for the report, an Alex 
Gaynor for the fix.

Modified: django/trunk/django/forms/models.py
===
--- django/trunk/django/forms/models.py 2009-04-16 14:25:18 UTC (rev 10574)
+++ django/trunk/django/forms/models.py 2009-04-16 14:26:08 UTC (rev 10575)
@@ -334,7 +334,8 @@
 fail_message = 'created'
 else:
 fail_message = 'changed'
-return save_instance(self, self.instance, self._meta.fields, 
fail_message, commit)
+return save_instance(self, self.instance, self._meta.fields,
+ fail_message, commit, exclude=self._meta.exclude)
 
 save.alters_data = True
 

Modified: django/trunk/tests/regressiontests/forms/models.py
===
--- django/trunk/tests/regressiontests/forms/models.py  2009-04-16 14:25:18 UTC 
(rev 10574)
+++ django/trunk/tests/regressiontests/forms/models.py  2009-04-16 14:26:08 UTC 
(rev 10575)
@@ -42,7 +42,7 @@
 {'file1': }
 >>> m = FileModel.objects.create(file=f.cleaned_data['file1'])
 
-# It's enough that m gets created without error.  Preservation of the exotic 
name is checked 
+# It's enough that m gets created without error.  Preservation of the exotic 
name is checked
 # in a file_uploads test; it's hard to do that correctly with doctest's 
unicode issues. So
 # we create and then immediately delete m so as to not leave the exotically 
named file around
 # for shutil.rmtree (on Windows) to have trouble with later.
@@ -85,5 +85,24 @@
 datetime.date(1969, 4, 4)
 >>> instance_form.initial['value']
 12
+
+>>> from django.forms import CharField
+>>> class ExcludingForm(ModelForm):
+... name = CharField(max_length=256)
+... class Meta:
+... model = Defaults
+... exclude = ['name']
+>>> f = ExcludingForm({'name': u'Hello', 'value': 99, 'def_date': 
datetime.date(1999, 3, 2)})
+>>> f.is_valid()
+True
+>>> f.cleaned_data['name']
+u'Hello'
+>>> obj = f.save()
+>>> obj.name
+u'class default value'
+>>> obj.value
+99
+>>> obj.def_date
+datetime.date(1999, 3, 2)
 >>> shutil.rmtree(temp_storage_location)
 """}


--~--~-~--~~~---~--~~
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] r10574 - in django/trunk: django/forms tests/regressiontests/forms

[noreply]

Author: russellm
Date: 2009-04-16 09:25:18 -0500 (Thu, 16 Apr 2009)
New Revision: 10574

Modified:
   django/trunk/django/forms/fields.py
   django/trunk/tests/regressiontests/forms/fields.py
Log:
Fixed #9948 -- Corrected URLField validation to match RFC1035 (URL analog of 
#9890). Thanks to kratorius for the report and fix.

Modified: django/trunk/django/forms/fields.py
===
--- django/trunk/django/forms/fields.py 2009-04-16 14:24:27 UTC (rev 10573)
+++ django/trunk/django/forms/fields.py 2009-04-16 14:25:18 UTC (rev 10574)
@@ -533,7 +533,7 @@
 
 url_re = re.compile(
 r'^https?://' # http:// or https://
-r'(?:(?:[A-Z0-9-]+\.)+[A-Z]{2,6}|' #domain...
+r'(?:(?:[A-Z0-9]+(?:-*[A-Z0-9]+)*\.)+[A-Z]{2,6}|' #domain...
 r'localhost|' #localhost...
 r'\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})' # ...or ip
 r'(?::\d+)?' # optional port

Modified: django/trunk/tests/regressiontests/forms/fields.py
===
--- django/trunk/tests/regressiontests/forms/fields.py  2009-04-16 14:24:27 UTC 
(rev 10573)
+++ django/trunk/tests/regressiontests/forms/fields.py  2009-04-16 14:25:18 UTC 
(rev 10574)
@@ -900,6 +900,10 @@
 u'http://www.example.com/'
 >>> f.clean('http://www.example.com:8000/test')
 u'http://www.example.com:8000/test'
+>>> f.clean('valid-with-hyphens.com')
+u'http://valid-with-hyphens.com/'
+>>> f.clean('subdomain.domain.com')
+u'http://subdomain.domain.com/'
 >>> f.clean('http://200.8.9.10')
 u'http://200.8.9.10/'
 >>> f.clean('http://200.8.9.10:8000/test')
@@ -924,6 +928,24 @@
 Traceback (most recent call last):
 ...
 ValidationError: [u'Enter a valid URL.']
+>>> f.clean('http://invalid-.com')
+Traceback (most recent call last):
+...
+ValidationError: [u'Enter a valid URL.']
+>>> f.clean('http://-invalid.com')
+Traceback (most recent call last):
+...
+ValidationError: [u'Enter a valid URL.']
+>>> f.clean('http://inv-.alid-.com')
+Traceback (most recent call last):
+...
+ValidationError: [u'Enter a valid URL.']
+>>> f.clean('http://inv-.-alid.com')
+Traceback (most recent call last):
+...
+ValidationError: [u'Enter a valid URL.']
+>>> f.clean('http://valid-hyphens.com')
+u'http://valid-hyphens.com/'
 
 >>> f = URLField(required=False)
 >>> f.clean('')


--~--~-~--~~~---~--~~
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] r10573 - in django/trunk: django/forms tests/regressiontests/forms

[noreply]

Author: russellm
Date: 2009-04-16 09:24:27 -0500 (Thu, 16 Apr 2009)
New Revision: 10573

Modified:
   django/trunk/django/forms/fields.py
   django/trunk/tests/regressiontests/forms/fields.py
Log:
Fixed #9890 -- Modified the regex validation for email addresses to match 
RFC822/1035. Thanks to ozgur for the report, and kratorius for the patch.

Modified: django/trunk/django/forms/fields.py
===
--- django/trunk/django/forms/fields.py 2009-04-16 14:16:16 UTC (rev 10572)
+++ django/trunk/django/forms/fields.py 2009-04-16 14:24:27 UTC (rev 10573)
@@ -256,8 +256,8 @@
 digits = len(digittuple)
 if decimals > digits:
 # We have leading zeros up to or past the decimal point.  Count
-# everything past the decimal point as a digit.  We do not count 
-# 0 before the decimal point as a digit since that would mean 
+# everything past the decimal point as a digit.  We do not count
+# 0 before the decimal point as a digit since that would mean
 # we would not allow max_digits = decimal_places.
 digits = decimals
 whole_digits = digits - decimals
@@ -283,7 +283,7 @@
 )
 
 class DateField(Field):
-widget = DateInput 
+widget = DateInput
 default_error_messages = {
 'invalid': _(u'Enter a valid date.'),
 }
@@ -422,7 +422,7 @@
 email_re = re.compile(
 r"(^[-!#$%&'*+/=?^_`{}|~0-9A-Z]+(\.[-!#$%&'*+/=?^_`{}|~0-9A-Z]+)*"  # 
dot-atom
 
r'|^"([\001-\010\013\014\016-\037!#-\[\]-\177]|\\[\001-011\013\014\016-\177])*"'
 # quoted-string
-r')@(?:[A-Z0-9-]+\.)+[A-Z]{2,6}$', re.IGNORECASE)  # domain
+r')@(?:[A-Z0-9]+(?:-*[A-Z0-9]+)*\.)+[A-Z]{2,6}$', re.IGNORECASE)  # domain
 
 class EmailField(RegexField):
 default_error_messages = {
@@ -829,7 +829,7 @@
 super(FilePathField, self).__init__(choices=(), required=required,
 widget=widget, label=label, initial=initial, help_text=help_text,
 *args, **kwargs)
-
+
 if self.required:
 self.choices = []
 else:

Modified: django/trunk/tests/regressiontests/forms/fields.py
===
--- django/trunk/tests/regressiontests/forms/fields.py  2009-04-16 14:16:16 UTC 
(rev 10572)
+++ django/trunk/tests/regressiontests/forms/fields.py  2009-04-16 14:24:27 UTC 
(rev 10573)
@@ -745,7 +745,28 @@
 Traceback (most recent call last):
 ...
 ValidationError: [u'Enter a valid e-mail address.']
+>>> f.clean('exam...@invalid-.com')
+Traceback (most recent call last):
+...
+ValidationError: [u'Enter a valid e-mail address.']
+>>> f.clean('exam...@-invalid.com')
+Traceback (most recent call last):
+...
+ValidationError: [u'Enter a valid e-mail address.']
+>>> f.clean('exam...@inv-.alid-.com')
+Traceback (most recent call last):
+...
+ValidationError: [u'Enter a valid e-mail address.']
+>>> f.clean('exam...@inv-.-alid.com')
+Traceback (most recent call last):
+...
+ValidationError: [u'Enter a valid e-mail address.']
+>>> f.clean('exam...@valid-hyphens.com')
+u'exam...@valid-hyphens.com'
 
+>>> f.clean('exam...@valid-with-hyphens.com')
+u'exam...@valid-with-hyphens.com'
+
 >>> f = EmailField(required=False)
 >>> f.clean('')
 u''
@@ -1104,7 +1125,7 @@
 
 # TypedChoiceField 
 
-# TypedChoiceField is just like ChoiceField, except that coerced types will 
+# TypedChoiceField is just like ChoiceField, except that coerced types will
 # be returned:
 >>> f = TypedChoiceField(choices=[(1, "+1"), (-1, "-1")], coerce=int)
 >>> f.clean('1')
@@ -1122,7 +1143,7 @@
 
 # This can also cause weirdness: be careful (bool(-1) == True, remember)
 >>> f.coerce = bool
->>> f.clean('-1') 
+>>> f.clean('-1')
 True
 
 # Even more weirdness: if you have a valid choice but your coercion function


--~--~-~--~~~---~--~~
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] r10572 - django/trunk/django/contrib/gis/db/models/sql

[noreply]

Author: jbronn
Date: 2009-04-16 09:16:16 -0500 (Thu, 16 Apr 2009)
New Revision: 10572

Modified:
   django/trunk/django/contrib/gis/db/models/sql/query.py
   django/trunk/django/contrib/gis/db/models/sql/where.py
Log:
Fixed #10836 -- Forgot to move import to to `where` module.  Thanks, seanl for 
ticket & patch.


Modified: django/trunk/django/contrib/gis/db/models/sql/query.py
===
--- django/trunk/django/contrib/gis/db/models/sql/query.py  2009-04-16 
13:29:31 UTC (rev 10571)
+++ django/trunk/django/contrib/gis/db/models/sql/query.py  2009-04-16 
14:16:16 UTC (rev 10572)
@@ -1,6 +1,5 @@
 from itertools import izip
 from django.db.models.query import sql
-from django.db.models.fields import FieldDoesNotExist
 from django.db.models.fields.related import ForeignKey
 
 from django.contrib.gis.db.backend import SpatialBackend

Modified: django/trunk/django/contrib/gis/db/models/sql/where.py
===
--- django/trunk/django/contrib/gis/db/models/sql/where.py  2009-04-16 
13:29:31 UTC (rev 10571)
+++ django/trunk/django/contrib/gis/db/models/sql/where.py  2009-04-16 
14:16:16 UTC (rev 10572)
@@ -1,5 +1,5 @@
 from django.db import connection
-from django.db.models.fields import Field
+from django.db.models.fields import Field, FieldDoesNotExist
 from django.db.models.sql.constants import LOOKUP_SEP
 from django.db.models.sql.expressions import SQLEvaluator
 from django.db.models.sql.where import WhereNode


--~--~-~--~~~---~--~~
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] #6094: core handlers do not catch middleware exceptions

[Django]

#6094: core handlers do not catch middleware exceptions
+---
  Reporter:  gwilson| Owner:  gwilson
Status:  assigned   | Milestone: 
 Component:  HTTP handling  |   Version:  SVN
Resolution: |  Keywords: 
 Stage:  Accepted   | Has_patch:  1  
Needs_docs:  0  |   Needs_tests:  0  
Needs_better_patch:  0  |  
+---
Changes (by carljm):

 * cc: carljm (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] #9022: Allow US armed forces state codes for USStateField

[Django]

#9022: Allow US armed forces state codes for USStateField
+---
  Reporter:  Daniel Pope   | Owner:  
dougvanhorn
Status:  closed | Milestone:
 
 Component:  django.contrib.localflavor |   Version:  
1.0
Resolution:  wontfix|  Keywords:
 
 Stage:  Accepted   | Has_patch:  1 
 
Needs_docs:  0  |   Needs_tests:  0 
 
Needs_better_patch:  0  |  
+---
Changes (by carljm):

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

Comment:

 As documented in the
 [http://docs.djangoproject.com/en/dev/internals/contributing/#id1
 contributing docs], do not reopen tickets marked wontfix by a core
 committer.  If you have something new to add, bring it up on the
 [http://groups.google.com/group/django-developers django-developers]
 mailing list.

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

Re: [Django] #10839: Pickling queryset.query doesn't work for gis models

[Django]

#10839: Pickling queryset.query doesn't work for gis models
-+--
  Reporter:  jtiai   | Owner:  nobody
Status:  new | Milestone:
 Component:  GIS |   Version:  SVN   
Resolution:  |  Keywords:
 Stage:  Unreviewed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by Alex):

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

Old description:

> If I pickle queryset.query which is GIS model I get following results
> (using Oracle as database):
> qs = MyModel.objects.filter(id=12345)
>
> before pickling:
>
> >>> qs.query
> 
> >>> qry_str = pickle.dumps(qs.query)
> >>> qry = pickle.loads(qry_str)
> >>> qry
> 
>
> Somehow query object has changed. It works as expected on non GIS models.

New description:

 If I pickle queryset.query which is GIS model I get following results
 (using Oracle as database):
 qs = MyModel.objects.filter(id=12345)

 before pickling:
 {{{
 >>> qs.query
 
 >>> qry_str = pickle.dumps(qs.query)
 >>> qry = pickle.loads(qry_str)
 >>> qry
 
 }}}
 Somehow query object has changed. It works as expected on non GIS models.

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

[Django] #10839: Pickling queryset.query doesn't work for gis models

[Django]

#10839: Pickling queryset.query doesn't work for gis models
---+
 Reporter:  jtiai  |   Owner:  nobody
   Status:  new|   Milestone:
Component:  GIS| Version:  SVN   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 If I pickle queryset.query which is GIS model I get following results
 (using Oracle as database):
 qs = MyModel.objects.filter(id=12345)

 before pickling:

 >>> qs.query
 
 >>> qry_str = pickle.dumps(qs.query)
 >>> qry = pickle.loads(qry_str)
 >>> qry
 

 Somehow query object has changed. It works as expected on non GIS models.

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

[Changeset] r10571 - django/branches/releases/1.0.X/docs/topics

[noreply]

Author: russellm
Date: 2009-04-16 08:29:31 -0500 (Thu, 16 Apr 2009)
New Revision: 10571

Modified:
   django/branches/releases/1.0.X/docs/topics/files.txt
Log:
[1.0.X] Fixed #10779 -- Corrected description of an example in the files docs. 
Thanks to timo for the patch.

Merge of r10567 from trunk.

Modified: django/branches/releases/1.0.X/docs/topics/files.txt
===
--- django/branches/releases/1.0.X/docs/topics/files.txt2009-04-16 
13:28:58 UTC (rev 10570)
+++ django/branches/releases/1.0.X/docs/topics/files.txt2009-04-16 
13:29:31 UTC (rev 10571)
@@ -25,7 +25,7 @@
 :class:`~django.db.models.ImageField`, Django provides a set of APIs you can 
use
 to deal with that file.
 
-Consider the following model, using a ``FileField`` to store a photo::
+Consider the following model, using an ``ImageField`` to store a photo::
 
 class Car(models.Model):
 name = models.CharField(max_length=255)
@@ -111,7 +111,7 @@
 >>> default_storage.exists(path)
 False
 
-See :ref:`ref-files-storage` for the file storage API. 
+See :ref:`ref-files-storage` for the file storage API.
 
 The built-in filesystem storage class
 -


--~--~-~--~~~---~--~~
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] r10570 - in django/branches/releases/1.0.X/docs/ref: contrib models

[noreply]

Author: russellm
Date: 2009-04-16 08:28:58 -0500 (Thu, 16 Apr 2009)
New Revision: 10570

Modified:
   django/branches/releases/1.0.X/docs/ref/contrib/admin.txt
   django/branches/releases/1.0.X/docs/ref/models/fields.txt
Log:
[1.0.X] Fixed #10776 -- Added metadata targets for the contrib.admin docs, and 
used one of those targets to clarify the SlugField docs. Thanks to ernop for 
the suggestion, and timo for the patch.

Merge of r10564 from trunk.

Modified: django/branches/releases/1.0.X/docs/ref/contrib/admin.txt
===
--- django/branches/releases/1.0.X/docs/ref/contrib/admin.txt   2009-04-16 
13:28:16 UTC (rev 10569)
+++ django/branches/releases/1.0.X/docs/ref/contrib/admin.txt   2009-04-16 
13:28:58 UTC (rev 10570)
@@ -7,6 +7,8 @@
 .. module:: django.contrib.admin
:synopsis: Django's admin site.
 
+.. currentmodule:: django.contrib.admin
+
 One of the most powerful parts of Django is the automatic admin interface. It
 reads metadata in your model to provide a powerful and production-ready
 interface that content producers can immediately use to start adding content to
@@ -38,7 +40,7 @@
``ModelAdmin`` classes.
 
 5. Hook the ``AdminSite`` instance into your URLconf.
-   
+
 .. seealso::
 
 For information about serving the media files (images, JavaScript, and CSS)
@@ -47,6 +49,8 @@
 ``ModelAdmin`` objects
 ==
 
+.. class:: ModelAdmin
+
 The ``ModelAdmin`` class is the representation of a model in the admin
 interface. These are stored in a file named ``admin.py`` in your application.
 Let's take a look at a very simple example of the ``ModelAdmin``::
@@ -82,8 +86,7 @@
 class AuthorAdmin(admin.ModelAdmin):
 date_hierarchy = 'pub_date'
 
-``date_hierarchy``
-~~
+.. attribute:: ModelAdmin.date_hierarchy
 
 Set ``date_hierarchy`` to the name of a ``DateField`` or ``DateTimeField`` in
 your model, and the change list page will include a date-based drilldown
@@ -93,8 +96,7 @@
 
 date_hierarchy = 'pub_date'
 
-``form``
-
+.. attribute:: ModelAdmin.form
 
 By default a ``ModelForm`` is dynamically created for your model. It is used
 to create the form presented on both the add/change pages. You can easily
@@ -103,8 +105,7 @@
 
 For an example see the section `Adding custom validation to the admin`_.
 
-``fieldsets``
-~
+.. attribute:: ModelAdmin.fieldsets
 
 Set ``fieldsets`` to control the layout of admin "add" and "change" pages.
 
@@ -183,8 +184,7 @@
 ``django.utils.html.escape()`` to escape any HTML special
 characters.
 
-``fields``
-~~
+.. attribute:: ModelAdmin.fields
 
 Use this option as an alternative to ``fieldsets`` if the layout does not
 matter and if you want to only show a subset of the available fields in the
@@ -203,8 +203,7 @@
 dictionary key that is within the ``fieldsets`` option, as described in
 the previous section.
 
-``exclude``
-~~~
+.. attribute:: ModelAdmin.exclude
 
 This attribute, if given, should be a list of field names to exclude from the
 form.
@@ -229,22 +228,19 @@
 ``birth_date``, the forms resulting from the above declarations will contain
 exactly the same fields.
 
-``filter_horizontal``
-~
+.. attribute:: ModelAdmin.filter_horizontal
 
 Use a nifty unobtrusive JavaScript "filter" interface instead of the
 usability-challenged  in the admin form. The value is a
 list of fields that should be displayed as a horizontal filter interface. See
 ``filter_vertical`` to use a vertical interface.
 
-``filter_vertical``
-~~~
+.. attribute:: ModelAdmin.filter_vertical
 
 Same as ``filter_horizontal``, but is a vertical display of the filter
 interface.
 
-``list_display``
-
+.. attribute:: ModelAdmin.list_display
 
 Set ``list_display`` to control which fields are displayed on the change list
 page of the admin.
@@ -381,8 +377,7 @@
   The above will tell Django to order by the ``first_name`` field when
   trying to sort by ``colored_first_name`` in the admin.
 
-``list_display_links``
-~~
+.. attribute:: ModelAdmin.list_display_links
 
 Set ``list_display_links`` to control which fields in ``list_display`` should
 be linked to the "change" page for an object.
@@ -405,8 +400,7 @@
 list_display = ('first_name', 'last_name', 'birthday')
 list_display_links = ('first_name', 'last_name')
 
-``list_filter``
-~~~
+.. attribute:: ModelAdmin.list_filter
 
 Set ``list_filter`` to activate filters in the right sidebar of the change list
 page of the admin. This should be a list of field names, and each specified
@@ -426,14 +420,12 @@
 
 (This example also has ``search_fields`` defined. See below.)
 
-``list_per_page``
-~
+.. attribute:: ModelAdmin.list_per_page
 
 Set ``list_per_page`` to control how many items appear on each paginated admin
 change list page. By default, 

[Changeset] r10569 - django/branches/releases/1.0.X/docs/ref/templates

[noreply]

Author: russellm
Date: 2009-04-16 08:28:16 -0500 (Thu, 16 Apr 2009)
New Revision: 10569

Modified:
   django/branches/releases/1.0.X/docs/ref/templates/builtins.txt
Log:
[1.0.X] Fixed #10704 -- Resurrected documentation for {% else %} clause on {% 
ifchanged %}, lost during docs refactor. Thanks to Tarken for the report.

Merge of r10563 from trunk.

Modified: django/branches/releases/1.0.X/docs/ref/templates/builtins.txt
===
--- django/branches/releases/1.0.X/docs/ref/templates/builtins.txt  
2009-04-16 13:27:46 UTC (rev 10568)
+++ django/branches/releases/1.0.X/docs/ref/templates/builtins.txt  
2009-04-16 13:28:16 UTC (rev 10569)
@@ -330,6 +330,19 @@
 {% endifchanged %}
 {% endfor %}
 
+The ``ifchanged`` tag can also take an optional ``{% else %}`` clause that
+will be displayed if the value has not changed::
+
+{% for match in matches %}
+{{ match }}
+{% endfor %}
+
 .. templatetag:: ifequal
 
 ifequal


--~--~-~--~~~---~--~~
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] r10568 - django/branches/releases/1.0.X/docs/topics

[noreply]

Author: russellm
Date: 2009-04-16 08:27:46 -0500 (Thu, 16 Apr 2009)
New Revision: 10568

Modified:
   django/branches/releases/1.0.X/docs/topics/i18n.txt
Log:
[1.0.X] Fixed #10822 -- Corrected minor typo in i18n docs. Thanks to 
prairiedogg for the report.

Merge of r10561 from trunk.

Modified: django/branches/releases/1.0.X/docs/topics/i18n.txt
===
--- django/branches/releases/1.0.X/docs/topics/i18n.txt 2009-04-16 12:48:46 UTC 
(rev 10567)
+++ django/branches/releases/1.0.X/docs/topics/i18n.txt 2009-04-16 13:27:46 UTC 
(rev 10568)
@@ -454,10 +454,10 @@
   path). This is only relevant when you are creating a translation for
   Django itself, see :ref:`contributing-translations`.
 
-Th script runs over your project source tree or your application source tree 
and
-pulls out all strings marked for translation. It creates (or updates) a message
-file in the directory ``locale/LANG/LC_MESSAGES``. In the ``de`` example, the
-file will be ``locale/de/LC_MESSAGES/django.po``.
+The script runs over your project source tree or your application source tree
+and pulls out all strings marked for translation. It creates (or updates) a
+message file in the directory ``locale/LANG/LC_MESSAGES``. In the ``de``
+example, the file will be ``locale/de/LC_MESSAGES/django.po``.
 
 By default ``django-admin.py makemessages`` examines every file that has the
 ``.html`` file extension. In case you want to override that default, use the


--~--~-~--~~~---~--~~
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] #9022: Allow US armed forces state codes for USStateField

[Django]

#9022: Allow US armed forces state codes for USStateField
+---
  Reporter:  Daniel Pope   | Owner:  
dougvanhorn
Status:  reopened   | Milestone:
 
 Component:  django.contrib.localflavor |   Version:  
1.0
Resolution: |  Keywords:
 
 Stage:  Accepted   | Has_patch:  1 
 
Needs_docs:  0  |   Needs_tests:  0 
 
Needs_better_patch:  0  |  
+---
Changes (by dougvanhorn):

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

Comment:

 I'm reopening this ticket because I don't think
 [http://code.djangoproject.com/ticket/10308#comment:3 Adrian's reasoning]
 is sound, based on the fact that there are non-US states in the
 us_states.py module, such as:

  * American Somoa
  * Guam
  * Northern Mariana Islands
  * Puerto Rico
  * Virgin Islands

 I would also point to the USStateField documentation:

 {{{
 #!python
 class USStateField(Field):
 """
 A form field that validates its input is a U.S. state name or
 abbreviation.
 It normalizes the input to the standard two-leter postal service
 abbreviation for the given state.
 """
 }}}

 Which, rather plainly, states that the intent of the field is to represent
 two-letter postal service abbreviations.


 If we're to believe us_states.py should only represent the 50 states with
 a star on the flag, we need to patch the us_states.py module to remove the
 US territories listed above.

-- 
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] #10812: Slight documentation inconsistency in querysets.txt

[Django]

#10812: Slight documentation inconsistency in querysets.txt
+---
  Reporter:  uzi| Owner:  nobody
Status:  closed | Milestone:  1.1   
 Component:  Documentation  |   Version:  SVN   
Resolution:  fixed  |  Keywords:
 Stage:  Ready for checkin  | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by russellm):

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

Comment:

 (In [10562]) Fixed #10812 -- Corrected typo in aggregation docs. Thanks to
 uzi for the report.

-- 
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] #10838: Pass user object to CommentForm (initial data)

[Django]

#10838: Pass user object to CommentForm (initial data)
--+-
  Reporter:  pigletto | Owner:  nobody  
Status:  new  | Milestone:  
 Component:  django.contrib.comments  |   Version:  SVN 
Resolution:   |  Keywords:  comments
 Stage:  Unreviewed   | Has_patch:  1   
Needs_docs:  0|   Needs_tests:  0   
Needs_better_patch:  0|  
--+-
Changes (by pigletto):

  * needs_better_patch:  => 0
  * version:  1.0 => SVN
  * 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] #10838: Pass user object to CommentForm (initial data)

[Django]

#10838: Pass user object to CommentForm (initial data)
-+--
 Reporter:  pigletto |   Owner:  nobody
   Status:  new  |   Milestone:
Component:  django.contrib.comments  | Version:  1.0   
 Keywords:  comments |   Stage:  Unreviewed
Has_patch:  1|  
-+--
 !CommentForm should check if current user is authenticated and if so,
 initial data for user's 'name' and 'email' should be filled.
 Also, it is very useful to have access to at last user object (request?)
 in form's init. This way you're able to customize it a lot, eg. hide some
 fields or mark them readonly depending on user.
 Proposed patch passes user object to !CommentForm and then initial data
 are populated with 'name' and 'email' from user object

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

[Changeset] r10567 - django/trunk/docs/topics

[noreply]

Author: russellm
Date: 2009-04-16 07:48:46 -0500 (Thu, 16 Apr 2009)
New Revision: 10567

Modified:
   django/trunk/docs/topics/files.txt
Log:
Fixed #10779 -- Corrected description of an example in the files docs. Thanks 
to timo for the patch.

Modified: django/trunk/docs/topics/files.txt
===
--- django/trunk/docs/topics/files.txt  2009-04-16 12:48:16 UTC (rev 10566)
+++ django/trunk/docs/topics/files.txt  2009-04-16 12:48:46 UTC (rev 10567)
@@ -25,7 +25,7 @@
 :class:`~django.db.models.ImageField`, Django provides a set of APIs you can 
use
 to deal with that file.
 
-Consider the following model, using a ``FileField`` to store a photo::
+Consider the following model, using an ``ImageField`` to store a photo::
 
 class Car(models.Model):
 name = models.CharField(max_length=255)
@@ -111,7 +111,7 @@
 >>> default_storage.exists(path)
 False
 
-See :ref:`ref-files-storage` for the file storage API. 
+See :ref:`ref-files-storage` for the file storage API.
 
 The built-in filesystem storage class
 -


--~--~-~--~~~---~--~~
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] r10566 - django/trunk/docs/ref/contrib/comments

[noreply]

Author: russellm
Date: 2009-04-16 07:48:16 -0500 (Thu, 16 Apr 2009)
New Revision: 10566

Modified:
   django/trunk/docs/ref/contrib/comments/custom.txt
Log:
Fixed #10559 -- Clarified documentation on customization of comments pages. 
Thanks to Thejaswi Puthraya for the patch.

Modified: django/trunk/docs/ref/contrib/comments/custom.txt
===
--- django/trunk/docs/ref/contrib/comments/custom.txt   2009-04-16 12:47:34 UTC 
(rev 10565)
+++ django/trunk/docs/ref/contrib/comments/custom.txt   2009-04-16 12:48:16 UTC 
(rev 10566)
@@ -25,7 +25,7 @@
 'my_comment_app',
 ...
 ]
-
+
 COMMENTS_APP = 'my_comment_app'
 
 The app named in :setting:`COMMENTS_APP` provides its custom behavior by
@@ -45,13 +45,13 @@
 
 #. Create a custom comment :class:`~django.db.models.Model` that adds on 
the
"title" field.
-
+
 #. Create a custom comment :class:`~django.forms.Form` that also adds this
"title" field.
-
+
 #. Inform Django of these objects by defining a few functions in a
custom :setting:`COMMENTS_APP`.
-   
+
 So, carrying on the example above, we're dealing with a typical app structure 
in
 the ``my_custom_app`` directory::
 
@@ -63,13 +63,16 @@
 In the ``models.py`` we'll define a ``CommentWithTitle`` model::
 
 from django.db import models
-from django.contrib.comments.models import BaseCommentAbstractModel
+from django.contrib.comments.models import Comment
 
-class CommentWithTitle(BaseCommentAbstractModel):
+class CommentWithTitle(Comment):
 title = models.CharField(max_length=300)
-
-All custom comment models must subclass :class:`BaseCommentAbstractModel`.
 
+Most custom comment models will subclass the :class:`Comment` model. However,
+if you want to substantially remove or change the fields available in the
+:class:`Comment` model, but don't want to rewrite the templates, you could
+try subclassing from :class:`BaseCommentAbstractModel`.
+
 Next, we'll define a custom comment form in ``forms.py``. This is a little more
 tricky: we have to both create a form and override
 :meth:`CommentForm.get_comment_model` and
@@ -82,11 +85,11 @@
 
 class CommentFormWithTitle(CommentForm):
 title = forms.CharField(max_length=300)
-
+
 def get_comment_model(self):
 # Use our custom comment model instead of the built-in one.
 return CommentWithTitle
-
+
 def get_comment_create_data(self):
 # Use the data of the superclass, and add in the title field
 data = super(CommentFormWithTitle, self).get_comment_create_data()
@@ -186,4 +189,4 @@
 Return the URL for the "approve this comment from moderation" view.
 
 The default implementation returns a reverse-resolved URL pointing
-to the :func:`django.contrib.comments.views.moderation.approve` view.
\ No newline at end of file
+to the :func:`django.contrib.comments.views.moderation.approve` view.


--~--~-~--~~~---~--~~
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] r10565 - django/trunk/docs/ref/contrib/admin

[noreply]

Author: russellm
Date: 2009-04-16 07:47:34 -0500 (Thu, 16 Apr 2009)
New Revision: 10565

Modified:
   django/trunk/docs/ref/contrib/admin/index.txt
Log:
Fixed #10726 -- Added documentation on AdminSite urls. Thanks to Alex Gaynor 
for the initial draft.

Modified: django/trunk/docs/ref/contrib/admin/index.txt
===
--- django/trunk/docs/ref/contrib/admin/index.txt   2009-04-16 12:46:58 UTC 
(rev 10564)
+++ django/trunk/docs/ref/contrib/admin/index.txt   2009-04-16 12:47:34 UTC 
(rev 10565)
@@ -1137,40 +1137,11 @@
 your own ``AdminSite`` instance (see below), and changing the 
``index_template``
 or ``login_template`` properties.
 
-Linking to admin views
-==
-
-.. versionadded:: 1.1
-
-All the admin views use :ref:`named URL patterns ` so it's
-easy to link to admin views with ``urlresolvers.reverse`` or the :ttag:`url`
-template tag.
-
-Each model gets its own set of views and its own name using the model's app 
name
-and model name. For example, the "add" view for a ``Choice`` model in a
-``polls`` app would be named ``"admin_polls_choice_add"``.
-
-All the available views and their names are:
-
-==  ==  ===
-ViewView name   Parameters
-==  ==  ===
-Change list ``"admin___changelist"``None
-Add object  ``"admin___add"``   None
-Change object   ``"admin___change"````object_id``
-Delete object   ``"admin___delete"````object_id``
-Object history  ``"admin___history"``   ``object_id``
-==  ==  ===
-
-For example, to get the change URL for a particular ``Choice`` object::
-
->>> from django.core import urlresolvers
->>> c = Choice.objects.get(...)
->>> change_url = urlresolvers.reverse('admin_polls_choice_change', (c.id,))
-
 ``AdminSite`` objects
 =
 
+.. class:: AdminSite
+
 A Django administrative site is represented by an instance of
 ``django.contrib.admin.sites.AdminSite``; by default, an instance of
 this class is created as ``django.contrib.admin.site`` and you can
@@ -1246,14 +1217,82 @@
 ('^advanced-admin/', include(advanced_site.urls)),
 )
 
+``AdminSite`` instances take a single argument to their constructor, their
+name, which can be anything you like. This argument becomes the prefix to the
+URL names for the purposes of :ref:`reversing them`. This
+is only necessary if you are using more than one ``AdminSite``.
+
 Adding views to admin sites
 ---
 
 .. versionadded:: 1.1
 
-Just like ``ModelAdmin``, ``AdminSite`` provides a
+Just like :class:`ModelAdmin`, :class:`AdminSite` provides a
 :meth:`~django.contrib.admin.ModelAdmin.get_urls()` method
 that can be overridden to define additional views for the site. To add
 a new view to your admin site, extend the base
 :meth:`~django.contrib.admin.ModelAdmin.get_urls()` method to include
 a pattern for your new view.
+
+.. note::
+Any view you render that uses the admin templates, or extends the base
+admin template, should include in it's context a variable named
+``admin_site`` that contains the name of the :class:`AdminSite` instance. 
For
+:class:`AdminSite` instances, this means ``self.name``; for 
:class:`ModelAdmin`
+instances, this means ``self.admin_site.name``.
+
+.. _admin-reverse-urls:
+
+Reversing Admin URLs
+
+
+.. versionadded:: 1.1
+
+When an :class:`AdminSite` is deployed, the views provided by that site are
+accessible using Django's :ref:`URL reversing system `.
+
+The :class:`AdminSite` provides the following named URL patterns:
+
+==  === =
+PageURL nameParameters
+==  === =
+Index   ``admin_index``
+Logout  ``admin_logout``
+Password change ``admin_password_change``
+Password change done``admin_password_change_done``
+i18n javascript ``admin_jsi18n``
+Application index page  ``admin_app_list``  ``app_label``
+==  === =
+
+These names will be prefixed with the name of the :class:`AdminSite` instance,
+plus an underscore. For example, if your :class:`AdminSite` was named
+``custom``, then the Logout view would be served using a URL with the name
+``custom_admin_logout``. The default :class:`AdminSite` doesn't use a prefix
+in it's URL names.
+
+Each :class:`ModelAdmin` instance provides an additional set of named URLs:
+
+==  
=   

[Changeset] r10564 - in django/trunk/docs/ref: contrib/admin models

[noreply]

Author: russellm
Date: 2009-04-16 07:46:58 -0500 (Thu, 16 Apr 2009)
New Revision: 10564

Modified:
   django/trunk/docs/ref/contrib/admin/index.txt
   django/trunk/docs/ref/models/fields.txt
Log:
Fixed #10776 -- Added metadata targets for the contrib.admin docs, and used one 
of those targets to clarify the SlugField docs. Thanks to ernop for the 
suggestion, and timo for the patch.

Modified: django/trunk/docs/ref/contrib/admin/index.txt
===
--- django/trunk/docs/ref/contrib/admin/index.txt   2009-04-16 12:46:15 UTC 
(rev 10563)
+++ django/trunk/docs/ref/contrib/admin/index.txt   2009-04-16 12:46:58 UTC 
(rev 10564)
@@ -7,6 +7,8 @@
 .. module:: django.contrib.admin
:synopsis: Django's admin site.
 
+.. currentmodule:: django.contrib.admin
+
 One of the most powerful parts of Django is the automatic admin interface. It
 reads metadata in your model to provide a powerful and production-ready
 interface that content producers can immediately use to start adding content to
@@ -46,7 +48,7 @@
:maxdepth: 1
 
actions
-   
+
 .. seealso::
 
 For information about serving the media files (images, JavaScript, and CSS)
@@ -55,6 +57,8 @@
 ``ModelAdmin`` objects
 ==
 
+.. class:: ModelAdmin
+
 The ``ModelAdmin`` class is the representation of a model in the admin
 interface. These are stored in a file named ``admin.py`` in your application.
 Let's take a look at a very simple example of the ``ModelAdmin``::
@@ -90,8 +94,7 @@
 class AuthorAdmin(admin.ModelAdmin):
 date_hierarchy = 'pub_date'
 
-``date_hierarchy``
-~~
+.. attribute:: ModelAdmin.date_hierarchy
 
 Set ``date_hierarchy`` to the name of a ``DateField`` or ``DateTimeField`` in
 your model, and the change list page will include a date-based drilldown
@@ -101,8 +104,7 @@
 
 date_hierarchy = 'pub_date'
 
-``form``
-
+.. attribute:: ModelAdmin.form
 
 By default a ``ModelForm`` is dynamically created for your model. It is used
 to create the form presented on both the add/change pages. You can easily
@@ -111,8 +113,7 @@
 
 For an example see the section `Adding custom validation to the admin`_.
 
-``fieldsets``
-~
+.. attribute:: ModelAdmin.fieldsets
 
 Set ``fieldsets`` to control the layout of admin "add" and "change" pages.
 
@@ -191,8 +192,7 @@
 ``django.utils.html.escape()`` to escape any HTML special
 characters.
 
-``fields``
-~~
+.. attribute:: ModelAdmin.fields
 
 Use this option as an alternative to ``fieldsets`` if the layout does not
 matter and if you want to only show a subset of the available fields in the
@@ -211,8 +211,7 @@
 dictionary key that is within the ``fieldsets`` option, as described in
 the previous section.
 
-``exclude``
-~~~
+.. attribute:: ModelAdmin.exclude
 
 This attribute, if given, should be a list of field names to exclude from the
 form.
@@ -237,22 +236,19 @@
 ``birth_date``, the forms resulting from the above declarations will contain
 exactly the same fields.
 
-``filter_horizontal``
-~
+.. attribute:: ModelAdmin.filter_horizontal
 
 Use a nifty unobtrusive JavaScript "filter" interface instead of the
 usability-challenged  in the admin form. The value is a
 list of fields that should be displayed as a horizontal filter interface. See
 ``filter_vertical`` to use a vertical interface.
 
-``filter_vertical``
-~~~
+.. attribute:: ModelAdmin.filter_vertical
 
 Same as ``filter_horizontal``, but is a vertical display of the filter
 interface.
 
-``list_display``
-
+.. attribute:: ModelAdmin.list_display
 
 Set ``list_display`` to control which fields are displayed on the change list
 page of the admin.
@@ -389,8 +385,7 @@
   The above will tell Django to order by the ``first_name`` field when
   trying to sort by ``colored_first_name`` in the admin.
 
-``list_display_links``
-~~
+.. attribute:: ModelAdmin.list_display_links
 
 Set ``list_display_links`` to control which fields in ``list_display`` should
 be linked to the "change" page for an object.
@@ -415,8 +410,7 @@
 
 .. _admin-list-editable:
 
-``list_editable``
-~
+.. attribute:: ModelAdmin.list_editable
 
 .. versionadded:: 1.1
 
@@ -441,8 +435,7 @@
 
 You'll get a validation error if any of these rules are broken.
 
-``list_filter``
-~~~
+.. attribute:: ModelAdmin.list_filter
 
 Set ``list_filter`` to activate filters in the right sidebar of the change list
 page of the admin. This should be a list of field names, and each specified
@@ -462,14 +455,12 @@
 
 (This example also has ``search_fields`` defined. See below.)
 
-``list_per_page``
-~
+.. attribute:: ModelAdmin.list_per_page
 
 Set ``list_per_page`` to control how many items appear on each paginated admin
 change list page. By default, this is set to ``100``.
 
-``list_select_related``

[Changeset] r10563 - django/trunk/docs/ref/templates

[noreply]

Author: russellm
Date: 2009-04-16 07:46:15 -0500 (Thu, 16 Apr 2009)
New Revision: 10563

Modified:
   django/trunk/docs/ref/templates/builtins.txt
Log:
Fixed #10704 -- Resurrected documentation for {% else %} clause on {% ifchanged 
%}, lost during docs refactor. Thanks to Tarken for the report.

Modified: django/trunk/docs/ref/templates/builtins.txt
===
--- django/trunk/docs/ref/templates/builtins.txt2009-04-16 12:45:35 UTC 
(rev 10562)
+++ django/trunk/docs/ref/templates/builtins.txt2009-04-16 12:46:15 UTC 
(rev 10563)
@@ -359,6 +359,19 @@
 {% endifchanged %}
 {% endfor %}
 
+The ``ifchanged`` tag can also take an optional ``{% else %}`` clause that
+will be displayed if the value has not changed::
+
+{% for match in matches %}
+{{ match }}
+{% endfor %}
+
 .. templatetag:: ifequal
 
 ifequal


--~--~-~--~~~---~--~~
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] r10562 - django/trunk/docs/ref/models

[noreply]

Author: russellm
Date: 2009-04-16 07:45:35 -0500 (Thu, 16 Apr 2009)
New Revision: 10562

Modified:
   django/trunk/docs/ref/models/querysets.txt
Log:
Fixed #10812 -- Corrected typo in aggregation docs. Thanks to uzi for the 
report.

Modified: django/trunk/docs/ref/models/querysets.txt
===
--- django/trunk/docs/ref/models/querysets.txt  2009-04-16 12:45:04 UTC (rev 
10561)
+++ django/trunk/docs/ref/models/querysets.txt  2009-04-16 12:45:35 UTC (rev 
10562)
@@ -188,7 +188,7 @@
 >>> q[0].entry__count
 42
 
-The ``Blog`` model doesn't define an ``entry_count`` attribute by itself,
+The ``Blog`` model doesn't define an ``entry__count`` attribute by itself,
 but by using a keyword argument to specify the aggregate function, you can
 control the name of the annotation::
 
@@ -1485,7 +1485,7 @@
 like ``contains`` but is significantly faster due to full-text indexing.
 
 Example::
-
+
 Entry.objects.filter(headline__search="+Django -jazz Python")
 
 SQL equivalent::


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

[noreply]

Author: russellm
Date: 2009-04-16 07:45:04 -0500 (Thu, 16 Apr 2009)
New Revision: 10561

Modified:
   django/trunk/docs/topics/i18n.txt
Log:
Fixed #10822 -- Corrected minor typo in i18n docs. Thanks to prairiedogg for 
the report.

Modified: django/trunk/docs/topics/i18n.txt
===
--- django/trunk/docs/topics/i18n.txt   2009-04-16 12:44:32 UTC (rev 10560)
+++ django/trunk/docs/topics/i18n.txt   2009-04-16 12:45:04 UTC (rev 10561)
@@ -454,10 +454,10 @@
   path). This is only relevant when you are creating a translation for
   Django itself, see :ref:`contributing-translations`.
 
-Th script runs over your project source tree or your application source tree 
and
-pulls out all strings marked for translation. It creates (or updates) a message
-file in the directory ``locale/LANG/LC_MESSAGES``. In the ``de`` example, the
-file will be ``locale/de/LC_MESSAGES/django.po``.
+The script runs over your project source tree or your application source tree
+and pulls out all strings marked for translation. It creates (or updates) a
+message file in the directory ``locale/LANG/LC_MESSAGES``. In the ``de``
+example, the file will be ``locale/de/LC_MESSAGES/django.po``.
 
 By default ``django-admin.py makemessages`` examines every file that has the
 ``.html`` file extension. In case you want to override that default, use the


--~--~-~--~~~---~--~~
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] r10560 - django/trunk/django/db

[noreply]

Author: russellm
Date: 2009-04-16 07:44:32 -0500 (Thu, 16 Apr 2009)
New Revision: 10560

Modified:
   django/trunk/django/db/__init__.py
Log:
Fixed #10833 -- Corrected load_backend so that it actually loads the requested 
backend, rather than always loading settings.DATABASE_BACKEND. Thanks to Alex 
Gaynor for the report and fix.

Modified: django/trunk/django/db/__init__.py
===
--- django/trunk/django/db/__init__.py  2009-04-14 19:14:32 UTC (rev 10559)
+++ django/trunk/django/db/__init__.py  2009-04-16 12:44:32 UTC (rev 10560)
@@ -14,7 +14,7 @@
 try:
 # Most of the time, the database backend will be one of the official
 # backends that ships with Django, so look there first.
-return import_module('.base', 'django.db.backends.%s' % 
settings.DATABASE_ENGINE)
+return import_module('.base', 'django.db.backends.%s' % backend_name)
 except ImportError, e:
 # If the import failed, we might be looking for a database backend
 # distributed external to Django. So we'll try that next.


--~--~-~--~~~---~--~~
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] #10779: Typo in Files documentation

[Django]

#10779: Typo in Files documentation
+---
  Reporter:  amiroff| Owner:  nobody 
Status:  new| Milestone: 
 Component:  Documentation  |   Version:  SVN
Resolution: |  Keywords:  typo, documentation
 Stage:  Ready for checkin  | Has_patch:  1  
Needs_docs:  0  |   Needs_tests:  0  
Needs_better_patch:  0  |  
+---
Changes (by timo):

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

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

Re: [Django] #8087: Template tags 'ifin' and 'ifnotin' checking if element is present in sequence

[Django]

#8087: Template tags 'ifin' and 'ifnotin' checking if element is present in
sequence
-+--
  Reporter:  emes| Owner:  nobody   
 
Status:  new | Milestone:   
 
 Component:  Template system |   Version:  SVN  
 
Resolution:  |  Keywords:  templatetag, 
tag, sequence
 Stage:  Design decision needed  | Has_patch:  1
 
Needs_docs:  0   |   Needs_tests:  0
 
Needs_better_patch:  0   |  
-+--
Comment (by dc):

 > Surely this behaviour should be supported in the default if tag?

 Good idea.

-- 
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] #10816: CsrfMiddleware false positive after session.flush()

[Django]

#10816: CsrfMiddleware false positive after session.flush()
---+
  Reporter:  Glenn | Owner:  nobody   
Status:  new   | Milestone:   
 Component:  Contrib apps  |   Version:  SVN  
Resolution:|  Keywords:  csrf sessions
 Stage:  Unreviewed| Has_patch:  0
Needs_docs:  0 |   Needs_tests:  0
Needs_better_patch:  0 |  
---+
Comment (by simon):

 Provided the value of the cookie (or a hash based on the value of the
 cookie) is included in a hidden form field the should be just as secure as
 something based on sessions.

-- 
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] #10701: manage.py runfcgi dies in response to SIGHUP/SIGUSR1, disallows log rotation

[Django]

#10701: manage.py runfcgi dies in response to SIGHUP/SIGUSR1, disallows log
rotation
-+--
  Reporter:  robbyd  | Owner:  nobody   
 
Status:  new | Milestone:   
 
 Component:  Core framework  |   Version:  1.0  
 
Resolution:  |  Keywords:  runfcgi, fastcgi, 
SIGHUP, log rotation
 Stage:  Unreviewed  | Has_patch:  0
 
Needs_docs:  0   |   Needs_tests:  0
 
Needs_better_patch:  0   |  
-+--
Changes (by alexkoshelev):

 * cc: alexkoshelev (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] #8087: Template tags 'ifin' and 'ifnotin' checking if element is present in sequence

[Django]

#8087: Template tags 'ifin' and 'ifnotin' checking if element is present in
sequence
-+--
  Reporter:  emes| Owner:  nobody   
 
Status:  new | Milestone:   
 
 Component:  Template system |   Version:  SVN  
 
Resolution:  |  Keywords:  templatetag, 
tag, sequence
 Stage:  Design decision needed  | Has_patch:  1
 
Needs_docs:  0   |   Needs_tests:  0
 
Needs_better_patch:  0   |  
-+--
Comment (by tomevans222):

 I was the submitter of #10821, and the more I think on it, the more a
 separate tag seems ridiculous. Surely this behaviour should be supported
 in the default if tag?


 {{{
 {% if foo in bar or a_bool or a_list %}{% wibble %}{% endif %}
 }}}

 dc: This would make your hard to do example:
 {{{
 {% if user.is_anonymous or user in ban_list %}
 }}}

 Which do you think is easier to read and has a clearer intention?

 I will prepare a patch that achieves this.

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

[Django] #10837: postgresql missing field type codes in data_types_reverse

[Django]

#10837: postgresql missing field type codes in data_types_reverse
---+
 Reporter:  trbs   |   Owner:  nobody   
 
   Status:  new|   Milestone:   
 
Component:  Database layer (models, ORM)   | Version:  1.0  
 
 Keywords:  bpchar, data_types_reverse, introspection  |   Stage:  
Unreviewed
Has_patch:  1  |  
---+
 I've created a patch to add 'char' field support to data_types_reverse in
 the PostgreSQL.
 As a char(50) is basically the same (CharField) as a varchar(50) for
 Django.

 Also created a second patch which also adds 'int8' to the list as an
 'IntegerField'.

 This would make inspectdb and other (third-party code?) that uses
 data_type_reverse a bit more complete for PG.

-- 
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] #8087: Template tags 'ifin' and 'ifnotin' checking if element is present in sequence

[Django]

#8087: Template tags 'ifin' and 'ifnotin' checking if element is present in
sequence
-+--
  Reporter:  emes| Owner:  nobody   
 
Status:  new | Milestone:   
 
 Component:  Template system |   Version:  SVN  
 
Resolution:  |  Keywords:  templatetag, 
tag, sequence
 Stage:  Design decision needed  | Has_patch:  1
 
Needs_docs:  0   |   Needs_tests:  0
 
Needs_better_patch:  0   |  
-+--
Comment (by dc):

 With new tag it is also hard to do: {% if user.is_anonymous or
 ban_list|contains:user %}

-- 
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] #10630: [PATCH] GZipMiddleware does not handle all MSIE issues.

[Django]

#10630: [PATCH] GZipMiddleware does not handle all MSIE issues.
--+-
  Reporter:  sebastian_noack  | Owner:  nobody
Status:  closed   | Milestone:  1.1   
 Component:  HTTP handling|   Version:  1.0   
Resolution:  fixed|  Keywords:
 Stage:  Accepted | Has_patch:  1 
Needs_docs:  0|   Needs_tests:  0 
Needs_better_patch:  0|  
--+-
Comment (by sebastian_noack):

 Replying to [comment:2 mtredinnick]:
 > We also probably need a way to indicate "don't gzip this", down the
 track, so that the !HttpResponse creator can avoid this middleware piece
 for particular pieces of content (trying to gzip a zip archive is pretty
 pointless, for example).

 Yo can do that in the vie function by striping 'gzip' from the request's
 HTTP_ACCEPT_ENCODING header. Maybe we should introduce a decorator for
 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
-~--~~~~--~~--~--~---

[Django] #10836: FieldDoesNotExist import in gis.db.models.sql.query should be in gis.db.models.sql.where

[Django]

#10836: FieldDoesNotExist import in gis.db.models.sql.query should be in
gis.db.models.sql.where
---+
 Reporter:  seanl  |   Owner:  nobody
   Status:  new|   Milestone:
Component:  GIS| Version:  SVN   
 Keywords: |   Stage:  Unreviewed
Has_patch:  1  |  
---+
 Self-explanatory - the import of FieldDoesNotExist is in the wrong file -
 the exception isn't raised anywhere in sql/query.py but it is in
 sql/where.py (in _check_geo_field). I'm guessing this was due to some code
 re-organization.

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