Re: [Django] #10164: AutoField is broken for sqlite backend [patch included]

[Django]

#10164: AutoField is broken for sqlite backend [patch included]
---+
  Reporter:  malte | Owner:  nobody 
 
Status:  new   | Milestone: 
 
 Component:  Database layer (models, ORM)  |   Version:  1.0
 
Resolution:|  Keywords:  sqlite 
autoincrement
 Stage:  Design decision needed| Has_patch:  1  
 
Needs_docs:  0 |   Needs_tests:  0  
 
Needs_better_patch:  0 |  
---+
Changes (by mattimustang):

 * cc: mattimustang (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] #10164: AutoField is broken for sqlite backend [patch included]

[Django]

#10164: AutoField is broken for sqlite backend [patch included]
---+
  Reporter:  malte | Owner:  nobody 
 
Status:  new   | Milestone: 
 
 Component:  Database layer (models, ORM)  |   Version:  1.0
 
Resolution:|  Keywords:  sqlite 
autoincrement
 Stage:  Design decision needed| Has_patch:  1  
 
Needs_docs:  0 |   Needs_tests:  0  
 
Needs_better_patch:  0 |  
---+
Comment (by mattimustang):

 Hi,

 This issue becomes a problem when using GenericRelations and sqlite3.

 {{{

 from django.db import models
 from django.contrib.contenttypes.models import ContentType
 from django.contrib.contenttypes import generic

 class TaggedItem(models.Model):
 tag = models.SlugField()
 content_type = models.ForeignKey(ContentType)
 object_id = models.PositiveIntegerField()
 content_object = generic.GenericForeignKey('content_type',
 'object_id')

 def __unicode__(self):
 return self.tag

 class Item(models.Model):
 name = models.CharField()

 def __unicode__(self):
 return self.name
 }}}

 Now if I create an Item and assign a tag to it, delete the Item, then
 create a new Item the tags remain and now point to the new Item. e.g.

 {{{
 >>> from myapp.models import TaggedItem, Item
 >>> from django.contrib.contenttypes.models import ContentType
 >>> i1 = Item(name='one')
 >>> i1.save()
 >>> i1.id
 1
 >>> t = TaggedItem(content_object=i1, tag='foo')
 >>> t.save()
 >>> item_type = ContentType.objects.get_for_model(i1)
 >>> TaggedItem.objects.filter(content_type__pk=item_type.id, object_id=1)
 []
 >>> i1.delete()
 >>> i2 = Item(name='two')
 >>> i2.save()
 >>> i2.id
 1
 >>> TaggedItem.objects.filter(content_type__pk=item_type.id, object_id=1)
 []

 }}}

 Changing sqlite3 backend to autoincrement would make it behave like
 postgres. I don't have mysql or oracle available to test their behaviour.

-- 
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] #12761: Paraguayan local flavor

[Django]

#12761: Paraguayan local flavor
-+--
  Reporter:  dschulz | Owner:  nobody   

Status:  new | Milestone:   

 Component:  django.contrib.localflavor  |   Version:  SVN  

Resolution:  |  Keywords:  local flavor 
paraguay
 Stage:  Ready for checkin   | Has_patch:  0

Needs_docs:  0   |   Needs_tests:  0

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

  * stage:  Unreviewed => Ready for checkin

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

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

[Changeset] r13975 - in django/branches/releases/1.2.X: django/contrib/admin tests/regressiontests/admin_widgets

[noreply]

Author: jezdez
Date: 2010-09-30 21:40:25 -0500 (Thu, 30 Sep 2010)
New Revision: 13975

Modified:
   django/branches/releases/1.2.X/django/contrib/admin/widgets.py
   django/branches/releases/1.2.X/tests/regressiontests/admin_widgets/models.py
Log:
[1.2.X] Fixed #14363 -- Fixed render method of ManyToManyRawIdWidget to set 
attrs to an empty dict. Thanks, tyrion and dpn.

Backport from trunk (r13971).

Modified: django/branches/releases/1.2.X/django/contrib/admin/widgets.py
===
--- django/branches/releases/1.2.X/django/contrib/admin/widgets.py  
2010-10-01 02:40:01 UTC (rev 13974)
+++ django/branches/releases/1.2.X/django/contrib/admin/widgets.py  
2010-10-01 02:40:25 UTC (rev 13975)
@@ -164,6 +164,8 @@
 in a  box.
 """
 def render(self, name, value, attrs=None):
+if attrs is None:
+attrs = {}
 attrs['class'] = 'vManyToManyRawIdAdminField'
 if value:
 value = ','.join([force_unicode(v) for v in value])

Modified: 
django/branches/releases/1.2.X/tests/regressiontests/admin_widgets/models.py
===
--- 
django/branches/releases/1.2.X/tests/regressiontests/admin_widgets/models.py
2010-10-01 02:40:01 UTC (rev 13974)
+++ 
django/branches/releases/1.2.X/tests/regressiontests/admin_widgets/models.py
2010-10-01 02:40:25 UTC (rev 13975)
@@ -133,6 +133,8 @@
 >>> w = ManyToManyRawIdWidget(rel)
 >>> print conditional_escape(w.render('test', [m1.pk, m2.pk], attrs={}))
  
+>>> print conditional_escape(w.render('test', [m1.pk]))
+ 
 >>> w._has_changed(None, None)
 False
 >>> w._has_changed([], None)

-- 
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] r13974 - django/branches/releases/1.2.X/django/contrib/admin

[noreply]

Author: jezdez
Date: 2010-09-30 21:40:01 -0500 (Thu, 30 Sep 2010)
New Revision: 13974

Modified:
   django/branches/releases/1.2.X/django/contrib/admin/widgets.py
Log:
[1.2.X] Fixed #14362 -- Made sure all parameters are passed to the 
ManyToManyRawIdWidget. Thanks, tyron.

Backport from trunk (r13970).

Modified: django/branches/releases/1.2.X/django/contrib/admin/widgets.py
===
--- django/branches/releases/1.2.X/django/contrib/admin/widgets.py  
2010-10-01 02:39:45 UTC (rev 13973)
+++ django/branches/releases/1.2.X/django/contrib/admin/widgets.py  
2010-10-01 02:40:01 UTC (rev 13974)
@@ -163,9 +163,6 @@
 A Widget for displaying ManyToMany ids in the "raw_id" interface rather 
than
 in a  box.
 """
-def __init__(self, rel, attrs=None, using=None):
-super(ManyToManyRawIdWidget, self).__init__(rel, attrs, using=None)
-
 def render(self, name, value, attrs=None):
 attrs['class'] = 'vManyToManyRawIdAdminField'
 if value:

-- 
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] r13973 - in django/branches/releases/1.2.X: django/templatetags tests/regressiontests/templates

[noreply]

Author: jezdez
Date: 2010-09-30 21:39:45 -0500 (Thu, 30 Sep 2010)
New Revision: 13973

Modified:
   django/branches/releases/1.2.X/django/templatetags/i18n.py
   django/branches/releases/1.2.X/tests/regressiontests/templates/tests.py
Log:
[1.2.X] Fixed #13568 -- Fixed the blocktrans tag to not raise a KeyError if the 
number of variables in the singular and the plural block differ. Thanks, 
deloide.

Backport from trunk (r13967).

Modified: django/branches/releases/1.2.X/django/templatetags/i18n.py
===
--- django/branches/releases/1.2.X/django/templatetags/i18n.py  2010-10-01 
02:39:25 UTC (rev 13972)
+++ django/branches/releases/1.2.X/django/templatetags/i18n.py  2010-10-01 
02:39:45 UTC (rev 13973)
@@ -76,8 +76,10 @@
 if self.plural and self.countervar and self.counter:
 count = self.counter.resolve(context)
 context[self.countervar] = count
-plural, vars = self.render_token_list(self.plural)
+plural, plural_vars = self.render_token_list(self.plural)
 result = translation.ungettext(singular, plural, count)
+if count != 1:
+vars = plural_vars
 else:
 result = translation.ugettext(singular)
 # Escape all isolated '%' before substituting in the context.

Modified: 
django/branches/releases/1.2.X/tests/regressiontests/templates/tests.py
===
--- django/branches/releases/1.2.X/tests/regressiontests/templates/tests.py 
2010-10-01 02:39:25 UTC (rev 13972)
+++ django/branches/releases/1.2.X/tests/regressiontests/templates/tests.py 
2010-10-01 02:39:45 UTC (rev 13973)
@@ -1116,6 +1116,9 @@
 'i18n24': ("{% load i18n %}{% trans 'Page not found'|upper %}", 
{'LANGUAGE_CODE': 'de'}, u'SEITE NICHT GEFUNDEN'),
 'i18n25': ('{% load i18n %}{% trans somevar|upper %}', {'somevar': 
'Page not found', 'LANGUAGE_CODE': 'de'}, u'SEITE NICHT GEFUNDEN'),
 
+# translation of plural form with extra field in singular form 
(#13568)
+'i18n26': ('{% load i18n %}{% blocktrans with myextra_field as 
extra_field count number as counter %}singular {{ extra_field }}{% plural 
%}plural{% endblocktrans %}', {'number': 1, 'myextra_field': 'test'}, "singular 
test"),
+
 ### HANDLING OF TEMPLATE_STRING_IF_INVALID 
###
 
 'invalidstr01': ('{{ var|default:"Foo" }}', {}, ('Foo','INVALID')),

-- 
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] r13972 - django/branches/releases/1.2.X/docs/ref

[noreply]

Author: jezdez
Date: 2010-09-30 21:39:25 -0500 (Thu, 30 Sep 2010)
New Revision: 13972

Modified:
   django/branches/releases/1.2.X/docs/ref/request-response.txt
Log:
[1.2.X] Fixed #13876 -- Fixed duplication in docs. Thanks, zerok and timo.

Backport from trunk (r13966).

Modified: django/branches/releases/1.2.X/docs/ref/request-response.txt
===
--- django/branches/releases/1.2.X/docs/ref/request-response.txt
2010-10-01 02:31:05 UTC (rev 13971)
+++ django/branches/releases/1.2.X/docs/ref/request-response.txt
2010-10-01 02:39:25 UTC (rev 13972)
@@ -405,16 +405,6 @@
 >>> response.write("Here's the text of the Web page.")
 >>> response.write("Here's another paragraph.")
 
-You can add and delete headers using dictionary syntax::
-
->>> response = HttpResponse()
->>> response['X-DJANGO'] = "It's the best."
->>> del response['X-PHP']
->>> response['X-DJANGO']
-"It's the best."
-
-Note that ``del`` doesn't raise ``KeyError`` if the header doesn't exist.
-
 Passing iterators
 ~
 
@@ -429,11 +419,15 @@
 Setting headers
 ~~~
 
-To set a header in your response, just treat it like a dictionary::
+To set or remove a header in your response, treat it like a dictionary::
 
 >>> response = HttpResponse()
 >>> response['Cache-Control'] = 'no-cache'
+>>> del response['Cache-Control']
 
+Note that unlike a dictionary, ``del`` doesn't raise ``KeyError`` if the header
+doesn't exist.
+
 .. versionadded:: 1.1
 
 HTTP headers cannot contain newlines. An attempt to set a header containing a

-- 
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] r13971 - in django/trunk: django/contrib/admin tests/regressiontests/admin_widgets

[noreply]

Author: jezdez
Date: 2010-09-30 21:31:05 -0500 (Thu, 30 Sep 2010)
New Revision: 13971

Modified:
   django/trunk/django/contrib/admin/widgets.py
   django/trunk/tests/regressiontests/admin_widgets/models.py
Log:
Fixed #14363 -- Fixed render method of ManyToManyRawIdWidget to set attrs to an 
empty dict. Thanks, tyrion and dpn.

Modified: django/trunk/django/contrib/admin/widgets.py
===
--- django/trunk/django/contrib/admin/widgets.py2010-10-01 02:30:45 UTC 
(rev 13970)
+++ django/trunk/django/contrib/admin/widgets.py2010-10-01 02:31:05 UTC 
(rev 13971)
@@ -156,6 +156,8 @@
 in a  box.
 """
 def render(self, name, value, attrs=None):
+if attrs is None:
+attrs = {}
 attrs['class'] = 'vManyToManyRawIdAdminField'
 if value:
 value = ','.join([force_unicode(v) for v in value])

Modified: django/trunk/tests/regressiontests/admin_widgets/models.py
===
--- django/trunk/tests/regressiontests/admin_widgets/models.py  2010-10-01 
02:30:45 UTC (rev 13970)
+++ django/trunk/tests/regressiontests/admin_widgets/models.py  2010-10-01 
02:31:05 UTC (rev 13971)
@@ -133,6 +133,8 @@
 >>> w = ManyToManyRawIdWidget(rel)
 >>> print conditional_escape(w.render('test', [m1.pk, m2.pk], attrs={}))
  
+>>> print conditional_escape(w.render('test', [m1.pk]))
+ 
 >>> w._has_changed(None, None)
 False
 >>> w._has_changed([], None)

-- 
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] r13970 - django/trunk/django/contrib/admin

[noreply]

Author: jezdez
Date: 2010-09-30 21:30:45 -0500 (Thu, 30 Sep 2010)
New Revision: 13970

Modified:
   django/trunk/django/contrib/admin/widgets.py
Log:
Fixed #14362 -- Made sure all parameters are passed to the 
ManyToManyRawIdWidget. Thanks, tyron.

Modified: django/trunk/django/contrib/admin/widgets.py
===
--- django/trunk/django/contrib/admin/widgets.py2010-10-01 02:05:45 UTC 
(rev 13969)
+++ django/trunk/django/contrib/admin/widgets.py2010-10-01 02:30:45 UTC 
(rev 13970)
@@ -155,9 +155,6 @@
 A Widget for displaying ManyToMany ids in the "raw_id" interface rather 
than
 in a  box.
 """
-def __init__(self, rel, attrs=None, using=None):
-super(ManyToManyRawIdWidget, self).__init__(rel, attrs, using=None)
-
 def render(self, name, value, attrs=None):
 attrs['class'] = 'vManyToManyRawIdAdminField'
 if value:

-- 
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] #13465: non_field_errors should be mentioned in the form api docs

[Django]

#13465: non_field_errors should be mentioned in the form api docs
+---
  Reporter:  SmileyChris| Owner:  nobody
Status:  reopened   | Milestone:
 Component:  Documentation  |   Version:  SVN   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  0 
Needs_docs:  1  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by SmileyChris):

  * needs_docs:  0 => 1
  * stage:  Design decision needed => Accepted

Comment:

 This came up again in IRC.

 Reviewing the current docs again, the usage methods are inferred here, but
 never explicitly shown how they could be used (common usage as opposed to
 the current mention in custom validation docs).

-- 
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] #14368: Reverse relation attribute for OneToOneField fails when set to None

[Django]

#14368: Reverse relation attribute for OneToOneField fails when set to None
---+
  Reporter:  gsakkis   | Owner:  nobody 
   
Status:  new   | Milestone:  1.3
   
 Component:  Database layer (models, ORM)  |   Version:  1.2
   
Resolution:|  Keywords:  
OneToOneField, bug
 Stage:  Accepted  | Has_patch:  0  
   
Needs_docs:  0 |   Needs_tests:  0  
   
Needs_better_patch:  0 |  
---+
Comment (by subsume):

 I disagree. Do you expect a message when you do: instance.queryset_set =
 SomeQueryset.objects.all()?

 You're explicitly defining an accessor and expecting the ORM to know what
 you mean. In your example, soul isn't a field on Bob so stop treating it
 like it is one. person is a field on Soul.

-- 
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] r13969 - django/trunk/django/contrib/admin/media/css

[noreply]

Author: jezdez
Date: 2010-09-30 21:05:45 -0500 (Thu, 30 Sep 2010)
New Revision: 13969

Modified:
   django/trunk/django/contrib/admin/media/css/widgets.css
Log:
Fixed tabs introduced in r13968.

Modified: django/trunk/django/contrib/admin/media/css/widgets.css
===
--- django/trunk/django/contrib/admin/media/css/widgets.css 2010-10-01 
02:02:58 UTC (rev 13968)
+++ django/trunk/django/contrib/admin/media/css/widgets.css 2010-10-01 
02:05:45 UTC (rev 13969)
@@ -199,9 +199,9 @@
 }
 
 span.clearable-file-input label {
-   color: #333;
+color: #333;
 font-size: 11px;
-   display: inline;
+display: inline;
 float: none;
 }
 

-- 
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] #3202: [patch] Faster SelectBox for ManyToMany

[Django]

#3202: [patch] Faster SelectBox for ManyToMany
---+
  Reporter:  gke...@gmail.com  | Owner:  xian
Status:  new   | Milestone:  
 Component:  django.contrib.admin  |   Version:  SVN 
Resolution:|  Keywords:  
 Stage:  Accepted  | Has_patch:  1   
Needs_docs:  0 |   Needs_tests:  0   
Needs_better_patch:  0 |  
---+
Changes (by subsume):

 * cc: subsume (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] r13968 - in django/trunk: django/contrib/admin django/contrib/admin/media/css django/db/models/fields django/forms docs/ref/forms docs/releases tests/regressiontests/admin_widgets tests/re

[noreply]

Author: jezdez
Date: 2010-09-30 21:02:58 -0500 (Thu, 30 Sep 2010)
New Revision: 13968

Modified:
   django/trunk/django/contrib/admin/media/css/widgets.css
   django/trunk/django/contrib/admin/widgets.py
   django/trunk/django/db/models/fields/files.py
   django/trunk/django/forms/fields.py
   django/trunk/django/forms/forms.py
   django/trunk/django/forms/widgets.py
   django/trunk/docs/ref/forms/fields.txt
   django/trunk/docs/ref/forms/widgets.txt
   django/trunk/docs/releases/1.3.txt
   django/trunk/tests/regressiontests/admin_widgets/models.py
   django/trunk/tests/regressiontests/forms/fields.py
   django/trunk/tests/regressiontests/forms/tests.py
   django/trunk/tests/regressiontests/forms/widgets.py
   django/trunk/tests/regressiontests/model_fields/models.py
   django/trunk/tests/regressiontests/model_fields/tests.py
   django/trunk/tests/regressiontests/model_forms_regress/models.py
   django/trunk/tests/regressiontests/model_forms_regress/tests.py
Log:
Fixed #7048 -- Added ClearableFileInput widget to clear file fields. Thanks for 
report and patch, jarrow and Carl Meyer.

Modified: django/trunk/django/contrib/admin/media/css/widgets.css
===
--- django/trunk/django/contrib/admin/media/css/widgets.css 2010-10-01 
02:02:01 UTC (rev 13967)
+++ django/trunk/django/contrib/admin/media/css/widgets.css 2010-10-01 
02:02:58 UTC (rev 13968)
@@ -198,6 +198,13 @@
 margin-left: 5px;
 }
 
+span.clearable-file-input label {
+   color: #333;
+font-size: 11px;
+   display: inline;
+float: none;
+}
+
 /* CALENDARS & CLOCKS */
 
 .calendarbox, .clockbox {

Modified: django/trunk/django/contrib/admin/widgets.py
===
--- django/trunk/django/contrib/admin/widgets.py2010-10-01 02:02:01 UTC 
(rev 13967)
+++ django/trunk/django/contrib/admin/widgets.py2010-10-01 02:02:58 UTC 
(rev 13968)
@@ -85,20 +85,12 @@
 class AdminRadioSelect(forms.RadioSelect):
 renderer = AdminRadioFieldRenderer
 
-class AdminFileWidget(forms.FileInput):
-"""
-A FileField Widget that shows its current value if it has one.
-"""
-def __init__(self, attrs={}):
-super(AdminFileWidget, self).__init__(attrs)
+class AdminFileWidget(forms.ClearableFileInput):
+template_with_initial = (u'%s'
+% forms.ClearableFileInput.template_with_initial)
+template_with_clear = (u'%s'
+   % forms.ClearableFileInput.template_with_clear)
 
-def render(self, name, value, attrs=None):
-output = []
-if value and hasattr(value, "url"):
-output.append('%s %s %s ' % 
\
-(_('Currently:'), value.url, value, _('Change:')))
-output.append(super(AdminFileWidget, self).render(name, value, attrs))
-return mark_safe(u''.join(output))
 
 class ForeignKeyRawIdWidget(forms.TextInput):
 """

Modified: django/trunk/django/db/models/fields/files.py
===
--- django/trunk/django/db/models/fields/files.py   2010-10-01 02:02:01 UTC 
(rev 13967)
+++ django/trunk/django/db/models/fields/files.py   2010-10-01 02:02:58 UTC 
(rev 13968)
@@ -282,7 +282,15 @@
 return os.path.join(self.get_directory_name(), 
self.get_filename(filename))
 
 def save_form_data(self, instance, data):
-if data:
+# Important: None means "no change", other false value means "clear"
+# This subtle distinction (rather than a more explicit marker) is
+# needed because we need to consume values that are also sane for a
+# regular (non Model-) Form to find in its cleaned_data dictionary.
+if data is not None:
+# This value will be converted to unicode and stored in the
+# database, so leaving False as-is is not acceptable.
+if not data:
+data = ''
 setattr(instance, self.name, data)
 
 def formfield(self, **kwargs):

Modified: django/trunk/django/forms/fields.py
===
--- django/trunk/django/forms/fields.py 2010-10-01 02:02:01 UTC (rev 13967)
+++ django/trunk/django/forms/fields.py 2010-10-01 02:02:58 UTC (rev 13968)
@@ -27,8 +27,9 @@
 
 from util import ErrorList
 from widgets import TextInput, PasswordInput, HiddenInput, 
MultipleHiddenInput, \
-FileInput, CheckboxInput, Select, NullBooleanSelect, SelectMultiple, \
-DateInput, DateTimeInput, TimeInput, SplitDateTimeWidget, 
SplitHiddenDateTimeWidget
+ClearableFileInput, CheckboxInput, Select, NullBooleanSelect, 
SelectMultiple, \
+DateInput, DateTimeInput, TimeInput, SplitDateTimeWidget, 
SplitHiddenDateTimeWidget, \
+FILE_INPUT_CONTRADICTION
 
 __all__ = (
 'Field', 'CharField', 'IntegerField',
@@ -108,6 +109,9 @@
 if self.localize:
 

[Changeset] r13967 - in django/trunk: django/templatetags tests/regressiontests/templates

[noreply]

Author: jezdez
Date: 2010-09-30 21:02:01 -0500 (Thu, 30 Sep 2010)
New Revision: 13967

Modified:
   django/trunk/django/templatetags/i18n.py
   django/trunk/tests/regressiontests/templates/tests.py
Log:
Fixed #13568 -- Fixed the blocktrans tag to not raise a KeyError if the number 
of variables in the singular and the plural block differ. Thanks, deloide.

Modified: django/trunk/django/templatetags/i18n.py
===
--- django/trunk/django/templatetags/i18n.py2010-10-01 02:01:38 UTC (rev 
13966)
+++ django/trunk/django/templatetags/i18n.py2010-10-01 02:02:01 UTC (rev 
13967)
@@ -76,8 +76,10 @@
 if self.plural and self.countervar and self.counter:
 count = self.counter.resolve(context)
 context[self.countervar] = count
-plural, vars = self.render_token_list(self.plural)
+plural, plural_vars = self.render_token_list(self.plural)
 result = translation.ungettext(singular, plural, count)
+if count != 1:
+vars = plural_vars
 else:
 result = translation.ugettext(singular)
 # Escape all isolated '%' before substituting in the context.

Modified: django/trunk/tests/regressiontests/templates/tests.py
===
--- django/trunk/tests/regressiontests/templates/tests.py   2010-10-01 
02:01:38 UTC (rev 13966)
+++ django/trunk/tests/regressiontests/templates/tests.py   2010-10-01 
02:02:01 UTC (rev 13967)
@@ -1116,6 +1116,9 @@
 'i18n24': ("{% load i18n %}{% trans 'Page not found'|upper %}", 
{'LANGUAGE_CODE': 'de'}, u'SEITE NICHT GEFUNDEN'),
 'i18n25': ('{% load i18n %}{% trans somevar|upper %}', {'somevar': 
'Page not found', 'LANGUAGE_CODE': 'de'}, u'SEITE NICHT GEFUNDEN'),
 
+# translation of plural form with extra field in singular form 
(#13568)
+'i18n26': ('{% load i18n %}{% blocktrans with myextra_field as 
extra_field count number as counter %}singular {{ extra_field }}{% plural 
%}plural{% endblocktrans %}', {'number': 1, 'myextra_field': 'test'}, "singular 
test"),
+
 ### HANDLING OF TEMPLATE_STRING_IF_INVALID 
###
 
 'invalidstr01': ('{{ var|default:"Foo" }}', {}, ('Foo','INVALID')),

-- 
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] r13966 - django/trunk/docs/ref

[noreply]

Author: jezdez
Date: 2010-09-30 21:01:38 -0500 (Thu, 30 Sep 2010)
New Revision: 13966

Modified:
   django/trunk/docs/ref/request-response.txt
Log:
Fixed #13876 -- Fixed duplication in docs. Thanks, zerok and timo.

Modified: django/trunk/docs/ref/request-response.txt
===
--- django/trunk/docs/ref/request-response.txt  2010-10-01 02:01:20 UTC (rev 
13965)
+++ django/trunk/docs/ref/request-response.txt  2010-10-01 02:01:38 UTC (rev 
13966)
@@ -420,16 +420,6 @@
 >>> response.write("Here's the text of the Web page.")
 >>> response.write("Here's another paragraph.")
 
-You can add and delete headers using dictionary syntax::
-
->>> response = HttpResponse()
->>> response['X-DJANGO'] = "It's the best."
->>> del response['X-PHP']
->>> response['X-DJANGO']
-"It's the best."
-
-Note that ``del`` doesn't raise ``KeyError`` if the header doesn't exist.
-
 Passing iterators
 ~
 
@@ -444,11 +434,15 @@
 Setting headers
 ~~~
 
-To set a header in your response, just treat it like a dictionary::
+To set or remove a header in your response, treat it like a dictionary::
 
 >>> response = HttpResponse()
 >>> response['Cache-Control'] = 'no-cache'
+>>> del response['Cache-Control']
 
+Note that unlike a dictionary, ``del`` doesn't raise ``KeyError`` if the header
+doesn't exist.
+
 .. versionadded:: 1.1
 
 HTTP headers cannot contain newlines. An attempt to set a header containing a

-- 
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] r13965 - in django/trunk/tests: regressiontests/views regressiontests/views/tests regressiontests/views/tests/generic templates/views

[noreply]

Author: jezdez
Date: 2010-09-30 21:01:20 -0500 (Thu, 30 Sep 2010)
New Revision: 13965

Added:
   django/trunk/tests/regressiontests/views/tests/generic/object_list.py
   django/trunk/tests/templates/views/article_list.html
Modified:
   django/trunk/tests/regressiontests/views/tests/__init__.py
   django/trunk/tests/regressiontests/views/urls.py
Log:
Fixed #13897 -- Added tests for pagination feature of the generic object_list 
view. Thanks, d0ugal and SmileyChris.

Modified: django/trunk/tests/regressiontests/views/tests/__init__.py
===
--- django/trunk/tests/regressiontests/views/tests/__init__.py  2010-10-01 
02:00:52 UTC (rev 13964)
+++ django/trunk/tests/regressiontests/views/tests/__init__.py  2010-10-01 
02:01:20 UTC (rev 13965)
@@ -2,6 +2,7 @@
 from defaults import *
 from generic.create_update import *
 from generic.date_based import *
+from generic.object_list import *
 from generic.simple import *
 from i18n import *
 from specials import *

Added: django/trunk/tests/regressiontests/views/tests/generic/object_list.py
===
--- django/trunk/tests/regressiontests/views/tests/generic/object_list.py   
(rev 0)
+++ django/trunk/tests/regressiontests/views/tests/generic/object_list.py   
2010-10-01 02:01:20 UTC (rev 13965)
@@ -0,0 +1,36 @@
+from django.test import TestCase
+
+
+class ObjectListTest(TestCase):
+fixtures = ['testdata.json']
+
+def check_pagination(self, url, expected_status_code, object_count=None):
+response = self.client.get(url)
+self.assertEqual(response.status_code, expected_status_code)
+
+if object_count:
+self.assertEqual(response.context['is_paginated'], True)
+self.assertEqual(len(response.context['page_obj'].object_list),
+ object_count)
+
+return response
+
+def test_finds_pages(self):
+# Check page count doesn't start at 0.
+self.check_pagination('/views/object_list/page0/', 404)
+
+# Check basic pages.
+self.check_pagination('/views/object_list/page/', 200, 2)
+self.check_pagination('/views/object_list/page1/', 200, 2)
+self.check_pagination('/views/object_list/page2/', 200, 1)
+self.check_pagination('/views/object_list/page3/', 404)
+
+# Check the special "last" page.
+self.check_pagination('/views/object_list/pagelast/', 200, 1)
+self.check_pagination('/views/object_list/pagenotlast/', 404)
+
+def test_no_paginate_by(self):
+# Ensure that the view isn't paginated by default.
+url = '/views/object_list_no_paginate_by/page1/'
+response = self.check_pagination(url, 200)
+self.assertEqual(response.context['is_paginated'], False)

Modified: django/trunk/tests/regressiontests/views/urls.py
===
--- django/trunk/tests/regressiontests/views/urls.py2010-10-01 02:00:52 UTC 
(rev 13964)
+++ django/trunk/tests/regressiontests/views/urls.py2010-10-01 02:01:20 UTC 
(rev 13965)
@@ -31,6 +31,16 @@
 'date_field': 'date_created',
 'month_format': '%m',
 }
+
+object_list_dict = {
+'queryset': Article.objects.all(),
+'paginate_by': 2,
+}
+
+object_list_no_paginate_by = {
+'queryset': Article.objects.all(),
+}
+
 numeric_days_info_dict = dict(date_based_info_dict, day_format='%d')
 
 date_based_datefield_info_dict = dict(date_based_info_dict, 
queryset=DateArticle.objects.all())
@@ -104,6 +114,12 @@
 'update_object', dict(slug_field='slug', model=UrlArticle)),
 )
 
+urlpatterns += patterns('django.views.generic.list_detail',
+(r'^object_list/page(?P[\w]*)/$', 'object_list', object_list_dict),
+(r'^object_list_no_paginate_by/page(?P[0-9]+)/$', 'object_list',
+ object_list_no_paginate_by),
+)
+
 # a view that raises an exception for the debug view
 urlpatterns += patterns('',
 (r'^raises/$', views.raises),

Added: django/trunk/tests/templates/views/article_list.html
===
--- django/trunk/tests/templates/views/article_list.html
(rev 0)
+++ django/trunk/tests/templates/views/article_list.html2010-10-01 
02:01:20 UTC (rev 13965)
@@ -0,0 +1 @@
+{{ object_list }}
\ 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.

[Changeset] r13964 - in django/trunk/docs: howto/deployment ref topics topics/http

[noreply]

Author: jezdez
Date: 2010-09-30 21:00:52 -0500 (Thu, 30 Sep 2010)
New Revision: 13964

Modified:
   django/trunk/docs/howto/deployment/modpython.txt
   django/trunk/docs/ref/generic-views.txt
   django/trunk/docs/ref/request-response.txt
   django/trunk/docs/topics/http/urls.txt
   django/trunk/docs/topics/signals.txt
   django/trunk/docs/topics/templates.txt
Log:
Fixed #14281 -- A few documentation fixes. Thanks, Ramiro and Timo.

Modified: django/trunk/docs/howto/deployment/modpython.txt
===
--- django/trunk/docs/howto/deployment/modpython.txt2010-09-29 17:58:29 UTC 
(rev 13963)
+++ django/trunk/docs/howto/deployment/modpython.txt2010-10-01 02:00:52 UTC 
(rev 13964)
@@ -1,5 +1,3 @@
-.. _howto-deployment-modpython:
-
 
 How to use Django with Apache and mod_python
 

Modified: django/trunk/docs/ref/generic-views.txt
===
--- django/trunk/docs/ref/generic-views.txt 2010-09-29 17:58:29 UTC (rev 
13963)
+++ django/trunk/docs/ref/generic-views.txt 2010-10-01 02:00:52 UTC (rev 
13964)
@@ -96,6 +96,8 @@
 .. versionadded:: 1.1
 The ``permanent`` keyword argument is new in Django 1.1.
 
+.. versionadded:: 1.3
+The ``query_string`` keyword argument is new in Django 1.3.
 
 **Example:**
 
@@ -380,7 +382,7 @@
 
 * ``date_list``: A list of ``datetime.date`` objects representing all
   days that have objects available in the given month, according to
-  ``queryset``, in ascending order.
+  ``queryset``, in ascending order.
 
 * ``month``: A ``datetime.date`` object representing the given month.
 

Modified: django/trunk/docs/ref/request-response.txt
===
--- django/trunk/docs/ref/request-response.txt  2010-09-29 17:58:29 UTC (rev 
13963)
+++ django/trunk/docs/ref/request-response.txt  2010-10-01 02:00:52 UTC (rev 
13964)
@@ -40,13 +40,13 @@
 Under some web server configurations, the portion of the URL after the host
 name is split up into a script prefix portion and a path info portion
 (this happens, for example, when using the ``django.root`` option
-with the :ref:`modpython handler from Apache 
`).
+with the :doc:`modpython handler from Apache 
`).
 The ``path_info`` attribute always contains the path info portion of the
 path, no matter what web server is being used. Using this instead of
 attr:`~HttpRequest.path` can make your code much easier to move between 
test
 and deployment servers.
 
-For example, if the ``django.root`` for your application is set to 
+For example, if the ``django.root`` for your application is set to
 ``"/minfo"``, then ``path`` might be ``"/minfo/music/bands/the_beatles/"``
 and ``path_info`` would be ``"/music/bands/the_beatles/"``.
 
@@ -542,6 +542,12 @@
 
 .. _`cookie Morsel`: 
http://docs.python.org/library/cookie.html#Cookie.Morsel
 
+.. versionchanged:: 1.3
+
+Both the possibility of specifying a ``datetime.datetime`` object in
+``expires`` and the auto-calculation of ``max_age`` in such case were added
+in Django 1.3.
+
 .. method:: HttpResponse.delete_cookie(key, path='/', domain=None)
 
 Deletes the cookie with the given key. Fails silently if the key doesn't

Modified: django/trunk/docs/topics/http/urls.txt
===
--- django/trunk/docs/topics/http/urls.txt  2010-09-29 17:58:29 UTC (rev 
13963)
+++ django/trunk/docs/topics/http/urls.txt  2010-10-01 02:00:52 UTC (rev 
13964)
@@ -939,9 +939,9 @@
 However, if your application constructs part of the URL hierarchy itself, you
 may occasionally need to generate URLs. In that case, you need to be able to
 find the base URL of the Django project within its web server
-(normally, :func:`~django.core.urlresolvers.reverse` takes care of this for 
+(normally, :func:`~django.core.urlresolvers.reverse` takes care of this for
 you). In that case, you can call ``get_script_prefix()``, which will return the
 script prefix portion of the URL for your Django project. If your Django
 project is at the root of its webserver, this is always ``"/"``, but it can be
-changed, for instance  by using ``django.root`` (see :ref:`How to use
-Django with Apache and mod_python `).
+changed, for instance  by using ``django.root`` (see :doc:`How to use
+Django with Apache and mod_python `).

Modified: django/trunk/docs/topics/signals.txt
===
--- django/trunk/docs/topics/signals.txt2010-09-29 17:58:29 UTC (rev 
13963)
+++ django/trunk/docs/topics/signals.txt2010-10-01 02:00:52 UTC (rev 
13964)
@@ -89,7 +89,8 @@
 
 request_finished.connect(my_callback)
 
-Alternatively, you can use a decorator used when you define 

Re: [Django] #5537: Remove Reverse Lookups on ForeignKeys/ManyToMany

[Django]

#5537: Remove Reverse Lookups on ForeignKeys/ManyToMany
+---
  Reporter:  dcramer| Owner:  nobody
Status:  new| Milestone:  1.3   
 Component:  Documentation  |   Version:  SVN   
Resolution: |  Keywords:
 Stage:  Ready for checkin  | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by russellm):

  * stage:  Accepted => Ready for checkin
  * milestone:  => 1.3

-- 
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] #12417: Add signing and signed cookies to Django

[Django]

#12417: Add signing and signed cookies to Django
-+--
  Reporter:  simon   | Owner:  simon
Status:  new | Milestone:  1.3  
 Component:  Core framework  |   Version:  SVN  
Resolution:  |  Keywords:   
 Stage:  Accepted| Has_patch:  1
Needs_docs:  0   |   Needs_tests:  0
Needs_better_patch:  0   |  
-+--
Comment (by mr.k...@gmail.com):

 Did this get reviewed by a cryptographer?

-- 
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] #12012: Integration with the Python standard library logging module

[Django]

#12012: Integration with the Python standard library logging module
-+--
  Reporter:  simon   | Owner:  nobody
Status:  new | Milestone:  1.3   
 Component:  Core framework  |   Version:  SVN   
Resolution:  |  Keywords:
 Stage:  Accepted| Has_patch:  1 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by tvon):

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

Re: [Django] #14370: Adding support for Autocomplete in contrib.admin

[Django]

#14370: Adding support for Autocomplete in contrib.admin
---+
  Reporter:  tyrion| Owner:  nobody  
Status:  new   | Milestone:  
 Component:  django.contrib.admin  |   Version:  1.2 
Resolution:|  Keywords:  autocomplete
 Stage:  Unreviewed| Has_patch:  1   
Needs_docs:  0 |   Needs_tests:  0   
Needs_better_patch:  0 |  
---+
Comment (by subsume):

 Would it be reasonable to deprecate raw_id_fields in favor of this?

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

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

Re: [Django] #14349: Add Belgium (be) localflavor

[Django]

#14349: Add Belgium (be) localflavor
-+--
  Reporter:  laurentluce | Owner:  laurentluce  
  
Status:  assigned| Milestone:  1.3  
  
 Component:  django.contrib.localflavor  |   Version:  SVN  
  
Resolution:  |  Keywords:  localflavor 
belgium
 Stage:  Ready for checkin   | Has_patch:  1
  
Needs_docs:  0   |   Needs_tests:  0
  
Needs_better_patch:  0   |  
-+--
Changes (by russellm):

  * stage:  Accepted => Ready for checkin

Comment:

 Patch looks good; marking RFC.

-- 
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] #14370: Adding support for Autocomplete in contrib.admin

[Django]

#14370: Adding support for Autocomplete in contrib.admin
---+
  Reporter:  tyrion| Owner:  nobody  
Status:  new   | Milestone:  
 Component:  django.contrib.admin  |   Version:  1.2 
Resolution:|  Keywords:  autocomplete
 Stage:  Unreviewed| Has_patch:  1   
Needs_docs:  0 |   Needs_tests:  0   
Needs_better_patch:  0 |  
---+
Changes (by subsume):

 * cc: subsume (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] #3202: [patch] Faster SelectBox for ManyToMany

[Django]

#3202: [patch] Faster SelectBox for ManyToMany
---+
  Reporter:  gke...@gmail.com  | Owner:  xian
Status:  new   | Milestone:  
 Component:  django.contrib.admin  |   Version:  SVN 
Resolution:|  Keywords:  
 Stage:  Accepted  | Has_patch:  1   
Needs_docs:  0 |   Needs_tests:  0   
Needs_better_patch:  0 |  
---+
Changes (by subsume):

  * needs_better_patch:  1 => 0

Comment:

 So I did some testing on a queryset of 14k. FF is *way* faster. IE and
 Chrome are unnoticably different.

 I'm not sure what benefit the other tickets that were merged into this one
 may have had, but I don't really see anything stopping this patch from
 being applied. It doesn't seem to revert any features currently 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] #14370: Adding support for Autocomplete in contrib.admin

[Django]

#14370: Adding support for Autocomplete in contrib.admin
---+
  Reporter:  tyrion| Owner:  nobody  
Status:  new   | Milestone:  
 Component:  django.contrib.admin  |   Version:  1.2 
Resolution:|  Keywords:  autocomplete
 Stage:  Unreviewed| Has_patch:  1   
Needs_docs:  0 |   Needs_tests:  0   
Needs_better_patch:  0 |  
---+
Changes (by tyrion):

  * needs_better_patch:  => 0
  * has_patch:  0 => 1
  * 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.

Re: [Django] #14043: Incorrect and/or confusing behaviour with nullable OneToOneField

[Django]

#14043: Incorrect and/or confusing behaviour with nullable OneToOneField
---+
  Reporter:  theevilgeek   | Owner: 
  
Status:  new   | Milestone: 
  
 Component:  Database layer (models, ORM)  |   Version:  SVN
  
Resolution:|  Keywords:  
OneToOneField, cascading delete, nullable
 Stage:  Design decision needed| Has_patch:  0  
  
Needs_docs:  0 |   Needs_tests:  0  
  
Needs_better_patch:  0 |  
---+
Changes (by gsakkis):

  * stage:  Accepted => Design decision needed

Comment:

 Replying to [comment:1 gsakkis]:
 >
 > Why do an update if it is going to be deleted right after ?

 Ugh, scratch that, I missed the `self.save()` in `become_ghost()`, that's
 where the UPDATE comes from; nothing to do with `self.delete()`.

 Back to the topic, it comes down to Django's indiscriminate ON DELETE
 CASCADE behavior, regardless of whether the ForeignKey/OneToOneField is
 nullable. IMO it would make more sense to treat nullable keys as ON DELETE
 SET NULL but that would most likely be backwards incompatible at this
 point. Changing to design decision needed, just in case.

-- 
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] #14370: Adding support for Autocomplete in contrib.admin

[Django]

#14370: Adding support for Autocomplete in contrib.admin
--+-
 Reporter:  tyrion|   Owner:  nobody
   Status:  new   |   Milestone:
Component:  django.contrib.admin  | Version:  1.2   
 Keywords:  autocomplete  |   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 I've tried to implement Autocomplete for contrib.admin using jQuery UI
 Autocomplete.[[BR]]
 Here's the code: http://bitbucket.org/tyrion/django [[BR]]
 Here's a live demo: http://djangoac.tyrion.mx/admin/ (login with
 test/test).
 (It supports both ForeignKey and ManyToMany).

 I don't know if I should attach the complete patch here. It's kinda big (I
 included jquery-ui), however you can see it online at
 http://bitbucket.org/tyrion/django/changeset/04488ec05e92 ).

 Now it's implemented using an "autocomplete_fields" attribute which is a
 dict (field:related_fields):
 {{{
 #!python
 class MyModelAdmin(admin.ModelAdmin):
 autocomplete_fields = {'user': ('username', 'email')}

 }}}

 But because I've been asked:
 {{{
  tyrion-mx: what about making the autocomplete_fields a dict of
 dicts, to be able to specify additional options for the autocompletion,
 e.g. number of search results or a custom label function?
 }}}
 I've written this patch (for my code) http://dpaste.com/hold/251220/
 that let's you control the "value" (what is displayed in the input),
 "label" (what is displayed in the dropdown) and "limit" (max number of
 results) properties.

 With it a modeladmin could look something like this:
 {{{
 #!python
 class DummyAdmin(admin.ModelAdmin):
 autocomplete_fields = dict(
 user1 = dict(
 fields = ('username', 'email'),
 value = 'username',
 limit = 10,
 ),
 friends = dict(
 fields = ('username', 'email'),
 label = u'%(first_name)s %(last_name)s',
 value = 'email',
 ),
 )
 }}}

 In that case "value" and "label" can be either a function, a fieldname or
 a string like `u'%(username)s "%(email)s"'`.

-- 
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] #3202: [patch] Faster SelectBox for ManyToMany

[Django]

#3202: [patch] Faster SelectBox for ManyToMany
---+
  Reporter:  gke...@gmail.com  | Owner:  xian
Status:  new   | Milestone:  
 Component:  django.contrib.admin  |   Version:  SVN 
Resolution:|  Keywords:  
 Stage:  Accepted  | Has_patch:  1   
Needs_docs:  0 |   Needs_tests:  0   
Needs_better_patch:  1 |  
---+
Comment (by subsume):

 Misunderstood patch limitations. Looking at it meanwhile to see if it
 still might apply.

-- 
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] #14367: Please add as_p() to form fields

[Django]

#14367: Please add as_p() to form fields
-+--
  Reporter:  dfoerster   | Owner:  nobody
Status:  closed  | Milestone:
 Component:  Forms   |   Version:  1.2   
Resolution:  duplicate   |  Keywords:
 Stage:  Unreviewed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by dpn):

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

Comment:

 Hey, I'm gonna mark this as a dupe of #3111 . as_p isn't mentioned there,
 but its the same idea :)

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #14347: Add required_if field to model fields

[Django]

#14347: Add required_if field to model fields
+---
  Reporter:  hejsan | Owner:  nobody
Status:  new| Milestone:
 Component:  Uncategorized  |   Version:
Resolution: |  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Comment (by dpn):

 FWIW this sounds like it's related to this discussion too
 http://groups.google.com/group/django-
 developers/browse_thread/thread/a040530cf2614824#

 Basically dealing with validation over multiple fields. I know yours is a
 param to the field and Yo Yo was talking about something like Meta, but
 yeah, they are conceptually related :P

 Seems like the jury was out on this..

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

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

Re: [Django] #12012: Integration with the Python standard library logging module

[Django]

#12012: Integration with the Python standard library logging module
-+--
  Reporter:  simon   | Owner:  nobody
Status:  new | Milestone:  1.3   
 Component:  Core framework  |   Version:  SVN   
Resolution:  |  Keywords:
 Stage:  Accepted| Has_patch:  1 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by russellm):

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

Comment:

 @anon - Nothing in particular; if you want to log to database, that's
 certainly an option with an appropriate handler.

 My only concern would be the extra database load that this logging
 technique would introduce, but that isn't something that you can declare
 as universally bad; it entirely depends on your load pattern and the
 amount of logging you intend to do.

-- 
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] #14368: Reverse relation attribute for OneToOneField fails when set to None

[Django]

#14368: Reverse relation attribute for OneToOneField fails when set to None
---+
  Reporter:  gsakkis   | Owner:  nobody 
   
Status:  new   | Milestone:  1.3
   
 Component:  Database layer (models, ORM)  |   Version:  1.2
   
Resolution:|  Keywords:  
OneToOneField, bug
 Stage:  Accepted  | Has_patch:  0  
   
Needs_docs:  0 |   Needs_tests:  0  
   
Needs_better_patch:  0 |  
---+
Comment (by gsakkis):

 At the very least, I expect a well-thought out exception message that
 explains what happened and why, like those checked for a few lines above:

 {{{
 if value is None and self.related.field.null == False:
 raise ValueError('Cannot assign None: "%s.%s" does not allow null
 values.' %
 (instance._meta.object_name,
 self.related.get_accessor_name()))
 elif value is not None and not isinstance(value, self.related.model):
 raise ValueError('Cannot assign "%r": "%s.%s" must be a "%s"
 instance.' %
   (value, instance._meta.object_name,
self.related.get_accessor_name(),
 self.related.opts.object_name))
 }}}

 The fact that there is no such message for this case means that it was
 missed, it's not a deliberate choice.

 As for what it should happen, I think it should do the equivalent of what
 the ForeignRelatedObjectsDescriptor does for foreign keys: make
 `A.link_to_B = None`, `B.link_to_A = None` and `B.save()`, thus breaking
 the relation between A and B (we're always talking about a `null=True`
 OneToOneField).

-- 
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] #14363: ManyToManyRawIdWidget.render is assuming `attrs` is always passed as a dict.

[Django]

#14363: ManyToManyRawIdWidget.render is assuming `attrs` is always passed as a
dict.
---+
  Reporter:  tyrion| Owner:  jezdez
Status:  assigned  | Milestone:
 Component:  django.contrib.admin  |   Version:  1.2   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by dpn):

 I've added some tests to the original patch.

 I've also adjusted a couple of indentation issues that seemed to be in the
 same area of tests :)

-- 
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] #3422: url configuration: include in combination with extra options messes up reverse resolving

[Django]

#3422: url configuration: include in combination with extra options messes up
reverse resolving
--+-
  Reporter:  Jeroen van Dongen   | 
Owner:  nobody
Status:  reopened | 
Milestone:
 Component:  Core framework   |   
Version:  SVN   
Resolution:   |  
Keywords:  urls.py reverse resolver extra_options
 Stage:  Accepted | 
Has_patch:  0 
Needs_docs:  0|   
Needs_tests:  0 
Needs_better_patch:  0|  
--+-
Changes (by subsume):

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

-- 
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] #3422: url configuration: include in combination with extra options messes up reverse resolving

[Django]

#3422: url configuration: include in combination with extra options messes up
reverse resolving
--+-
  Reporter:  Jeroen van Dongen   | 
Owner:  nobody
Status:  closed   | 
Milestone:
 Component:  Core framework   |   
Version:  SVN   
Resolution:  wontfix  |  
Keywords:  urls.py reverse resolver extra_options
 Stage:  Accepted | 
Has_patch:  0 
Needs_docs:  0|   
Needs_tests:  0 
Needs_better_patch:  0|  
--+-
Comment (by subsume):

 reopening this. I misunderstood the original problem but its a rather
 obscure way to set up one's urls.

-- 
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] #3422: url configuration: include in combination with extra options messes up reverse resolving

[Django]

#3422: url configuration: include in combination with extra options messes up
reverse resolving
--+-
  Reporter:  Jeroen van Dongen   | 
Owner:  nobody
Status:  closed   | 
Milestone:
 Component:  Core framework   |   
Version:  SVN   
Resolution:  wontfix  |  
Keywords:  urls.py reverse resolver extra_options
 Stage:  Accepted | 
Has_patch:  0 
Needs_docs:  0|   
Needs_tests:  0 
Needs_better_patch:  0|  
--+-
Changes (by subsume):

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

Comment:

 OP seemed mistaken in thinking that these args factored into the resolving
 of a URL. Malcolm sees a use case but nobody's really chimed in in a few
 years so I think its safe to close. Please forgive my overreach if this is
 an inappropriate move. I've never heard of anyone expecting this behavior
 from extra arguments and for those who do want the specificity, there's
 named urls.

-- 
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] #2750: ManyToManyField ignores 'default' option

[Django]

#2750: ManyToManyField ignores 'default' option
---+
  Reporter:  bangcok_dange...@hotmail.com  | Owner:  nobody
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:
Resolution:|  Keywords:
 Stage:  Someday/Maybe | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by subsume):

 +1 in favor of documentation update to reflect the status of default and
 null in relation to M2Ms.

 With signals and a million other tools its easy to get this default and
 I'm not certain that I agree with the meaning or obviousness of 'default'
 when it comes to this 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-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] #14368: Reverse relation attribute for OneToOneField fails when set to None

[Django]

#14368: Reverse relation attribute for OneToOneField fails when set to None
---+
  Reporter:  gsakkis   | Owner:  nobody 
   
Status:  new   | Milestone:  1.3
   
 Component:  Database layer (models, ORM)  |   Version:  1.2
   
Resolution:|  Keywords:  
OneToOneField, bug
 Stage:  Accepted  | Has_patch:  0  
   
Needs_docs:  0 |   Needs_tests:  0  
   
Needs_better_patch:  0 |  
---+
Changes (by subsume):

 * cc: subsume (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] #14365: Make template-rendering signals available also in DEBUG mode

[Django]

#14365: Make template-rendering signals available also in DEBUG mode
+---
  Reporter:  carljm | Owner:  carljm
Status:  new| Milestone:
 Component:  Testing framework  |   Version:  SVN   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Comment (by carljm):

 Oh, the patch is also available at
 http://github.com/carljm/django/compare/master...ticket_14365

-- 
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] #14360: Clarify documentation of triage states

[Django]

#14360: Clarify documentation of triage states
+---
  Reporter:  russellm   | Owner:  nobody
Status:  new| Milestone:  1.3   
 Component:  Documentation  |   Version:  1.2   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Comment (by gsakkis):

 > Obviously, some seem to imply the later meaning into "Accepted" which
 could raise the question regarding whether it is named correctly (I say it
 is fine)

 I disagree. Especially for a ticket with a patch,  I read "Accepted" as
 "the patch has been reviewed and accepted by the powers that be (albeit
 not applied yet for whatever reason)". What's adding to the confusion is
 the (as it turns out unrelated) "accept ticket" radio button action, as I
 had the chance to find out very recently :)

 I propose "Verified" or "Confirmed" as much less ambiguous alternatives of
 "Accepted".

 > Sure there is this:
 http://docs.djangoproject.com/en/dev/internals/contributing/#ticket-triage

 > But that hardly makes clear exactly what "accepted" actually means.

 I have to disagree again, sorry :) To me this link actually does explain
 what "Accepted" means for Django. The problem is, of course, that it's
 probably the first time I see it (or maybe I had seen time once upon a
 time and completely forgot about it). If the term "Accepted" remains as
 is, a link to this picture just besides (or on top of) the triage stage
 widget might help alleviate the problem. I still prefer the rename to
 "Verified" or "Confirmed".

 Just my 0.02€

-- 
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] #14365: Make template-rendering signals available also in DEBUG mode

[Django]

#14365: Make template-rendering signals available also in DEBUG mode
+---
  Reporter:  carljm | Owner:  carljm
Status:  new| Milestone:
 Component:  Testing framework  |   Version:  SVN   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by carljm):

  * owner:  nobody => carljm
  * has_patch:  0 => 1

Comment:

 Here's my initial go at a patch. It bases the sending of the signal on the
 value of TEMPLATE_DEBUG, and setup_test_environment forces the sending of
 the signal regardless.

 As you can see, this patch does a boolean if check on every template
 render. This is the simplest, most straightforward code, so I decided to
 try it first and check the performance impact. I added a
 template_render_simple benchmark to djangobench (available at
 http://github.com/carljm/djangobench/tree/template_render_simple) to focus
 on the render call itself and eliminate as much noise as possible. Results
 also attached: djangobench certainly isn't detecting any noticeable
 slowdown; half the time it seems to think it's faster, which suggests to
 me that any impact is so small as to be completely insignificant.

 If someone can detect a statistically significant slowdown from this
 change, or suggest any alternative benchmarking methods that might detect
 one, I have ideas for how the boolean check could be done just once at
 import time. But all of these ideas would involve less readable and
 maintainable code, so I'm going to vote for the simple approach in the
 absence of any evidence of a performance issue.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #14368: Reverse relation attribute for OneToOneField fails when set to None

[Django]

#14368: Reverse relation attribute for OneToOneField fails when set to None
---+
  Reporter:  gsakkis   | Owner:  nobody 
   
Status:  new   | Milestone:  1.3
   
 Component:  Database layer (models, ORM)  |   Version:  1.2
   
Resolution:|  Keywords:  
OneToOneField, bug
 Stage:  Accepted  | Has_patch:  0  
   
Needs_docs:  0 |   Needs_tests:  0  
   
Needs_better_patch:  0 |  
---+
Comment (by subsume):

 I'm not really sure this is a bug. What are you hoping to achieve by
 setting the accessor to be None?

 If you have A.attribute which points to B, the information is still stored
 on B and so changes need to be made in the context of B.

-- 
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] #14349: Add Belgium (be) localflavor

[Django]

#14349: Add Belgium (be) localflavor
-+--
  Reporter:  laurentluce | Owner:  laurentluce  
  
Status:  assigned| Milestone:  1.3  
  
 Component:  django.contrib.localflavor  |   Version:  SVN  
  
Resolution:  |  Keywords:  localflavor 
belgium
 Stage:  Accepted| Has_patch:  1
  
Needs_docs:  0   |   Needs_tests:  0
  
Needs_better_patch:  0   |  
-+--
Changes (by laurentluce):

  * needs_better_patch:  1 => 0

Comment:

 - Replaced doctests by unittests.
 - Modified tests/regressiontests/forms/tests.py to import BE localflavor
 unit tests properly
 - Add my name to AUTHORS

-- 
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] #3298: max_age doesn't work on mobile phone

[Django]

#3298: max_age doesn't work on mobile phone
---+
  Reporter:  s...@ernerot.com  | Owner:  nobody
Status:  closed| Milestone:
 Component:  Contrib apps  |   Version:
Resolution:  invalid   |  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by subsume):

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

Comment:

 err. per above.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #3298: max_age doesn't work on mobile phone

[Django]

#3298: max_age doesn't work on mobile phone
---+
  Reporter:  s...@ernerot.com  | Owner:  nobody
Status:  new   | Milestone:
 Component:  Contrib apps  |   Version:
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by subsume):

  * stage:  Accepted => Unreviewed

Comment:

 Closing this ticket. By this point these browsers are considered legacy
 systems and there's no evidence the problem isn't the legacy software in
 question.

-- 
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] #14368: Reverse relation attribute for OneToOneField fails when set to None

[Django]

#14368: Reverse relation attribute for OneToOneField fails when set to None
---+
  Reporter:  gsakkis   | Owner:  nobody 
   
Status:  new   | Milestone:  1.3
   
 Component:  Database layer (models, ORM)  |   Version:  1.2
   
Resolution:|  Keywords:  
OneToOneField, bug
 Stage:  Accepted  | Has_patch:  0  
   
Needs_docs:  0 |   Needs_tests:  0  
   
Needs_better_patch:  0 |  
---+
Changes (by gsakkis):

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

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #14369: TEMPLATE_STRING_IF_INVALID settable per template rendering

[Django]

#14369: TEMPLATE_STRING_IF_INVALID settable per template rendering
-+--
 Reporter:  vanschelven  |   Owner:  nobody
   Status:  new  |   Milestone:
Component:  Template system  | Version:  1.2   
 Keywords:   |   Stage:  Unreviewed
Has_patch:  0|  
-+--
 It would be nice if TEMPLATE_STRING_IF_INVALID is settable per template
 rendering.

 I have created a version of this here:
 http://bitbucket.org/vanschelven/django/changeset/7cfe30a771b7

 In this particular prototype the TEMPLATE_STRING_IF_INVALID is looked up
 in the context, as well as in the settings (in that order).
 A greater reworking of the templating system would allow for
 template.render(.., string_if_invalid="YOUR_STRING %s")

 In some cases you want to be absolutely sure that whatever you tell the
 template to render either shows up, or generates an error.
 This can also be used in combination with Exceptions on rendering by using
 a tool like this:

 
http://bitbucket.org/vanschelven/django_invalid_template_exception/src/2c5772c3f21d/invalid_template_exception/__init__.py

 In some cases (notably the admin) it is unfortunately currently impossible
 to use the TEMPLATE_STRING_IF_INVALID at all.
 Having a per-template approach allows for more flexibility.

-- 
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] #12420: "OneToOneField doesn't allow assignment of None"

[Django]

#12420: "OneToOneField doesn't allow assignment of None"
---+
  Reporter:  kbrownlees| Owner:  andrewsk
Status:  closed| Milestone:  1.2 
 Component:  Database layer (models, ORM)  |   Version:  SVN 
Resolution:  fixed |  Keywords:  
 Stage:  Ready for checkin | Has_patch:  1   
Needs_docs:  0 |   Needs_tests:  0   
Needs_better_patch:  0 |  
---+
Comment (by gsakkis):

 Fair enough, opened a new ticket at #14368.

-- 
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] #14368: Reverse relation attribute for OneToOneField fails when set to None

[Django]

#14368: Reverse relation attribute for OneToOneField fails when set to None
--+-
 Reporter:  gsakkis   |   Owner:  nobody
   Status:  new   |   Milestone:  1.3   
Component:  Database layer (models, ORM)  | Version:  1.2   
 Keywords:  OneToOneField, bug|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 Initially reported by reopening #12420
 (http://code.djangoproject.com/ticket/12420#comment:10), moved to a new
 ticket after the assignee's suggestion.

 Test case with the sample models used at #14043:

 {{{
 In [6]: bob = Person.objects.create(age=34)
 In [7]: bobs_soul = Soul.objects.create(person=bob)
 In [8]: bob.soul == bobs_soul
 Out[8]: True
 In [9]: bob.soul = None
 ---
 AttributeErrorTraceback (most recent call
 last)

 --> 258 setattr(value, self.related.field.attname,
 getattr(instance, self.related.field.rel.get_related_field().attname))
 259
 260 # Since we already know what the related object is, seed
 the related


 AttributeError: 'NoneType' object has no attribute 'person_id'
 }}}

 The offending lines are
 
http://code.djangoproject.com/browser/django/trunk/django/db/models/fields/related.py#L258
 and
 
http://code.djangoproject.com/browser/django/trunk/django/db/models/fields/related.py#L264.
 It's clearly a bug because the comment at
 
http://code.djangoproject.com/browser/django/trunk/django/db/models/fields/related.py#L238
 explicitly mentions "If null=True, we can assign null 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-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] #6735: Class-based generic views

[Django]

#6735: Class-based generic views
+---
  Reporter:  jkocherhans| Owner:  david
Status:  assigned   | Milestone:   
 Component:  Generic views  |   Version:   
Resolution: |  Keywords:   
 Stage:  Accepted   | Has_patch:  1
Needs_docs:  1  |   Needs_tests:  0
Needs_better_patch:  0  |  
+---
Changes (by chromano):

 * cc: chromano (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] #6735: Class-based generic views

[Django]

#6735: Class-based generic views
+---
  Reporter:  jkocherhans| Owner:  david
Status:  assigned   | Milestone:   
 Component:  Generic views  |   Version:   
Resolution: |  Keywords:   
 Stage:  Accepted   | Has_patch:  1
Needs_docs:  1  |   Needs_tests:  0
Needs_better_patch:  0  |  
+---
Changes (by DaNmarner):

 * cc: DaNmarner (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] #14367: Please add as_p() to form fields

[Django]

#14367: Please add as_p() to form fields
---+
 Reporter:  dfoerster  |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Forms  | Version:  1.2   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 The form.as_p() method is very handy but can't always be user. When
 customizing the layout of a form one has to specify for each field the
 label (using get_label), a possible error message and the form widget.

 It would be very handy, if form fields had a as_p() method that prints the
 fields label, error message and widget just as the forms as_p() method
 does.

-- 
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] #3202: [patch] Faster SelectBox for ManyToMany

[Django]

#3202: [patch] Faster SelectBox for ManyToMany
---+
  Reporter:  gke...@gmail.com  | Owner:  xian
Status:  new   | Milestone:  
 Component:  django.contrib.admin  |   Version:  SVN 
Resolution:|  Keywords:  
 Stage:  Accepted  | Has_patch:  1   
Needs_docs:  0 |   Needs_tests:  0   
Needs_better_patch:  1 |  
---+
Comment (by subsume):

 So it doesn't speed up IE: big deal! Lots of other browsers have gained
 momentum since this patch was written and its possible it will help some
 or all of them.

-- 
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] #7048: Support clearing FileFields with ModelForms

[Django]

#7048: Support clearing FileFields with ModelForms
---+
  Reporter:  jarrow| Owner:  carljm   
Status:  assigned  | Milestone:   
 Component:  Forms |   Version:  SVN  
Resolution:|  Keywords:  sprintSep2010
 Stage:  Accepted  | Has_patch:  1
Needs_docs:  0 |   Needs_tests:  0
Needs_better_patch:  0 |  
---+
Changes (by btubbs):

 * cc: brent.tu...@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.

Re: [Django] #6534: Add min_choices and max_choices

[Django]

#6534: Add min_choices and max_choices
-+--
  Reporter:  dcramer | Owner:  nobody
Status:  closed  | Milestone:
 Component:  Forms   |   Version:  SVN   
Resolution:  wontfix |  Keywords:
 Stage:  Design decision needed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by subsume):

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

Comment:

 Closed per above.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #9194: Allow additional hashing algorithms for passwords

[Django]

#9194: Allow additional hashing algorithms for passwords
-+--
  Reporter:  dcramer | Owner:  nobody
Status:  closed  | Milestone:
 Component:  Authentication  |   Version:  1.0   
Resolution:  duplicate   |  Keywords:
 Stage:  Design decision needed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by subsume):

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

Comment:

 Dupe of #6028 and a lack of support for a more comprehensive pluggable
 backend for this use-case.

-- 
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] #6827: [Feature] Allow contains to work with lists

[Django]

#6827: [Feature] Allow contains to work with lists
---+
  Reporter:  dcramer   | Owner:  nobody
Status:  closed| Milestone:
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:  wontfix   |  Keywords:
 Stage:  Design decision needed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by subsume):

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

Comment:

 Closing this. There are a lot of other ways to achieve this and to me
 there's no reason why AND should be the default above OR.

 PS: I have david's blessing

-- 
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] #14365: Make template-rendering signals available also in DEBUG mode

[Django]

#14365: Make template-rendering signals available also in DEBUG mode
+---
  Reporter:  carljm | Owner:  nobody
Status:  new| Milestone:
 Component:  Testing framework  |   Version:  SVN   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by carljm):

  * needs_better_patch:  => 0
  * stage:  Unreviewed => Accepted
  * version:  1.2 => SVN
  * needs_tests:  => 0
  * needs_docs:  => 0

Comment:

 Marking Accepted based on IRC approval-in-concept (depending on
 performance impact) from Russell and Jacob.

-- 
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] #4509: Allow prepopulated_fields for non-slug fields

[Django]

#4509: Allow prepopulated_fields for non-slug fields
---+
  Reporter:  jfind...@gmail.com| Owner:  adrian  
Status:  closed| Milestone:  
 Component:  django.contrib.admin  |   Version:  SVN 
Resolution:  wontfix   |  Keywords:  prepopulate_from
 Stage:  Accepted  | Has_patch:  0   
Needs_docs:  0 |   Needs_tests:  0   
Needs_better_patch:  0 |  
---+
Changes (by subsume):

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

Comment:

 Alex said he wouldn't mind a wontfix so here it is.

 There are so many other ways to solve this problem. You can attach your
 own media to the fields in question. You can change your use case and
 create a check-box instead of duplicating the fields in the form.
 Prepopulated_fields has a history of only working for slug-fields, so this
 ticket is invalid because it was never an advertised use of
 prepopulated_fields.

-- 
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] #10771: Add a transaction context manager

[Django]

#10771: Add a transaction context manager
---+
  Reporter:  obeattie  | Owner:  nobody 

Status:  new   | Milestone:  1.3

 Component:  Database layer (models, ORM)  |   Version:  SVN

Resolution:|  Keywords:  
transaction, contextmanager
 Stage:  Accepted  | Has_patch:  1  

Needs_docs:  0 |   Needs_tests:  0  

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

 * cc: chromano (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] #14366: Model.objects.none().values(...).anything() is broken

[Django]

#14366: Model.objects.none().values(...).anything() is broken
---+
  Reporter:  carljm| Owner:  nobody
Status:  new   | Milestone:  1.3   
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Ready for checkin | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by Alex):

  * 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.

Re: [Django] #14366: Model.objects.none().values(...).anything() is broken

[Django]

#14366: Model.objects.none().values(...).anything() is broken
---+
  Reporter:  carljm| Owner:  nobody
Status:  new   | Milestone:  1.3   
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by carljm):

  * has_patch:  0 => 1
  * version:  1.2 => SVN
  * milestone:  => 1.3

-- 
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] #14366: Model.objects.none().values(...).anything() is broken

[Django]

#14366: Model.objects.none().values(...).anything() is broken
---+
  Reporter:  carljm| Owner:  nobody
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  1.2   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by carljm):

 I looked around for a while to see if I could find a way to pin this on
 multi-db, but no luck. Turns out it's just a simple matter of
 EmptyQuerySet._clone() ignoring its "setup" arg instead of passing it on
 to QuerySet._clone(). Patch with test attached, also at
 http://github.com/carljm/django/compare/master...ticket_14366

-- 
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] #12012: Integration with the Python standard library logging module

[Django]

#12012: Integration with the Python standard library logging module
-+--
  Reporter:  simon   | Owner:  nobody
Status:  new | Milestone:  1.3   
 Component:  Core framework  |   Version:  SVN   
Resolution:  |  Keywords:
 Stage:  Accepted| Has_patch:  1 
Needs_docs:  1   |   Needs_tests:  1 
Needs_better_patch:  1   |  
-+--
Comment (by anonymous):

 I've made a working logger by just using a simple encapsulation of
 database table with two main field: level and text, this has the advantage
 of being instantly available in Django admin.  What am I missing with this
 approach?

-- 
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] #11313: list_editable fields don't support 'save' in multiuser environment

[Django]

#11313: list_editable fields don't support 'save' in multiuser environment
---+
  Reporter:  margieroginski| Owner:  nobody
Status:  reopened  | Milestone:  1.3   
 Component:  django.contrib.admin  |   Version:  1.1-beta-1
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by andybak):

 Is there not a much bigger problem with list_editable?

 Admin1 has the changelist open
 Admin2 makes a load of changes
 Admin1 makes a single change and wipes all of Admin2's changes

 This will affect least for the number of items specified in
 ModelAdmin.list_per_page which is 100 by default.

-- 
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] #29: Fix usability issue with limit_choices_to and "Add another" in admin

[Django]

#29: Fix usability issue with limit_choices_to and "Add another" in admin
---+
  Reporter:  adrian| Owner:  anonymous
Status:  assigned  | Milestone:   
 Component:  django.contrib.admin  |   Version:  SVN  
Resolution:|  Keywords:   
 Stage:  Someday/Maybe | Has_patch:  0
Needs_docs:  0 |   Needs_tests:  0
Needs_better_patch:  0 |  
---+
Comment (by subsume):

 If your requirements are so particular you can show all staff members in
 that drop-down and have form validation warn you when attempting to select
 one who isn't takes_photos=True. You could create a dropdown widget which
 the valid choices more obvious (some bold, some gray, etc).

 ...or maybe sit on the idea another 5 years =)

-- 
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] #14366: Model.objects.none().values(...).anything() is broken

[Django]

#14366: Model.objects.none().values(...).anything() is broken
---+
  Reporter:  carljm| Owner:  nobody
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  1.2   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by Alex):

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

Comment:

 Marking as accepted because this is the first ORM bug in a while that
 isn't my fault.

-- 
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] #14206: contrib:admin dynamic list_display support

[Django]

#14206: contrib:admin dynamic list_display support
---+
  Reporter:  gabejackson   | Owner:  nobody 

Status:  new   | Milestone: 

 Component:  django.contrib.admin  |   Version:  1.2

Resolution:|  Keywords:  list_display 
override dynamic admin
 Stage:  Accepted  | Has_patch:  0  

Needs_docs:  0 |   Needs_tests:  0  

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

  * stage:  Unreviewed => Accepted

Comment:

 Marking as accepted, because right now the only way to solve this isn't
 thread safe.

-- 
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] #14206: contrib:admin dynamic list_display support

[Django]

#14206: contrib:admin dynamic list_display support
---+
  Reporter:  gabejackson   | Owner:  nobody 

Status:  new   | Milestone: 

 Component:  django.contrib.admin  |   Version:  1.2

Resolution:|  Keywords:  list_display 
override dynamic admin
 Stage:  Unreviewed| Has_patch:  0  

Needs_docs:  0 |   Needs_tests:  0  

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

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

Comment:

 This could be solved without a patch using proxy models, since there may
 be a whole world of difference between what your two audiences see (not
 only in list_display, but also in the form itself).

 You create a proxy model of your original model and you assign permissions
 to whoever based on what's 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-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] #14366: Model.objects.none().values(...).anything() is broken

[Django]

#14366: Model.objects.none().values(...).anything() is broken
--+-
 Reporter:  carljm|   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Database layer (models, ORM)  | Version:  1.2   
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 There's a bug in the interaction of EmptyQuerySet and ValuesQuerySet;
 chaining .none() with .values() and then following that with any QuerySet
 method that causes a clone results in "AttributeError: 'ValuesQuerySet'
 object has no attribute 'field_names'".

 (Obviously this chain is useless in the simple case, but the utility of
 .none() is for methods that need to return a QuerySet but in some cases
 should return one with no results; this can easily break in such cases if
 the caller of that method does further processing the returned queryset
 that includes .values()).

-- 
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] #25: Filtering interface on ForeignKey boxes

[Django]

#25: Filtering interface on ForeignKey  boxes
---+
  Reporter:  adrian| Owner:  cpharmston
Status:  assigned  | Milestone:  1.3   
 Component:  django.contrib.admin  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by anonymous):

 * cc: rokclim...@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] #14365: Make template-rendering signals available also in DEBUG mode

[Django]

#14365: Make template-rendering signals available also in DEBUG mode
---+
 Reporter:  carljm |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Testing framework  | Version:  1.2   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 Django's test setup monkeypatches the template renderer to send a signal
 every time a template is rendered. The test client handles this signal to
 provide template-rendered debugging information.

 It would be useful to have access to this signal in DEBUG mode, not only
 in testing, so that the test Client can be used from the python shell
 without losing the template info, and so external tools like django-debug-
 toolbar can make use of it without having to monkeypatch.

 The original reason for the current behavior was performance; signals used
 to be quite slow. This is no longer the case (and it should be possible to
 make the performance impact in production nothing more than a single DEBUG
 check at startup/init time). Nonetheless, any patch here should come with
 performance impact data.

-- 
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] #14363: ManyToManyRawIdWidget.render is assuming `attrs` is always passed as a dict.

[Django]

#14363: ManyToManyRawIdWidget.render is assuming `attrs` is always passed as a
dict.
---+
  Reporter:  tyrion| Owner:  jezdez
Status:  assigned  | Milestone:
 Component:  django.contrib.admin  |   Version:  1.2   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by jezdez):

  * status:  new => assigned
  * needs_better_patch:  => 0
  * stage:  Unreviewed => Accepted
  * needs_tests:  => 0
  * needs_docs:  => 0

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #6552: django.core.context_processors.auth causes "Vary: Cookie" header no matter what

[Django]

#6552: django.core.context_processors.auth causes "Vary: Cookie" header no 
matter
what
-+--
  Reporter:  o...@iola.dk| Owner:  lukeplant
Status:  closed  | Milestone:   
 Component:  Authentication  |   Version:  SVN  
Resolution:  fixed   |  Keywords:   
 Stage:  Accepted| Has_patch:  1
Needs_docs:  1   |   Needs_tests:  0
Needs_better_patch:  0   |  
-+--
Changes (by lukeplant):

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

Comment:

 From my experiments, it is still is behaving correctly, using any backend
 including the `SessionStorage` backend. The `get_messages` call is
 effectively lazy because the object it returns only accesses the session
 if the contents are accessed by iterating over it. Perhaps you have a
 template somewhere that is iterating over the 'messages' value.

 If you can attach a minimal test project with views and templates that
 show the problem, please re-open.

-- 
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] #14363: ManyToManyRawIdWidget.render is assuming `attrs` is always passed as a dict.

[Django]

#14363: ManyToManyRawIdWidget.render is assuming `attrs` is always passed as a
dict.
--+-
 Reporter:  tyrion|   Owner:  jezdez
   Status:  new   |   Milestone:
Component:  django.contrib.admin  | Version:  1.2   
 Keywords:|   Stage:  Unreviewed
Has_patch:  1 |  
--+-
 {{{
 #!python
 def render(self, name, value, attrs=None):
 attrs['class'] = 'vManyToManyRawIdAdminField'
 if value:
 value = ','.join([force_unicode(v) for v in value])
 else:
 value = ''
 return super(ManyToManyRawIdWidget, self).render(name, value,
 attrs)
 }}}
 Either if I pass something else than a dict-like object or if I don't pass
 nothing at all, the method will raise an exception.

-- 
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] #14362: ManyToManyRawIdWidget doesn't work with multidb

[Django]

#14362: ManyToManyRawIdWidget doesn't work with multidb
---+
  Reporter:  tyrion| Owner:  jezdez
Status:  new   | Milestone:
 Component:  django.contrib.admin  |   Version:  1.2   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by tyrion):

  * needs_better_patch:  => 0
  * has_patch:  0 => 1
  * 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] #14362: ManyToManyRawIdWidget doesn't work with multidb

[Django]

#14362: ManyToManyRawIdWidget doesn't work with multidb
--+-
 Reporter:  tyrion|   Owner:  jezdez
   Status:  new   |   Milestone:
Component:  django.contrib.admin  | Version:  1.2   
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 The init method of ManyToManyRawIdWidget is defined as follows:
 {{{
 #!python
 def __init__(self, rel, attrs=None, using=None):
 super(ManyToManyRawIdWidget, self).__init__(rel, attrs, using=None)
 }}}

 It is completely ignoring the `using` parameter (whatever will be passed
 to the method, it will pass None to the parent method).
 Moreover this init method seems useless.

-- 
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] #14361: problem with logging

[Django]

#14361: problem with logging
+---
  Reporter:  pitons | Owner:  nobody
Status:  closed | Milestone:
 Component:  Uncategorized  |   Version:  1.2   
Resolution:  invalid|  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:  => invalid
  * needs_tests:  => 0
  * needs_docs:  => 0

Comment:

 Trac isn't a user-support forum. If you're having problems, please post to
 the django-users mailing list, or as in the #django IRC room on Freenode.

-- 
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] #14361: problem with logging

[Django]

#14361: problem with logging
---+
 Reporter:  pitons |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Uncategorized  | Version:  1.2   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 Hi there djangoliers! :)
 Could somebody help me with following problem:
 I have a http://whitetrash.sourceforge.net/
 working on CentOS 5.5 with python 2.4.3 and Django-1.1.2.tar.gz (same was
 with Django-1.2.1.tar.gz)
 but when I try to do anything like "python manage.py *" at the end of the
 command I get error:
 Error in atexit._run_exitfuncs:
 Traceback (most recent call last):
   File "/usr/lib/python2.4/atexit.py", line 24, in _run_exitfuncs
 func(*targs, **kargs)
   File "/usr/lib/python2.4/logging/__init__.py", line 1333, in shutdown
 h.close()
   File "/usr/lib/python2.4/logging/handlers.py", line 644, in close
 logging.Handler.close(self)
   File "/usr/lib/python2.4/logging/__init__.py", line 674, in close
 del _handlers[self]
 KeyError: 
 Error in sys.exitfunc:
 Traceback (most recent call last):
   File "/usr/lib/python2.4/atexit.py", line 24, in _run_exitfuncs
 func(*targs, **kargs)
   File "/usr/lib/python2.4/logging/__init__.py", line 1333, in shutdown
 h.close()
   File "/usr/lib/python2.4/logging/handlers.py", line 644, in close
 logging.Handler.close(self)
   File "/usr/lib/python2.4/logging/__init__.py", line 674, in close
 del _handlers[self]
 KeyError: 

 Have searched for solution for weeks with no success.
 will be very grateful on any help or comments on this one
 also needed details will gladly provide!

 Also can add that recently found out that CentOS lacks debuging features
 as written in:
 http://thomas.apestaart.org/log/?p=863

 p.s. have same soft on debian 5 with python 2.5 and no errors, but it's
 vital to get it working on centos and python 2.4.
 or somehow avoid/workaround those errors on python 2.4 if it's version
 related.

 thanks in advance!
 Pitons

-- 
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] #13815: Excluding isnull=False testing failing on reverse optional relations

[Django]

#13815: Excluding isnull=False testing failing on reverse optional relations
---+
  Reporter:  bpeschier | Owner:  nobody 
 
Status:  new   | Milestone: 
 
 Component:  Database layer (models, ORM)  |   Version:  SVN
 
Resolution:|  Keywords:  isnull, 
reverse relation
 Stage:  Unreviewed| Has_patch:  1  
 
Needs_docs:  0 |   Needs_tests:  0  
 
Needs_better_patch:  0 |  
---+
Comment (by anonymous):

 Tested it with django 1.1.2 and this patch fixes alot of issues for me! (I
 have a stack of workarounds for this bug).
 Thank you!

 Hope this gets applied for the next release.

-- 
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] #6552: django.core.context_processors.auth causes "Vary: Cookie" header no matter what

[Django]

#6552: django.core.context_processors.auth causes "Vary: Cookie" header no 
matter
what
-+--
  Reporter:  o...@iola.dk| Owner:  lukeplant
Status:  reopened| Milestone:   
 Component:  Authentication  |   Version:  SVN  
Resolution:  |  Keywords:   
 Stage:  Accepted| Has_patch:  1
Needs_docs:  1   |   Needs_tests:  0
Needs_better_patch:  0   |  
-+--
Changes (by intrepidweb):

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

Comment:

 Hi -- I am not sure if this is related, but I want to report it in case. I
 recently had a problem with the Vary:Cookie header unexpectedly being
 added to my responses. I scoured my code for unintentional accessing of
 the session. I couldn't find anything. Eventually through testing I
 pinpointed the auth context processor
 (django.contrib.auth.context_processors.auth) as the source of the
 problem. My temporary fix was to comment out the 'messages' assignment in
 the dict returned by the processor. That did the trick; now the
 Vary:Cookie header is only being added when the session is indeed
 accessed. Any ideas of what's going on? Should get_messages perhaps be
 lazily accessed, just like get_user?

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #6994: Files created by FastCGI server are world-writable

[Django]

#6994: Files created by FastCGI server are world-writable
--+-
  Reporter:  Antonis Christofides   | 
Owner:  nobody
Status:  closed   | 
Milestone:
 Component:  django-admin.py  |   
Version:  SVN   
Resolution:  fixed|  
Keywords:
 Stage:  Ready for checkin| 
Has_patch:  1 
Needs_docs:  1|   
Needs_tests:  0 
Needs_better_patch:  0|  
--+-
Changes (by aptiko):

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

Comment:

 I am not absolutely certain of the trac workflow used in Django, but in
 most software projects we don't reopen fixed bugs when the fix turns out
 to be buggy; instead, we file new bugs. The original bug was that the
 files are world-writeable, whereas the new bug is that the new
 configuration option does not work properly.

 Therefore, please file this as a new bug (and CC me since I'm the author
 of the buggy code).

-- 
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] #12420: "OneToOneField doesn't allow assignment of None"

[Django]

#12420: "OneToOneField doesn't allow assignment of None"
---+
  Reporter:  kbrownlees| Owner:  andrewsk
Status:  closed| Milestone:  1.2 
 Component:  Database layer (models, ORM)  |   Version:  SVN 
Resolution:  fixed |  Keywords:  
 Stage:  Ready for checkin | Has_patch:  1   
Needs_docs:  0 |   Needs_tests:  0   
Needs_better_patch:  0 |  
---+
Changes (by andrewsk):

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

Comment:

 @gsakkis - bob.soul from your example is a reverse relation.
 Person table doesn't actually have soul_id. So, the way Django deals with
 it,
 if you assign an instance of Soul (i.e. bobs_soul) to bob.soul, it
 modifies bobs_soul.person_id,
 so it will be equal to bob.id (line 258). But, then you still need to save
 "bobs_soul" object, not
 "bob". Which might be a bit counter intuitive, because it looks like we
 are trying to modify "bob"
 object.
 Now in case when we are trying to assign None, to bob.soul, it fails to
 modify assigned value, obviously,
 because it is not an instance of a Soul.
 If our intention is to severe the relation between objects, we can
 speculate about two approaches here:

   1. Check for the fact that the value is None, and don't do anything.
   But in this case assignment of None wouldn't change anything after
 saving any of our object to db.
   (So we didn't reach our goal)
   2. Retrieve previous value of "bobs_soul" and modify it's place_id to be
 None.
   The problem here is that we will be creating new instance of
 "bobs_soul",
   then modifying it, but it wouldn't be available outside of the
 descriptor. So, there is no way to save this
   newly created instance. (Unless we will be in fact modifying object from
 related object's cache, and this object
   is still referenced by user. Like in your example, you have bobs_soul
 created before, so with the second approach
   user will be able to do bobs_soul.save() after bob.soul=None, and it
 will break the relation)

 Both of these approaches doesn't allow us to break the relation between
 objects. So, maybe the best way is not to allow assignment
 on the reverse relation attribute for OneToOneField, or do not allow
 assignment of None, with proper error message, telling that
 an assignment should be performed on the other end.

 Anyways. The original intention of this ticket was to fix the bug which
 didn't allow to assign None to OneToOneFields in model forms.
 In my opinion, the issue with reverse relation attribute should be moved
 to a separate ticket.

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

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

Re: [Django] #14349: Add Belgium (be) localflavor

[Django]

#14349: Add Belgium (be) localflavor
-+--
  Reporter:  laurentluce | Owner:  laurentluce  
  
Status:  assigned| Milestone:  1.3  
  
 Component:  django.contrib.localflavor  |   Version:  SVN  
  
Resolution:  |  Keywords:  localflavor 
belgium
 Stage:  Accepted| Has_patch:  1
  
Needs_docs:  0   |   Needs_tests:  0
  
Needs_better_patch:  1   |  
-+--
Changes (by russellm):

  * needs_better_patch:  0 => 1

Comment:

 We're in the process of trying to purge the doctests from our test suite.
 We're trying to avoid adding doctests if at all possible, and doctests for
 completely new functionality are one of those things that are easy to
 avoid.

-- 
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] #14349: Add Belgium (be) localflavor

[Django]

#14349: Add Belgium (be) localflavor
-+--
  Reporter:  laurentluce | Owner:  laurentluce  
  
Status:  assigned| Milestone:  1.3  
  
 Component:  django.contrib.localflavor  |   Version:  SVN  
  
Resolution:  |  Keywords:  localflavor 
belgium
 Stage:  Accepted| Has_patch:  1
  
Needs_docs:  0   |   Needs_tests:  0
  
Needs_better_patch:  0   |  
-+--
Comment (by gvangool):

 One more thing, you might want to switch from doctests to unittests.
 It has come up on the mailing list once before in a
 [http://groups.google.com/group/django-developers/msg/2ee447a82d0f0fb9
 message from Alex].

-- 
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] #14353: unique_together new style is not working properly

[Django]

#14353: unique_together new style is not working properly
+---
  Reporter:  draxus | Owner:  nobody 
Status:  closed | Milestone: 
 Component:  Uncategorized  |   Version:  1.2
Resolution:  worksforme |  Keywords:  unique, restriction
 Stage:  Unreviewed | Has_patch:  0  
Needs_docs:  0  |   Needs_tests:  0  
Needs_better_patch:  0  |  
+---
Comment (by draxus):

 Today is working in both ways. What a mistery...

 I will reopen this ticket if it happens again. Thank you very much for
 your answer.

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