Re: [Django] #13260: urlresolvers.reverse() generates invalid URLs when an argument contains % character

[Django]

#13260: urlresolvers.reverse() generates invalid URLs when an argument contains 
%
character
-+--
  Reporter:  semenov | Owner:  stumbles
Status:  assigned| Milestone:  
 Component:  Core framework  |   Version:  1.1 
Resolution:  |  Keywords:  
 Stage:  Accepted| Has_patch:  1   
Needs_docs:  0   |   Needs_tests:  0   
Needs_better_patch:  0   |  
-+--
Changes (by stumbles):

  * has_patch:  0 => 1

Comment:

 Added a copy of russellm's regression test to also test kwargs.

 Have resolved by applying urlquote to the args and kwargs values. Special
 characters "+$*/" are marked as safe to comply with existing regression
 tests.

 This is my first Django patch, so any feedback would be appreciated.

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

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

[Django] #13317: {% blocktrans %}: accessing attributes and general documentation concerning variables

[Django]

#13317: {% blocktrans %}: accessing attributes and general documentation 
concerning
variables
-+--
 Reporter:  ChrisMorgan  |   Owner:  nobody
   Status:  new  |   Milestone:
Component:  Documentation| Version:  SVN   
 Keywords:  blocktrans variables attributes  |   Stage:  Unreviewed
Has_patch:  0|  
-+--
 In the Django template system, it's documented about using `{% blocktrans
 %}` with local variables; it says that:

 "To translate a template expression -- say, using template filters -- you
 need to bind the expression to a local variable for use within the
 translation block:"

 This caused me quite a bit of trouble as it didn't occur to me for a very
 long time that accessing attributes on a model object would qualify as a
 template expression.  This meant that for ages I was trying to work out
 why this caused a !KeyError:

 {{{
 {% blocktrans %}That will cost ${{ i.price }}{% endblocktrans %}
 }}}

 I think that it needs to be either specified in
 docs/topics/i18n/internationalization that this sort of a situation would
 need to be done like this:

 {{{
 {% blocktrans with i.price as price %}That will cost ${{ price }}{%
 endblocktrans %}
 }}}

 Or, better still, it should be fixed so that it works... but considering
 how gettext works this probably isn't reasonable. Currently though it only
 shows examples of filters and that made it so that the reason my code was
 breaking didn't occur to me.

 Also the documentation of the "count" thing is very vague. It took me a
 while to work out (partly due to the fact that recognition "count" is
 missing from the Pygments lexer) that it is just using `count` instead of
 `with` or `and`, like the following. It could be considerably improved by
 spelling this out in so many words.

 {{{
 {% blocktrans with i.price as price count i.length as years %}That will
 cost ${{ price }} per year{% plural %}That will cost ${{ price }} per {{
 years }} years{% endblocktrans %}
 }}}

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

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

Re: [Django] #13260: urlresolvers.reverse() generates invalid URLs when an argument contains % character

[Django]

#13260: urlresolvers.reverse() generates invalid URLs when an argument contains 
%
character
-+--
  Reporter:  semenov | Owner:  stumbles
Status:  assigned| Milestone:  
 Component:  Core framework  |   Version:  1.1 
Resolution:  |  Keywords:  
 Stage:  Accepted| Has_patch:  0   
Needs_docs:  0   |   Needs_tests:  0   
Needs_better_patch:  0   |  
-+--
Changes (by stumbles):

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

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

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

Re: [Django] #5925: Unable to use urlresolvers (url, reverse ) feature in redirect argument of decorator user_passes_test

[Django]

#5925: Unable to use urlresolvers (url,reverse ) feature in redirect argument of
decorator user_passes_test
-+--
  Reporter:  anonymous   | Owner:  SmileyChris  
  
Status:  assigned| Milestone:   
  
 Component:  Core framework  |   Version:  SVN  
  
Resolution:  |  Keywords:  
urlresolver,reverse,decorator,url,permalink
 Stage:  Accepted| Has_patch:  1
  
Needs_docs:  0   |   Needs_tests:  0
  
Needs_better_patch:  0   |  
-+--
Changes (by clouserw):

 * cc: clous...@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-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #13316: AuthenticationForm shouldn't prefill user's password on failure

[Django]

#13316: AuthenticationForm shouldn't prefill user's password on failure
+---
 Reporter:  clouserw|   Owner:  nobody
   Status:  new |   Milestone:
Component:  Authentication  | Version:  SVN   
 Keywords:  |   Stage:  Unreviewed
Has_patch:  1   |  
+---
 contrib.auth.forms.AuthenticationForm should be passing render_value=False
 to the PasswordInput widget to prevent incorrect passwords from being
 passed back to the page.  I'm attaching 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-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #13315: Backwards-incompatible change not documented: PostGISAdaptor -> PostGISAdapter

[Django]

#13315: Backwards-incompatible change not documented: PostGISAdaptor ->
PostGISAdapter
+---
  Reporter:  bkonkle| Owner:  nobody
 
Status:  new| Milestone:  1.2   
 
 Component:  Documentation  |   Version:  1.2-beta  
 
Resolution: |  Keywords:  geodjango, gis, postgis, 
PostGISAdaptor
 Stage:  Unreviewed | Has_patch:  1 
 
Needs_docs:  0  |   Needs_tests:  0 
 
Needs_better_patch:  0  |  
+---
Changes (by bkonkle):

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

Comment:

 Correction - I forgot the 's' on the end of 'backends' for the renamed
 class.  I'm uploading a new diff.

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

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

[Django] #13315: Backwards-incompatible change not documented: PostGISAdaptor -> PostGISAdapter

[Django]

#13315: Backwards-incompatible change not documented: PostGISAdaptor ->
PostGISAdapter
-+--
 Reporter:  bkonkle  |   Owner:  nobody
   Status:  new  |   Milestone:  1.2   
Component:  Documentation| Version:  1.2-beta  
 Keywords:  geodjango, gis, postgis, PostGISAdaptor  |   Stage:  Unreviewed
Has_patch:  1|  
-+--
 The django.contrib.gis.db.backend.postgis.adaptor.PostGISAdaptor class has
 been renamed to
 django.contrib.gis.db.backend.postgis.adapter.PostGISAdapter in 1.2, but
 this is not documented in
 http://docs.djangoproject.com/en/dev/releases/1.2/.  I'm attaching a patch
 that will add a quick note about it.

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

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

[Django] #13314: "FIleField" validation does not account for "upload_to" when counting characters

[Django]

#13314: "FIleField" validation does not account for "upload_to" when counting
characters
---+
 Reporter:  denilsonsa |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Uncategorized  | Version:  1.1   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 I have a model with a FileField object:

 {{{
 def set_file (instance, filename):
 return os.path.join("uploaded_files/my_obj_%d" % instance.my_obj_id,
 os.path.basename(filename))

 class MyModel(models.Model):
 my_file = models.FileField(upload_to=set_file, null=True)
 }}}

 And I have a view that receives the POST and handles it to a trivial
 forms.ModelForm object. In that view I check for .is_valid().

 Since the FileField creates a 100-char column at the database, any
 filename greater than 100 chars will be rejected, and the form instance
 will have a nice error message talking about this.

 However, this comparison is broken, because the actual data stored at the
 database won't be the filename, but instead the return value of the
 "upload_to" callable. This returned value, in my case, has more characters
 than the actual filename.

 Thus, in this case, filenames between 75 and 100 characters will be
 accepted by the form validation, but will be rejected by the database when
 the actual .save() occurs.

 I'm not very sure about what is the best solution, but the
 forms.fields.FileField shouldn't rely just on the max_length parameter
 when validating the input.

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

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

Re: [Django] #13275: url_backwards_re catastrophic backtracking (?) problem

[Django]

#13275: url_backwards_re catastrophic backtracking (?) problem
+---
  Reporter:  kmtracey   | Owner:  SmileyChris
Status:  assigned   | Milestone:  1.2
 Component:  Template system|   Version:  SVN
Resolution: |  Keywords: 
 Stage:  Ready for checkin  | Has_patch:  1  
Needs_docs:  0  |   Needs_tests:  0  
Needs_better_patch:  0  |  
+---
Comment (by SmileyChris):

 I solved the problem by not bothering with creating another regular
 expression at all.

 The new method is to:

 1. Do a quick check to see if the arguments could be the old format (all
 argument bits except the last [but always the first] contain a comma)

 2. If it could be the old format, try to compile the first argument as a
 variable

 3. If compiling fails, assume it's the old format. Arguments are
 concatenated (they were a comma with a space) and then split by commas.

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

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

Re: [Django] #13275: url_backwards_re catastrophic backtracking (?) problem

[Django]

#13275: url_backwards_re catastrophic backtracking (?) problem
+---
  Reporter:  kmtracey   | Owner:  SmileyChris
Status:  assigned   | Milestone:  1.2
 Component:  Template system|   Version:  SVN
Resolution: |  Keywords: 
 Stage:  Ready for checkin  | Has_patch:  1  
Needs_docs:  0  |   Needs_tests:  0  
Needs_better_patch:  0  |  
+---
Changes (by SmileyChris):

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

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

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

[Changeset] r12942 - in django/trunk/docs: . ref/contrib/gis

[noreply]

Author: jbronn
Date: 2010-04-09 15:51:01 -0500 (Fri, 09 Apr 2010)
New Revision: 12942

Modified:
   django/trunk/docs/index.txt
   django/trunk/docs/ref/contrib/gis/create_template_postgis-1.5.sh
   django/trunk/docs/ref/contrib/gis/install.txt
   django/trunk/docs/ref/contrib/gis/layermapping.txt
   django/trunk/docs/ref/contrib/gis/tutorial.txt
Log:
Minor documentation tweaks for GeoDjango, including addition of link to main 
index, and removal of unsupported `:download:` directives.


Modified: django/trunk/docs/index.txt
===
--- django/trunk/docs/index.txt 2010-04-09 13:24:13 UTC (rev 12941)
+++ django/trunk/docs/index.txt 2010-04-09 20:51:01 UTC (rev 12942)
@@ -168,6 +168,7 @@
 * :ref:`Databrowse `
 * :ref:`E-mail (sending) `
 * :ref:`Flatpages `
+* :ref:`GeoDjango `
 * :ref:`Humanize `
 * :ref:`Internationalization `
 * :ref:`Jython support `

Modified: django/trunk/docs/ref/contrib/gis/create_template_postgis-1.5.sh
===
--- django/trunk/docs/ref/contrib/gis/create_template_postgis-1.5.sh
2010-04-09 13:24:13 UTC (rev 12941)
+++ django/trunk/docs/ref/contrib/gis/create_template_postgis-1.5.sh
2010-04-09 20:51:01 UTC (rev 12942)
@@ -6,4 +6,5 @@
 psql -d template_postgis -f $POSTGIS_SQL_PATH/postgis.sql # Loading the 
PostGIS SQL routines
 psql -d template_postgis -f $POSTGIS_SQL_PATH/spatial_ref_sys.sql
 psql -d template_postgis -c "GRANT ALL ON geometry_columns TO PUBLIC;" # 
Enabling users to alter spatial tables.
+psql -d template_postgis -c "GRANT ALL ON geography_columns TO PUBLIC;"
 psql -d template_postgis -c "GRANT ALL ON spatial_ref_sys TO PUBLIC;"

Modified: django/trunk/docs/ref/contrib/gis/install.txt
===
--- django/trunk/docs/ref/contrib/gis/install.txt   2010-04-09 13:24:13 UTC 
(rev 12941)
+++ django/trunk/docs/ref/contrib/gis/install.txt   2010-04-09 20:51:01 UTC 
(rev 12942)
@@ -89,7 +89,7 @@
     
  ==
 :ref:`GEOS `Geometry Engine Open Source   Yes
   3.2, 3.1, 3.0
 `PROJ.4`_ Cartographic Projections library  Yes 
(PostgreSQL and SQLite only)  4.7, 4.6, 4.5, 4.4
-:ref:`GDAL `Geospatial Data Abstraction Library   No (but, 
required for SQLite) 1.6, 1.5, 1.4
+:ref:`GDAL `Geospatial Data Abstraction Library   No (but, 
required for SQLite) 1.7, 1.6, 1.5, 1.4
 :ref:`GeoIP `  IP-based geolocation library  No 
   1.4
 `PostGIS`__   Spatial extensions for PostgreSQL Yes 
(PostgreSQL only) 1.5, 1.4, 1.3
 `SpatiaLite`__Spatial extensions for SQLite Yes (SQLite 
only) 2.4, 2.3
@@ -150,13 +150,13 @@
 First, download GEOS 3.2 from the refractions website and untar the source 
 archive::
 
-$ wget http://download.osgeo.org/geos/geos-3.2.0.tar.bz2
-$ tar xjf geos-3.2.0.tar.bz2
+$ wget http://download.osgeo.org/geos/geos-3.2.1.tar.bz2
+$ tar xjf geos-3.2.1.tar.bz2
 
 Next, change into the directory where GEOS was unpacked, run the configure 
 script, compile, and install::
 
-$ cd geos-3.2.0
+$ cd geos-3.2.1
 $ ./configure
 $ make
 $ sudo make install
@@ -465,11 +465,11 @@
 
 Because SpatiaLite must be loaded as an external extension, it requires the
 ``enable_load_extension`` method, which is only available in versions 2.5+.
-Thus, download pysqlite2 2.5, and untar::
+Thus, download pysqlite2 2.6, and untar::
   
-$ wget http://pysqlite.googlecode.com/files/pysqlite-2.5.6.tar.gz
-$ tar xzf pysqlite-2.5.6.tar.gz
-$ cd pysqlite-2.5.6
+$ wget http://pysqlite.googlecode.com/files/pysqlite-2.6.0.tar.gz
+$ tar xzf pysqlite-2.6.0.tar.gz
+$ cd pysqlite-2.6.0
 
 Next, use a text editor (e.g., ``emacs`` or ``vi``) to edit the ``setup.cfg`` 
file
 to look like the following::
@@ -520,7 +520,7 @@
versions 1.4 and 1.5 use ``/contrib/postgis-1.4/postgis.sql`` and
``/contrib/postgis-1.5/postgis.sql``, respectively.
 
-   The example below assumes 1.5, thus you may need to modify
+   The example below assumes PostGIS 1.5, thus you may need to modify
``POSTGIS_SQL_PATH`` and the name of the SQL file for the specific 
version of PostGIS you are using.
 
@@ -540,20 +540,18 @@
 $ psql -d template_postgis -f $POSTGIS_SQL_PATH/spatial_ref_sys.sql
 # Enabling users to alter spatial tables.
 $ psql -d template_postgis -c "GRANT ALL ON geometry_columns TO PUBLIC;"
+$ psql -d template_postgis -c "GRANT ALL ON geography_columns TO PUBLIC;"
 $ psql -d template_postgis -c "GRANT ALL ON spatial_ref_sys TO PUBLIC;"
 
-
-
-
 These commands may be placed in a shell script for later use; for convenience
 the following s

Re: [Django] #13275: url_backwards_re catastrophic backtracking (?) problem

[Django]

#13275: url_backwards_re catastrophic backtracking (?) problem
--+-
  Reporter:  kmtracey | Owner:  SmileyChris
Status:  assigned | Milestone:  1.2
 Component:  Template system  |   Version:  SVN
Resolution:   |  Keywords: 
 Stage:  Accepted | Has_patch:  0  
Needs_docs:  0|   Needs_tests:  0  
Needs_better_patch:  0|  
--+-
Changes (by SmileyChris):

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

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

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

Re: [Django] #13312: order_by on null-field gives different results on different db engines

[Django]

#13312: order_by on null-field gives different results on different db engines
---+
  Reporter:  binary| Owner:  nobody 
   
Status:  closed| Milestone: 
   
 Component:  Database layer (models, ORM)  |   Version:  1.1
   
Resolution:  wontfix   |  Keywords:  ordering, 
order_by
 Stage:  Unreviewed| Has_patch:  0  
   
Needs_docs:  0 |   Needs_tests:  0  
   
Needs_better_patch:  0 |  
---+
Changes (by ubernostrum):

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

Comment:

 I think this is one of those cases where we really just have to tell
 people to know the behavior of the DB they choose to use; `NULL`-handling
 in all its many forms is one of those things that's just not worth the
 time and complexity of abstraction.

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

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

Re: [Django] #10146: Support for contrib/markdown extension_configs in settings.py

[Django]

#10146: Support for contrib/markdown extension_configs in settings.py
---+
  Reporter:  bdejong   | Owner:  nobody 
 
Status:  new   | Milestone:  1.3
 
 Component:  Contrib apps  |   Version:  SVN
 
Resolution:|  Keywords:  markdown config extensions 
extension_configs
 Stage:  Accepted  | Has_patch:  1  
 
Needs_docs:  0 |   Needs_tests:  0  
 
Needs_better_patch:  0 |  
---+
Comment (by ubernostrum):

 The request for documentation for reST filter support has been split off
 to #13310; this ticket is now solely for the feature of supporting
 Markdown extensions.

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

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

Re: [Django] #13310: RESTRUCTUREDTEXT_FILTER_SETTINGS is undocumented

[Django]

#13310: RESTRUCTUREDTEXT_FILTER_SETTINGS is undocumented
+---
  Reporter:  Wraithan   | Owner:  nobody
Status:  new| Milestone:  1.2   
 Component:  Documentation  |   Version:  1.1   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by ubernostrum):

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

Comment:

 This was split off, at my request, from #10146 which additionally
 requested support for a similar feature for Markdown. Since we already
 support reST extensions, though, there's no good reason for them not to be
 documented.

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

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

Re: [Django] #13313: Custom Default Manager with extra __init__ arguments fails if model is used in a ManyToManyField

[Django]

#13313: Custom Default Manager with extra __init__ arguments fails if model is 
used
in a ManyToManyField
---+
  Reporter:  cbw...@gmail.com  | Owner:  nobody 
 
Status:  new   | Milestone:  1.2
 
 Component:  Database layer (models, ORM)  |   Version:  SVN
 
Resolution:|  Keywords:  
ManyToManyField, Manager
 Stage:  Unreviewed| Has_patch:  0  
 
Needs_docs:  0 |   Needs_tests:  0  
 
Needs_better_patch:  0 |  
---+
Changes (by cbw...@gmail.com):

  * keywords:  => ManyToManyField, Manager
  * needs_better_patch:  => 0
  * version:  1.1 => 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-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #13313: Custom Default Manager with extra __init__ arguments fails if model is used in a ManyToManyField

[Django]

#13313: Custom Default Manager with extra __init__ arguments fails if model is 
used
in a ManyToManyField
--+-
 Reporter:  cbw...@gmail.com  |   Owner:  nobody
   Status:  new   |   Milestone:  1.2   
Component:  Database layer (models, ORM)  | Version:  1.1   
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 Suppose I have the following classes:

 {{{
 class SpecialManager(models.Manager):
 def __init__(self, special_arg):
 self.special_arg=special_arg
 def random_method():
 pass

 class SpecialModel(models.Model):
 objects = SpecialManager('hello')
 pass

 class InnocentModel(models.Model):
 my_friends = models.ManyToManyField(SpecialModel)
 }}}

 This is all well and fine, until I actually try to use the model:

 {{{
 >>> obj = InnocentModel.objects.all()[0]
 >>> obj.my_friends
 Traceback (most recent call last):
   File "", line 1, in 
   File "d:\code\env\src\django\django\db\models\fields\related.py", line
 716, in __get__
 reverse=False
   File "d:\code\env\src\django\django\db\models\fields\related.py", line
 469, in __init__
 super(ManyRelatedManager, self).__init__()
 TypeError: __init__() takes at least 2 arguments (1 given)
 }}}

 This is because related.py creates a subclass of the manager's default
 model for relation purposes:

 
http://code.djangoproject.com/browser/django/trunk/django/db/models/fields/related.py?rev=12908#L706
 {{{
 # Dynamically create a class that subclasses the related
 # model's default manager.
 rel_model=self.field.rel.to
 superclass = rel_model._default_manager.__class__
 RelatedManager = create_many_related_manager(superclass,
 self.field.rel)

 manager = RelatedManager(
 model=rel_model,
 core_filters={'%s__pk' % self.field.related_query_name():
 instance._get_pk_val()},
 instance=instance,
 symmetrical=self.field.rel.symmetrical,
 source_field_name=self.field.m2m_field_name(),
 target_field_name=self.field.m2m_reverse_field_name(),
 reverse=False
 )
 }}}

 This manager is then instantiated, and calls super():

 
http://code.djangoproject.com/browser/django/trunk/django/db/models/fields/related.py?rev=12908#L469

 {{{
 465 class ManyRelatedManager(superclass):
 466 def __init__(self, model=None, core_filters=None,
 instance=None, symmetrical=None,
 467 join_table=None, source_field_name=None,
 target_field_name=None,
 468 reverse=False):
 469 super(ManyRelatedManager, self).__init__()
 }}}

 And because this super() is now calling the custom manager's __init__
 without passing in any parameters, we get the traceback above.

 So, a few questions:

 1. Is this a documentation error? Should managers not take __init__
 paramaters?

 2. You'll notice I don't have use_for_related_fields specified on my
 manager. According to the documentation (
 http://docs.djangoproject.com/en/dev/topics/db/managers/#using-managers-
 for-related-object-access ) django should use the default manager, right?

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

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

[Django] #13312: order_by on null-field gives different results on different db engines

[Django]

#13312: order_by on null-field gives different results on different db engines
--+-
 Reporter:  binary|   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Database layer (models, ORM)  | Version:  1.1   
 Keywords:  ordering, order_by|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 Applying order_by on null=True fields gives different results on mysql and
 pgsql: pgsql thinks that NULL values are bigger than any and mysql that
 smaller. I think that this must be unified on all engines for prevent
 problems with portability. pgsql has additional parameter for this:

 {{{
 SELECT select_list
 FROM table_expression
 ORDER BY sort_expression1 [ASC | DESC] [NULLS { FIRST | LAST }]
  [, sort_expression2 [ASC | DESC] [NULLS { FIRST | LAST }]
 ...]
 }}}

 But I don't know how it on other engines.

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

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

Re: [Django] #6434: auto_now and auto_now_add documentation

[Django]

#6434: auto_now and auto_now_add documentation
+---
  Reporter:  jok...@radgjafahus.is  | Owner:  adamnelson
 
Status:  new| Milestone:
 
 Component:  Documentation  |   Version:  SVN   
 
Resolution: |  Keywords:  datefield 
auto_now auto_now_add
 Stage:  Accepted   | Has_patch:  1 
 
Needs_docs:  0  |   Needs_tests:  0 
 
Needs_better_patch:  1  |  
+---
Changes (by adamnelson):

  * owner:  nobody => adamnelson

Comment:

 Nobody seems to be working on this so I'll take it.

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

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

Re: [Django] #12986: SelectDateField doesn't repost data when USE_L10N = True and LANGUAGE_CODE = 'nl'

[Django]

#12986: SelectDateField doesn't repost data when USE_L10N = True and 
LANGUAGE_CODE
= 'nl'
---+
  Reporter:  w...@go2people.nl  | Owner:  bmihelac
Status:  reopened  | Milestone:  1.2 
 Component:  Forms |   Version:  1.2-beta
Resolution:|  Keywords:  
 Stage:  Accepted  | Has_patch:  1   
Needs_docs:  0 |   Needs_tests:  1   
Needs_better_patch:  0 |  
---+
Changes (by jezdez):

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

Comment:

 Please don't close tickets that haven't been fixed in trunk.

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

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

Re: [Django] #12986: SelectDateField doesn't repost data when USE_L10N = True and LANGUAGE_CODE = 'nl'

[Django]

#12986: SelectDateField doesn't repost data when USE_L10N = True and 
LANGUAGE_CODE
= 'nl'
---+
  Reporter:  w...@go2people.nl  | Owner:  bmihelac
Status:  closed| Milestone:  1.2 
 Component:  Forms |   Version:  1.2-beta
Resolution:  fixed |  Keywords:  
 Stage:  Accepted  | Has_patch:  1   
Needs_docs:  0 |   Needs_tests:  1   
Needs_better_patch:  0 |  
---+
Changes (by anonymous):

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

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

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

Re: [Django] #10702: .extra() should accept "having" parameter

[Django]

#10702: .extra() should accept "having" parameter
---+
  Reporter:  carljm| Owner:  nobody
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Design decision needed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by fetzig):

 * cc: kelm...@fetzig.at (added)

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

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

Re: [Django] #2131: HttpResponseSendFile for serving static files handler-specific sendfile mechanism

[Django]

#2131: HttpResponseSendFile for serving static files handler-specific sendfile
mechanism
---+
  Reporter:  ymasuda[at]ethercube.com  | Owner:  ccahoon
Status:  new   | Milestone: 
 Component:  Core framework|   Version:  SVN
Resolution:|  Keywords: 
 Stage:  Fixed on a branch | Has_patch:  1  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Changes (by david):

 * cc: david (added)

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

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

[Changeset] r12941 - in django/trunk: django/db/models tests/regressiontests/delete_regress

[noreply]

Author: russellm
Date: 2010-04-09 08:24:13 -0500 (Fri, 09 Apr 2010)
New Revision: 12941

Modified:
   django/trunk/django/db/models/query.py
   django/trunk/tests/regressiontests/delete_regress/tests.py
Log:
Fixed #13309 -- Ensure that delete() deletes everything it should delete(). 
Thanks to craig.kime...@gmail.com for the report.

Modified: django/trunk/django/db/models/query.py
===
--- django/trunk/django/db/models/query.py  2010-04-09 13:08:08 UTC (rev 
12940)
+++ django/trunk/django/db/models/query.py  2010-04-09 13:24:13 UTC (rev 
12941)
@@ -429,13 +429,14 @@
 # Delete objects in chunks to prevent the list of related objects from
 # becoming too long.
 seen_objs = None
+del_itr = iter(del_query)
 while 1:
 # Collect a chunk of objects to be deleted, and then all the
 # objects that are related to the objects that are to be deleted.
 # The chunking *isn't* done by slicing the del_query because we
 # need to maintain the query cache on del_query (see #12328)
 seen_objs = CollectedObjects(seen_objs)
-for i, obj in izip(xrange(CHUNK_SIZE), del_query):
+for i, obj in izip(xrange(CHUNK_SIZE), del_itr):
 obj._collect_sub_objects(seen_objs)
 
 if not seen_objs:

Modified: django/trunk/tests/regressiontests/delete_regress/tests.py
===
--- django/trunk/tests/regressiontests/delete_regress/tests.py  2010-04-09 
13:08:08 UTC (rev 12940)
+++ django/trunk/tests/regressiontests/delete_regress/tests.py  2010-04-09 
13:24:13 UTC (rev 12941)
@@ -106,3 +106,11 @@
 self.assertEquals(PlayedWith.objects.count(), 0)
 # first two asserts just sanity checks, this is the kicker:
 self.assertEquals(PlayedWithNote.objects.count(), 0)
+
+class LargeDeleteTests(TestCase):
+def test_large_deletes(self):
+"Regression for #13309 -- if the number of objects > chunk size, 
deletion still occurs"
+for x in range(300):
+track = Book.objects.create(pagecount=x+100)
+Book.objects.all().delete()
+self.assertEquals(Book.objects.count(), 0)

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

Re: [Django] #13308: dumpdata doesn't honor router information

[Django]

#13308: dumpdata doesn't honor router information
---+
  Reporter:  russellm  | Owner:  nobody  
Status:  closed| Milestone:  1.2 
 Component:  Database layer (models, ORM)  |   Version:  1.2-beta
Resolution:  fixed |  Keywords:  
 Stage:  Accepted  | Has_patch:  0   
Needs_docs:  0 |   Needs_tests:  0   
Needs_better_patch:  0 |  
---+
Changes (by russellm):

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

Comment:

 (In [12940]) Fixed #13308 -- Ensured that dumpdata correctly interacts
 with router allow_syncdb directions. Thanks to Francis (wizard_2) 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-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r12940 - in django/trunk: django/core/management/commands tests/regressiontests/multiple_database

[noreply]

Author: russellm
Date: 2010-04-09 08:08:08 -0500 (Fri, 09 Apr 2010)
New Revision: 12940

Modified:
   django/trunk/django/core/management/commands/dumpdata.py
   django/trunk/tests/regressiontests/multiple_database/tests.py
Log:
Fixed #13308 -- Ensured that dumpdata correctly interacts with router 
allow_syncdb directions. Thanks to Francis (wizard_2) for the report.

Modified: django/trunk/django/core/management/commands/dumpdata.py
===
--- django/trunk/django/core/management/commands/dumpdata.py2010-04-09 
12:39:08 UTC (rev 12939)
+++ django/trunk/django/core/management/commands/dumpdata.py2010-04-09 
13:08:08 UTC (rev 12940)
@@ -1,7 +1,7 @@
 from django.core.exceptions import ImproperlyConfigured
 from django.core.management.base import BaseCommand, CommandError
 from django.core import serializers
-from django.db import connections, DEFAULT_DB_ALIAS
+from django.db import connections, router, DEFAULT_DB_ALIAS
 from django.utils.datastructures import SortedDict
 
 from optparse import make_option
@@ -79,7 +79,7 @@
 # Now collate the objects to be serialized.
 objects = []
 for model in sort_dependencies(app_list.items()):
-if not model._meta.proxy:
+if not model._meta.proxy and router.allow_syncdb(using, model):
 objects.extend(model._default_manager.using(using).all())
 
 try:

Modified: django/trunk/tests/regressiontests/multiple_database/tests.py
===
--- django/trunk/tests/regressiontests/multiple_database/tests.py   
2010-04-09 12:39:08 UTC (rev 12939)
+++ django/trunk/tests/regressiontests/multiple_database/tests.py   
2010-04-09 13:08:08 UTC (rev 12940)
@@ -1,8 +1,11 @@
 import datetime
 import pickle
+import sys
+from StringIO import StringIO
 
 from django.conf import settings
 from django.contrib.auth.models import User
+from django.core import management
 from django.db import connections, router, DEFAULT_DB_ALIAS
 from django.db.utils import ConnectionRouter
 from django.test import TestCase
@@ -1211,10 +1214,19 @@
 self.old_routers = router.routers
 router.routers = [AuthRouter()]
 
+# Redirect stdout to a buffer so we can test
+# the output of a management command
+self.old_stdout = sys.stdout
+self.stdout = StringIO()
+sys.stdout = self.stdout
+
 def tearDown(self):
 # Restore the 'other' database as an independent database
 router.routers = self.old_routers
 
+# Restore stdout
+sys.stdout = self.old_stdout
+
 def test_auth_manager(self):
 "The methods on the auth manager obey database hints"
 # Create one user using default allocation policy
@@ -1243,6 +1255,22 @@
 self.assertEquals(User.objects.using('default').count(), 1)
 self.assertEquals(User.objects.using('other').count(), 1)
 
+def test_dumpdata(self):
+"Check that dumpdata honors allow_syncdb restrictions on the router"
+User.objects.create_user('alice', 'al...@example.com')
+User.objects.db_manager('default').create_user('bob', 
'b...@example.com')
+
+# Check that dumping the default database doesn't try to include auth
+# because allow_syncdb prohibits auth on default
+self.stdout.flush()
+management.call_command('dumpdata', 'auth', format='json', 
database='default')
+self.assertEquals(self.stdout.getvalue(), '[]\n')
+
+# Check that dumping the other database does include auth
+self.stdout.flush()
+management.call_command('dumpdata', 'auth', format='json', 
database='other')
+self.assertTrue('al...@example.com' in self.stdout.getvalue())
+
 class UserProfileTestCase(TestCase):
 def setUp(self):
 self.old_auth_profile_module = getattr(settings, 
'AUTH_PROFILE_MODULE', None)
@@ -1307,7 +1335,6 @@
 except Book.DoesNotExist:
 self.fail('"The Definitive Guide to Django" should exist on both 
databases')
 
-
 class PickleQuerySetTestCase(TestCase):
 multi_db = True
 

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

[Changeset] r12939 - in django/trunk: django/db/backends/mysql tests/regressiontests/model_fields

[noreply]

Author: russellm
Date: 2010-04-09 07:39:08 -0500 (Fri, 09 Apr 2010)
New Revision: 12939

Modified:
   django/trunk/django/db/backends/mysql/compiler.py
   django/trunk/tests/regressiontests/model_fields/models.py
   django/trunk/tests/regressiontests/model_fields/tests.py
Log:
Fixed #13293 -- Corrected a problem with the MySQL handling of boolean return 
values when a query has an extra() clause. Thanks to mk for the report and 
draft patch.

Modified: django/trunk/django/db/backends/mysql/compiler.py
===
--- django/trunk/django/db/backends/mysql/compiler.py   2010-04-09 11:07:17 UTC 
(rev 12938)
+++ django/trunk/django/db/backends/mysql/compiler.py   2010-04-09 12:39:08 UTC 
(rev 12939)
@@ -3,14 +3,14 @@
 class SQLCompiler(compiler.SQLCompiler):
 def resolve_columns(self, row, fields=()):
 values = []
-for value, field in map(None, row, fields):
+index_extra_select = len(self.query.extra_select.keys())
+for value, field in map(None, row[index_extra_select:], fields):
 if (field and field.get_internal_type() in ("BooleanField", 
"NullBooleanField") and
 value in (0, 1)):
 value = bool(value)
 values.append(value)
-return tuple(values)
+return row[:index_extra_select] + tuple(values)
 
-
 class SQLInsertCompiler(compiler.SQLInsertCompiler, SQLCompiler):
 pass
 

Modified: django/trunk/tests/regressiontests/model_fields/models.py
===
--- django/trunk/tests/regressiontests/model_fields/models.py   2010-04-09 
11:07:17 UTC (rev 12938)
+++ django/trunk/tests/regressiontests/model_fields/models.py   2010-04-09 
12:39:08 UTC (rev 12939)
@@ -69,6 +69,7 @@
 
 class BooleanModel(models.Model):
 bfield = models.BooleanField()
+string = models.CharField(max_length=10, default='abc')
 
 ###
 # ImageField

Modified: django/trunk/tests/regressiontests/model_fields/tests.py
===
--- django/trunk/tests/regressiontests/model_fields/tests.py2010-04-09 
11:07:17 UTC (rev 12938)
+++ django/trunk/tests/regressiontests/model_fields/tests.py2010-04-09 
12:39:08 UTC (rev 12939)
@@ -191,6 +191,13 @@
 self.assertTrue(isinstance(b4.nbfield, bool))
 self.assertEqual(b4.nbfield, False)
 
+# http://code.djangoproject.com/ticket/13293
+# Verify that when an extra clause exists, the boolean
+# conversions are applied with an offset
+b5 = BooleanModel.objects.all().extra(
+select={'string_length': 'LENGTH(string)'})[0]
+self.assertFalse(isinstance(b5.pk, bool))
+
 class ChoicesTests(django.test.TestCase):
 def test_choices_and_field_display(self):
 """

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

[Changeset] r12938 - in django/trunk/django/contrib/auth: . tests

[noreply]

Author: russellm
Date: 2010-04-09 06:07:17 -0500 (Fri, 09 Apr 2010)
New Revision: 12938

Added:
   django/trunk/django/contrib/auth/tests/decorators.py
Modified:
   django/trunk/django/contrib/auth/decorators.py
   django/trunk/django/contrib/auth/tests/__init__.py
Log:
Fixed #13304 -- Updated auth decorators so they can be used with callable 
classes. Thanks to Horst Gutmann for the report and patch.

Modified: django/trunk/django/contrib/auth/decorators.py
===
--- django/trunk/django/contrib/auth/decorators.py  2010-04-07 23:37:48 UTC 
(rev 12937)
+++ django/trunk/django/contrib/auth/decorators.py  2010-04-09 11:07:17 UTC 
(rev 12938)
@@ -5,6 +5,7 @@
 
 from django.contrib.auth import REDIRECT_FIELD_NAME
 from django.http import HttpResponseRedirect
+from django.utils.decorators import available_attrs
 from django.utils.http import urlquote
 
 
@@ -25,7 +26,7 @@
 path = urlquote(request.get_full_path())
 tup = login_url, redirect_field_name, path
 return HttpResponseRedirect('%s?%s=%s' % tup)
-return wraps(view_func)(_wrapped_view)
+return wraps(view_func, 
assigned=available_attrs(view_func))(_wrapped_view)
 return decorator
 
 

Modified: django/trunk/django/contrib/auth/tests/__init__.py
===
--- django/trunk/django/contrib/auth/tests/__init__.py  2010-04-07 23:37:48 UTC 
(rev 12937)
+++ django/trunk/django/contrib/auth/tests/__init__.py  2010-04-09 11:07:17 UTC 
(rev 12938)
@@ -1,12 +1,13 @@
+from django.contrib.auth.tests.auth_backends import BackendTest, 
RowlevelBackendTest, AnonymousUserBackendTest, NoAnonymousUserBackendTest
 from django.contrib.auth.tests.basic import BASIC_TESTS
-from django.contrib.auth.tests.views \
-import PasswordResetTest, ChangePasswordTest, LoginTest, LogoutTest
+from django.contrib.auth.tests.decorators import LoginRequiredTestCase
 from django.contrib.auth.tests.forms import FORM_TESTS
 from django.contrib.auth.tests.remote_user \
 import RemoteUserTest, RemoteUserNoCreateTest, RemoteUserCustomTest
-from django.contrib.auth.tests.auth_backends import BackendTest, 
RowlevelBackendTest, AnonymousUserBackendTest, NoAnonymousUserBackendTest
+from django.contrib.auth.tests.models import ProfileTestCase
 from django.contrib.auth.tests.tokens import TOKEN_GENERATOR_TESTS
-from django.contrib.auth.tests.models import ProfileTestCase
+from django.contrib.auth.tests.views \
+import PasswordResetTest, ChangePasswordTest, LoginTest, LogoutTest
 
 # The password for the fixture data users is 'password'
 

Added: django/trunk/django/contrib/auth/tests/decorators.py
===
--- django/trunk/django/contrib/auth/tests/decorators.py
(rev 0)
+++ django/trunk/django/contrib/auth/tests/decorators.py2010-04-09 
11:07:17 UTC (rev 12938)
@@ -0,0 +1,25 @@
+from unittest import TestCase
+
+from django.contrib.auth.decorators import login_required
+
+
+class LoginRequiredTestCase(TestCase):
+"""
+Tests the login_required decorators
+"""
+def testCallable(self):
+"""
+Check that login_required is assignable to callable objects.
+"""
+class CallableView(object):
+def __call__(self, *args, **kwargs):
+pass
+login_required(CallableView())
+
+def testView(self):
+"""
+Check that login_required is assignable to normal views.
+"""
+def normal_view(request):
+pass
+login_required(normal_view)
\ No newline at end of file

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

Re: [Django] #13296: order_with_respect_to fails to correctly track _order after deleting entries

[Django]

#13296: order_with_respect_to fails to correctly track _order after deleting
entries
+---
  Reporter:  krijesta   | Owner:  nobody
Status:  reopened   | Milestone:
 Component:  Uncategorized  |   Version:  1.1   
Resolution: |  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by krijesta):

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

Comment:

 Sorry for being unclear I didn't mean for this to be taken as an issue
 with the admin interface (I was just using it for convenience). I believe
 that this is an issue with the models themselves in that the save()
 function needs to be more intelligent or the delete() function needs to do
 more cleanup. The code required to reproduce this is here:

 {{{
 #!python
 class Question(models.Model):
 q = models.CharField(max_length=200)
 def __unicode__(self):
 return self.q

 class Answer(models.Model):
 question = models.ForeignKey(Question)
 a = models.CharField(max_length=200)
 class Meta:
 order_with_respect_to = 'question'
 def __unicode__(self):
 return self.a
 }}}

 Run these commands in a 'python manage.py shell' and they have the same
 results (while avoiding any possible complications with the admin
 interface):

 {{{
 #!python
 from mysite.scutle.models import Question, Answer
 question = Question(q="Question 1")
 question.save()
 a1 = question.answer_set.create(a="Answer 1")
 a1.save()  #_order=0
 a2 = question.answer_set.create(a="Answer 2")
 a2.save()  #_order=1
 a3 = question.answer_set.create(a="Answer 3")
 a3.save()  #_order=2
 a4 = question.answer_set.create(a="Answer 4")
 a4.save()  #_order=3
 question.answer_set.all()
 # You should get: [, , , ]
 a1.delete()
 a2.delete()
 a5 = question.answer_set.create(a="Answer 5")
 a5.save()  # Here _order=2 (duplication of order value of a3)
 question.answer_set.all()
 # You now get [, , ]
 which is incorrect (at least to my understanding of the code)
 a6 = question.answer_set.create(a="Answer 6")
 a6.save()
 a7 = question.answer_set.create(a="Answer 7")
 a7.save()
 question.answer_set.all()
 # They get even more odd when you add more, this will result in:
 #[, , , , ] This is clearly out of order
 }}}

 At the end, looking at the SQL tables shows that the "_order" values in
 the db are set as 2, 3, 2, 3 and 4 for pk's 3, 4, 5, 6 and 7 (in their
 respective orders). This seems incorrect to me as there is duplication of
 the order values for answers to the same question, and the ordering
 doesn't respect the order answers are added to the question.

 Calling question.set_answer_order with a list of the pks of the answers
 does correct this list with the _order values form 0 to 4. This represents
 a potential solution to this problem: if
 question.set_answer_order(question.get_answer_order()) is called every
 time an entry from the list is removed the orders are corrected to be
 starting from 0 and going to (number of entires - 1), and so new entries
 (which seem to get given an "_order" value equal to the number of existing
 entries) will always be added last to the list. So this code works as
 expected:
 {{{
 #!python
 from mysite.scutle.models import Question, Answer
 question = Question(q="Question 1")
 question.save()
 a1 = question.answer_set.create(a="Answer 1")
 a1.save()
 a2 = question.answer_set.create(a="Answer 2")
 a2.save()
 a3 = question.answer_set.create(a="Answer 3")
 a3.save()
 a4 = question.answer_set.create(a="Answer 4")
 a4.save()
 question.answer_set.all()
 # You should get: [, , , ]
 a1.delete()
 question.set_answer_order(question.get_answer_order())
 a2.delete()
 question.set_answer_order(question.get_answer_order())
 a5 = question.answer_set.create(a="Answer 5")
 a5.save() # gets _order=2 as before, but the other _orders are now 0 and 1
 rather than 2 and 3 as in the previous example
 question.answer_set.all()
 # Output is now in correct order: [, ,
 ]
 a6 = question.answer_set.create(a="Answer 6")
 a6.save()
 a7 = question.answer_set.create(a="Answer 7")
 a7.save()
 question.answer_set.all()
 # And ordering is still correct [, ,
 , , ]
 }}}

 This leads to a solution where this is called automatically on a delete()
 function call to any model with order_with_respect_to set, or
 alternatively more intelligence around what value "_order" is assigned on
 a save() call (so that it gets the current largest number + 1)

 A similar issue occurs with multiple questions, moving an answer from one
 question to another doesn't change the value of "_order" (a solution for
 the ordering issue above might also solve this

Re: [Django] #12780: Provide a hook for compound form/formset validation in ModelAdmin

[Django]

#12780: Provide a hook for compound form/formset validation in ModelAdmin
---+
  Reporter:  mrts  | Owner:  nobody
Status:  new   | Milestone:
 Component:  django.contrib.admin  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  1 
Needs_better_patch:  0 |  
---+
Comment (by mrts):

 I'll have to abandon driving this further, sorry.

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

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

Re: [Django] #7028: Better raw_id_fields feedback in newform-admins branch

[Django]

#7028: Better raw_id_fields feedback in newform-admins branch
---+
  Reporter:  Marcob   | Owner:  nobody 

Status:  new   | Milestone: 

 Component:  django.contrib.admin  |   Version:  SVN

Resolution:|  Keywords:  
raw-id-fields nfa-someday design_ux
 Stage:  Accepted  | Has_patch:  1  

Needs_docs:  0 |   Needs_tests:  1  

Needs_better_patch:  1 |  
---+
Comment (by mrts):

 My patch is complete, but doesn't touch ManyToManyFields. I can not drive
 this further though for various reasons, so someone else should step up
 and continue the work.

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

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

Re: [Django] #13299: Handicapped objects passed to models signals during loaddata

[Django]

#13299: Handicapped objects passed to models signals during loaddata
+---
  Reporter:  patrys | Owner:  nobody  
Status:  new| Milestone:  
 Component:  Documentation  |   Version:  1.2-beta
Resolution: |  Keywords:  
 Stage:  Accepted   | Has_patch:  0   
Needs_docs:  0  |   Needs_tests:  0   
Needs_better_patch:  0  |  
+---
Comment (by patrys):

 Yes, I understand why parent object data is not available when loading a
 fixture and agree that doing an extra `select` for each `insert` is not a
 good idea.

 Documenting `raw=True` would also let people skip signals during loading
 of fixtures. This might be the desired behavior if the fixture also
 contains objects normally created by `post_save`.

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

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

[Django] #13311: Template Tag modules that raise an ImportError are difficult to debug

[Django]

#13311: Template Tag modules that raise an ImportError are difficult to debug
-+--
 Reporter:  amccurdy |   Owner:  nobody
   Status:  new  |   Milestone:
Component:  Template system  | Version:  1.2-beta  
 Keywords:  templatetag library  |   Stage:  Unreviewed
Has_patch:  0|  
-+--
 I have several template tag libraries that I register using the
 add_to_builtins function. While upgrading to Django 1.2, I found that one
 of these template tag libraries was raising an ImportError. The
 ImportError was hidden from me however, because
 django.template.import_library catches ImportError and simply returns
 None.  The None value still gets added to the django.template.builtins
 module-level variable, which eventually ends up making it's way to the
 Parser class's add_library function.  Parser.add_library references the
 .tags attribute without checking for None, raising an AttributeError.
 There's was no indication of which template tag library caused the error,
 making this a pain to track down.

 I would suggest that django.template.import_library not mask the
 ImportError. If this breaks backwards compatibility, then at least raise
 the ImportError from django.template.add_to_builtins.

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

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