Re: [Django] #10848: added my name to AUTHORS

[Django]

#10848: added my name to AUTHORS
+---
  Reporter:  prairiedogg| Owner:  nobody
Status:  new| Milestone:
 Component:  Documentation  |   Version:  1.0   
Resolution: |  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Comment (by prairiedogg):

 Thanks for the pointers.  I have completed and sent back the contributors
 license agreement.  I plan to start a blog at some point, when I do I'll
 submit that as my contact page.  If there's a strong preference to include
 my email I've included it in the ICLA, otherwise, I'll just post another
 patch when I get around to starting the blog.

-- 
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] #10872: Support of 'list_editable' in admin when using GeoDjango geometry fields

[Django]

#10872: Support of 'list_editable' in admin when using GeoDjango geometry fields
--+-
  Reporter:  springmeyer  | Owner:  nobody
Status:  new  | Milestone:  1.1   
 Component:  GIS  |   Version:  SVN   
Resolution:   |  Keywords:
 Stage:  Accepted | Has_patch:  1 
Needs_docs:  0|   Needs_tests:  0 
Needs_better_patch:  1|  
--+-
Comment (by springmeyer):

 Alex wisely caught the deeper issue here that we should be using 'name'
 instead of 'field' from the attr's for the unique field name. Doing so,
 along with using 'name' for the namespacing of each map's javascript gets
 things working nicely and more cleanly for both the changelist view and
 the record view.

 New patch attached. Didn't need to alter the openlayers.js at all
 (therefore left the reference to {{ field }} in that file - we can clean
 that up whenever).

 Thanks Alex,

 -dane

-- 
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] #10872: Support of 'list_editable' in admin when using GeoDjango geometry fields

[Django]

#10872: Support of 'list_editable' in admin when using GeoDjango geometry fields
--+-
  Reporter:  springmeyer  | Owner:  nobody
Status:  new  | Milestone:  1.1   
 Component:  GIS  |   Version:  SVN   
Resolution:   |  Keywords:
 Stage:  Accepted | Has_patch:  1 
Needs_docs:  0|   Needs_tests:  0 
Needs_better_patch:  1|  
--+-
Changes (by Alex):

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

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

[Django] #10872: Support of 'list_editable' in admin when using GeoDjango geometry fields

[Django]

#10872: Support of 'list_editable' in admin when using GeoDjango geometry fields
-+--
 Reporter:  springmeyer  |   Owner:  nobody
   Status:  new  |   Milestone:  1.1   
Component:  GIS  | Version:  SVN   
 Keywords:   |   Stage:  Unreviewed
Has_patch:  1|  
-+--
 The post data sent from a GeoDjango geometry field currently fails when
 'list_editable' is used in the Django Admin (when using the GeoDjango
 OSMGeoAdmin)

 The problem occurs for two small reasons:

 1) Because the geometry field is a textarea whose name is contructed from
 {{ field }} rather than {{ id }} the post data does not get prepended with
 the 'form-row' information.
  * See:
 
http://code.djangoproject.com/browser/django/trunk/django/contrib/gis/templates/gis/admin/openlayers.html#L35

 2) Because (I think) the geometry widget textarea is hidden the geometry
 field {{ id }} is prefixed with 'id_' unlike other fields I've noticed.

 So, any easy fix for #1 is to use {{ id }} instead of {{ field }} like:
 {{{
 Index: django/contrib/gis/templates/gis/admin/openlayers.html
 ===
 --- django/contrib/gis/templates/gis/admin/openlayers.html  (revision
 10604)
 +++ django/contrib/gis/templates/gis/admin/openlayers.html  (working
 copy)
 @@ -32,6 +32,6 @@
  
  Delete all Features
  {% if display_wkt %} WKT debugging window:{% endif %}
 -{{ wkt }}
 +{{ wkt }}
  {% block init_function %}{{ module
 }}.init();{% endblock %}
  

 }}}

 But that raises/creates issue #2 which effectively breaks the successful
 posting of data in both the list_editable changelist view and on the
 normal record view page (due to the 'id_' prefixing).

 I've been looking through the commit (r10077) and the django forms trying
 to track down how and where and why this 'id_' gets prefixed. I can't
 quite suss out where it is happening well enough to feel like I know the
 right place to tackle this.

 So, my best fix at this point is to strip the 'id_' off of the field id
 inside the geodjango form widget. The attached patch does that in a way to
 gets the list_editable working and still works great with the normal
 record edit/view page. So, a classic 'this patch works (seemingly)
 perfectly, but sucks : )

 I'm concerned about some solution to this because I anticipate that once
 users running 1.1 discover this 'list_editable' feature I'm sure many
 using GeoDjango folks will want to try it out and will hit this.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, 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] #9420: Correction to documentation on get(**kwargs) queryset method

[Django]

#9420: Correction to documentation on get(**kwargs) queryset method
+---
  Reporter:  daveyjoe   | Owner:  nobody
Status:  closed | Milestone:
 Component:  Documentation  |   Version:  1.0   
Resolution:  fixed  |  Keywords:  documentation get queryset
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by CollinAnderson):

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

Comment:

 [10598] actually fixed #9492.

-- 
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] r10604 - django/branches/releases/1.0.X/django/contrib/gis/db/backend/postgis

[noreply]

Author: jbronn
Date: 2009-04-19 19:11:36 -0500 (Sun, 19 Apr 2009)
New Revision: 10604

Modified:
   
django/branches/releases/1.0.X/django/contrib/gis/db/backend/postgis/creation.py
Log:
[1.0.X] Fixed #10364 -- Correctly identify test spatial database creation 
errors to the user.

Backport of r10603 from trunk.


Modified: 
django/branches/releases/1.0.X/django/contrib/gis/db/backend/postgis/creation.py
===
--- 
django/branches/releases/1.0.X/django/contrib/gis/db/backend/postgis/creation.py
2009-04-19 23:31:14 UTC (rev 10603)
+++ 
django/branches/releases/1.0.X/django/contrib/gis/db/backend/postgis/creation.py
2009-04-20 00:11:36 UTC (rev 10604)
@@ -54,16 +54,19 @@
 cursor.execute(create_sql)
 #print create_sql
 except Exception, e:
-# Drop and recreate, if necessary.
-if not autoclobber:
-confirm = raw_input("\nIt appears the database, %s, already 
exists. Type 'yes' to delete it, or 'no' to cancel: " % db_name)
-if autoclobber or confirm == 'yes':
-if verbosity >= 1: print 'Destroying old spatial database...'
-drop_db(db_name)
-if verbosity >= 1: print 'Creating new spatial database...'
-cursor.execute(create_sql)
+if 'already exists' in e.pgerror.lower():
+# Database already exists, drop and recreate if user agrees.
+if not autoclobber:
+confirm = raw_input("\nIt appears the database, %s, already 
exists. Type 'yes' to delete it, or 'no' to cancel: " % db_name)
+if autoclobber or confirm == 'yes':
+if verbosity >= 1: print 'Destroying old spatial database...'
+drop_db(db_name)
+if verbosity >= 1: print 'Creating new spatial database...'
+cursor.execute(create_sql)
+else:
+raise Exception('Spatial Database Creation canceled.')
 else:
-raise Exception('Spatial Database Creation canceled.')
+raise Exception('Spatial database creation failed: "%s"' % 
e.pgerror.strip())
 
 created_regex = re.compile(r'^createdb: database creation failed: ERROR:  
database ".+" already exists')
 def _create_with_shell(db_name, verbosity=1, autoclobber=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] #10364: Incorrect error message given when role does not have create database privilege

[Django]

#10364: Incorrect error message given when role does not have create database
privilege
---+
  Reporter:  tylere| Owner:  jbronn
Status:  closed| Milestone:  1.1   
 Component:  GIS   |   Version:  SVN   
Resolution:  fixed |  Keywords:
 Stage:  Accepted  | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by jbronn):

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

Comment:

 (In r10603) Fixed #10364 -- Correctly identify test spatial database
 creation errors to the 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
-~--~~~~--~~--~--~---

[Changeset] r10603 - django/trunk/django/contrib/gis/db/backend/postgis

[noreply]

Author: jbronn
Date: 2009-04-19 18:31:14 -0500 (Sun, 19 Apr 2009)
New Revision: 10603

Modified:
   django/trunk/django/contrib/gis/db/backend/postgis/creation.py
Log:
Fixed #10364 -- Correctly identify test spatial database creation errors to the 
user.


Modified: django/trunk/django/contrib/gis/db/backend/postgis/creation.py
===
--- django/trunk/django/contrib/gis/db/backend/postgis/creation.py  
2009-04-19 23:07:24 UTC (rev 10602)
+++ django/trunk/django/contrib/gis/db/backend/postgis/creation.py  
2009-04-19 23:31:14 UTC (rev 10603)
@@ -46,16 +46,19 @@
 # Trying to create the database first.
 cursor.execute(create_sql)
 except Exception, e:
-# Drop and recreate, if necessary.
-if not autoclobber:
-confirm = raw_input("\nIt appears the database, %s, already 
exists. Type 'yes' to delete it, or 'no' to cancel: " % db_name)
-if autoclobber or confirm == 'yes':
-if verbosity >= 1: print 'Destroying old spatial database...'
-drop_db(db_name)
-if verbosity >= 1: print 'Creating new spatial database...'
-cursor.execute(create_sql)
+if 'already exists' in e.pgerror.lower():
+# Database already exists, drop and recreate if user agrees.
+if not autoclobber:
+confirm = raw_input("\nIt appears the database, %s, already 
exists. Type 'yes' to delete it, or 'no' to cancel: " % db_name)
+if autoclobber or confirm == 'yes':
+if verbosity >= 1: print 'Destroying old spatial database...'
+drop_db(db_name)
+if verbosity >= 1: print 'Creating new spatial database...'
+cursor.execute(create_sql)
+else:
+raise Exception('Spatial database creation canceled.')
 else:
-raise Exception('Spatial Database Creation canceled.')
+raise Exception('Spatial database creation failed: "%s"' % 
e.pgerror.strip())
 
 created_regex = re.compile(r'^createdb: database creation failed: ERROR:  
database ".+" already exists')
 def _create_with_shell(db_name, verbosity=1, autoclobber=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] #10364: Incorrect error message given when role does not have create database privilege

[Django]

#10364: Incorrect error message given when role does not have create database
privilege
---+
  Reporter:  tylere| Owner:  jbronn
Status:  new   | Milestone:  1.1   
 Component:  GIS   |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by jbronn):

  * owner:  nobody => jbronn

-- 
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] #10832: GIS test runner (run_tests) should reorder test suite like django.test.simple.run_tests

[Django]

#10832: GIS test runner (run_tests) should reorder test suite like
django.test.simple.run_tests
---+
  Reporter:  seanl | Owner:  jbronn
Status:  closed| Milestone:  1.1   
 Component:  GIS   |   Version:  SVN   
Resolution:  fixed |  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by jbronn):

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

Comment:

 (In r10602) Fixed #10832 -- now use `reorder_suite` in GeoDjango test
 runner, thanks seanl for ticket & patch; restored original ordering of
 GEOS tests, as placing last no longer necessary.

-- 
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] r10602 - django/trunk/django/contrib/gis/tests

[noreply]

Author: jbronn
Date: 2009-04-19 18:07:24 -0500 (Sun, 19 Apr 2009)
New Revision: 10602

Modified:
   django/trunk/django/contrib/gis/tests/__init__.py
Log:
Fixed #10832 -- now use `reorder_suite` in GeoDjango test runner, thanks seanl 
for ticket & patch; restored original ordering of GEOS tests, as placing last 
no longer necessary.


Modified: django/trunk/django/contrib/gis/tests/__init__.py
===
--- django/trunk/django/contrib/gis/tests/__init__.py   2009-04-19 22:49:15 UTC 
(rev 10601)
+++ django/trunk/django/contrib/gis/tests/__init__.py   2009-04-19 23:07:24 UTC 
(rev 10602)
@@ -1,4 +1,5 @@
 import sys, unittest
+from django.test.simple import reorder_suite, TestCase
 from django.utils.importlib import import_module
 
 def geo_suite():
@@ -16,6 +17,10 @@
 # The test suite.
 s = unittest.TestSuite()
 
+# Adding the GEOS tests.
+from django.contrib.gis.geos import tests as geos_tests
+s.addTest(geos_tests.suite())
+
 # Tests that require use of a spatial database (e.g., creation of models)
 test_apps = ['geoapp', 'relatedapp']
 
@@ -48,14 +53,6 @@
 tsuite = import_module('django.contrib.gis.tests.' + suite_name)
 s.addTest(tsuite.suite())
 
-# Adding the GEOS tests _last_.  Doing this because if suite starts
-# immediately with this test while after running syncdb, it will cause a
-# segmentation fault.  My initial guess is that SpatiaLite is still in
-# critical areas of non thread-safe GEOS code when the test suite is run.
-# TODO: Confirm my reasoning. Are there other consequences?
-from django.contrib.gis.geos import tests as geos_tests
-s.addTest(geos_tests.suite())
-
 return s, test_apps
 
 def run_gis_tests(test_labels, **kwargs):
@@ -158,6 +155,8 @@
 for test in extra_tests:
 suite.addTest(test)
 
+suite = reorder_suite(suite, (TestCase,))
+
 # Executing the tests (including the model tests), and destorying the
 # test database after the tests have completed.
 result = unittest.TextTestRunner(verbosity=verbosity).run(suite)


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, 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] #10832: GIS test runner (run_tests) should reorder test suite like django.test.simple.run_tests

[Django]

#10832: GIS test runner (run_tests) should reorder test suite like
django.test.simple.run_tests
---+
  Reporter:  seanl | Owner:  jbronn
Status:  new   | Milestone:  1.1   
 Component:  GIS   |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by jbronn):

  * owner:  nobody => jbronn

Comment:

 Replying to [comment:1 kmtracey]:
 > Particularly as there are apparently already some ordering requirements
 for gis testing in order to avoid segfaults...hopefully moving the
 !TestCase tests to the front do not conflict with that?

 That segfault-prevention ordering was only needed when using the
 SpatiaLite 2.3 beta version.  Fortunately, the 2.3 stable release and
 recent improvements in the way !GeoDjango retrieves SRID information have
 made this ordering requirement moot, and I'll remove it when I patch this
 ticket.

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

[Changeset] r10601 - django/trunk/django/contrib/gis/tests

[noreply]

Author: jbronn
Date: 2009-04-19 17:49:15 -0500 (Sun, 19 Apr 2009)
New Revision: 10601

Modified:
   django/trunk/django/contrib/gis/tests/__init__.py
Log:
Fixed #10791 -- The GeoDjango test runner now respects the `--noinput` 
command-line option, thanks to seanl for ticket & patch; replaced docstring 
with URL to latest documentation.


Modified: django/trunk/django/contrib/gis/tests/__init__.py
===
--- django/trunk/django/contrib/gis/tests/__init__.py   2009-04-19 03:44:06 UTC 
(rev 10600)
+++ django/trunk/django/contrib/gis/tests/__init__.py   2009-04-19 22:49:15 UTC 
(rev 10601)
@@ -115,45 +115,10 @@
 
 def run_tests(test_labels, verbosity=1, interactive=True, extra_tests=[], 
suite=None):
 """
-This module allows users to run tests for GIS apps that require the 
creation
-of a spatial database.  Currently, this is only required for PostgreSQL as
-PostGIS needs extra overhead in test database creation.
-
-In order to create a PostGIS database, the DATABASE_USER (or
-TEST_DATABASE_USER, if defined) will require superuser priviliges.
-
-To accomplish this outside the `postgres` user, you have a few options:
-  (A) Make your user a super user:
-This may be done at the time the user is created, for example:
-$ createuser --superuser 
-
-Or you may alter the user's role from the SQL shell (assuming this
-is done from an existing superuser role):
-postgres# ALTER ROLE  SUPERUSER;
-
-  (B) Create your own PostgreSQL database as a local user:
-1. Initialize database: `initdb -D /path/to/user/db`
-2. If there's already a Postgres instance on the machine, it will need
-   to use a different TCP port than 5432. Edit postgresql.conf (in
-   /path/to/user/db) to change the database port (e.g. `port = 5433`).
-3. Start this database `pg_ctl -D /path/to/user/db start`
-
-  (C) On Windows platforms the pgAdmin III utility may also be used as
-a simple way to add superuser privileges to your database user.
-
-The TEST_RUNNER needs to be set in your settings like so:
-
-  TEST_RUNNER='django.contrib.gis.tests.run_tests'
-
-Note: This test runner assumes that the PostGIS SQL files ('lwpostgis.sql'
-and 'spatial_ref_sys.sql') are installed in the directory specified by
-`pg_config --sharedir` (and defaults to /usr/local/share if that fails).
-This behavior is overridden if POSTGIS_SQL_PATH is set in your settings.
-
-Windows users should set POSTGIS_SQL_PATH manually because the output
-of `pg_config` uses paths like 'C:/PROGRA~1/POSTGR~1/..'.
-
-Finally, the tests may be run by invoking `./manage.py test`.
+Set `TEST_RUNNER` in your settings with this routine in order to
+scaffold test spatial databases correctly for your GeoDjango models.
+For more documentation, please consult the following URL:
+  http://geodjango.org/docs/testing.html.
 """
 from django.conf import settings
 from django.db import connection
@@ -171,7 +136,7 @@
 old_name = settings.DATABASE_NAME
 
 # Creating the test spatial database.
-create_test_spatial_db(verbosity=verbosity)
+create_test_spatial_db(verbosity=verbosity, autoclobber=not interactive)
 
 # The suite may be passed in manually, e.g., when we run the GeoDjango 
test,
 # we want to build it and pass it in due to some customizations.  
Otherwise,


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, 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] #10516: Admin search doesn't work when having multiple search_fields to the same base model.

[Django]

#10516: Admin search doesn't work when having multiple search_fields to the same
base model.
---+
  Reporter:  akaariai  | Owner: 
   
Status:  new   | Milestone:  1.1
   
 Component:  django.contrib.admin  |   Version:  1.0
   
Resolution:|  Keywords:  search, 
inheritance, admin
 Stage:  Accepted  | Has_patch:  0  
   
Needs_docs:  0 |   Needs_tests:  0  
   
Needs_better_patch:  0 |  
---+
Changes (by anonymous):

  * owner:  cbess =>

Comment:

 won't have time to finish

-- 
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] #10672: Proxy Model does not send save signal

[Django]

#10672: Proxy Model does not send save signal
---+
  Reporter:  zbyte64   | Owner:  nobody
Status:  new   | Milestone:  1.1   
 Component:  Database layer (models, ORM)  |   Version:  1.1-beta-1
Resolution:|  Keywords:
 Stage:  Design decision needed| Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by Alex):

 My guess is the issue is that by default a weak reference is used, and
 since you overwrite the class references to the inner closure ceases to
 exist.

-- 
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] #10672: Proxy Model does not send save signal

[Django]

#10672: Proxy Model does not send save signal
---+
  Reporter:  zbyte64   | Owner:  nobody
Status:  new   | Milestone:  1.1   
 Component:  Database layer (models, ORM)  |   Version:  1.1-beta-1
Resolution:|  Keywords:
 Stage:  Design decision needed| Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by Valera_Grishin):

 Ah, sorry. I forgot to add last line of code in both examples above:
 {{{
 #!python
 ChangeListener = ChangeListener()
 }}}
 That is, I immediately instantiate ChangeListener after it has been
 defined. But, first example doesn't work while second one does work fine.
 This seems quite misterious to me since the difference is only the
 location of "listener" definition (inside or outside of ChangeListener).

 P.S. Alex, this is not a support question but a question whether this is
 the same bug or separate ticket needs to be added. Thanks.

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

Re: [Django] #10153: 'gte' missing in get_db_prep_lookup lookup

[Django]

#10153: 'gte'  missing in  get_db_prep_lookup lookup
---+
  Reporter:  gatwanagu | Owner:  joelhooks  
  
Status:  new   | Milestone:  1.1
  
 Component:  Database layer (models, ORM)  |   Version:  1.0
  
Resolution:|  Keywords:  queryset 
field lookup
 Stage:  Accepted  | Has_patch:  1  
  
Needs_docs:  0 |   Needs_tests:  1  
  
Needs_better_patch:  0 |  
---+
Changes (by jdunck):

  * needs_tests:  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] #5594: The url tag won't work with multiple admin sites

[Django]

#5594: The url tag won't work with multiple admin sites
---+
  Reporter:  jkocherhans   | Owner:  nobody
Status:  closed| Milestone:
 Component:  django.contrib.admin  |   Version:  newforms-admin
Resolution:  duplicate |  Keywords:  nfa-someday   
 Stage:  Someday/Maybe | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by Alex):

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

Comment:

 Marking as a dupe of #10061 since that solves this issue.

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

Re: [Django] #4501: Coverage support for tests

[Django]

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

  * keywords:  => gsoc
  * needs_better_patch:  0 => 1
  * needs_docs:  0 => 1
  * needs_tests:  0 => 1
  * milestone:  => 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] #10808: Multiple inheritance (model-based) broken for __init__ of common fields in diamond inheritance

[Django]

#10808: Multiple inheritance (model-based) broken for __init__ of common fields 
in
diamond inheritance
---+
  Reporter:  mikemintz | 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 |  
---+
Changes (by mikemintz):

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

Comment:

 It looks like the reason this is happening is in the "for field in
 fields_iter:" loop around line 224 for db/models/base.py. We iterate
 through the fields in order, but "name" is defined twice in the fields, so
 the second time it's reached, the argument has been popped from kwargs,
 and we set it back to field.get_default().

 This could be easily solved by having a local set of "set_fields" in
 !__init!__. Each time we call setattr on field.attname, we add
 field.attname to the set (and don't call setattr on it again if it's been
 set already).

 If this sounds like a reasonable solution, I can write a 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] #10672: Proxy Model does not send save signal

[Django]

#10672: Proxy Model does not send save signal
---+
  Reporter:  zbyte64   | Owner:  nobody
Status:  new   | Milestone:  1.1   
 Component:  Database layer (models, ORM)  |   Version:  1.1-beta-1
Resolution:|  Keywords:
 Stage:  Design decision needed| Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by Alex):

 That will not work either, a signal will not be called unless it is
 connected which doesn't happen unless that code is excecuted.  Please
 don't use trac for asking for these support questions, use either #django
 on freenode or django-users 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] #7539: Add ON DELETE and ON UPDATE support to Django

[Django]

#7539: Add ON DELETE and ON UPDATE support to Django
---+
  Reporter:  glassfordm| Owner:  nobody 
Status:  new   | Milestone: 
 Component:  Database layer (models, ORM)  |   Version:  SVN
Resolution:|  Keywords:  feature
 Stage:  Design decision needed| Has_patch:  1  
Needs_docs:  1 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Changes (by diegobz):

 * cc: diegobz (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] #10396: Django File Upload /Image Upload Forms are broken with Safari (3 and beta 4)

[Django]

#10396: Django File Upload /Image Upload Forms are broken with Safari (3 and 
beta
4)
---+
  Reporter:  sir...@gmx.de | Owner:  nobody
Status:  new   | Milestone:  1.1   
 Component:  File uploads/storage  |   Version:  1.0   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by raphael):

 Hum... I cannot replicate it even outside of admin (I used Safari 3.2.1 on
 MacOS). My assumption is that it is a Safari related problem.

 Which version are you using ?

 Did you try to load a sample file with the same HTML content to see if it
 is related to Django ?

-- 
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] #10349: ManyToMany field does not take dynamic initial values into account

[Django]

#10349: ManyToMany field does not take dynamic initial values into account
---+
  Reporter:  fas   | Owner:  fas
 
Status:  new   | Milestone:  1.1
 
 Component:  Database layer (models, ORM)  |   Version:  1.0
 
Resolution:|  Keywords:  
ManyToMany, initial, dynamic, lambda
 Stage:  Accepted  | Has_patch:  1  
 
Needs_docs:  0 |   Needs_tests:  1  
 
Needs_better_patch:  0 |  
---+
Changes (by fas):

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

Comment:

 When using Field.formfield you can pass a lambda function as the initial
 value which will be passed over to the form field. When rendering the form
 field, the initial value will be evaluated in case it is a function. This
 is done in forms/forms.py, method as_widget.

 The ManyToManyField however overwrites the formfield method in order to
 set its initial value to be a list of IDs. It assumes that the given
 initial value is a list of related objects. It also assumes that the form
 class to be used is forms.ModelMultipleChoiceField or that the form field
 to be used takes a list of IDs. Both assumptions are incorrect.
 {{{
 def formfield(self, **kwargs):
 defaults = {'form_class': forms.ModelMultipleChoiceField,
 'queryset':
 self.rel.to._default_manager.complex_filter(self.rel.limit_choices_to)}
 defaults.update(kwargs)
 # If initial is passed in, it's a list of related objects, but the
 # MultipleChoiceField takes a list of IDs.
 if defaults.get('initial') is not None:
 defaults['initial'] = [i._get_pk_val() for i in
 defaults['initial']]
 return super(ManyToManyField, self).formfield(**defaults)
 }}}

 This makes it impossible to pass a function for the initial value and also
 makes it impossible to create a custom form field that needs the related
 object and not only its IDs. I revoke my initial patch and propose that we
 should find a solution that works without the two assumptions made above.
 I think ModelChoiceField (forms/models.py) might the the right place.
 Applying the same transformation (object->ID) there before passing the
 initial to the super (ChoiceField) should solve the problem.

 Any suggestions?

-- 
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] #10870: Aggregates with joins ignore extra filters provided by setup_joins

[Django]

#10870: Aggregates with joins ignore extra filters provided by setup_joins
--+-
  Reporter:  fas  | Owner:  fas 

Status:  new  | Milestone:  

 Component:  ORM aggregation  |   Version:  SVN 

Resolution:   |  Keywords:  orm, aggregation, join, 
contenttypes, filter
 Stage:  Accepted | Has_patch:  0   

Needs_docs:  0|   Needs_tests:  0   

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

 * cc: mben...@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
-~--~~~~--~~--~--~---

[Django] #10871: Add input support to admin actions (with patch)

[Django]

#10871: Add input support to admin actions (with patch)
--+-
 Reporter:  Adys  |   Owner:  Adys  
   Status:  new   |   Milestone:
Component:  django.contrib.admin  | Version:  1.1-beta-1
 Keywords:|   Stage:  Unreviewed
Has_patch:  1 |  
--+-
 I wanted to be able to set tags to a lot of objects at once in the admin
 site.
 The attached patch adds a takes_input attribute to an admin action
 (default False). If set to True, a 4th "input" argument will be passed,
 which you can use as such:
 {{{
 def add_tag(modeladmin, request, queryset, input):
 for obj in queryset:
 Tag.objects.add_tag(obj, input)
 add_tag.takes_input = True
 }}}

 I'd love some comments on it. Some TODO would be:
 - Hiding the input if no give action takes an input
 - js-disabling it if the current selected action doesn't take an input..
 not too sure about 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
-~--~~~~--~~--~--~---

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

[Django]

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

 Replying to [comment:9 kmtracey]:

 The problem brought up by julien and kmtracey is already reported by
 #9988.

-- 
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] #10672: Proxy Model does not send save signal

[Django]

#10672: Proxy Model does not send save signal
---+
  Reporter:  zbyte64   | Owner:  nobody
Status:  new   | Milestone:  1.1   
 Component:  Database layer (models, ORM)  |   Version:  1.1-beta-1
Resolution:|  Keywords:
 Stage:  Design decision needed| Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by Valera_Grishin):

 Well, I though so too unless following happened to work:

 {{{
 #!python
 from django.db import models
 from django.db.models.signals import post_save

 class MyModel(models.Model):
 pass

 def listener(sender, **kwargs):
 print "MyModel changed"

 class ChangeLinstener:
def __init__(self):
post_save.connect(listener, sender=MyModel)
 }}}

 Which looks like hackish design (the "listener" function should be inside
 ChangeListener).

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