Re: [Django] #14689: AUTH_USER_PROFILE setting not parsed correctly.

[Django]

#14689: AUTH_USER_PROFILE setting not parsed correctly.
---+
  Reporter:  twoolie   | Owner:  nobody   
Status:  closed| Milestone:   
 Component:  Contrib apps  |   Version:  1.2  
Resolution:  invalid   |  Keywords:  AUTH_USER_PROFILE
 Stage:  Unreviewed| Has_patch:  1
Needs_docs:  0 |   Needs_tests:  0
Needs_better_patch:  0 |  
---+
Changes (by twoolie):

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

Comment:

 Nevermind, i figured out why this behavior is ok.

-- 
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] #14689: AUTH_USER_PROFILE setting not parsed correctly.

[Django]

#14689: AUTH_USER_PROFILE setting not parsed correctly.
---+
 Reporter:  twoolie|   Owner:  nobody
   Status:  new|   Milestone:
Component:  Contrib apps   | Version:  1.2   
 Keywords:  AUTH_USER_PROFILE  |   Stage:  Unreviewed
Has_patch:  1  |  
---+
 currently the behavior  of AUTH_USER_PROFILE does not allow for imported
 profiles from a packaged distribution.
 e.g. i have downloaded sphene community tools and i wish to set
 AUTH_PROFILE_MODULE = 'sphene.community.CommunityUserProfile'

 The current code at 
 {{{
 try:
 app_label, model_name = settings.AUTH_PROFILE_MODULE.split('.')
 except ValueError:
 raise SiteProfileNotAvailable('app_label and model_name should'
 ' be separated by a dot in the AUTH_PROFILE_MODULE set'
 'ting')
 }}}
 this does not take into account that app_label can itself be dot-
 delimited.

 I propose the following patch.
 {{{
 try:
 path = settings.AUTH_PROFILE_MODULE.split('.')
 app_label = ".".join(path[0:-1])
 model_name = path[-1]
 except ValueError:
 raise SiteProfileNotAvailable('app_label and model_name should'
 ' be separated by a dot in the AUTH_PROFILE_MODULE set'
 'ting')
 }}}

-- 
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] #13283: CACHE_MIDDLEWARE_ANONYMOUS_ONLY kills anonymous caching efficiency

[Django]

#13283: CACHE_MIDDLEWARE_ANONYMOUS_ONLY kills anonymous caching efficiency
---+
  Reporter:  carljm| Owner:  nobody 
 
Status:  new   | Milestone: 
 
 Component:  Cache system  |   Version:  SVN
 
Resolution:|  Keywords:  session accessed vary 
cookie
 Stage:  Accepted  | Has_patch:  1  
 
Needs_docs:  0 |   Needs_tests:  0  
 
Needs_better_patch:  1 |  
---+
Comment (by natrius):

 Carl, I added a modified version of your test from the patch, which caught
 an issue I hadn't seen. It's in the pull request.

-- 
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] #14529: Save messages for proxy models show a crazy verbose_name

[Django]

#14529: Save messages for proxy models show a crazy verbose_name
---+
  Reporter:  rlaa...@wiktel.com| Owner:  nobody
Status:  new   | Milestone:  1.3   
 Component:  django.contrib.admin  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  1 
Needs_better_patch:  1 |  
---+
Changes (by rasca):

  * needs_better_patch:  0 => 1
  * stage:  Unreviewed => Accepted
  * version:  1.2 => SVN
  * milestone:  => 1.3

Comment:

 Okay, I can confirm this happens in 1.2 and in trunk.
 I've applied the patch but it solves this partially. Also, I'm not sure
 that's the best approach.

 When you don't define a {{{__unicode__()}}} it shows
 {{{"whatever"_Deferred_"fields" object}}} in the changelist's list always.

-- 
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] #14688: BaseInlineFormSet does not support "auto_id"

[Django]

#14688: BaseInlineFormSet does not support "auto_id"
---+
 Reporter:  vicvicvic  |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Forms  | Version:  SVN   
 Keywords:  formsets   |   Stage:  Unreviewed
Has_patch:  1  |  
---+
 `BaseInlineFormSet.__init__` does not accept the `auto_id` argument,
 unlike its ancestors. Furthmore, its parent `BaseModelFormSet` takes
 `**kwargs` and passes them along.

 I can't think of a good reason for this omission/difference. I've attached
 a small patch to "match" `BaseInlineFormSet.__init__` with
 `BaseModelFormSet.__init__`. The patch puts the "new" `auto_id` argument
 last in order to maximize backwards compatibility (the order is different
 for `BaseModelFormSet`).

 Arguably, both `prefix` and `auto_id` could be removed from the explicit
 arg list since they're just passed along (in both `BaseModelFormSet` and
 `BaseInlineFormSet`).

-- 
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] #14682: Class based views docs should be more explicit about template location

[Django]

#14682: Class based views docs should be more explicit about template location
+---
  Reporter:  PaulM  | 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  |  
+---
Changes (by gabrielhurley):

  * 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] #10414: select_related ignores unrecognized fields

[Django]

#10414: select_related ignores unrecognized fields
---+
  Reporter:  trebor74hr| Owner:  trebor74hr 
   
Status:  assigned  | Milestone:  1.3
   
 Component:  Database layer (models, ORM)  |   Version: 
   
Resolution:|  Keywords:  
select_related
 Stage:  Design decision needed| Has_patch:  1  
   
Needs_docs:  0 |   Needs_tests:  0  
   
Needs_better_patch:  0 |  
---+
Comment (by mtredinnick):

 I found some old (handwritten) notes I had around this item from back in
 2007. Introducing `select_related()` functionality for specific fields was
 a measurable performance impact (lots more introspection of models to
 construct the queryset). Avoiding yet another check against the list of
 available fields sped this up slightly. Being fast for correct code is (at
 least was) more important than catching every possible way somebody can
 fumble-finger something. Execution speed on the Python side unfortunately
 slowed down further since those days, so this might now disappear into the
 noise.

-- 
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] #14687: Proxy model inheritance and DoesNotExist exception

[Django]

#14687: Proxy model inheritance and DoesNotExist exception
---+
  Reporter:  vladimir_webdev   | Owner:  nobody 
  
Status:  closed| Milestone: 
  
 Component:  Database layer (models, ORM)  |   Version:  1.3-alpha  
  
Resolution:  worksforme|  Keywords:  proxy 
model, DoesNotExist
 Stage:  Unreviewed| Has_patch:  0  
  
Needs_docs:  0 |   Needs_tests:  0  
  
Needs_better_patch:  0 |  
---+
Changes (by rasca):

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

Comment:

 Neither do I... closing it as worksforme

-- 
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] #14591: UnicodeDecodeError when trying to render the label of a field

[Django]

#14591: UnicodeDecodeError when trying to render the label of a field
-+--
  Reporter:  panosl  | Owner:  nobody 
Status:  reopened| Milestone: 
 Component:  django.contrib.admin|   Version:  1.2
Resolution:  |  Keywords:  unicode
 Stage:  Design decision needed  | Has_patch:  1  
Needs_docs:  0   |   Needs_tests:  1  
Needs_better_patch:  0   |  
-+--
Changes (by rasca):

  * needs_tests:  0 => 1
  * stage:  Unreviewed => Design decision needed

Comment:

 Okey, I get the error now. It wont happen if you use {{{ugettext_lazy}}}
 instead of {{{gettext_lazy}}}.

 I'm marking it as DDN, cause I'm not sure if this should be accepted or
 not to preserve consistency.

-- 
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] #14687: Proxy model inheritance and DoesNotExist exception

[Django]

#14687: Proxy model inheritance and DoesNotExist exception
---+
  Reporter:  vladimir_webdev   | Owner:  nobody 
  
Status:  new   | Milestone: 
  
 Component:  Database layer (models, ORM)  |   Version:  1.3-alpha  
  
Resolution:|  Keywords:  proxy 
model, DoesNotExist
 Stage:  Unreviewed| Has_patch:  0  
  
Needs_docs:  0 |   Needs_tests:  0  
  
Needs_better_patch:  0 |  
---+
Comment (by mattmcc):

 I can't reproduce this in 1.2 or trunk.

 {{{
 >>> from tst.models import MyProxyModel
 >>> MyProxyModel.objects.all()
 []
 >>> try:
 ... MyProxyModel.get_current()
 ... except MyProxyModel.DoesNotExist:
 ... pass
 ...
 >>>
 }}}

-- 
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] #14623: DateTimeField(auto_now=True) does not change when update is called

[Django]

#14623: DateTimeField(auto_now=True) does not change when update is called
---+
  Reporter:  mklauber  | Owner:  nobody 
   
Status:  closed| Milestone:  1.3
   
 Component:  Database layer (models, ORM)  |   Version:  1.2
   
Resolution:  invalid   |  Keywords:  
DateTimeField auto_now
 Stage:  Accepted  | Has_patch:  0  
   
Needs_docs:  0 |   Needs_tests:  0  
   
Needs_better_patch:  0 |  
---+
Changes (by lukeplant):

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

Comment:

 I really don't think that the docs for
 [http://docs.djangoproject.com/en/dev/ref/models/querysets/#update-kwargs
 update()] would give you the expectations you describe. It is very clear
 that it works on the level of an SQL update and the save() method is not
 called, and the docs for `DateTimeField` are equally clear that auto_now
 is applied when the object is saved. Django has DB access code on several
 levels, and we cannot add caveats for every single low level operation in
 the docs for every single high level operation.

-- 
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] r14565 - in django/branches/releases/1.2.X: django/core/management django/utils tests/modeltests/invalid_models

[noreply]

Author: ramiro
Date: 2010-11-14 17:36:40 -0600 (Sun, 14 Nov 2010)
New Revision: 14565

Modified:
   django/branches/releases/1.2.X/django/core/management/validation.py
   django/branches/releases/1.2.X/django/utils/itercompat.py
   django/branches/releases/1.2.X/tests/modeltests/invalid_models/models.py
Log:
[1.2.X] Fixed #3055 -- Validate that models target of a GenericRelation have a 
GenericForeignKey field.

Thanks jason for diagnosing the problem and Marcos Moyano for the patch.

Backport of [14563] from trunk

Modified: django/branches/releases/1.2.X/django/core/management/validation.py
===
--- django/branches/releases/1.2.X/django/core/management/validation.py 
2010-11-14 23:35:16 UTC (rev 14564)
+++ django/branches/releases/1.2.X/django/core/management/validation.py 
2010-11-14 23:36:40 UTC (rev 14565)
@@ -1,7 +1,14 @@
 import sys
+
+from django.contrib.contenttypes.generic import GenericForeignKey, 
GenericRelation
 from django.core.management.color import color_style
 from django.utils.itercompat import is_iterable
 
+try:
+any
+except NameError:
+from django.utils.itercompat import any
+
 class ModelErrorCollection:
 def __init__(self, outfile=sys.stdout):
 self.errors = []
@@ -216,6 +223,12 @@
 e.add(opts, "'%s' specifies an m2m relation through model %s, "
 "which has not been installed" % (f.name, f.rel.through)
 )
+elif isinstance(f, GenericRelation):
+if not any([isinstance(vfield, GenericForeignKey) for vfield 
in f.rel.to._meta.virtual_fields]):
+e.add(opts, "Model '%s' must have a GenericForeignKey in "
+"order to create a GenericRelation that points to it."
+% f.rel.to.__name__
+)
 
 rel_opts = f.rel.to._meta
 rel_name = RelatedObject(f.rel.to, cls, f).get_accessor_name()

Modified: django/branches/releases/1.2.X/django/utils/itercompat.py
===
--- django/branches/releases/1.2.X/django/utils/itercompat.py   2010-11-14 
23:35:16 UTC (rev 14564)
+++ django/branches/releases/1.2.X/django/utils/itercompat.py   2010-11-14 
23:36:40 UTC (rev 14565)
@@ -37,3 +37,9 @@
 if not item:
 return False
 return True
+
+def any(iterable):
+for item in iterable:
+if item:
+return True
+return False

Modified: 
django/branches/releases/1.2.X/tests/modeltests/invalid_models/models.py
===
--- django/branches/releases/1.2.X/tests/modeltests/invalid_models/models.py
2010-11-14 23:35:16 UTC (rev 14564)
+++ django/branches/releases/1.2.X/tests/modeltests/invalid_models/models.py
2010-11-14 23:36:40 UTC (rev 14565)
@@ -4,6 +4,7 @@
 This example exists purely to point out errors in models.
 """
 
+from django.contrib.contenttypes import generic
 from django.db import models
 
 class FieldErrors(models.Model):
@@ -210,6 +211,21 @@
 class Meta:
 ordering = ("does_not_exist",)
 
+class Tag(models.Model):
+   name = models.CharField("name", max_length=20)
+
+class TaggedObject(models.Model):
+   object_id = models.PositiveIntegerField("Object ID")
+   tag = models.ForeignKey(Tag)
+   content_object = generic.GenericForeignKey()
+
+class UserTaggedObject(models.Model):
+   object_tag = models.ForeignKey(TaggedObject)
+
+class ArticleAttachment(models.Model):
+   tags = generic.GenericRelation(TaggedObject)
+   user_tags = generic.GenericRelation(UserTaggedObject)
+
 model_errors = """invalid_models.fielderrors: "charfield": CharFields require 
a "max_length" attribute that is a positive integer.
 invalid_models.fielderrors: "charfield2": CharFields require a "max_length" 
attribute that is a positive integer.
 invalid_models.fielderrors: "charfield3": CharFields require a "max_length" 
attribute that is a positive integer.
@@ -315,4 +331,5 @@
 invalid_models.nonuniquefktarget1: Field 'bad' under model 'FKTarget' must 
have a unique=True constraint.
 invalid_models.nonuniquefktarget2: Field 'bad' under model 'FKTarget' must 
have a unique=True constraint.
 invalid_models.nonexistingorderingwithsingleunderscore: "ordering" refers to 
"does_not_exist", a field that doesn't exist.
+invalid_models.articleattachment: Model 'UserTaggedObject' must have a 
GenericForeignKey in order to create a GenericRelation that points to it.
 """

-- 
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] r14564 - in django/trunk/django/contrib/sessions: . backends

[noreply]

Author: lukeplant
Date: 2010-11-14 17:35:16 -0600 (Sun, 14 Nov 2010)
New Revision: 14564

Modified:
   django/trunk/django/contrib/sessions/backends/db.py
   django/trunk/django/contrib/sessions/models.py
Log:
Fixed potential circular import problem.

Modified: django/trunk/django/contrib/sessions/backends/db.py
===
--- django/trunk/django/contrib/sessions/backends/db.py 2010-11-14 23:21:39 UTC 
(rev 14563)
+++ django/trunk/django/contrib/sessions/backends/db.py 2010-11-14 23:35:16 UTC 
(rev 14564)
@@ -1,11 +1,11 @@
 import datetime
 from django.conf import settings
-from django.contrib.sessions.models import Session
 from django.contrib.sessions.backends.base import SessionBase, CreateError
 from django.core.exceptions import SuspiciousOperation
 from django.db import IntegrityError, transaction, router
 from django.utils.encoding import force_unicode
 
+
 class SessionStore(SessionBase):
 """
 Implements database session store.
@@ -76,3 +76,7 @@
 Session.objects.get(session_key=session_key).delete()
 except Session.DoesNotExist:
 pass
+
+
+# At bottom to avoid circular import
+from django.contrib.sessions.models import Session

Modified: django/trunk/django/contrib/sessions/models.py
===
--- django/trunk/django/contrib/sessions/models.py  2010-11-14 23:21:39 UTC 
(rev 14563)
+++ django/trunk/django/contrib/sessions/models.py  2010-11-14 23:35:16 UTC 
(rev 14564)
@@ -4,6 +4,7 @@
 from django.db import models
 from django.utils.translation import ugettext_lazy as _
 
+
 class SessionManager(models.Manager):
 def encode(self, session_dict):
 """
@@ -51,4 +52,6 @@
 def get_decoded(self):
 return SessionStore().decode(self.session_data)
 
+
+# At bottom to avoid circular import
 from django.contrib.sessions.backends.db import SessionStore

-- 
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] #3055: GenericRelation should squawk if pointed to a model that doesn't have a GenericForeignKey on it

[Django]

#3055: GenericRelation should squawk if pointed to a model that doesn't have a
GenericForeignKey on it
---+
  Reporter:  pa...@elasticworld.org| Owner:  
marcosmoyano
Status:  closed| Milestone: 
 
 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 ramiro):

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

Comment:

 Fixed in r14563.

-- 
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] r14563 - in django/trunk: django/core/management django/utils tests/modeltests/invalid_models

[noreply]

Author: ramiro
Date: 2010-11-14 17:21:39 -0600 (Sun, 14 Nov 2010)
New Revision: 14563

Modified:
   django/trunk/django/core/management/validation.py
   django/trunk/django/utils/itercompat.py
   django/trunk/tests/modeltests/invalid_models/models.py
Log:
Fiexed #3055 -- Validate that models target of a GenericRelation have a 
GenericForeignKey field.

Thanks jason for diagnosing the problem and Marcos Moyano for the patch.

Modified: django/trunk/django/core/management/validation.py
===
--- django/trunk/django/core/management/validation.py   2010-11-14 22:23:46 UTC 
(rev 14562)
+++ django/trunk/django/core/management/validation.py   2010-11-14 23:21:39 UTC 
(rev 14563)
@@ -1,7 +1,14 @@
 import sys
+
+from django.contrib.contenttypes.generic import GenericForeignKey, 
GenericRelation
 from django.core.management.color import color_style
 from django.utils.itercompat import is_iterable
 
+try:
+any
+except NameError:
+from django.utils.itercompat import any
+
 class ModelErrorCollection:
 def __init__(self, outfile=sys.stdout):
 self.errors = []
@@ -224,6 +231,12 @@
 e.add(opts, "'%s' specifies an m2m relation through model %s, "
 "which has not been installed" % (f.name, f.rel.through)
 )
+elif isinstance(f, GenericRelation):
+if not any([isinstance(vfield, GenericForeignKey) for vfield 
in f.rel.to._meta.virtual_fields]):
+e.add(opts, "Model '%s' must have a GenericForeignKey in "
+"order to create a GenericRelation that points to it."
+% f.rel.to.__name__
+)
 
 rel_opts = f.rel.to._meta
 rel_name = RelatedObject(f.rel.to, cls, f).get_accessor_name()

Modified: django/trunk/django/utils/itercompat.py
===
--- django/trunk/django/utils/itercompat.py 2010-11-14 22:23:46 UTC (rev 
14562)
+++ django/trunk/django/utils/itercompat.py 2010-11-14 23:21:39 UTC (rev 
14563)
@@ -37,3 +37,9 @@
 if not item:
 return False
 return True
+
+def any(iterable):
+for item in iterable:
+if item:
+return True
+return False

Modified: django/trunk/tests/modeltests/invalid_models/models.py
===
--- django/trunk/tests/modeltests/invalid_models/models.py  2010-11-14 
22:23:46 UTC (rev 14562)
+++ django/trunk/tests/modeltests/invalid_models/models.py  2010-11-14 
23:21:39 UTC (rev 14563)
@@ -4,6 +4,7 @@
 This example exists purely to point out errors in models.
 """
 
+from django.contrib.contenttypes import generic
 from django.db import models
 
 class FieldErrors(models.Model):
@@ -216,7 +217,21 @@
 class InvalidSetDefault(models.Model):
 fk = models.ForeignKey('self', on_delete=models.SET_DEFAULT)
 
+class Tag(models.Model):
+   name = models.CharField("name", max_length=20)
 
+class TaggedObject(models.Model):
+   object_id = models.PositiveIntegerField("Object ID")
+   tag = models.ForeignKey(Tag)
+   content_object = generic.GenericForeignKey()
+
+class UserTaggedObject(models.Model):
+   object_tag = models.ForeignKey(TaggedObject)
+
+class ArticleAttachment(models.Model):
+   tags = generic.GenericRelation(TaggedObject)
+   user_tags = generic.GenericRelation(UserTaggedObject)
+
 model_errors = """invalid_models.fielderrors: "charfield": CharFields require 
a "max_length" attribute that is a positive integer.
 invalid_models.fielderrors: "charfield2": CharFields require a "max_length" 
attribute that is a positive integer.
 invalid_models.fielderrors: "charfield3": CharFields require a "max_length" 
attribute that is a positive integer.
@@ -324,4 +339,5 @@
 invalid_models.nonexistingorderingwithsingleunderscore: "ordering" refers to 
"does_not_exist", a field that doesn't exist.
 invalid_models.invalidsetnull: 'fk' specifies on_delete=SET_NULL, but cannot 
be null.
 invalid_models.invalidsetdefault: 'fk' specifies on_delete=SET_DEFAULT, but 
has no default value.
+invalid_models.articleattachment: Model 'UserTaggedObject' must have a 
GenericForeignKey in order to create a GenericRelation that points to it.
 """

-- 
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] #14591: UnicodeDecodeError when trying to render the label of a field

[Django]

#14591: UnicodeDecodeError when trying to render the label of a field
---+
  Reporter:  panosl| Owner:  nobody 
Status:  reopened  | Milestone: 
 Component:  django.contrib.admin  |   Version:  1.2
Resolution:|  Keywords:  unicode
 Stage:  Unreviewed| Has_patch:  1  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Comment (by panosl):

 Hey Rasca, please don't hate me :)

 I was mistaken, since the error was coming from the verbose_name, rather
 than the translation of the field, 'cause of course when you don't set any
 list options, the only  that shows up is the model's name.

 I've made a demo project/app for you to see first hand.

 Download it from http://panos.solhost.org/temp/uerror_project.tar.gz

 admin credentials are: admin/pass

 visit the admin page for uerror app, and you'll see the error.

 Sorry for wasting your time prior to this, I should have done this from
 the start, but I've nailed it for you (hopefully), let me know if you need
 any other info.

-- 
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] #14153: Redirects fail if URL has appended query string

[Django]

#14153: Redirects fail if URL has appended query string
-+--
  Reporter:  richardb| Owner:  nobody  
Status:  closed  | Milestone:  
 Component:  Contrib apps|   Version:  1.2 
Resolution:  invalid |  Keywords:  redirect
 Stage:  Design decision needed  | Has_patch:  0   
Needs_docs:  0   |   Needs_tests:  1   
Needs_better_patch:  0   |  
-+--
Changes (by lukeplant):

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

Comment:

 For the reason given by dmoisset, and for backwards compatibility for
 people relying on current behaviour, I'm going to close as INVALID. At the
 moment, if you want the query string to be ignored you'll have to roll
 your own.  A setting is not good solution for this, since you might have a
 mixture of cases where you want the query string and where you don't. A
 fuller solution would almost certainly require changes to the model, and
 we don't have a migration framework to support that.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #13879: method_decorator doesn't supports decorators with arguments

[Django]

#13879: method_decorator doesn't supports decorators with arguments
+---
  Reporter:  marinho| Owner:  nobody 
Status:  new| Milestone:  1.3
 Component:  Uncategorized  |   Version:  1.2
Resolution: |  Keywords:  sprintnov13, decorators
 Stage:  Accepted   | Has_patch:  0  
Needs_docs:  0  |   Needs_tests:  0  
Needs_better_patch:  0  |  
+---
Changes (by lukeplant):

  * stage:  Design decision needed => Accepted

Comment:

 Technically, `method_decorator` works as advertised. `permission_required`
 is not actually a decorator. `permission_required('spam.more_eggs')` is a
 decorator, and `permission_required` is a decorator ''generator'' (it
 returns a decorator when you call it with some arguments).

 But I agree that the goal set out lrekucki is a good one, and that a
 `method_decorator_with_args` (or some better name) would be desirable, and
 that the OP's solution is not a good idea.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] r14562 - django/trunk/django/contrib/sessions

[noreply]

Author: lukeplant
Date: 2010-11-14 16:23:46 -0600 (Sun, 14 Nov 2010)
New Revision: 14562

Modified:
   django/trunk/django/contrib/sessions/models.py
   django/trunk/django/contrib/sessions/tests.py
Log:
Fixed #14685 - incompatible code in contrib.sessions.models

Thanks to PaulM for the report.

Modified: django/trunk/django/contrib/sessions/models.py
===
--- django/trunk/django/contrib/sessions/models.py  2010-11-14 15:50:01 UTC 
(rev 14561)
+++ django/trunk/django/contrib/sessions/models.py  2010-11-14 22:23:46 UTC 
(rev 14562)
@@ -3,18 +3,13 @@
 
 from django.db import models
 from django.utils.translation import ugettext_lazy as _
-from django.conf import settings
-from django.utils.hashcompat import md5_constructor
 
-
 class SessionManager(models.Manager):
 def encode(self, session_dict):
 """
 Returns the given session dictionary pickled and encoded as a string.
 """
-pickled = pickle.dumps(session_dict)
-pickled_md5 = md5_constructor(pickled + 
settings.SECRET_KEY).hexdigest()
-return base64.encodestring(pickled + pickled_md5)
+return SessionStore().encode(session_dict)
 
 def save(self, session_key, session_dict, expire_date):
 s = self.model(session_key, self.encode(session_dict), expire_date)
@@ -54,14 +49,6 @@
 verbose_name_plural = _('sessions')
 
 def get_decoded(self):
-encoded_data = base64.decodestring(self.session_data)
-pickled, tamper_check = encoded_data[:-32], encoded_data[-32:]
-if md5_constructor(pickled + settings.SECRET_KEY).hexdigest() != 
tamper_check:
-from django.core.exceptions import SuspiciousOperation
-raise SuspiciousOperation("User tampered with session cookie.")
-try:
-return pickle.loads(pickled)
-# Unpickling can cause a variety of exceptions. If something happens,
-# just return an empty dictionary (an empty session).
-except:
-return {}
+return SessionStore().decode(self.session_data)
+
+from django.contrib.sessions.backends.db import SessionStore

Modified: django/trunk/django/contrib/sessions/tests.py
===
--- django/trunk/django/contrib/sessions/tests.py   2010-11-14 15:50:01 UTC 
(rev 14561)
+++ django/trunk/django/contrib/sessions/tests.py   2010-11-14 22:23:46 UTC 
(rev 14562)
@@ -263,7 +263,34 @@
 
 backend = DatabaseSession
 
+def test_session_get_decoded(self):
+"""
+Test we can use Session.get_decoded to retrieve data stored
+in normal way
+"""
+self.session['x'] = 1
+self.session.save()
 
+s = Session.objects.get(session_key=self.session.session_key)
+
+self.assertEqual(s.get_decoded(), {'x': 1})
+
+def test_sessionmanager_save(self):
+"""
+Test SessionManager.save method
+"""
+# Create a session
+self.session['y'] = 1
+self.session.save()
+
+s = Session.objects.get(session_key=self.session.session_key)
+# Change it
+Session.objects.save(s.session_key, {'y':2}, s.expire_date)
+# Clear cache, so that it will be retrieved from DB
+del self.session._session_cache
+self.assertEqual(self.session['y'], 2)
+
+
 class CacheDBSessionTests(SessionTestsMixin, TestCase):
 
 backend = CacheDBSession

-- 
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] #14685: contrib.sessions.models has incompatible or extraneous code

[Django]

#14685: contrib.sessions.models has incompatible or extraneous code
--+-
  Reporter:  PaulM| Owner:  nobody
Status:  new  | Milestone:  1.3   
 Component:  django.contrib.sessions  |   Version:  1.2   
Resolution:   |  Keywords:
 Stage:  Unreviewed   | Has_patch:  0 
Needs_docs:  0|   Needs_tests:  0 
Needs_better_patch:  0|  
--+-
Changes (by lukeplant):

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

Comment:

 The code appears to support the API for
 [http://docs.djangoproject.com/en/dev/topics/http/sessions/#using-
 sessions-out-of-views using sessions outside of views] - which is
 documented but completely untested. It's possible that no-one . I'll
 commit a fix shortly.

 Thanks for the catch.

-- 
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] #14687: Proxy model inheritance and DoesNotExist exception

[Django]

#14687: Proxy model inheritance and DoesNotExist exception
---+
  Reporter:  vladimir_webdev   | Owner:  nobody 
  
Status:  new   | Milestone: 
  
 Component:  Database layer (models, ORM)  |   Version:  1.3-alpha  
  
Resolution:|  Keywords:  proxy 
model, DoesNotExist
 Stage:  Unreviewed| Has_patch:  0  
  
Needs_docs:  0 |   Needs_tests:  0  
  
Needs_better_patch:  0 |  
---+
Changes (by vladimir_webdev):

 * cc: vladimir.web...@gmail.com (added)
  * component:  Uncategorized => Database layer (models, ORM)

-- 
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] #14687: Proxy model inheritance and DoesNotExist exception

[Django]

#14687: Proxy model inheritance and DoesNotExist exception
--+-
  Reporter:  vladimir_webdev  | Owner:  nobody  
 
Status:  new  | Milestone:  
 
 Component:  Uncategorized|   Version:  1.3-alpha   
 
Resolution:   |  Keywords:  proxy model, 
DoesNotExist
 Stage:  Unreviewed   | Has_patch:  0   
 
Needs_docs:  0|   Needs_tests:  0   
 
Needs_better_patch:  0|  
--+-
Changes (by vladimir_webdev):

  * needs_better_patch:  => 0
  * version:  1.2 => 1.3-alpha
  * 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] #14687: Proxy model inheritance and DoesNotExist exception

[Django]

#14687: Proxy model inheritance and DoesNotExist exception
---+
 Reporter:  vladimir_webdev|   Owner:  nobody
   Status:  new|   Milestone:
Component:  Uncategorized  | Version:  1.2   
 Keywords:  proxy model, DoesNotExist  |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 Code example:

 {{{
 class MyModel(models.Model):
 @classmethod
 def get_current(self):
 self.objects.filter(pk=1).get()

 class MyProxyModel(MyModel):
 class Meta:
 proxy = True

 try:
 current = MyProxyModel,get_current()
 except MyProxyModel.DoesNotExist: # will never be caught, because
 MyModel.DoesNotExist is actually raised
 pass
 }}}

 To fix this behaviour I simply overwrite exception as this:

 {{{
 MyProxyModel.DoesNotExist = MyModel.DoesNotExist
 }}}

-- 
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] #14663: L10N of dates in Norwegian.

[Django]

#14663: L10N of dates in Norwegian.
---+
  Reporter:  nfg   | Owner:  nobody 
   
Status:  new   | Milestone:  1.3
   
 Component:  Internationalization  |   Version:  1.2
   
Resolution:|  Keywords:  l10n norwegian 
formats
 Stage:  Accepted  | Has_patch:  1  
   
Needs_docs:  0 |   Needs_tests:  0  
   
Needs_better_patch:  0 |  
---+
Comment (by rasca):

 Someone who knows Norwegian other than the patch uploader should check
 this patch, and if it's okey mark it as 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] #13937: Sub-query (exclude) fails when joining

[Django]

#13937: Sub-query (exclude) fails when joining
---+
  Reporter:  subsume   | Owner: 
Status:  new   | Milestone: 
 Component:  Database layer (models, ORM)  |   Version:  1.2
Resolution:|  Keywords: 
 Stage:  Unreviewed| Has_patch:  0  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Changes (by k0001):

  * owner:  k0001 =>

Comment:

 Could you tell a bit more about your scenario? Please provide some sample
 models, your expected results and your actual results.

 Appart from —needlessly? I'm not sure— checking if the Primary Key is not
 null, I wonder why would this fail for you.

-- 
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] #14663: L10N of dates in Norwegian.

[Django]

#14663: L10N of dates in Norwegian.
---+
  Reporter:  nfg   | Owner:  nobody 
   
Status:  new   | Milestone:  1.3
   
 Component:  Internationalization  |   Version:  1.2
   
Resolution:|  Keywords:  l10n norwegian 
formats
 Stage:  Accepted  | Has_patch:  1  
   
Needs_docs:  0 |   Needs_tests:  0  
   
Needs_better_patch:  0 |  
---+
Changes (by anonymous):

  * needs_better_patch:  => 0
  * needs_docs:  => 0
  * stage:  Unreviewed => Accepted
  * needs_tests:  => 0
  * 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] #14240: filesizeformat should localize number

[Django]

#14240: filesizeformat should localize number
+---
  Reporter:  David Danier   | Owner:  
anonymous
Status:  assigned   | Milestone:
   
 Component:  Template system|   Version:  
1.2  
Resolution: |  Keywords:
   
 Stage:  Accepted   | Has_patch:  1 
   
Needs_docs:  0  |   Needs_tests:  0 
   
Needs_better_patch:  0  |  
+---
Changes (by David Danier ):

  * needs_tests:  1 => 0

Comment:

 I attached an updated patch including:
  * Use of round() in filesizeformat(). This should be ok, as all numbers
 are converted to float first, so we don't need to handle
 Decimal.quantize().
  * Fix of fallback-output, which is currently not localized ("0 bytes",
 see except, 0 might be singular in some languages or something totally
 different, who knows)
  * Added tests, thanks Russel for the pointer.
  * Updated myself in AUTHORS

 About round(): I think just cutting of the last digits inside
 number_format() should be the intended behaviour. number_format() should
 not care about doing something other than just formatting the number. So
 round() must be called outside of number_format(). Perhaps Django could
 provide some generic round()-function to accomplish differences betweeen
 float and Decimal, but thats definately outside the scope of this ticket
 and number_format.

-- 
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] #14591: UnicodeDecodeError when trying to render the label of a field

[Django]

#14591: UnicodeDecodeError when trying to render the label of a field
---+
  Reporter:  panosl| Owner:  nobody 
Status:  reopened  | Milestone: 
 Component:  django.contrib.admin  |   Version:  1.2
Resolution:|  Keywords:  unicode
 Stage:  Unreviewed| Has_patch:  1  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Changes (by rasca):

 * cc: ras...@hotmail.com (added)

Comment:

 Just tried it in Django 1.2, 1.2.3 and trunk and working fine in all of
 them (python 2.6.6)...

 This is what I did: copied your first snippet to models.py,
 then added {{{admin.site.register(MyModel)}}} to admin.py,
 set the LANGAUGE_CODE to es-ar,
 {{{makemessages -l es_AR}}},
 modified the .po to {{{msgid "name" msgstr "áéíóñúόνομα"}}},
 {{{compilemessages}}}, {{{runserver}}} and entered the admin and it shows
 "Áéíóñúόνομα:" before the name field in the changeform

 It works fine.. can you reproduce the problem in simple steps like this
 ones?

-- 
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] #14018: Introduce class_plural %-substitution placeholder for related_name of ForeignKey/ManyToManyField

[Django]

#14018: Introduce class_plural %-substitution placeholder for related_name of
ForeignKey/ManyToManyField
---+
  Reporter:  puxlit| Owner:  nobody 
   
Status:  new   | Milestone:  1.3
   
 Component:  Database layer (models, ORM)  |   Version:  SVN
   
Resolution:|  Keywords:  
related_name, ManyToManyField, ForeignKey, abstract base class
 Stage:  Design decision needed| Has_patch:  1  
   
Needs_docs:  0 |   Needs_tests:  0  
   
Needs_better_patch:  1 |  
---+
Changes (by lrekucki):

  * needs_better_patch:  0 => 1
  * stage:  Unreviewed => Design decision needed

Comment:

 The patch "as is" surely needs improvement. A simple solution that comes
 to mind would be adding {{{name_plural}}} to Meta. Then
 {{{%(class_plural)}}} could be replaced with that value or with class'
 name with an "s" added. The example above would then look something like
 this:
 {{{

 class Tag(models.Model):
 slug = models.SlugField(max_length=63, unique=True)

 class Post(models.Model):
 slug = models.SlugField(max_length=127, unique=True)
 tags = models.ManyToManyField(Tag,
 related_name='tagged_%(class_plural)s')

 class Meta:
 abstract = True

 class Entry(Post):
 title = models.CharField(max_length=255)
 content = models.TextField()

 class Meta:
 name_plural = "entries" # related attribute will be
 "tagged_entries"
 verbose_name_plural = _("Journal entries")

 class Event(Post):
 summary = models.CharField(max_length=255)
 start_date = models.DateTimeField()
 # related attribute will be "tagged_events"
 }}}

 I don't think much people care about this that much, so it's mostly a
 "nice to have" feature.

-- 
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] r14561 - in django/branches/releases/1.2.X/django/conf: . project_template

[noreply]

Author: ramiro
Date: 2010-11-14 09:50:01 -0600 (Sun, 14 Nov 2010)
New Revision: 14561

Modified:
   django/branches/releases/1.2.X/django/conf/global_settings.py
   django/branches/releases/1.2.X/django/conf/project_template/settings.py
Log:
[1.2.X] Fixed #10650 -- Clarified description of MEDIA_ROOT in setting files. 
Thanks jjconti, tvon, vak, Muhammad Alkarouri and thiggins for their work.

Backport of [14560] from trunk

Modified: django/branches/releases/1.2.X/django/conf/global_settings.py
===
--- django/branches/releases/1.2.X/django/conf/global_settings.py   
2010-11-14 15:42:54 UTC (rev 14560)
+++ django/branches/releases/1.2.X/django/conf/global_settings.py   
2010-11-14 15:50:01 UTC (rev 14561)
@@ -258,7 +258,7 @@
 # Default file storage mechanism that holds media.
 DEFAULT_FILE_STORAGE = 'django.core.files.storage.FileSystemStorage'
 
-# Absolute path to the directory that holds media.
+# Absolute filesystem path to the directory that will hold user uploaded files.
 # Example: "/home/media/media.lawrence.com/"
 MEDIA_ROOT = ''
 

Modified: 
django/branches/releases/1.2.X/django/conf/project_template/settings.py
===
--- django/branches/releases/1.2.X/django/conf/project_template/settings.py 
2010-11-14 15:42:54 UTC (rev 14560)
+++ django/branches/releases/1.2.X/django/conf/project_template/settings.py 
2010-11-14 15:50:01 UTC (rev 14561)
@@ -43,7 +43,7 @@
 # calendars according to the current locale
 USE_L10N = True
 
-# Absolute path to the directory that holds media.
+# Absolute filesystem path to the directory that will hold user uploaded files.
 # Example: "/home/media/media.lawrence.com/"
 MEDIA_ROOT = ''
 

-- 
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] r14560 - in django/trunk/django/conf: . project_template

[noreply]

Author: ramiro
Date: 2010-11-14 09:42:54 -0600 (Sun, 14 Nov 2010)
New Revision: 14560

Modified:
   django/trunk/django/conf/global_settings.py
   django/trunk/django/conf/project_template/settings.py
Log:
Fixed #10650 -- Clarified description of MEDIA_ROOT in setting files. Thanks 
jjconti, tvon, vak, Muhammad Alkarouri and thiggins for their work.

Modified: django/trunk/django/conf/global_settings.py
===
--- django/trunk/django/conf/global_settings.py 2010-11-14 14:15:58 UTC (rev 
14559)
+++ django/trunk/django/conf/global_settings.py 2010-11-14 15:42:54 UTC (rev 
14560)
@@ -255,7 +255,7 @@
 # Default file storage mechanism that holds media.
 DEFAULT_FILE_STORAGE = 'django.core.files.storage.FileSystemStorage'
 
-# Absolute path to the directory that holds media.
+# Absolute filesystem path to the directory that will hold user uploaded files.
 # Example: "/home/media/media.lawrence.com/"
 MEDIA_ROOT = ''
 

Modified: django/trunk/django/conf/project_template/settings.py
===
--- django/trunk/django/conf/project_template/settings.py   2010-11-14 
14:15:58 UTC (rev 14559)
+++ django/trunk/django/conf/project_template/settings.py   2010-11-14 
15:42:54 UTC (rev 14560)
@@ -43,7 +43,7 @@
 # calendars according to the current locale
 USE_L10N = True
 
-# Absolute path to the directory that holds media.
+# Absolute filesystem path to the directory that will hold user uploaded files.
 # Example: "/home/media/media.lawrence.com/media/"
 MEDIA_ROOT = ''
 

-- 
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] #14176: Error raised when using django.contrib.comments.feeds.LatestCommentsFeed

[Django]

#14176: Error raised when using django.contrib.comments.feeds.LatestCommentsFeed
--+-
  Reporter:  psychcf  | Owner:  nobody
Status:  new  | Milestone:
 Component:  django.contrib.comments  |   Version:  1.2   
Resolution:   |  Keywords:
 Stage:  Unreviewed   | Has_patch:  0 
Needs_docs:  0|   Needs_tests:  0 
Needs_better_patch:  0|  
--+-
Comment (by zeth):

 So in other words, you need to use an instance of the class instead of the
 class itself.

 So instead of:

  'comments': LatestCommentFeed,

 You need:

  'comments': LatestCommentFeed(),

 It is a 'gotcha' but not a valid bug. This can be closed.

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

[noreply]

Author: ramiro
Date: 2010-11-14 08:15:58 -0600 (Sun, 14 Nov 2010)
New Revision: 14559

Modified:
   django/trunk/docs/ref/databases.txt
Log:
Fixed #14536 -- Corrected DB connection OPTIONS examples in documentation. 
Thanks denilsonsa for reporting the error.

Modified: django/trunk/docs/ref/databases.txt
===
--- django/trunk/docs/ref/databases.txt 2010-11-14 14:09:52 UTC (rev 14558)
+++ django/trunk/docs/ref/databases.txt 2010-11-14 14:15:58 UTC (rev 14559)
@@ -73,8 +73,8 @@
 the :setting:`OPTIONS` part of your database configuration in
 :setting:`DATABASES`::
 
-OPTIONS = {
-"autocommit": True,
+'OPTIONS': {
+'autocommit': True,
 }
 
 In this configuration, Django still ensures that :ref:`delete()
@@ -325,8 +325,8 @@
 * Another option is to use the ``init_command`` option for MySQLdb prior to
   creating your tables::
 
-  OPTIONS = {
- "init_command": "SET storage_engine=INNODB",
+  'OPTIONS': {
+ 'init_command': 'SET storage_engine=INNODB',
   }
 
   This sets the default storage engine upon connecting to the database.
@@ -489,9 +489,9 @@
 * Increase the default timeout value by setting the ``timeout`` database
   option option::
 
-  OPTIONS = {
+  'OPTIONS': {
   # ...
- "timeout": 20,
+  'timeout': 20,
   # ...
   }
 

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

[noreply]

Author: ramiro
Date: 2010-11-14 08:09:52 -0600 (Sun, 14 Nov 2010)
New Revision: 14558

Modified:
   django/branches/releases/1.2.X/docs/ref/databases.txt
Log:
Fixed #14536 -- Corrected DB connection OPTIONS examples in documentation. 
Thanks denilsonsa for reporting the error.

Modified: django/branches/releases/1.2.X/docs/ref/databases.txt
===
--- django/branches/releases/1.2.X/docs/ref/databases.txt   2010-11-13 
18:43:13 UTC (rev 14557)
+++ django/branches/releases/1.2.X/docs/ref/databases.txt   2010-11-14 
14:09:52 UTC (rev 14558)
@@ -55,8 +55,8 @@
 the :setting:`OPTIONS` part of your database configuration in
 :setting:`DATABASES`::
 
-OPTIONS = {
-"autocommit": True,
+'OPTIONS': {
+'autocommit': True,
 }
 
 In this configuration, Django still ensures that :ref:`delete()
@@ -306,8 +306,8 @@
 * Another option is to use the ``init_command`` option for MySQLdb prior to
   creating your tables::
 
-  OPTIONS = {
- "init_command": "SET storage_engine=INNODB",
+  'OPTIONS': {
+ 'init_command': 'SET storage_engine=INNODB',
   }
 
   This sets the default storage engine upon connecting to the database.
@@ -470,9 +470,9 @@
 * Increase the default timeout value by setting the ``timeout`` database
   option option::
 
-  OPTIONS = {
+  'OPTIONS': {
   # ...
- "timeout": 20,
+  'timeout': 20,
   # ...
   }
 

-- 
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] #14332: manage testserver and manage runserver should have similiar address:port options

[Django]

#14332: manage testserver and manage runserver should have similiar address:port
options
-+--
  Reporter:  wildf...@progsoc.org| Owner:  fheinz
Status:  reopened| Milestone:
 Component:  django-admin.py |   Version:  1.2   
Resolution:  |  Keywords:
 Stage:  Design decision needed  | Has_patch:  1 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  1   |  
-+--
Comment (by fheinz):

 I agree that "there should be one obvious way to do it" is a Good Thing.
 What we have now is "there are two incompatible ways to do it, and you
 must choose the right one or it won't work".

 The change you propose would give us indeed one way to do it, at the price
 of breaking backwards compatibility for *both* runserver and testserver.

 I know that the current implementation doesn't work if you absolutely need
 to give a fixture a numerical name without extension, and put it first in
 the list of fixtures. That is an unlikely use case, and the --addrport
 option saves the day anyway.

 The way I see it, of the three option that are on the table right now
 (providing a homogeneous interface that breaks backwards compatibility,
 providing a homogeneous but redundant user interface without breaking
 backwards compatibility, and leaving things as they are with an redundant
 and inconsistent interface), the patch implements the least objectionable
 one.

-- 
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] #14686: ORM support for VoltDB

[Django]

#14686: ORM support for VoltDB
---+
  Reporter:  sylverb   | Owner:  nobody 
 
Status:  closed| Milestone: 
 
 Component:  Database layer (models, ORM)  |   Version:  SVN
 
Resolution:  wontfix   |  Keywords:  database, 
voltdb
 Stage:  Unreviewed| Has_patch:  0  
 
Needs_docs:  0 |   Needs_tests:  0  
 
Needs_better_patch:  0 |  
---+
Changes (by lrekucki):

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

Comment:

 You should probably see [http://groups.google.com/group/django-
 developers/browse_frm/thread/c9cdc88a40cfae22/e7fc4d4d65e23677#e7fc4d4d65e23677
 this django-dev thread] (which was about some other DBMS, but I think it
 applies). In short, Django encourages you to create 3rd party database
 backends and doesn't plan to include any more backends in the core at the
 moment.

-- 
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] #14686: ORM support for VoltDB

[Django]

#14686: ORM support for VoltDB
---+
  Reporter:  sylverb   | Owner:  nobody 
 
Status:  new   | Milestone: 
 
 Component:  Database layer (models, ORM)  |   Version:  SVN
 
Resolution:|  Keywords:  database, 
voltdb
 Stage:  Unreviewed| Has_patch:  0  
 
Needs_docs:  0 |   Needs_tests:  0  
 
Needs_better_patch:  0 |  
---+
Changes (by sylverb):

  * needs_better_patch:  => 0
  * 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] #14674: ResetPasswordForm doesn't consider unusable_password setting

[Django]

#14674: ResetPasswordForm doesn't consider unusable_password setting
-+--
  Reporter:  summerisgone| Owner:  nobody   

Status:  new | Milestone:  1.3  

 Component:  Authentication  |   Version:  SVN  

Resolution:  |  Keywords:  unusable_password, 
authorization, reset password, sprintnov13
 Stage:  Accepted| Has_patch:  1

Needs_docs:  0   |   Needs_tests:  0

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

 Here's a patch. Lack of "any" isn't a problem, 'cause you can just turn in
 into 3 line loop... or add it to {{{django.utils.itercompat}}} like I did
 (we have all(), so I don't see a reason why we shouldn't have any()).
 Anyway, after giving this more thought, this can cause trouble if someone
 used the PasswordResetForm as part of his registration process. I know at
 least one application that would be affected, but this may just be a
 misuse of this form.

-- 
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] #14591: UnicodeDecodeError when trying to render the label of a field

[Django]

#14591: UnicodeDecodeError when trying to render the label of a field
---+
  Reporter:  panosl| Owner:  nobody 
Status:  reopened  | Milestone: 
 Component:  django.contrib.admin  |   Version:  1.2
Resolution:|  Keywords:  unicode
 Stage:  Unreviewed| Has_patch:  1  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Changes (by panosl):

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

Comment:

 Replying to [comment:2 rasca]:
 > Just tried this and it works for me with no problems..

 Did you actually try to add a translation for the string? I forgot to
 state that explicitly, sorry.

 Try setting a greek locale for example and setting the str to 'όνομα'.

-- 
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] #14674: ResetPasswordForm doesn't consider unusable_password setting

[Django]

#14674: ResetPasswordForm doesn't consider unusable_password setting
-+--
  Reporter:  summerisgone| Owner:  nobody   

Status:  new | Milestone:  1.3  

 Component:  Authentication  |   Version:  SVN  

Resolution:  |  Keywords:  unusable_password, 
authorization, reset password, sprintnov13
 Stage:  Accepted| Has_patch:  1

Needs_docs:  0   |   Needs_tests:  0

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

 lrekucki,
 I like your patch but the 'any' function is part of python 2.5 and later.

 I am not sure if 2 'count' queries or evaluating the queryset is
 recommended.

-- 
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] #14680: Add a file to ignore unnecessary and compiled files from various version control systems

[Django]

#14680: Add a file to ignore unnecessary and compiled files from various version
control systems
+---
  Reporter:  thejaswi_puthraya  | Owner:  nobody
  
Status:  reopened   | Milestone:
  
 Component:  Core framework |   Version:  SVN   
  
Resolution: |  Keywords:  sprintnov13, 
gitignore, hgignore
 Stage:  Unreviewed | Has_patch:  1 
  
Needs_docs:  0  |   Needs_tests:  0 
  
Needs_better_patch:  0  |  
+---
Changes (by thejaswi_puthraya):

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

Comment:

 I created this ticket on a discussion with jezdez during the sprint. So
 please leave it open till further discussion.

 About trac not able to read the patch, the raw version of the ticket reads
 fine. So the patch seems to be alright.

-- 
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] #14686: ORM support for VoltDB

[Django]

#14686: ORM support for VoltDB
--+-
 Reporter:  sylverb   |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Database layer (models, ORM)  | Version:  SVN   
 Keywords:  database, voltdb  |   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 Hello,

 Would be great to have ORM support for [http://voltdb.com/content/voltdb-
 features-overview VoltDB] DBMS.

 They've released a native Python driver and it's a very promising DB which
 is a mix between NoSQL & relational SQL. The database retains the data in
 RAM and distributes both the data and the SQL engine which processes it,
 across the server or server cluster's processor cores. VoltDB is designed
 to ensure transactional consistency while eliminating legacy overhead.

 In short it's designed for the Web and takes care of sharding while still
 using SQL as a query language.

 SB

-- 
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] #14685: contrib.sessions.models has incompatible or extraneous code

[Django]

#14685: contrib.sessions.models has incompatible or extraneous code
-+--
 Reporter:  PaulM|   Owner:  nobody
   Status:  new  |   Milestone:  1.3   
Component:  django.contrib.sessions  | Version:  1.2   
 Keywords:   |   Stage:  Unreviewed
Has_patch:  0|  
-+--
 
[http://code.djangoproject.com/browser/django/trunk/django/contrib/sessions/models.py
 `contrib.sessions.models`] has a couple methods that seem outdated and
 extraneous.

 The specific problem methods are `SessionManager.encode()` and
 `Session.get_decoded()`. They definitely duplicate functionality (at a
 copy-paste level) now found elsewhere. I ''think'' these may be vestigal,
 but I haven't fully investigated. Someone more familiar with the sessions
 framework might want to take a look.

 If these are still in use somewhere, they need to be updated to match
 their new, higher security analogs in `contrib.sessions.backends.base`.

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