Re: [Django] #5390: Add signals to ManyRelatedManager

[Django]

#5390: Add signals to ManyRelatedManager
--+-
  Reporter:  Ludovico Magnocavallo   | Owner:  
rvdrijst   
Status:  assigned | Milestone:  
   
 Component:  Database layer (models, ORM) |   Version:  SVN 
   
Resolution:   |  Keywords:  
manytomanyfield feature signals
 Stage:  Design decision needed   | Has_patch:  1   
   
Needs_docs:  0|   Needs_tests:  0   
   
Needs_better_patch:  0|  
--+-
Comment (by ubernostrum):

 Replying to [comment:23 wmdmark]:
 > +1 Please include this fix in the upcoming release. I'm having to do
 some awful code hacks to get around this.

 You do realize the feature freeze for 1.1 has passed already, right (in
 fact, 1.1 is behind schedule because we delayed a bit for a late-running
 feature)? No new feature checkins will happen until after the release, at
 which point proposals for inclusion in 1.2 will open.

 If you're really interested in getting a feature into Django, it's in your
 best interest to get involved on the developers' list and pay attention to
 the release schedule.

-- 
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] #5390: Add signals to ManyRelatedManager

[Django]

#5390: Add signals to ManyRelatedManager
--+-
  Reporter:  Ludovico Magnocavallo   | Owner:  
rvdrijst   
Status:  assigned | Milestone:  
   
 Component:  Database layer (models, ORM) |   Version:  SVN 
   
Resolution:   |  Keywords:  
manytomanyfield feature signals
 Stage:  Design decision needed   | Has_patch:  1   
   
Needs_docs:  0|   Needs_tests:  0   
   
Needs_better_patch:  0|  
--+-
Comment (by wmdmark):

 +1 Please include this fix in the upcoming release. I'm having to do some
 awful code hacks to get around 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] #10927: Content Types shortcut view throws 500s easily

[Django]

#10927: Content Types shortcut view throws 500s easily
---+
  Reporter:  jdunck| Owner:  nobody
Status:  new   | Milestone:
 Component:  Contrib apps  |   Version:  1.1-beta-1
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by jdunck):

 The simpler one probably works-for-me.  I chose the .to_python route
 because that uniformly raises ValidationError-- I wasn't sure about the
 assumption that any cast in the ORM would fail as ValueError.

-- 
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] #10929: Support a default value for Sum (and possibly other aggregation functions)

[Django]

#10929: Support a default value for Sum (and possibly other aggregation 
functions)
--+-
 Reporter:  nolan |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Database layer (models, ORM)  | Version:  1.1-beta-1
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 By default, annotate(sum_field = Sum(...)) results in sum_field being NULL
 if there were no values to sum.  In most cases, 0 would be a better option
 here, for proper sorting in a later order_by, and for comparisons using
 lt/gt/gte/lte.

 A monkeypatch to implement default values for NULL using COALESCE is
 available here:
 http://stackoverflow.com/questions/553038/treat-null-as-0-in-django-model

-- 
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] #10901: auth.contrib silently catching TypeError

[Django]

#10901: auth.contrib silently catching TypeError
-+--
  Reporter:  anonymous   | Owner:  nobody
Status:  closed  | Milestone:
 Component:  Authentication  |   Version:  1.0   
Resolution:  invalid |  Keywords:
 Stage:  Unreviewed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by mtredinnick):

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

Comment:

 This isn't a bug for the reasons explained here and in the original thread
 on django-users. We are using `TypeError` in the way it is intended in
 Python. That it happens to also disguise programmer errors is not really
 our problem, since people shouldn't be relying on it to that (programmer
 errors should be caught earlier). This is an expected exceptional
 condition that we are handling. We are handling in a deliberate fashion by
 realising that it's not a problem for our execution path.

 And if none of that convinced you, I'm sorry, but changing it would also
 be backwards incompatible and even though this is a contrib app and we can
 change things that are geuine bugs, this isn't a bug and there are a
 ''lot'' of custom authentication backends in the wild.

-- 
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] #10928: BooleanField: different behaviour when default=callable

[Django]

#10928: BooleanField: different behaviour when default=callable
-+--
  Reporter:  a...@gc-web.de  | Owner:  nobody
Status:  new | Milestone:
 Component:  Uncategorized   |   Version:  SVN   
Resolution:  |  Keywords:
 Stage:  Unreviewed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Comment (by a...@gc-web.de):

 Ok, I found out that I can work around by returning None instead of False
 from the callable, the value="" attribute is left out in the hidden
 initial. A possible fix would be to make the CheckboxInput widget accept
 {{{u"False"}}} as {{{False}}} in the _has_changed check, or by preventing
 the hidden initial field from having value="False" in the first place.

-- 
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] #10922: Model formsets - matching POST data to model instances is fragile

[Django]

#10922: Model formsets - matching POST data to model instances is fragile
-+--
  Reporter:  kmtracey| Owner:  nobody
Status:  new | Milestone:
 Component:  Forms   |   Version:  1.0   
Resolution:  |  Keywords:
 Stage:  Unreviewed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by Alex):

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

Comment:

 A few concerns here: a) this is may be SQL inefficient, I haven't checked
 yet. b) There's a fair amount of code duplications since add_fields needs
 to do something *very* similar to what we do here.

-- 
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] #10928: BooleanField: different behaviour when default=callable

[Django]

#10928: BooleanField: different behaviour when default=callable
-+--
  Reporter:  a...@gc-web.de  | Owner:  nobody
Status:  new | Milestone:
 Component:  Uncategorized   |   Version:  SVN   
Resolution:  |  Keywords:
 Stage:  Unreviewed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by a...@gc-web.de):

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

Comment:

 Oh, hit submit too fast. Basically, the callable-form emits, when used in
 a ModelForm (for example the admin), the following hidden initial-field:

 {{{
 
 }}}

 This has the effect that {{{form.has_changed()}}} is always True, so that
 extra forms of formsets are always considered for validation.

-- 
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] #10928: BooleanField: different behaviour when default=callable

[Django]

#10928: BooleanField: different behaviour when default=callable
+---
 Reporter:  a...@gc-web.de  |   Owner:  nobody
   Status:  new |   Milestone:
Component:  Uncategorized   | Version:  SVN   
 Keywords:  |   Stage:  Unreviewed
Has_patch:  0   |  
+---
 When using a callable, the behaviour of the BooleanField is different from
 just using a constant. Example:
 {{{
 foo = models.BooleanField(default=lambda: False)
 }}}
 vs.
 {{{
 foo = models.BooleanField(default=False)
 }}}

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

Re: [Django] #10660: GeometryField doesn't honor "required" attribute

[Django]

#10660: GeometryField doesn't honor "required" attribute
-+--
  Reporter:  framos  | Owner:  framos
Status:  closed  | Milestone:  1.1   
 Component:  GIS |   Version:  1.0   
Resolution:  fixed   |  Keywords:
 Stage:  Unreviewed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by jbronn):

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

Comment:

 (In r10634) Fixed #10660 -- GeometryField no longer requires srid/null
 keywords, and now respects required; coordinate transformations now done
 inside gis.forms.GeometryField -- benefit being that OSMGeoAdmin no longer
 requires 900913 entry in spatial_ref_sys thus enabling it to work with
 MySQL/Oracle spatial backends; added tests for geographic forms.

-- 
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] r10634 - in django/trunk/django/contrib/gis: forms tests

[noreply]

Author: jbronn
Date: 2009-04-25 13:24:32 -0500 (Sat, 25 Apr 2009)
New Revision: 10634

Added:
   django/trunk/django/contrib/gis/tests/test_geoforms.py
Modified:
   django/trunk/django/contrib/gis/forms/__init__.py
   django/trunk/django/contrib/gis/forms/fields.py
   django/trunk/django/contrib/gis/tests/__init__.py
Log:
Fixed #10660 -- `GeometryField` no longer requires `srid`/`null` keywords, and 
now respects `required`; coordinate transformations now done inside 
`gis.forms.GeometryField` -- benefit being that `OSMGeoAdmin` no longer 
requires 900913 entry in `spatial_ref_sys` thus enabling it to work with 
MySQL/Oracle spatial backends; added tests for geographic forms.


Modified: django/trunk/django/contrib/gis/forms/__init__.py
===
--- django/trunk/django/contrib/gis/forms/__init__.py   2009-04-24 20:34:48 UTC 
(rev 10633)
+++ django/trunk/django/contrib/gis/forms/__init__.py   2009-04-25 18:24:32 UTC 
(rev 10634)
@@ -1 +1,2 @@
+from django.forms import *
 from django.contrib.gis.forms.fields import GeometryField

Modified: django/trunk/django/contrib/gis/forms/fields.py
===
--- django/trunk/django/contrib/gis/forms/fields.py 2009-04-24 20:34:48 UTC 
(rev 10633)
+++ django/trunk/django/contrib/gis/forms/fields.py 2009-04-25 18:24:32 UTC 
(rev 10634)
@@ -1,12 +1,15 @@
 from django import forms
-from django.contrib.gis.db.backend import SpatialBackend
 from django.utils.translation import ugettext_lazy as _
 
+# While this couples the geographic forms to the GEOS library,
+# it decouples from database (by not importing SpatialBackend).
+from django.contrib.gis.geos import GEOSGeometry
+
 class GeometryField(forms.Field):
 """
 This is the basic form field for a Geometry.  Any textual input that is
-accepted by SpatialBackend.Geometry is accepted by this form.  By default, 
-this is GEOSGeometry, which accepts WKT, HEXEWKB, WKB, and GeoJSON.
+accepted by GEOSGeometry is accepted by this form.  By default,
+this includes WKT, HEXEWKB, WKB (in a buffer), and GeoJSON.
 """
 widget = forms.Textarea
 
@@ -14,12 +17,16 @@
 'no_geom' : _(u'No geometry value provided.'),
 'invalid_geom' : _(u'Invalid geometry value.'),
 'invalid_geom_type' : _(u'Invalid geometry type.'),
-}
+'transform_error' : _(u'An error occurred when transforming the 
geometry'
+  'to the SRID of the geometry form field.'),
+}
 
 def __init__(self, **kwargs):
-self.null = kwargs.pop('null')
-self.geom_type = kwargs.pop('geom_type')
-self.srid = kwargs.pop('srid')
+# Pop out attributes from the database field, or use sensible
+# defaults (e.g., allow None).
+self.srid = kwargs.pop('srid', None)
+self.geom_type = kwargs.pop('geom_type', 'GEOMETRY')
+self.null = kwargs.pop('null', True)
 super(GeometryField, self).__init__(**kwargs)
 
 def clean(self, value):
@@ -29,21 +36,32 @@
 the value cannot be instantiated as a Geometry.
 """
 if not value:
-if self.null:
-# The geometry column allows NULL, return None.
+if self.null and not self.required:
+# The geometry column allows NULL and is not required.
 return None
 else:
 raise forms.ValidationError(self.error_messages['no_geom'])
- 
+
+# Trying to create a Geometry object from the form value.
 try:
-# Trying to create a Geometry object from the form value.
-geom = SpatialBackend.Geometry(value)
+geom = GEOSGeometry(value)
 except:
 raise forms.ValidationError(self.error_messages['invalid_geom'])
-  
+
 # Ensuring that the geometry is of the correct type (indicated
 # using the OGC string label).
 if str(geom.geom_type).upper() != self.geom_type and not 
self.geom_type == 'GEOMETRY':
 raise 
forms.ValidationError(self.error_messages['invalid_geom_type'])
 
+# Transforming the geometry if the SRID was set.
+if self.srid:
+if not geom.srid:
+# Should match that of the field if not given.
+geom.srid = self.srid
+elif self.srid != -1 and self.srid != geom.srid:
+try:
+geom.transform(self.srid)
+except:
+raise 
forms.ValidationError(self.error_messages['transform_error'])
+
 return geom

Modified: django/trunk/django/contrib/gis/tests/__init__.py
===
--- django/trunk/django/contrib/gis/tests/__init__.py   2009-04-24 20:34:48 UTC 
(rev 10633)
+++ django/trunk/django/contrib/gis/tests/__init__.py   2009-04-25 18:24:32 UTC 
(rev 10634)
@@ 

Re: [Django] #10927: Content Types shortcut view throws 500s easily

[Django]

#10927: Content Types shortcut view throws 500s easily
---+
  Reporter:  jdunck| Owner:  nobody
Status:  new   | Milestone:
 Component:  Contrib apps  |   Version:  1.1-beta-1
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by Alex):

 Err sorry, I misread the 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] #10927: Content Types shortcut view throws 500s easily

[Django]

#10927: Content Types shortcut view throws 500s easily
---+
  Reporter:  jdunck| Owner:  nobody
Status:  new   | Milestone:
 Component:  Contrib apps  |   Version:  1.1-beta-1
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by Alex):

 Why does this raise a 404 if the PK isn't an integer?  That's not the
 correct behavior as we support all sorts of other pks.

-- 
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 |  
---+
Comment (by fas):

 Ok, here is an example. We have a many-to-many relation between articles
 and publications.

 {{{
 from django.db import models

 class Publication(models.Model):
 title = models.CharField(max_length=30)
 date = models.DateField()

 class Article(models.Model):
 headline = models.CharField(max_length=100)
 publications = models.ManyToManyField(Publication)
 }}}

 Then we create a model form that has a callback for the form field. Such a
 callback is used in the admin.
 In the following example, the initial value of 'publications' of the
 article form should be the ten latest publications.

 {{{
 from django.forms.models import modelform_factory

 def formfield_for_dbfield(db_field, **kwargs):
 if db_field.name == 'publications':
 kwargs['initial'] = lambda:
 Publication.objects.all().order_by('-date')[:10]
 return db_field.formfield(**kwargs)

 modelform_factory(Article, formfield_callback=formfield_for_dbfield)
 }}}

 A lambda expression is used so that the expression will not be evaluated
 once but every time, preventing the initial selection from getting
 outdated (same reason you would use date.today instead of date.today() as
 an initial value for a date field).

-- 
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] #10927: Content Types shortcut view throws 500s easily

[Django]

#10927: Content Types shortcut view throws 500s easily
---+
  Reporter:  jdunck| Owner:  nobody
Status:  new   | Milestone:
 Component:  Contrib apps  |   Version:  1.1-beta-1
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by jdunck):

  * has_patch:  0 => 1

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

[Django] #10927: Content Types shortcut view throws 500s easily

[Django]

#10927: Content Types shortcut view throws 500s easily
+---
   Reporter:  jdunck|Owner:  nobody
 Status:  new   |Milestone:
  Component:  Contrib apps  |  Version:  1.1-beta-1
   Keywords:|Stage:  Unreviewed
  Has_patch:  0 |   Needs_docs:  0 
Needs_tests:  0 |   Needs_better_patch:  0 
+---
 BaseHandler.handle_uncaught_exception calls mail_admins any time an
 uncaught exception occurs.  In my general usage, this is very rare.

 The contenttypes.views.shortcut view, many arbitrary URLs will throw a
 500.  Since crawlers probe URL spaces, this leads to a lot of noise in
 error emails.

-- 
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] #10926: Poll tutorial submit error

[Django]

#10926: Poll tutorial submit error
+---
  Reporter:  shawn  | Owner:  nobody
Status:  closed | Milestone:
 Component:  Documentation  |   Version:  1.0   
Resolution:  duplicate  |  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by shawn):

  * status:  new => closed
  * needs_better_patch:  => 0
  * resolution:  => duplicate
  * 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] #10926: Poll tutorial submit error

[Django]

#10926: Poll tutorial submit error
---+
 Reporter:  shawn  |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Documentation  | Version:  1.0   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 I think there might be an error in the Poll tutorial.  I've gone through
 the entire tutorial and I've got everything working, but the only issue is
 that when you don't click on one of the radio buttons before pressing the
 submit button, it shows the error properly, but after that you cannot
 legitimately vote or it will give a 404.

-- 
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] #494: Collapse in admin interface for inline related objects

[Django]

#494: Collapse in admin interface for inline related objects
---+
  Reporter:  jcsto...@nilling.nl   | Owner:  aptiko 
 
Status:  assigned  | Milestone: 
 
 Component:  django.contrib.admin  |   Version:  newforms-admin 
 
Resolution:|  Keywords:  edit_inline, 
nfa-someday
 Stage:  Accepted  | Has_patch:  1  
 
Needs_docs:  0 |   Needs_tests:  0  
 
Needs_better_patch:  0 |  
---+
Changes (by jacob):

  * keywords:  edit_inline, nfa-someday, gsoc09-admin-refactor =>
   edit_inline, nfa-someday

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

Re: [Django] #897: Bi-Directional ManyToMany in Admin

[Django]

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

  * keywords:  => gsoc09-admin-refactor

-- 
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] #494: Collapse in admin interface for inline related objects

[Django]

#494: Collapse in admin interface for inline related objects
---+
  Reporter:  jcsto...@nilling.nl   | Owner:  aptiko 

Status:  assigned  | Milestone: 

 Component:  django.contrib.admin  |   Version:  newforms-admin 

Resolution:|  Keywords:  edit_inline, 
nfa-someday, gsoc09-admin-refactor
 Stage:  Accepted  | Has_patch:  1  

Needs_docs:  0 |   Needs_tests:  0  

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

  * keywords:  edit_inline, nfa-someday => edit_inline, nfa-someday, gsoc09
   -admin-refactor

-- 
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] #9025: Nested Inline Support in Admin

[Django]

#9025: Nested Inline Support in Admin
-+--
  Reporter:  pixelcort   | Owner:  nobody
Status:  new | Milestone:
 Component:  django.contrib.admin|   Version:  SVN   
Resolution:  |  Keywords:  admin-refactor
 Stage:  Design decision needed  | Has_patch:  1 
Needs_docs:  0   |   Needs_tests:  1 
Needs_better_patch:  1   |  
-+--
Changes (by mrts):

  * keywords:  => admin-refactor
  * version:  1.0 => SVN

Comment:

 To give more context why this is useful, let me illustrate this with a
 common use case.

 Suppose you model events that can have one or more occurrences.

 Each occurrence has a single location and one or more time slots (e.g. a
 theatre performance that takes place in hall A on Tuesday and Wednesday
 and
 in hall B on Saturday.)

 You get the following model structure:
 {{{
 class Event(models.Model):
 name = models.CharField(max_length=255)

 def __unicode__(self):
 return self.name

 class Location(models.Model):
 name = models.CharField(max_length=255)

 def __unicode__(self):
 return self.name

 class Occurrence(models.Model):
 event = models.ForeignKey(Event)
 location = models.ForeignKey(Location)

 class TimeSlot(models.Model):
 occurrence = models.ForeignKey(Occurrence)
 start = models.DateTimeField()
 end = models.DateTimeField()
 }}}

 For the admin, you need occurrences to be displayed when you edit
 the events. The occurrences themselves need to display times lots.
 Thus, inline nesting is needed:
 {{{
 class TimeSlotInline(admin.TabularInline):
 model = TimeSlot
 extra = 1

 class OccurrenceInline(admin.TabularInline):
 model = Occurrence
 inlines = (TimeSlotInline,)
 extra = 2

 class EventAdmin(admin.ModelAdmin):
 inlines = (OccurrenceInline,)

 admin.site.register(Event, EventAdmin)
 admin.site.register(Location)
 }}}

 A design decision is also needed on how deep the nesting should be. It's
 possible to support arbitrarily deep nesting with recursion, whether
 that's
 feasible or necessary remains open.  Perhaps an extension mechanism should
 be
 provided so that API users can control the inlines and nesting.

 The result could look like this:

 [[Image(http://img524.imageshack.us/img524/9852/nestedadmin.png)]]

-- 
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] #10924: Should use variance() and stddev() rather than var_samp() and stddev_samp() on Postgresql < 8.2

[Django]

#10924: Should use variance() and stddev() rather than var_samp() and 
stddev_samp()
on Postgresql < 8.2
---+
  Reporter:  Richard Davies   |
 Owner: 
Status:  closed| 
Milestone: 
 Component:  ORM aggregation   |   
Version:  SVN
Resolution:  wontfix   |  
Keywords: 
 Stage:  Unreviewed| 
Has_patch:  0  
Needs_docs:  0 |   
Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Changes (by russellm):

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

Comment:

 This works for Postgres, but unfortunately it poses problems cross-
 platform. MySQL uses StdDev and Variance as aliases for the population
 statistics, not the sample statistics. I believe the unofficial SQlite
 extension that supports stddev and variance does the same.

 We could make the determination of the backend function a very complex
 affair in order to support every possible database, but in the interests
 of keeping implementations simple, I'm going to mark this wontfix. For
 those users using Postgres pre 8.2, defining a custom aggregate function
 isn't that difficult - in this case, it's just a matter of subclassing the
 Django provided aggregates and overriding the function name.

-- 
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 |  
---+
Comment (by russellm):

 My suggestion is that you provide a test case, like I asked you to.

 I completely understand what the code is trying to do. I can see the
 analog with what happens with normal form fields. On the face of it, the
 patch looks fine. However, I can't come up with a single code example that
 would actually exercise the patch you have provided.

 If you provide a callable to the initial argument when instantiating a
 form, the callable is evaluated. If you define a form field with a
 callable initial value, it is evaluated.

 Don't just explain your patch with words - you need to show me an example
 of code where you can provide a callable for an m2m field that doesn't
 work with the current Django trunk, but does work when you apply your
 patch. Ideally, that example would be integrated into the existing Django
 test suite, but at this point, I'd take any example, standalone or
 otherwise.

-- 
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] #10925: Django tutorial part 2: was_published_today example

[Django]

#10925: Django tutorial part 2: was_published_today example
---+
 Reporter:  rm |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Documentation  | Version:  1.0   
 Keywords:  tutorial   |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 The following code adding the ''short_description'' resides in models.py,
 which could be mentioned in the text above.  Earlier code snippets were
 from admin.py, which led me to try editing the wrong module.  Please
 clarify the text on the code location, otherwise the tutorial is just
 great!

 BR,
   Risto


 {{{
 def was_published_today(self):
 return self.pub_date.date() == datetime.date.today()
 was_published_today.short_description = 'Published today?'
 }}}

-- 
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] #5768: Allow QuerySet.values() to return values spanning joins (for multi-valued relations)

[Django]

#5768: Allow QuerySet.values() to return values spanning joins (for multi-valued
relations)
-+--
  Reporter:  anonymous   | Owner:  
Status:  new | Milestone:  1.2 
 Component:  Database layer (models, ORM)|   Version:  0.96
Resolution:  |  Keywords:  
 Stage:  Accepted| Has_patch:  1   
Needs_docs:  0   |   Needs_tests:  0   
Needs_better_patch:  0   |  
-+--
Changes (by mrts):

  * milestone:  => 1.2

Comment:

 Tentatively pushing to 1.2 as this lines up with `defer()` and `only()`,
 covering the missing ground.

-- 
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] #10924: Should use variance() and stddev() rather than var_samp() and stddev_samp() on Postgresql < 8.2

[Django]

#10924: Should use variance() and stddev() rather than var_samp() and 
stddev_samp()
on Postgresql < 8.2
--+-
 Reporter:  Richard Davies   |  Status:  
new
Milestone:|   Component:  
ORM aggregation
  Version:  SVN   |Keywords:
 
Stage:  Unreviewed|   Has_patch:  0 
 
--+-
 As per http://developer.postgresql.org/pgdocs/postgres/release-8-2.html ,
 the aggregation functions var_pop(), var_samp(), stddev_pop(), and
 stddev_samp() were first introduced in Postgresql 8.2.

 However, var_samp() and stddev_samp() were merely renamings of the pre-
 existing aggregates variance() and stddev(), so we could extend support to
 earlier versions of Postgresql by using those older function names where
 appropriate.

-- 
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] #10906: Aggregation support absent on postgres < 8.2

[Django]

#10906: Aggregation support absent on postgres < 8.2
---+
  Reporter:  Richard Davies   |
 Owner: 
Status:  new   | 
Milestone:  1.1
 Component:  ORM aggregation   |   
Version:  SVN
Resolution:|  
Keywords: 
 Stage:  Unreviewed| 
Has_patch:  1  
Needs_docs:  0 |   
Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Changes (by Richard Davies ):

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

Comment:

 (I meant to refer to #10142 and #10289, not [10142])

-- 
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 chr):

 cannot reproduce on safari 4 beta using the above form snippet.

-- 
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] #10646: memcached's incr and decr should throw ValueError if keys don't exist

[Django]

#10646: memcached's incr and decr should throw ValueError if keys don't exist
-+--
  Reporter:  dauerbaustelle  | Owner:  anonymous
   
Status:  assigned| Milestone:  1.1  
   
 Component:  Cache system|   Version:  1.1-beta-1   
   
Resolution:  |  Keywords:  memcached, cache, incr, 
decr
 Stage:  Accepted| Has_patch:  1
   
Needs_docs:  0   |   Needs_tests:  1
   
Needs_better_patch:  0   |  
-+--
Changes (by russellm):

  * milestone:  => 1.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
-~--~~~~--~~--~--~---