[Changeset] r15216 - django/trunk/tests/regressiontests/generic_views

[noreply]

Author: russellm
Date: 2011-01-15 00:33:36 -0600 (Sat, 15 Jan 2011)
New Revision: 15216

Modified:
   django/trunk/tests/regressiontests/generic_views/dates.py
Log:
Fixed #15048 -- Modified a test case to avoid a known bug in Python 2.4's time 
library. Thanks to ?\197?\129ukasz Rekucki for the report.

Modified: django/trunk/tests/regressiontests/generic_views/dates.py
===
--- django/trunk/tests/regressiontests/generic_views/dates.py   2011-01-15 
06:31:38 UTC (rev 15215)
+++ django/trunk/tests/regressiontests/generic_views/dates.py   2011-01-15 
06:33:36 UTC (rev 15216)
@@ -221,10 +221,10 @@
 future = datetime.date(datetime.date.today().year + 1, 1, 1)
 b = Book.objects.create(name="The New New Testement", pages=600, 
pubdate=future)
 
-res = self.client.get('/dates/books/%s/week/0/' % future.year)
+res = self.client.get('/dates/books/%s/week/1/' % future.year)
 self.assertEqual(res.status_code, 404)
 
-res = self.client.get('/dates/books/%s/week/0/allow_future/' % 
future.year)
+res = self.client.get('/dates/books/%s/week/1/allow_future/' % 
future.year)
 self.assertEqual(res.status_code, 200)
 self.assertEqual(list(res.context['books']), [b])
 

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

[Changeset] r15215 - in django/trunk: django/core/management/commands docs/ref tests/regressiontests/admin_scripts

[noreply]

Author: russellm
Date: 2011-01-15 00:31:38 -0600 (Sat, 15 Jan 2011)
New Revision: 15215

Modified:
   django/trunk/django/core/management/commands/runserver.py
   django/trunk/docs/ref/django-admin.txt
   django/trunk/tests/regressiontests/admin_scripts/tests.py
Log:
Fixed #14928 -- Ensure that a fully qualified domain name can be used for 
runserver. Thanks to Karmel Allison for the report, ?\197?\129ukasz Rekucki for 
the patch, and claudep for the tests.

Modified: django/trunk/django/core/management/commands/runserver.py
===
--- django/trunk/django/core/management/commands/runserver.py   2011-01-15 
06:12:56 UTC (rev 15214)
+++ django/trunk/django/core/management/commands/runserver.py   2011-01-15 
06:31:38 UTC (rev 15215)
@@ -9,7 +9,12 @@
 from django.core.servers.basehttp import AdminMediaHandler, run, 
WSGIServerException
 from django.utils import autoreload
 
-naiveip_re = 
r'^(?:(?P\d{1,3}(?:\.\d{1,3}){3}|\[[a-fA-F0-9:]+\]):)?(?P\d+)$'
+naiveip_re = re.compile(r"""^(?:
+(?P
+(?P\d{1,3}(?:\.\d{1,3}){3}) | # IPv4 address
+(?P\[[a-fA-F0-9:]+\]) |   # IPv6 address
+(?P[a-zA-Z0-9-]+(?:\.[a-zA-Z0-9-]+)*) # FQDN
+):)?(?P\d+)$""", re.X)
 DEFAULT_PORT = "8000"
 
 class BaseRunserverCommand(BaseCommand):
@@ -33,28 +38,29 @@
 
 def handle(self, addrport='', *args, **options):
 self.use_ipv6 = options.get('use_ipv6')
-if self.use_ipv6 and not hasattr(socket, 'AF_INET6'):
+if self.use_ipv6 and not socket.has_ipv6:
 raise CommandError('Your Python does not support IPv6.')
 if args:
 raise CommandError('Usage is runserver %s' % self.args)
+self._raw_ipv6 = False
 if not addrport:
 self.addr = ''
 self.port = DEFAULT_PORT
 else:
 m = re.match(naiveip_re, addrport)
 if m is None:
-raise CommandError('%r is not a valid port number'
+raise CommandError('"%s" is not a valid port number '
'or address:port pair.' % addrport)
-self.addr, self.port = m.groups()
+self.addr, _ipv4, _ipv6, _fqdn, self.port = m.groups()
 if not self.port.isdigit():
 raise CommandError("%r is not a valid port number." % 
self.port)
 if self.addr:
-if self.addr.startswith('[') and self.addr.endswith(']'):
+if _ipv6:
 self.addr = self.addr[1:-1]
 self.use_ipv6 = True
-elif self.use_ipv6:
-raise CommandError('IPv6 addresses must be surrounded '
-   'with brackets, e.g. [::1].')
+self._raw_ipv6 = True
+elif self.use_ipv6 and not _fqdn:
+raise CommandError('"%s" is not a valid IPv6 address.' % 
self.addr)
 if not self.addr:
 self.addr = self.use_ipv6 and '::1' or '127.0.0.1'
 self.run(*args, **options)
@@ -86,7 +92,7 @@
 ) % {
 "version": self.get_version(),
 "settings": settings.SETTINGS_MODULE,
-"addr": self.use_ipv6 and '[%s]' % self.addr or self.addr,
+"addr": self._raw_ipv6 and '[%s]' % self.addr or self.addr,
 "port": self.port,
 "quit_command": quit_command,
 })

Modified: django/trunk/docs/ref/django-admin.txt
===
--- django/trunk/docs/ref/django-admin.txt  2011-01-15 06:12:56 UTC (rev 
15214)
+++ django/trunk/docs/ref/django-admin.txt  2011-01-15 06:31:38 UTC (rev 
15215)
@@ -616,7 +616,7 @@
 
 Run a FastCGI server as a daemon and write the spawned PID in a file.
 
-runserver [port or ipaddr:port]
+runserver [port or address:port]
 ---
 
 .. django-admin:: runserver
@@ -653,9 +653,11 @@
 
 .. versionchanged:: 1.3
 
-You can also provide an IPv6 address surrounded by brackets
-(eg. ``[200a::1]:8000``). This will automaticaly enable IPv6 support.
+You can provide an IPv6 address surrounded by brackets
+(e.g. ``[200a::1]:8000``). This will automatically enable IPv6 support.
 
+A hostname containing ASCII-only characters can also be used.
+
 .. django-admin-option:: --adminmedia
 
 Use the ``--adminmedia`` option to tell Django where to find the various CSS
@@ -721,6 +723,14 @@
 
 django-admin.py runserver [2001:0db8:1234:5678::9]:7000
 
+Port 8000 on IPv4 address of host ``localhost``::
+
+django-admin.py runserver localhost:8000
+
+Port 8000 on IPv6 address of host ``localhost``::
+
+django-admin.py runserver -6 localhost:8000
+
 Serving static files with the development server
 
 

Modified: django/trunk/tests/regressiontests/admin_scripts/tests.py
===
--- 

[Changeset] r15214 - django/trunk/django/core/cache

[noreply]

Author: russellm
Date: 2011-01-15 00:12:56 -0600 (Sat, 15 Jan 2011)
New Revision: 15214

Modified:
   django/trunk/django/core/cache/__init__.py
Log:
Fixed #15079 -- Added a missing import in the cache infrastructure. Thanks to 
jaylett for the report.

Modified: django/trunk/django/core/cache/__init__.py
===
--- django/trunk/django/core/cache/__init__.py  2011-01-15 06:06:34 UTC (rev 
15213)
+++ django/trunk/django/core/cache/__init__.py  2011-01-15 06:12:56 UTC (rev 
15214)
@@ -18,6 +18,7 @@
 from django.core import signals
 from django.core.cache.backends.base import (
 InvalidCacheBackendError, CacheKeyWarning, BaseCache)
+from django.core.exceptions import ImproperlyConfigured
 from django.utils import importlib
 
 try:

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

[Changeset] r15213 - in django/branches/releases/1.2.X: django/core/mail django/core/mail/backends tests/regressiontests/mail

[noreply]

Author: russellm
Date: 2011-01-15 00:06:34 -0600 (Sat, 15 Jan 2011)
New Revision: 15213

Modified:
   django/branches/releases/1.2.X/django/core/mail/backends/smtp.py
   django/branches/releases/1.2.X/django/core/mail/message.py
   django/branches/releases/1.2.X/tests/regressiontests/mail/tests.py
Log:
[1.2.X] Fixed #15042 -- Ensured that email addresses without a domain can still 
be mail recipients. Patch also improves the IDN handling introduced by r15006, 
and refactors the test suite to ensure even feature coverage. Thanks to net147 
for the report, and to ?\197?\129ukasz Rekucki for the awesome patch.

Backport of r15211 from trunk.

Modified: django/branches/releases/1.2.X/django/core/mail/backends/smtp.py
===
--- django/branches/releases/1.2.X/django/core/mail/backends/smtp.py
2011-01-15 06:06:09 UTC (rev 15212)
+++ django/branches/releases/1.2.X/django/core/mail/backends/smtp.py
2011-01-15 06:06:34 UTC (rev 15213)
@@ -1,5 +1,4 @@
 """SMTP email backend class."""
-
 import smtplib
 import socket
 import threading
@@ -7,7 +6,9 @@
 from django.conf import settings
 from django.core.mail.backends.base import BaseEmailBackend
 from django.core.mail.utils import DNS_NAME
+from django.core.mail.message import sanitize_address
 
+
 class EmailBackend(BaseEmailBackend):
 """
 A wrapper that manages the SMTP network connection.
@@ -91,17 +92,13 @@
 self._lock.release()
 return num_sent
 
-def _sanitize(self, email):
-name, domain = email.split('@', 1)
-email = '@'.join([name, domain.encode('idna')])
-return email
-
 def _send(self, email_message):
 """A helper method that does the actual sending."""
 if not email_message.recipients():
 return False
-from_email = self._sanitize(email_message.from_email)
-recipients = map(self._sanitize, email_message.recipients())
+from_email = sanitize_address(email_message.from_email, 
email_message.encoding)
+recipients = [sanitize_address(addr, email_message.encoding)
+  for addr in email_message.recipients()]
 try:
 self.connection.sendmail(from_email, recipients,
 email_message.message().as_string())

Modified: django/branches/releases/1.2.X/django/core/mail/message.py
===
--- django/branches/releases/1.2.X/django/core/mail/message.py  2011-01-15 
06:06:09 UTC (rev 15212)
+++ django/branches/releases/1.2.X/django/core/mail/message.py  2011-01-15 
06:06:34 UTC (rev 15213)
@@ -12,6 +12,7 @@
 from django.conf import settings
 from django.core.mail.utils import DNS_NAME
 from django.utils.encoding import smart_str, force_unicode
+from email.Utils import parseaddr
 
 # Don't BASE64-encode UTF-8 messages so that we avoid unwanted attention from
 # some spam filters.
@@ -54,6 +55,22 @@
 return msgid
 
 
+# Header names that contain structured address data (RFC #5322)
+ADDRESS_HEADERS = set([
+'from',
+'sender',
+'reply-to',
+'to',
+'cc',
+'bcc',
+'resent-from',
+'resent-sender',
+'resent-to',
+'resent-cc',
+'resent-bcc',
+])
+
+
 def forbid_multi_line_headers(name, val, encoding):
 """Forbids multi-line headers, to prevent header injection."""
 encoding = encoding or settings.DEFAULT_CHARSET
@@ -63,43 +80,57 @@
 try:
 val = val.encode('ascii')
 except UnicodeEncodeError:
-if name.lower() in ('to', 'from', 'cc'):
-result = []
-for nm, addr in getaddresses((val,)):
-nm = str(Header(nm.encode(encoding), encoding))
-try:
-addr = addr.encode('ascii')
-except UnicodeEncodeError:  # IDN
-addr = str(Header(addr.encode(encoding), encoding))
-result.append(formataddr((nm, addr)))
-val = ', '.join(result)
+if name.lower() in ADDRESS_HEADERS:
+val = ', '.join(sanitize_address(addr, encoding)
+for addr in getaddresses((val,)))
 else:
-val = Header(val.encode(encoding), encoding)
+val = str(Header(val, encoding))
 else:
 if name.lower() == 'subject':
 val = Header(val)
 return name, val
 
+
+def sanitize_address(addr, encoding):
+if isinstance(addr, basestring):
+addr = parseaddr(force_unicode(addr))
+nm, addr = addr
+nm = str(Header(nm, encoding))
+try:
+addr = addr.encode('ascii')
+except UnicodeEncodeError:  # IDN
+if u'@' in addr:
+localpart, domain = addr.split(u'@', 1)
+localpart = str(Header(localpart, encoding))
+domain = domain.encode('idna')
+addr = '@'.join([localpart, domain])
+else:
+addr = str(Header(addr, encoding))
+return formataddr((nm, 

[Changeset] r15212 - django/branches/releases/1.2.X/django/core/handlers

[noreply]

Author: russellm
Date: 2011-01-15 00:06:09 -0600 (Sat, 15 Jan 2011)
New Revision: 15212

Modified:
   django/branches/releases/1.2.X/django/core/handlers/wsgi.py
Log:
[1.2.X] Corrected r15205 syntax to be Python2.4 compatible.

Backport of r15210 from trunk.

Modified: django/branches/releases/1.2.X/django/core/handlers/wsgi.py
===
--- django/branches/releases/1.2.X/django/core/handlers/wsgi.py 2011-01-15 
05:55:24 UTC (rev 15211)
+++ django/branches/releases/1.2.X/django/core/handlers/wsgi.py 2011-01-15 
06:06:09 UTC (rev 15212)
@@ -226,13 +226,14 @@
 if self._request_middleware is None:
 self.initLock.acquire()
 try:
-# Check that middleware is still uninitialised.
-if self._request_middleware is None:
-self.load_middleware()
-except:
-# Unload whatever middleware we got
-self._request_middleware = None
-raise
+try:
+# Check that middleware is still uninitialised.
+if self._request_middleware is None:
+self.load_middleware()
+except:
+# Unload whatever middleware we got
+self._request_middleware = None
+raise
 finally:
 self.initLock.release()
 

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

[Changeset] r15211 - in django/trunk: django/core/mail django/core/mail/backends tests/regressiontests/mail

[noreply]

Author: russellm
Date: 2011-01-14 23:55:24 -0600 (Fri, 14 Jan 2011)
New Revision: 15211

Modified:
   django/trunk/django/core/mail/backends/smtp.py
   django/trunk/django/core/mail/message.py
   django/trunk/tests/regressiontests/mail/tests.py
Log:
Fixed #15042 -- Ensured that email addresses without a domain can still be mail 
recipients. Patch also improves the IDN handling introduced by r15006, and 
refactors the test suite to ensure even feature coverage. Thanks to net147 for 
the report, and to ?\197?\129ukasz Rekucki for the awesome patch.

Modified: django/trunk/django/core/mail/backends/smtp.py
===
--- django/trunk/django/core/mail/backends/smtp.py  2011-01-15 05:54:55 UTC 
(rev 15210)
+++ django/trunk/django/core/mail/backends/smtp.py  2011-01-15 05:55:24 UTC 
(rev 15211)
@@ -1,5 +1,4 @@
 """SMTP email backend class."""
-
 import smtplib
 import socket
 import threading
@@ -7,7 +6,9 @@
 from django.conf import settings
 from django.core.mail.backends.base import BaseEmailBackend
 from django.core.mail.utils import DNS_NAME
+from django.core.mail.message import sanitize_address
 
+
 class EmailBackend(BaseEmailBackend):
 """
 A wrapper that manages the SMTP network connection.
@@ -91,17 +92,13 @@
 self._lock.release()
 return num_sent
 
-def _sanitize(self, email):
-name, domain = email.split('@', 1)
-email = '@'.join([name, domain.encode('idna')])
-return email
-
 def _send(self, email_message):
 """A helper method that does the actual sending."""
 if not email_message.recipients():
 return False
-from_email = self._sanitize(email_message.from_email)
-recipients = map(self._sanitize, email_message.recipients())
+from_email = sanitize_address(email_message.from_email, 
email_message.encoding)
+recipients = [sanitize_address(addr, email_message.encoding)
+  for addr in email_message.recipients()]
 try:
 self.connection.sendmail(from_email, recipients,
 email_message.message().as_string())

Modified: django/trunk/django/core/mail/message.py
===
--- django/trunk/django/core/mail/message.py2011-01-15 05:54:55 UTC (rev 
15210)
+++ django/trunk/django/core/mail/message.py2011-01-15 05:55:24 UTC (rev 
15211)
@@ -12,6 +12,7 @@
 from django.conf import settings
 from django.core.mail.utils import DNS_NAME
 from django.utils.encoding import smart_str, force_unicode
+from email.Utils import parseaddr
 
 # Don't BASE64-encode UTF-8 messages so that we avoid unwanted attention from
 # some spam filters.
@@ -54,6 +55,22 @@
 return msgid
 
 
+# Header names that contain structured address data (RFC #5322)
+ADDRESS_HEADERS = set([
+'from',
+'sender',
+'reply-to',
+'to',
+'cc',
+'bcc',
+'resent-from',
+'resent-sender',
+'resent-to',
+'resent-cc',
+'resent-bcc',
+])
+
+
 def forbid_multi_line_headers(name, val, encoding):
 """Forbids multi-line headers, to prevent header injection."""
 encoding = encoding or settings.DEFAULT_CHARSET
@@ -63,43 +80,57 @@
 try:
 val = val.encode('ascii')
 except UnicodeEncodeError:
-if name.lower() in ('to', 'from', 'cc'):
-result = []
-for nm, addr in getaddresses((val,)):
-nm = str(Header(nm.encode(encoding), encoding))
-try:
-addr = addr.encode('ascii')
-except UnicodeEncodeError:  # IDN
-addr = str(Header(addr.encode(encoding), encoding))
-result.append(formataddr((nm, addr)))
-val = ', '.join(result)
+if name.lower() in ADDRESS_HEADERS:
+val = ', '.join(sanitize_address(addr, encoding)
+for addr in getaddresses((val,)))
 else:
-val = Header(val.encode(encoding), encoding)
+val = str(Header(val, encoding))
 else:
 if name.lower() == 'subject':
 val = Header(val)
 return name, val
 
+
+def sanitize_address(addr, encoding):
+if isinstance(addr, basestring):
+addr = parseaddr(force_unicode(addr))
+nm, addr = addr
+nm = str(Header(nm, encoding))
+try:
+addr = addr.encode('ascii')
+except UnicodeEncodeError:  # IDN
+if u'@' in addr:
+localpart, domain = addr.split(u'@', 1)
+localpart = str(Header(localpart, encoding))
+domain = domain.encode('idna')
+addr = '@'.join([localpart, domain])
+else:
+addr = str(Header(addr, encoding))
+return formataddr((nm, addr))
+
+
 class SafeMIMEText(MIMEText):
-
+
 def __init__(self, text, subtype, charset):
 self.encoding = charset
 MIMEText.__init__(self, text, subtype, charset)
-

[Changeset] r15210 - django/trunk/django/core/handlers

[noreply]

Author: russellm
Date: 2011-01-14 23:54:55 -0600 (Fri, 14 Jan 2011)
New Revision: 15210

Modified:
   django/trunk/django/core/handlers/wsgi.py
Log:
Corrected r15205 syntax to be Python2.4 compatible.

Modified: django/trunk/django/core/handlers/wsgi.py
===
--- django/trunk/django/core/handlers/wsgi.py   2011-01-15 00:18:15 UTC (rev 
15209)
+++ django/trunk/django/core/handlers/wsgi.py   2011-01-15 05:54:55 UTC (rev 
15210)
@@ -243,13 +243,14 @@
 if self._request_middleware is None:
 self.initLock.acquire()
 try:
-# Check that middleware is still uninitialised.
-if self._request_middleware is None:
-self.load_middleware()
-except:
-# Unload whatever middleware we got
-self._request_middleware = None
-raise
+try:
+# Check that middleware is still uninitialised.
+if self._request_middleware is None:
+self.load_middleware()
+except:
+# Unload whatever middleware we got
+self._request_middleware = None
+raise
 finally:
 self.initLock.release()
 

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

Re: [Django] #15086: Django 1.2.4 on FreeBSD serious error

[Django]

#15086: Django 1.2.4 on FreeBSD serious error
+---
  Reporter:  crow16...@mail.ru  | Owner:  nobody
Status:  closed | Milestone:
 Component:  Forms  |   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:

 There isn't anywhere near enough detail here to consider this a bug
 report. You haven't even told us what error you are getting -- just that
 it is "serious".

 Closing invalid; if you want us to take this report seriously, you need to
 provide a reproducible test case. If you can do so, feel free to reopen.

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

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

Re: [Django] #10405: quoted class names in foreign key definition causes 'str' object has no attribute '_default_manager'

[Django]

#10405: quoted class names in foreign key definition causes 'str' object has no
attribute '_default_manager'
---+
  Reporter:  danbrwn   | Owner:  mitsuhiko  
   
Status:  new   | Milestone: 
   
 Component:  Database layer (models, ORM)  |   Version:  1.2
   
Resolution:|  Keywords:  
foreign,key,quoted
 Stage:  Accepted  | Has_patch:  0  
   
Needs_docs:  0 |   Needs_tests:  0  
   
Needs_better_patch:  0 |  
---+
Changes (by eduardocereto):

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

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

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

Re: [Django] #6903: Go back to old change_list view after hitting save

[Django]

#6903: Go back to old change_list view after hitting save
-+--
  Reporter:  jarrow  | Owner: 
Status:  new | Milestone: 
 Component:  django.contrib.admin|   Version:  SVN
Resolution:  |  Keywords: 
 Stage:  Design decision needed  | Has_patch:  1  
Needs_docs:  0   |   Needs_tests:  0  
Needs_better_patch:  0   |  
-+--
Changes (by empty):

 * cc: empty (added)

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

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

Re: [Django] #6903: Go back to old change_list view after hitting save

[Django]

#6903: Go back to old change_list view after hitting save
-+--
  Reporter:  jarrow  | Owner: 
Status:  new | Milestone: 
 Component:  django.contrib.admin|   Version:  SVN
Resolution:  |  Keywords: 
 Stage:  Design decision needed  | Has_patch:  1  
Needs_docs:  0   |   Needs_tests:  0  
Needs_better_patch:  0   |  
-+--
Changes (by robhudson):

 * cc: r...@cogit8.org (added)

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

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

[Changeset] r15209 - django/trunk/tests/regressiontests/i18n/commands

[noreply]

Author: ramiro
Date: 2011-01-14 18:18:15 -0600 (Fri, 14 Jan 2011)
New Revision: 15209

Modified:
   django/trunk/tests/regressiontests/i18n/commands/extraction.py
Log:
Modified a try block construct in a test case to be compatible with Python 2.4.

Modified: django/trunk/tests/regressiontests/i18n/commands/extraction.py
===
--- django/trunk/tests/regressiontests/i18n/commands/extraction.py  
2011-01-15 00:15:39 UTC (rev 15208)
+++ django/trunk/tests/regressiontests/i18n/commands/extraction.py  
2011-01-15 00:18:15 UTC (rev 15209)
@@ -63,10 +63,11 @@
 os.chdir(self.test_dir)
 shutil.copyfile('./templates/template_with_error.txt', 
'./templates/template_with_error.html')
 self.assertRaises(SyntaxError, management.call_command, 
'makemessages', locale=LOCALE, verbosity=0)
-try:
-management.call_command('makemessages', locale=LOCALE, verbosity=0)
-except SyntaxError, e:
-self.assertEqual(str(e), 'Translation blocks must not include 
other block tags: blocktrans (file templates/template_with_error.html, line 3)')
+try: # TODO: Simplify this try/try block when we drop support for 
Python 2.4
+try:
+management.call_command('makemessages', locale=LOCALE, 
verbosity=0)
+except SyntaxError, e:
+self.assertEqual(str(e), 'Translation blocks must not include 
other block tags: blocktrans (file templates/template_with_error.html, line 3)')
 finally:
 os.remove('./templates/template_with_error.html')
 os.remove('./templates/template_with_error.html.py') # Waiting for 
#8536 to be fixed

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

[Changeset] r15208 - django/trunk/tests/regressiontests/multiple_database

[noreply]

Author: ramiro
Date: 2011-01-14 18:15:39 -0600 (Fri, 14 Jan 2011)
New Revision: 15208

Modified:
   django/trunk/tests/regressiontests/multiple_database/tests.py
Log:
Enhanced slightly the tests added in r15185 to demonstrate that #14948 doesn't 
affect trunk. Refs #14948. Thanks Harm Geerts.

Modified: django/trunk/tests/regressiontests/multiple_database/tests.py
===
--- django/trunk/tests/regressiontests/multiple_database/tests.py   
2011-01-14 23:30:17 UTC (rev 15207)
+++ django/trunk/tests/regressiontests/multiple_database/tests.py   
2011-01-15 00:15:39 UTC (rev 15208)
@@ -1851,7 +1851,7 @@
 if not hasattr(model, '_meta'):
 raise ValueError
 
-class RouterM2MThroughTestCase(TestCase):
+class RouterModelArgumentTestCase(TestCase):
 multi_db = True
 
 def setUp(self):
@@ -1861,7 +1861,7 @@
 def tearDown(self):
 router.routers = self.old_routers
 
-def test_m2m_through(self):
+def test_m2m_collection(self):
 b = Book.objects.create(title="Pro Django",
 published=datetime.date(2008, 12, 16))
 
@@ -1872,3 +1872,13 @@
 b.authors.remove(p)
 # test clear
 b.authors.clear()
+# test setattr
+b.authors = [p]
+# test M2M collection
+b.delete()
+
+def test_foreignkey_collection(self):
+person = Person.objects.create(name='Bob')
+pet = Pet.objects.create(owner=person, name='Wart')
+# test related FK collection
+person.delete()

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

[Changeset] r15207 - in django/branches/releases/1.2.X: django/db/models tests/regressiontests/multiple_database

[noreply]

Author: ramiro
Date: 2011-01-14 17:30:17 -0600 (Fri, 14 Jan 2011)
New Revision: 15207

Modified:
   django/branches/releases/1.2.X/django/db/models/base.py
   
django/branches/releases/1.2.X/tests/regressiontests/multiple_database/tests.py
Log:
[1.2.X] Fixed #14948 -- Fixed a couple of cases where invalid model classes 
were passed to the database router when collecting reverse foreign key and many 
to many relationships. Thanks shell_dweller for the report and Harm Geerts for 
the patch.

This also enhances tests added in r15186.

Code in SVN trunk doesn't suffer from this problem because it was refactored in 
r14507.

Modified: django/branches/releases/1.2.X/django/db/models/base.py
===
--- django/branches/releases/1.2.X/django/db/models/base.py 2011-01-14 
23:19:50 UTC (rev 15206)
+++ django/branches/releases/1.2.X/django/db/models/base.py 2011-01-14 
23:30:17 UTC (rev 15207)
@@ -612,7 +612,7 @@
 
 for related in self._meta.get_all_related_many_to_many_objects():
 if related.field.rel.through:
-db = router.db_for_write(related.field.rel.through.__class__, 
instance=self)
+db = router.db_for_write(related.field.rel.through, 
instance=self)
 opts = related.field.rel.through._meta
 reverse_field_name = related.field.m2m_reverse_field_name()
 nullable = opts.get_field(reverse_field_name).null
@@ -622,7 +622,7 @@
 
 for f in self._meta.many_to_many:
 if f.rel.through:
-db = router.db_for_write(f.rel.through.__class__, 
instance=self)
+db = router.db_for_write(f.rel.through, instance=self)
 opts = f.rel.through._meta
 field_name = f.m2m_field_name()
 nullable = opts.get_field(field_name).null

Modified: 
django/branches/releases/1.2.X/tests/regressiontests/multiple_database/tests.py
===
--- 
django/branches/releases/1.2.X/tests/regressiontests/multiple_database/tests.py 
2011-01-14 23:19:50 UTC (rev 15206)
+++ 
django/branches/releases/1.2.X/tests/regressiontests/multiple_database/tests.py 
2011-01-14 23:30:17 UTC (rev 15207)
@@ -1739,7 +1739,7 @@
 if not hasattr(model, '_meta'):
 raise ValueError
 
-class RouterM2MThroughTestCase(TestCase):
+class RouterModelArgumentTestCase(TestCase):
 multi_db = True
 
 def setUp(self):
@@ -1749,7 +1749,7 @@
 def tearDown(self):
 router.routers = self.old_routers
 
-def test_m2m_through(self):
+def test_m2m_collection(self):
 b = Book.objects.create(title="Pro Django",
 published=datetime.date(2008, 12, 16))
 
@@ -1760,3 +1760,13 @@
 b.authors.remove(p)
 # test clear
 b.authors.clear()
+# test setattr
+b.authors = [p]
+# Test M2M collection (_collect_sub_objects() in Django <= 1.2.X)
+b.delete()
+
+def test_foreignkey_collection(self):
+person = Person.objects.create(name='Bob')
+pet = Pet.objects.create(owner=person, name='Wart')
+# Test related FK collection (_collect_sub_objects() in Django <= 
1.2.X)
+person.delete()

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

[Changeset] r15206 - django/branches/releases/1.2.X/django/core/handlers

[noreply]

Author: andrewgodwin
Date: 2011-01-14 17:19:50 -0600 (Fri, 14 Jan 2011)
New Revision: 15206

Modified:
   django/branches/releases/1.2.X/django/core/handlers/wsgi.py
Log:
[1.2.X] Fixed #11193 -- WSGI handler not properly handling lock on error in 
load_middleware. Thanks to Phillip Sitbon.

Backport of [15205] from trunk

Modified: django/branches/releases/1.2.X/django/core/handlers/wsgi.py
===
--- django/branches/releases/1.2.X/django/core/handlers/wsgi.py 2011-01-14 
23:18:21 UTC (rev 15205)
+++ django/branches/releases/1.2.X/django/core/handlers/wsgi.py 2011-01-14 
23:19:50 UTC (rev 15206)
@@ -225,10 +225,16 @@
 # settings weren't available.
 if self._request_middleware is None:
 self.initLock.acquire()
-# Check that middleware is still uninitialised.
-if self._request_middleware is None:
-self.load_middleware()
-self.initLock.release()
+try:
+# Check that middleware is still uninitialised.
+if self._request_middleware is None:
+self.load_middleware()
+except:
+# Unload whatever middleware we got
+self._request_middleware = None
+raise
+finally:
+self.initLock.release()
 
 set_script_prefix(base.get_script_name(environ))
 signals.request_started.send(sender=self.__class__)

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

[Changeset] r15205 - in django/trunk: django/core/handlers tests/regressiontests tests/regressiontests/handlers

[noreply]

Author: andrewgodwin
Date: 2011-01-14 17:18:21 -0600 (Fri, 14 Jan 2011)
New Revision: 15205

Added:
   django/trunk/tests/regressiontests/handlers/
   django/trunk/tests/regressiontests/handlers/__init__.py
   django/trunk/tests/regressiontests/handlers/models.py
   django/trunk/tests/regressiontests/handlers/tests.py
Modified:
   django/trunk/django/core/handlers/wsgi.py
Log:
Fixed #11193 -- WSGI handler not properly handling lock on error in 
load_middleware. Thanks to Phillip Sitbon.

Modified: django/trunk/django/core/handlers/wsgi.py
===
--- django/trunk/django/core/handlers/wsgi.py   2011-01-14 08:31:14 UTC (rev 
15204)
+++ django/trunk/django/core/handlers/wsgi.py   2011-01-14 23:18:21 UTC (rev 
15205)
@@ -242,10 +242,16 @@
 # settings weren't available.
 if self._request_middleware is None:
 self.initLock.acquire()
-# Check that middleware is still uninitialised.
-if self._request_middleware is None:
-self.load_middleware()
-self.initLock.release()
+try:
+# Check that middleware is still uninitialised.
+if self._request_middleware is None:
+self.load_middleware()
+except:
+# Unload whatever middleware we got
+self._request_middleware = None
+raise
+finally:
+self.initLock.release()
 
 set_script_prefix(base.get_script_name(environ))
 signals.request_started.send(sender=self.__class__)

Added: django/trunk/tests/regressiontests/handlers/__init__.py
===

Added: django/trunk/tests/regressiontests/handlers/models.py
===

Added: django/trunk/tests/regressiontests/handlers/tests.py
===
--- django/trunk/tests/regressiontests/handlers/tests.py
(rev 0)
+++ django/trunk/tests/regressiontests/handlers/tests.py2011-01-14 
23:18:21 UTC (rev 15205)
@@ -0,0 +1,25 @@
+from django.utils import unittest
+from django.conf import settings
+from django.core.handlers.wsgi import WSGIHandler
+
+class HandlerTests(unittest.TestCase):
+
+def test_lock_safety(self):
+"""
+Tests for bug #11193 (errors inside middleware shouldn't leave
+the initLock locked).
+"""
+# Mangle settings so the handler will fail
+old_middleware_classes = settings.MIDDLEWARE_CLASSES
+settings.MIDDLEWARE_CLASSES = 42
+# Try running the handler, it will fail in load_middleware
+handler = WSGIHandler()
+self.assertEqual(handler.initLock.locked(), False)
+try:
+handler(None, None)
+except:
+pass
+self.assertEqual(handler.initLock.locked(), False)
+# Reset settings
+settings.MIDDLEWARE_CLASSES = old_middleware_classes
+

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

[Django] #15086: Django 1.2.4 on FreeBSD serious error

[Django]

#15086: Django 1.2.4 on FreeBSD serious error
---+
 Reporter:  crow16...@mail.ru  |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Forms  | Version:  1.2   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 Hi, dear!
 First of all - thanks a lot for your work!
 I have updated django from 1.2.3 (FreeBSD) to 1.2.4 and now I have a
 serious error (returned to 1.2.3 version)
 I have model and when this model save data, post_save signal creates some
 other models. When I do it in shell like pp = MyModel(), pp.save() -
 all fine,
 but when I do it in form like MyForm.save() I have a trouble - records are
 doubled. In 1.2.3 django all worked fine.

 If you need more info please let me know.

 Best Reagards,
 Crow16384

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

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

Re: [Django] #15042: 1.2.4 regression: send_mail doesn't access email recipient with no domain

[Django]

#15042: 1.2.4 regression: send_mail doesn't access email recipient with no 
domain
---+
  Reporter:  net147| Owner:  lrekucki   
   
Status:  new   | Milestone:  1.3
   
 Component:  django.core.mail  |   Version:  1.2
   
Resolution:|  Keywords:  blocker regression 
send_mail email
 Stage:  Accepted  | Has_patch:  1  
   
Needs_docs:  0 |   Needs_tests:  0  
   
Needs_better_patch:  0 |  
---+
Changes (by lrekucki):

  * has_patch:  0 => 1

Comment:

 The patch contains:

  * Refactored tests for mail handling:
 * {{{MailTests}}} class contains test cases related to EmailMessage
 class that don't depend on any backend.
 * {{{BaseEmailBackendTests}}} contains all other tests that involve
 actually sending any messages.
 * {{{FakeSMTPServer}}} using Python's {{{smptd}}} module for testing
 the SMTP backend. This runs in another thread for the duration of the
 testcase.
  * Correct handling of IDN: all headers that contain email addresses must
 be sanitized properly. Otherwise, the whole header will be encoded as
 "quoted-printable", thus loosing it's structure. I tried sending some
 emails to a localy defined IDN and Postfix treats the value in {{{From:
 =?utf-8?b?ZnLDtm1Aw7bDpMO8LmNvbQ==?=}}} as it was a mailbox name.
  * Some support for non-ASCII characters in local-part of the email
 (they're encoded as they we're before).
  * A fix and a regression test for this issue.

 Note: Backporting to 1.2.X involves moving some code from
 {{{setUpClass/tearDownClass}}} in {{{SMTPBackendTests}}} to
 {{{setUp/tearDown}}}. Should I make a seperate patch ?

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

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

Re: [Django] #15085: Cache arguments section uses invalid LOCATION for FileCache

[Django]

#15085: Cache arguments section uses invalid LOCATION for FileCache
--+-
  Reporter:  abdela...@gmail.com  | Owner:  nobody
Status:  new  | Milestone:
 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 jezdez):

  * needs_better_patch:  => 0
  * stage:  Unreviewed => Ready for checkin
  * needs_tests:  => 0
  * needs_docs:  => 0

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

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

Re: [Django] #15068: initial_data fixtures using natural keys fail in tests with multiple databases

[Django]

#15068: initial_data fixtures using natural keys fail in tests with multiple
databases
+---
  Reporter:  dcramer| Owner:  nobody
Status:  closed | Milestone:
 Component:  Testing framework  |   Version:  1.2   
Resolution:  invalid|  Keywords:
 Stage:  Accepted   | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Comment (by dcramer):

 Natural keys require the data to exist in the database before they're
 referenced. With the way fixtures work, they're instantiated before
 running the "allow_syncdb" check. In our case, a database with the name
 "analytics" was loaded before "default", which contains very few tables.
 When it gets around to a fixture with a natural key, it attempts to
 instantiate it using the natural key code path, which attempts to validate
 a foreign key against a table that does not exist. I'm pretty certain this
 is valid, and while it may be an edge case (not sure how common natural
 key usage is), it's certainly very odd behavior.

 I attempted to shift loading fixtures after syncdb was done (on every
 database), but that still doesnt solve it, as the fixtures load per
 database (not globally), and in this case, they still have the same issue.
 I think the proper fix would be to change natural keys so they're mapped
 in memory, but that requires quite a large change to Django itself I
 imagine, as last I knew relationships dont support associations if they
 dont have an identifier, which these wouldn't.

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

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

[Django] #15085: Cache arguments section uses invalid LOCATION for FileCache

[Django]

#15085: Cache arguments section uses invalid LOCATION for FileCache
-+--
 Reporter:  abdela...@gmail.com  |   Owner:  nobody
   Status:  new  |   Milestone:
Component:  Documentation| Version:  SVN   
 Keywords:   |   Stage:  Unreviewed
Has_patch:  0|  
-+--
 The Cache arguments section describes options for a FileCache but uses a
 URL rather than an absolute path (it's just accidentally copied from the
 memcached LOCATION). It should use /var/tmp/django_cache instead.

 /django/trunk/docs/topics/cache.txt &
 http://docs.djangoproject.com/en/dev/topics/cache/#cache-arguments


 {{{
 -'LOCATION': '127.0.0.1:11211',
 +'LOCATION': '/var/tmp/django_cache',
 }}}

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

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

Re: [Django] #14249: Inactive users have less permissions then anonymous users with custom backend

[Django]

#14249: Inactive users have less permissions then anonymous users with custom
backend
-+--
  Reporter:  hvdklauw| Owner:  nobody   
Status:  reopened| Milestone:  1.3  
 Component:  Authentication  |   Version:  1.3-alpha
Resolution:  |  Keywords:   
 Stage:  Accepted| Has_patch:  1
Needs_docs:  0   |   Needs_tests:  0
Needs_better_patch:  0   |  
-+--
Comment (by SmileyChris):

 Er, this is what the changed documentation said, and is also the normal
 deprecation path isn't it?

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

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

Re: [Django] #14249: Inactive users have less permissions then anonymous users with custom backend

[Django]

#14249: Inactive users have less permissions then anonymous users with custom
backend
-+--
  Reporter:  hvdklauw| Owner:  nobody   
Status:  reopened| Milestone:  1.3  
 Component:  Authentication  |   Version:  1.3-alpha
Resolution:  |  Keywords:   
 Stage:  Accepted| Has_patch:  1
Needs_docs:  0   |   Needs_tests:  0
Needs_better_patch:  0   |  
-+--
Changes (by jezdez):

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

Comment:

 Changing this to a pendingdeprecation warning doesn't make sense here,
 since we are going to require to support inactive users in 1.5.

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

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

Re: [Django] #15076: inspectdb to quote ForeignKey class names to avoid need to reorder classes/solve circular dependencies

[Django]

#15076: inspectdb to quote ForeignKey class names to avoid need to reorder
classes/solve circular dependencies
+---
  Reporter:  saschwarz  | Owner:  nobody
Status:  new| Milestone:
 Component:  django-admin.py inspectdb  |   Version:  1.2   
Resolution: |  Keywords:
 Stage:  Design decision needed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Comment (by j...@deserettechnology.com):

 Please see attached patch; it only quotes model names if the model has not
 yet been written out. Is that an acceptable deal? It should prevent
 quoting known model names but still quote model names that have not been
 initialized yet.

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

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

Re: [Django] #10967: save(force_update=True) crashes with model inheritance

[Django]

#10967: save(force_update=True) crashes with model inheritance
---+
  Reporter:  lgs   | Owner:  nobody
Status:  new   | Milestone:  1.3   
 Component:  Database layer (models, ORM)  |   Version:  1.0   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  1 |  
---+
Comment (by anonymous):

 I'd say the #HG comments at the beginning of the patch aren't recognized
 by trac. Maybe remove them manually ?

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

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

Re: [Django] #15084: Unnecessary imports lead to ImportError

[Django]

#15084: Unnecessary imports lead to ImportError
+---
  Reporter:  vanschelven| Owner:  nobody
Status:  new| Milestone:
 Component:  Uncategorized  |   Version:  1.2   
Resolution: |  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by vanschelven):

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

Comment:

 The suggested fix looks a lot better to me than what I came up with. I
 think a better way to phrase it would be "the logic in my solution above
 does not totally replicate the attached patch". Better to use a python
 built in than to "roll your own"

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

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

Re: [Django] #11460: Admin changelist shows no rows with a non-zero count where ForeignKeys are used in list_display and data is bad

[Django]

#11460: Admin changelist shows no rows with a non-zero count where ForeignKeys 
are
used in list_display and data is bad
-+--
  Reporter:  afitzpatrick| Owner:  nobody
Status:  reopened| Milestone:
 Component:  django.contrib.admin|   Version:  1.0   
Resolution:  |  Keywords:
 Stage:  Design decision needed  | Has_patch:  1 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Comment (by anonymous):

 Adding a note to the
 
[http://docs.djangoproject.com/en/1.2/ref/contrib/admin/#django.contrib.admin.ModelAdmin.list_display
 docs] may be enough to save developers some grief (this would have helped
 me).  Maybe something along the lines of: "Inconsistent row counts may be
 caused by missing foreign key values or a foreign key field incorrectly
 set to nullable=False."

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

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

Re: [Django] #15084: Unnecessary imports lead to ImportError

[Django]

#15084: Unnecessary imports lead to ImportError
+---
  Reporter:  vanschelven| Owner:  nobody
Status:  new| Milestone:
 Component:  Uncategorized  |   Version:  1.2   
Resolution: |  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Comment (by j...@deserettechnology.com):

 What about the attached patch? It may not totally replicate the logic in
 your solution above, but appears to do the same thing that Django has been
 doing without actually importing the app.

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

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

Re: [Django] #11667: Full traceback if import error before model validation

[Django]

#11667: Full traceback if import error before model validation
+---
  Reporter:  jedie  | Owner:  nobody
Status:  new| Milestone:
 Component:  django-admin.py runserver  |   Version:  1.1   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  1 
Needs_better_patch:  0  |  
+---
Changes (by vanschelven):

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

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

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

Re: [Django] #11667: Full traceback if import error before model validation

[Django]

#11667: Full traceback if import error before model validation
+---
  Reporter:  jedie  | Owner:  nobody
Status:  new| Milestone:
 Component:  django-admin.py runserver  |   Version:  1.1   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  1 
Needs_better_patch:  0  |  
+---
Comment (by vanschelven):

 Any movement on this?

 I can't count the number of times I've dived into the Django code and
 added a 'raise'. Of course, the proper solution would be simply to drop
 the associated try/catch block, since all it does is obfuscate things.

 This can be rewritten:

 {{{
 206 if self.can_import_settings:
 207 try:
 208 from django.utils import translation
 209 translation.activate('en-us')
 210 except ImportError, e:
 211 # If settings should be available, but aren't,
 212 # raise the error and quit.
 213 sys.stderr.write(smart_str(self.style.ERROR('Error:
 %s\n' % e)))
 214 sys.exit(1)
 }}}

 I'll submit a patch in a sec.

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

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

Re: [Django] #15064: DJANGO_SETTINGS_MODULE doesn't work with runserver

[Django]

#15064: DJANGO_SETTINGS_MODULE doesn't work with runserver
--+-
  Reporter:  olau | Owner:  nobody
Status:  new  | Milestone:
 Component:  django-admin.py  |   Version:  1.2   
Resolution:   |  Keywords:
 Stage:  Accepted | Has_patch:  0 
Needs_docs:  0|   Needs_tests:  0 
Needs_better_patch:  0|  
--+-
Changes (by russellm):

  * needs_better_patch:  => 0
  * stage:  Unreviewed => Accepted
  * component:  Uncategorized => django-admin.py
  * needs_tests:  => 0
  * needs_docs:  => 0

Comment:

 There is an inconsistency here, which should be addressed. manage.py and
 django-admin.py do much more path-fiddling than is good practice, and this
 sort of bug is the result.

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

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

Re: [Django] #15084: Unnecessary imports lead to ImportError

[Django]

#15084: Unnecessary imports lead to ImportError
+---
  Reporter:  vanschelven| Owner:  nobody
Status:  new| Milestone:
 Component:  Uncategorized  |   Version:  1.2   
Resolution: |  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Comment (by vanschelven):

 This is my 'works for me' solution, I can imagine it has some hairy
 consequences (Jython?)

 {{{
 def get_apppath(appname):
 def get(base, parts):
 l0 = [base] + parts + ["__init__.py"]
 l1 = [base] + parts + ["__init__.pyc"]
 if not (os.path.isfile(os.path.join(*l0)) or
 os.path.isfile(os.path.join(*l1))):
 return None
 return os.path.join(l0[:-1])

 import sys
 import os
 parts = appname.split(".")
 for base in sys.path:
 result = get(base, parts)
 if not get(base, parts) is None:
 return os.path.join(base, *parts)
 raise Exception("No such app: %s" % appname)

 }}}

 Combined, obviously, with a call to get_apppath instead of import_module
 in trans_real.py

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

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

Re: [Django] #15081: When running tests you cannot use data that is inserted the /sql/model.sql

[Django]

#15081: When running tests you cannot use data that is inserted the
/sql/model.sql
+---
  Reporter:  maesjoch   | Owner:  nobody
Status:  reopened   | Milestone:
 Component:  Testing framework  |   Version:  1.2   
Resolution: |  Keywords:  custom sql
 Stage:  Accepted   | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by russellm):

  * status:  closed => reopened
  * resolution:  worksforme =>
  * stage:  Unreviewed => Accepted

Comment:

 Following more detail on IRC: This only affects MySQL.

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

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

Re: [Django] #15084: Unnecessary imports lead to ImportError

[Django]

#15084: Unnecessary imports lead to ImportError
+---
  Reporter:  vanschelven| Owner:  nobody
Status:  new| Milestone:
 Component:  Uncategorized  |   Version:  1.2   
Resolution: |  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by vanschelven):

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

Comment:

 I'm not able to reproduce the error in a simple example. It does occur in
 my full project. However, I cannot simply put a full proprietary project
 online. All I can do at this point is hope someone else has a similar
 experience and a simple example.

 I'll also produce the "works for me" patch mentioned 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-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #10809: mod_wsgi authentication handler

[Django]

#10809: mod_wsgi authentication handler
-+--
  Reporter:  baumer1122  | Owner:  davidfischer
Status:  assigned| Milestone:  
 Component:  Authentication  |   Version:  SVN 
Resolution:  |  Keywords:  mod_wsgi
 Stage:  Design decision needed  | Has_patch:  1   
Needs_docs:  0   |   Needs_tests:  0   
Needs_better_patch:  0   |  
-+--
Changes (by anonymous):

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

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

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

Re: [Django] #13007: Django fails to log in when a cookie is set on the same domain containing a colon

[Django]

#13007: Django fails to log in when a cookie is set on the same domain 
containing a
colon
+---
  Reporter:  Warlax | Owner:  nobody
Status:  reopened   | Milestone:  1.3   
 Component:  HTTP handling  |   Version:  SVN   
Resolution: |  Keywords:  cookies, sprintdec2010
 Stage:  Ready for checkin  | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by Ubercore):

 * cc: Ubercore (added)

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

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

Re: [Django] #6773: Confusing error when ForeignKey lookup fails while serializing

[Django]

#6773: Confusing error when ForeignKey lookup fails while serializing
+---
  Reporter:  kcarnold   | Owner:
Status:  new| Milestone:  1.3   
 Component:  Serialization  |   Version:  1.2-alpha 
Resolution: |  Keywords:  dumpdata exception
 Stage:  Fixed on a branch  | Has_patch:  0 
Needs_docs:  1  |   Needs_tests:  1 
Needs_better_patch:  0  |  
+---
Changes (by anonymous):

  * needs_docs:  0 => 1
  * stage:  Design decision needed => Fixed on a branch
  * version:  SVN => 1.2-alpha
  * needs_tests:  0 => 1
  * 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-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #15084: Unnecessary imports lead to ImportError

[Django]

#15084: Unnecessary imports lead to ImportError
---+
 Reporter:  vanschelven|   Owner:  nobody
   Status:  new|   Milestone:
Component:  Uncategorized  | Version:  1.2   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 django/utils/translation/trans_real.py contains

 {{{
  for appname in settings.INSTALLED_APPS:
 app = import_module(appname)
 apppath = os.path.join(os.path.dirname(app.__file__),
 'locale')
 }}}

 As you can see, the only reason apps are imported here is to determine
 their location so a locale path can be tucked on. However, importing apps
 comes at a cost. There are cases in which this import leads to a circular
 reference, leading to the inability of the application to load.

 There may be more locations where this particular loop over INSTALLED_APPS
 leads to problems, though I have not encountered them.

 On a somewhat related note, I don't think Django provides us with an easy
 way to loop over the installed apps. We have models.get_apps, but that
 doesn't work for modelless apps. This might lead to issues such as the one
 I reported here:
 https://github.com/jezdez/django-staticfiles/issues#issue/2

 I'll try to reproduce the negative consequences (the ImportError) in a few
 moments and post the results here. I also have some kind of patch for this
 running in production, but I can imagine it's not really core-proof.
 Evaluation is appreciated.

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

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

Re: [Django] #10967: save(force_update=True) crashes with model inheritance

[Django]

#10967: save(force_update=True) crashes with model inheritance
---+
  Reporter:  lgs   | Owner:  nobody
Status:  new   | Milestone:  1.3   
 Component:  Database layer (models, ORM)  |   Version:  1.0   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  1 |  
---+
Comment (by vanschelven):

 Ok, I added the patch and tests that prove the problem exists. I'm not
 sure why my patch shows so badly in Trac, would gladly resubmit if someone
 has pointers about that.

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

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

Re: [Django] #10967: save(force_update=True) crashes with model inheritance

[Django]

#10967: save(force_update=True) crashes with model inheritance
---+
  Reporter:  lgs   | Owner:  nobody
Status:  new   | Milestone:  1.3   
 Component:  Database layer (models, ORM)  |   Version:  1.0   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  1 |  
---+
Comment (by vanschelven):

 Hi,

 I figured I'd take a look at this problem as it was on the list for 1.3.

 The offending code is indeed in django/db/models/base.py

 {{{
 522 if force_update or non_pks:
 523 values = [(f, None, (raw and getattr(self,
 f.attname) or f.pre_save(self, False))) for f in non_pks]
 524 rows =
 manager.using(using).filter(pk=pk_val)._update(values)
 525 if force_update and values and not rows:
 526 raise DatabaseError("Forced update did not
 affect any rows.")
 }}}

 For a subclass with no fields this loop is executed twice, once for the
 base class and once for its child. The second time values is an empty
 list, therefore rows is 0 and the exception is raised on line 526. I
 propose simply adding a check for values, and only raising an exception if
 values is non-empty. Patch will be attached.

 Klaas

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

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

Re: [Django] #15050: FormWizard URLConf documentation misleading

[Django]

#15050: FormWizard URLConf documentation misleading
-+--
  Reporter:  root+dja...@localdomain.pl  | Owner:  nobody
Status:  new | Milestone:
 Component:  django.contrib.formtools|   Version:  1.2   
Resolution:  |  Keywords:  wizard
 Stage:  Accepted| Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by russellm):

  * needs_better_patch:  => 0
  * component:  Documentation => django.contrib.formtools
  * needs_tests:  => 0
  * keywords:  => wizard
  * needs_docs:  => 0
  * stage:  Unreviewed => Accepted

Comment:

 This isn't just a documentation issue -- it's pointing at a pretty glaring
 hole in the formwizard as currently implemented.

 Essentially, FormWizard needs to be updated to use Django's own class-
 based view structure (which took a long time to finalize specifically
 because of the issue you describe here). The good news is that there is at
 least one effort in the works to do just this -- Stephan Jäkel, has been
 working on [https://github.com/stephrdev/django-formwizard django-
 formwizard] to address this, and a couple of other problems with the
 FormWizard framework (#7439, #9200, #2).

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

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

Re: [Django] #11112: Formsets not supported as steps in FormWizard

[Django]

#2: Formsets not supported as steps in FormWizard
--+-
  Reporter:  hlecuanda   | Owner:  nobody  
 
Status:  new  | Milestone:  
 
 Component:  django.contrib.formtools |   Version:  SVN 
 
Resolution:   |  Keywords:  
FormWizard FormSet wizard
 Stage:  Accepted | Has_patch:  1   
 
Needs_docs:  0|   Needs_tests:  0   
 
Needs_better_patch:  0|  
--+-
Changes (by russellm):

  * keywords:  FormWizard FormSet => FormWizard FormSet wizard

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

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

Re: [Django] #7439: FormWizard don't process multipart forms

[Django]

#7439: FormWizard don't process multipart forms
+---
  Reporter:  Damian Świstowski   | 
Owner:  nobody
Status:  new| 
Milestone:
 Component:  django.contrib.formtools   |   
Version:  SVN   
Resolution: |  
Keywords:  wizard
 Stage:  Accepted   | 
Has_patch:  1 
Needs_docs:  1  |   
Needs_tests:  1 
Needs_better_patch:  1  |  
+---
Changes (by russellm):

  * keywords:  => wizard

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

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

Re: [Django] #15068: initial_data fixtures using natural keys fail in tests with multiple databases

[Django]

#15068: initial_data fixtures using natural keys fail in tests with multiple
databases
+---
  Reporter:  dcramer| Owner:  nobody
Status:  closed | Milestone:
 Component:  Testing framework  |   Version:  1.2   
Resolution:  invalid|  Keywords:
 Stage:  Accepted   | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by russellm):

  * status:  new => closed
  * resolution:  => invalid
  * component:  Uncategorized => Testing framework
  * stage:  Unreviewed => Accepted

Comment:

 I'm having difficulty in seeing how this situation would arise. Fixtures
 can't cross databases, and they are saved raw on the database they're
 being loaded onto. All test databases are created before the first test is
 created. I can't see how a test fixture -- which is loaded after all the
 databases have been configured -- could cause "table does not exist" or
 "database does not exist" errors.

 Closing invalid; As with #15063, feel free to reopen if you can provide a
 comprehensive report that describes (or better yet, demonstrates) exactly
 how this would occur.

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

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

Re: [Django] #15063: multi_db flag on TestCase causes invalid error reporting

[Django]

#15063: multi_db flag on TestCase causes invalid error reporting
+---
  Reporter:  dcramer| 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:

 You appear to be describing a situation where a test database can't
 synchronize all the tables it should have, and as a result, fixture
 loading fails.

 For my money, that situation *should* raise errors.

 I'm not sure I see how this is related to multi-db. Setting multi-db=True
 increases the number of databases that will be synchronized, but it
 doesn't change the way individual databases are synchronized. If you get
 this problem with multi-db, you should be able to reproduce it with a
 single database under the right conditions.

 Closing invalid; if I've missed the point, feel free to reopen and provide
 more detail. For the record, you should also feel free to provide
 sufficient detail when you open a ticket in the first place :-)

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

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

Re: [Django] #15054: ContentTypes and proxied models

[Django]

#15054: ContentTypes and proxied models
---+
  Reporter:  jakedrake | Owner:  nobody  
Status:  closed| Milestone:  
 Component:  Contrib apps  |   Version:  1.2 
Resolution:  duplicate |  Keywords:  contentype proxy
 Stage:  Unreviewed| Has_patch:  0   
Needs_docs:  0 |   Needs_tests:  0   
Needs_better_patch:  0 |  
---+
Changes (by russellm):

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

Comment:

 I'm going to mark this one a duplicate. It isn't exactly the same
 presentation as #14492 or #11154, but the root cause is the same -- an
 inconsistency with the understanding of whether a proxy model is the same
 content type or a different content type. Having another open ticket
 doesn't help clarify the underlying problem.

 I'm loathed to introduce a new meta setting like you describe, but given
 the widespread usage of Proxy classes (and the conflict in understanding
 what it means), it may be the only way to resolve the problem.#

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

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

Re: [Django] #811: [patch] IPv6 address field support

[Django]

#811: [patch] IPv6 address field support
-+--
  Reporter:  mattimust...@gmail.com  | Owner:  adrian   
  
Status:  reopened| Milestone:   
  
 Component:  Core framework  |   Version:  SVN  
  
Resolution:  |  Keywords:  ipv6 
IPAddressField
 Stage:  Accepted| Has_patch:  1
  
Needs_docs:  0   |   Needs_tests:  0
  
Needs_better_patch:  0   |  
-+--
Changes (by anonymous):

 * cc: simon-dja...@captainsubtle.com (added)

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

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

Re: [Django] #14492: Model proxy instance does not equal the respective model instance

[Django]

#14492: Model proxy instance does not equal the respective model instance
---+
  Reporter:  bruth | Owner:  bruth
Status:  assigned  | 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 |  
---+
Comment (by russellm):

 #15054 is another presentation of the same underlying issue (what is a
 proxy).

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

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

Re: [Django] #11154: Inconsistency with permissions for proxy models

[Django]

#11154: Inconsistency with permissions for proxy models
-+--
  Reporter:  etianen | Owner:  nobody
Status:  new | Milestone:  1.3   
 Component:  Authentication  |   Version:  SVN   
Resolution:  |  Keywords:
 Stage:  Accepted| Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Comment (by russellm):

 #14492 and #15054 describe very closely related problems.

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

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

Re: [Django] #15083: TemplateResponse doesn't use custom per-request URLConf

[Django]

#15083: TemplateResponse doesn't use custom per-request URLConf
+---
  Reporter:  russellm   | Owner:  nobody 
Status:  new| Milestone:  1.3
 Component:  Generic views  |   Version:  1.2
Resolution: |  Keywords:  blocker
 Stage:  Accepted   | Has_patch:  0  
Needs_docs:  0  |   Needs_tests:  0  
Needs_better_patch:  0  |  
+---
Changes (by russellm):

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

Comment:

 I suspect the fix here will be to reorganize the logic so that the
 TemplateResponse is rendered before the URLConf is reset.

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

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

[Django] #15083: TemplateResponse doesn't use custom per-request URLConf

[Django]

#15083: TemplateResponse doesn't use custom per-request URLConf
---+
 Reporter:  russellm   |   Owner:  nobody
   Status:  new|   Milestone:  1.3   
Component:  Generic views  | Version:  1.2   
 Keywords:  blocker|   Stage:  Unreviewed
Has_patch:  0  |  
---+
 via Sayane on django-dev mailing list:

 There is a problem with TemplateResponse and request.urlconf. Custom
 urlconf is removed[1] before TemplateResponse is rendered. This means that
 any call to reverse() when rendering template will use default urlconf
 (from settings). This makes TemplateResponse useless when using custom
 urlconf.

 [1]
 
http://code.djangoproject.com/browser/django/trunk/django/core/handlers/base.py#L166

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

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

Re: [Django] #15026: Test failures in django.contrib.sessions on default project when memcached used as CACHE_BACKEND

[Django]

#15026: Test failures in django.contrib.sessions on default project when 
memcached
used as CACHE_BACKEND
--+-
  Reporter:  jsdalton | Owner:  nobody
Status:  new  | Milestone:  1.3   
 Component:  django.contrib.sessions  |   Version:  SVN   
Resolution:   |  Keywords:
 Stage:  Accepted | Has_patch:  1 
Needs_docs:  0|   Needs_tests:  0 
Needs_better_patch:  1|  
--+-
Comment (by jsdalton):

 Thanks for fixing the status.

 To answer your question regarding the patch:

 I basically took the "do the least possible that works" route and
 essentially just improved what was in the existing test code. This test
 function was already attempting to delete the session it created via
 `session.delete()`, but that command was leaving an orphan session record
 in the cache with a key of '1'. So all I really did here was explicitly
 remove that orphaned session as well, and wrapped it up in a try/finally
 block to ensure it was executed. I think that's indeed sufficient to clean
 up this particular test, and there are no other session tests involving
 the cache that create these orphaned records. Note that this test
 (test_invalid_key) is the only test to create it's own session in a local
 variable. The rest in general use the instance variable `self.session`
 which is deleted in the `tearDown` method.

 That said:

 I would agree that tear down for the cache is not being handled very well
 in comparison with the database and the file backends. For the database,
 it's already getting cleaned at the end of every test in the Django test
 suite. For the file backend, there is some extra code in the tearDown
 method that basically just deletes all the files created. The cache
 backend tests have no such method, so basically anything that is not being
 explicitly deleted *is* being left in around in the cache. Ideally, we'd
 create a tearDown method for the cache backend tests that cleared out all
 the junk we had put in there. However, to my knowledge at least, there is
 no good way of cleaning up the cache easily. (Using `cache.clear()` was
 the quick and dirty solution, but I discarded that idea for the reasons
 cited in my other comment.)

 Anyhow, I don't have any great ideas for how to remove what was created in
 the cache during these runs without specifically targeting the records
 created. If you think there's another approach that might work, I'd be
 happy to consider it and submit a patch if there was a feasible way to
 implement it.

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

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

Re: [Django] #15082: delete() does not function consistently with CharField PKs

[Django]

#15082: delete() does not function consistently with CharField PKs
-+--
  Reporter:  w004dal | Owner:  nobody   
Status:  closed  | Milestone:   
 Component:  Core framework  |   Version:  1.2  
Resolution:  invalid |  Keywords:  model, db
 Stage:  Unreviewed  | Has_patch:  0
Needs_docs:  1   |   Needs_tests:  0
Needs_better_patch:  0   |  
-+--
Comment (by w004dal):

 Please reopen this bug to at least improve the documentation on
 http://docs.djangoproject.com/en/dev/topics/db/queries to include this
 subtlety.

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

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

Re: [Django] #15082: delete() does not function consistently with CharField PKs

[Django]

#15082: delete() does not function consistently with CharField PKs
-+--
  Reporter:  w004dal | Owner:  nobody   
Status:  closed  | Milestone:   
 Component:  Core framework  |   Version:  1.2  
Resolution:  invalid |  Keywords:  model, db
 Stage:  Unreviewed  | Has_patch:  0
Needs_docs:  1   |   Needs_tests:  0
Needs_better_patch:  0   |  
-+--
Comment (by russellm):

 If you have questions, please ask them on django-users.

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

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

Re: [Django] #15082: delete() does not function consistently with CharField PKs

[Django]

#15082: delete() does not function consistently with CharField PKs
-+--
  Reporter:  w004dal | Owner:  nobody   
Status:  closed  | Milestone:   
 Component:  Core framework  |   Version:  1.2  
Resolution:  invalid |  Keywords:  model, db
 Stage:  Unreviewed  | Has_patch:  0
Needs_docs:  1   |   Needs_tests:  0
Needs_better_patch:  0   |  
-+--
Changes (by w004dal):

  * needs_docs:  0 => 1

Comment:

 What is the expected behavior for the class below? {{{ DoesWork }}} should
 be syntactic sugar for DoesNotWorkToo:

 {{{
 class DoesNotWorkToo(models.Model):
 some_key = models.IntegerField(primary_key=True)
 mac_id = models.CharField(max_length=17)
 ip = models.CharField('Host/IP Address', max_length=255)
 }}}

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

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

Re: [Django] #15069: ValidationError message isn't helpful in tracking down the field that fails validation

[Django]

#15069: ValidationError message isn't helpful in tracking down the field that 
fails
validation
--+-
  Reporter:  Steve Steiner   | Owner:  
nobody   
Status:  new  | Milestone:  
 
 Component:  Forms|   Version:  1.2 
 
Resolution:   |  Keywords:  
ValidationError, exception, error message
 Stage:  Accepted | Has_patch:  0   
 
Needs_docs:  0|   Needs_tests:  0   
 
Needs_better_patch:  0|  
--+-
Changes (by russellm):

  * stage:  Unreviewed => Accepted
  * component:  Core framework => Forms
  * milestone:  1.3 =>

Comment:

 A reasonable suggestion; not for 1.3, however, because we have hit feature
 freeze, and this would be a new feature.

 Out of interest, the BaseValidator (on which the min/max value validators
 is based) already does this; but the min/max validation strings don't
 exploit the capability.

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

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

Re: [Django] #15082: delete() does not function consistently with CharField PKs

[Django]

#15082: delete() does not function consistently with CharField PKs
-+--
  Reporter:  w004dal | Owner:  nobody   
Status:  new | Milestone:   
 Component:  Core framework  |   Version:  1.2  
Resolution:  |  Keywords:  model, db
 Stage:  Unreviewed  | Has_patch:  0
Needs_docs:  0   |   Needs_tests:  0
Needs_better_patch:  0   |  
-+--
Changes (by russellm):

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

Old description:

> I'm working with MyISAM tables with MySQL and have the following behavior
> with delete() on Django 1.2.3-1 on Fedora Core 12.
>
> class DoesWork(models.Model):
> mac_id = models.CharField(max_length=17)
> ip = models.CharField('Host/IP Address', max_length=255)
>
> class DoesNotWork(models.Model):
> mac_id = models.CharField(max_length=17, primary_key=True)
> ip = models.CharField('Host/IP Address', max_length=255)
>
> The following works as expected, creating, deleting, and putting the item
> back:
> zz = DoesWork.objects.create(mac_id='99:99:99:99:99:99', ip='127.0.0.1')
> zz.delete() # remove from DB
> zz.save() # it's back in the DB
>
> However, if I use the DoesNotWork model, whose only difference is having
> a CharField as a primary key:
> zz = DoesNotWork.objects.create(mac_id='99:99:99:99:99:99',
> ip='127.0.0.1')
> zz.delete() # remove from DB
> zz.save() # EXCEPTION THROWN:
>
> IntegrityError: (1048, "Column 'mac_id' cannot be null")
>
> I checked by printing out zz.__dict__, and the mac_id was 'None' with the
> DoesNotWork object, but was untouched with the DoesWork object.

New description:

 I'm working with MyISAM tables with MySQL and have the following behavior
 with delete() on Django 1.2.3-1 on Fedora Core 12.
 {{{
 class DoesWork(models.Model):
 mac_id = models.CharField(max_length=17)
 ip = models.CharField('Host/IP Address', max_length=255)

 class DoesNotWork(models.Model):
 mac_id = models.CharField(max_length=17, primary_key=True)
 ip = models.CharField('Host/IP Address', max_length=255)
 }}}
 The following works as expected, creating, deleting, and putting the item
 back:
 {{{
 zz = DoesWork.objects.create(mac_id='99:99:99:99:99:99', ip='127.0.0.1')
 zz.delete() # remove from DB
 zz.save() # it's back in the DB
 }}}
 However, if I use the DoesNotWork model, whose only difference is having a
 CharField as a primary key:
 {{{
 zz = DoesNotWork.objects.create(mac_id='99:99:99:99:99:99',
 ip='127.0.0.1')
 zz.delete() # remove from DB
 zz.save() # EXCEPTION THROWN:

 IntegrityError: (1048, "Column 'mac_id' cannot be null")
 }}}
 I checked by printing out zz.!__dict!__, and the mac_id was 'None' with
 the DoesNotWork object, but was untouched with the DoesWork object.

Comment:

 Corrected formatting. Please use preview.

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

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

Re: [Django] #15082: delete() does not function consistently with CharField PKs

[Django]

#15082: delete() does not function consistently with CharField PKs
-+--
  Reporter:  w004dal | Owner:  nobody   
Status:  closed  | Milestone:   
 Component:  Core framework  |   Version:  1.2  
Resolution:  invalid |  Keywords:  model, db
 Stage:  Unreviewed  | Has_patch:  0
Needs_docs:  0   |   Needs_tests:  0
Needs_better_patch:  0   |  
-+--
Changes (by russellm):

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

Comment:

 This is working as expected. When you delete the object, it's primary key
 is set to None. In the model DoesNotWork, the primary key is manually
 allocated, so subsequent saves are prevented. In the model DoesWork, the
 primary key is automatically allocated, so a new object is inserted.

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

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

Re: [Django] #15080: collectstatic with fabric example should use -v0 to speed it up

[Django]

#15080: collectstatic with fabric example should use -v0 to speed it up
+---
  Reporter:  hvdklauw   | Owner:  nobody

Status:  new| Milestone:  1.3   

 Component:  Documentation  |   Version:  1.3-beta  

Resolution: |  Keywords:  staticfiles, 
collectstatic, fabric
 Stage:  Ready for checkin  | Has_patch:  1 

Needs_docs:  0  |   Needs_tests:  0 

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

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

Re: [Django] #15079: django/core/cache/__init__.py missing import

[Django]

#15079: django/core/cache/__init__.py missing import
+---
  Reporter:  jaylett| Owner:  nobody 
Status:  new| Milestone:  1.3
 Component:  Cache system   |   Version:  SVN
Resolution: |  Keywords:  blocker
 Stage:  Ready for checkin  | Has_patch:  0  
Needs_docs:  0  |   Needs_tests:  0  
Needs_better_patch:  0  |  
+---
Changes (by russellm):

  * keywords:  => blocker
  * needs_better_patch:  => 0
  * stage:  Unreviewed => Ready for checkin
  * needs_tests:  => 0
  * needs_docs:  => 0

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

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

Re: [Django] #15066: GzipMiddleware does not work with generator-created responses

[Django]

#15066: GzipMiddleware does not work with generator-created responses
--+-
  Reporter:  Andreas Sommer   | Owner:  nobody
Status:  closed   | Milestone:
 Component:  Uncategorized|   Version:  SVN   
Resolution:  duplicate|  Keywords:  gzip  
 Stage:  Unreviewed   | Has_patch:  1 
Needs_docs:  0|   Needs_tests:  0 
Needs_better_patch:  0|  
--+-
Changes (by russellm):

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

Comment:

 Duplicate of #7581.

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

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

Re: [Django] #15077: Error in documentation for running Django on a shared-hosting provider with Apache

[Django]

#15077: Error in documentation for running Django on a shared-hosting provider 
with
Apache
+---
  Reporter:  MarkusH| Owner:  nobody  
Status:  new| Milestone:  
 Component:  Documentation  |   Version:  1.2 
Resolution: |  Keywords:  htaccess
 Stage:  Accepted   | Has_patch:  1   
Needs_docs:  0  |   Needs_tests:  0   
Needs_better_patch:  0  |  
+---
Changes (by russellm):

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

Comment:

 The documentation is correct, providing you're using mod_fastcgi. If
 you're using mod_fcgid, the script name you give is correct. The docs need
 to be clarified about this distinction.

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

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

[Django] #15082: delete() does not function consistently with CharField PKs

[Django]

#15082: delete() does not function consistently with CharField PKs
+---
 Reporter:  w004dal |   Owner:  nobody
   Status:  new |   Milestone:
Component:  Core framework  | Version:  1.2   
 Keywords:  model, db   |   Stage:  Unreviewed
Has_patch:  0   |  
+---
 I'm working with MyISAM tables with MySQL and have the following behavior
 with delete() on Django 1.2.3-1 on Fedora Core 12.

 class DoesWork(models.Model):
 mac_id = models.CharField(max_length=17)
 ip = models.CharField('Host/IP Address', max_length=255)

 class DoesNotWork(models.Model):
 mac_id = models.CharField(max_length=17, primary_key=True)
 ip = models.CharField('Host/IP Address', max_length=255)

 The following works as expected, creating, deleting, and putting the item
 back:
 zz = DoesWork.objects.create(mac_id='99:99:99:99:99:99', ip='127.0.0.1')
 zz.delete() # remove from DB
 zz.save() # it's back in the DB

 However, if I use the DoesNotWork model, whose only difference is having a
 CharField as a primary key:
 zz = DoesNotWork.objects.create(mac_id='99:99:99:99:99:99',
 ip='127.0.0.1')
 zz.delete() # remove from DB
 zz.save() # EXCEPTION THROWN:

 IntegrityError: (1048, "Column 'mac_id' cannot be null")

 I checked by printing out zz.__dict__, and the mac_id was 'None' with the
 DoesNotWork object, but was untouched with the DoesWork object.

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

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

Re: [Django] #15067: base36_to_int returns a long in certain situations

[Django]

#15067: base36_to_int returns a long in certain situations
-+--
  Reporter:  Garthex | Owner:  nobody
Status:  new | Milestone:
 Component:  Core framework  |   Version:  1.2   
Resolution:  |  Keywords:
 Stage:  Accepted| Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by russellm):

  * stage:  Unreviewed => Accepted

Comment:

 I suspect the answer here will be to only allow 12 digits instead of 13.
 That will allow integers up to 4738381338321616895 instead of
 9223372036854775807, but (ahem) that should be enough for anybody.

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

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

Re: [Django] #15071: Fix the text in the footer in the documentation

[Django]

#15071: Fix the text in the footer in the documentation
--+-
  Reporter:  aruseni  | Owner:  nobody
Status:  new  | Milestone:
 Component:  Django Web site  |   Version:  1.2   
Resolution:   |  Keywords:
 Stage:  Accepted | Has_patch:  0 
Needs_docs:  0|   Needs_tests:  0 
Needs_better_patch:  0|  
--+-
Changes (by russellm):

  * needs_better_patch:  => 0
  * stage:  Unreviewed => Accepted
  * component:  Uncategorized => Django Web site
  * needs_tests:  => 0
  * needs_docs:  => 0

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

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

Re: [Django] #15058: sys.path.append()

[Django]

#15058: sys.path.append()
+---
  Reporter:  daghenrik  | Owner:  nobody
Status:  reopened   | Milestone:
 Component:  Documentation  |   Version:  1.2   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by russellm):

  * status:  closed => reopened
  * resolution:  wontfix =>
  * component:  Uncategorized => Documentation
  * stage:  Unreviewed => Accepted

Comment:

 No - wait - on second reading -- our docs could be a little clearer. It
 isn't (necessarily) as simple as just putting the second entry in your
 PYTHONPATH, but that will be a common solution.

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

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

Re: [Django] #15059: Additional Documentation for the objects in the admin templates

[Django]

#15059: Additional Documentation for the objects in the admin templates
+---
  Reporter:  mlakewood  | Owner:  nobody  
Status:  new| Milestone:  
 Component:  Documentation  |   Version:  1.2 
Resolution: |  Keywords:  admin templates override
 Stage:  Accepted   | Has_patch:  0   
Needs_docs:  0  |   Needs_tests:  0   
Needs_better_patch:  0  |  
+---
Changes (by russellm):

  * needs_better_patch:  => 0
  * stage:  Unreviewed => Accepted
  * component:  Uncategorized => Documentation
  * needs_tests:  => 0
  * needs_docs:  => 0

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

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

Re: [Django] #15061: Remove redundant code in ModelFormMixin

[Django]

#15061: Remove redundant code in ModelFormMixin
+---
  Reporter:  rasca  | Owner:  rasca
Status:  assigned   | Milestone:  1.3  
 Component:  Generic views  |   Version:  SVN  
Resolution: |  Keywords:   
 Stage:  Ready for checkin  | Has_patch:  1
Needs_docs:  0  |   Needs_tests:  0
Needs_better_patch:  0  |  
+---
Changes (by russellm):

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

Re: [Django] #15062: r14389 breaks getattr on Manager subclasses

[Django]

#15062: r14389 breaks getattr on Manager subclasses
---+
  Reporter:  clelland  | Owner:  nobody 
   
Status:  reopened  | Milestone:  1.3
   
 Component:  Database layer (models, ORM)  |   Version:  SVN
   
Resolution:|  Keywords:  regression 
blocker
 Stage:  Accepted  | Has_patch:  0  
   
Needs_docs:  0 |   Needs_tests:  0  
   
Needs_better_patch:  0 |  
---+
Changes (by russellm):

  * stage:  Unreviewed => Accepted

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

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

Re: [Django] #15058: sys.path.append()

[Django]

#15058: sys.path.append()
+---
  Reporter:  daghenrik  | Owner:  nobody
Status:  closed | Milestone:
 Component:  Uncategorized  |   Version:  1.2   
Resolution:  wontfix|  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by russellm):

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

Comment:

 I'm going to mark this wontfix --

  * It's a mod_wsgi configuration issue
  * Django's mod_wsgi docs state (correctly) that you need to have the
 project PYTHONPATH configured
  * The mod_wsgi Django docs describe this specific issue and the solution
  * Django's mod_wsgi docs points at the mod_wsgi Django 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-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #15056: 'NoneType' object is not callable (smart_unicode is None)

[Django]

#15056: 'NoneType' object is not callable (smart_unicode is None)
+---
  Reporter:  kenseehart | 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
  * resolution:  => invalid

Comment:

 Closing invalid; this report doesn't contain enough detail to reproduce
 the problem, and as Karen suggests, it is suggestive of a corrupt install.
 Feel free to reopen if you can provide specific instructions for
 reproducing the problem.

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

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

Re: [Django] #15048: Test failing on Python 2.4 since year 2011 :)

[Django]

#15048: Test failing on Python 2.4 since year 2011 :)
+---
  Reporter:  lrekucki   | Owner:  nobody 
Status:  new| Milestone:  1.3
 Component:  Generic views  |   Version:  SVN
Resolution: |  Keywords:  blocker
 Stage:  Accepted   | Has_patch:  0  
Needs_docs:  0  |   Needs_tests:  0  
Needs_better_patch:  0  |  
+---
Changes (by russellm):

  * needs_better_patch:  => 0
  * needs_tests:  => 0
  * milestone:  => 1.3
  * keywords:  => blocker
  * needs_docs:  => 0
  * stage:  Unreviewed => Accepted

Comment:

 Method based generic views are affected -- they're just not tested as
 robustly as the new generic views.

 Since this is a known failure in Python that has been fixed in subsequent
 releases, the fix probably lies in fixing the test suite to avoid the
 problematic date -- the test is just validating that a future date is
 rejected unless configured to be allowed, so if the test checks for week 1
 rather than week 0, for example, the bug doesn't appear.

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

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

Re: [Django] #15062: r14389 breaks getattr on Manager subclasses

[Django]

#15062: r14389 breaks getattr on Manager subclasses
---+
  Reporter:  clelland  | Owner:  nobody 
   
Status:  reopened  | Milestone:  1.3
   
 Component:  Database layer (models, ORM)  |   Version:  SVN
   
Resolution:|  Keywords:  regression 
blocker
 Stage:  Unreviewed| Has_patch:  0  
   
Needs_docs:  0 |   Needs_tests:  0  
   
Needs_better_patch:  0 |  
---+
Changes (by kmtracey):

  * keywords:  => regression blocker

Comment:

 Marking as regression since what worked in 1.2.3 is breaking in 1.2.4. I
 don't know if a fix is possible, but if not this might warrant at least a
 note in the release notes...I know of one project that had to back off
 1.2.4 due to running into this (plus another regression that has been
 fixed).

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

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

Re: [Django] #15081: When running tests you cannot use data that is inserted the /sql/model.sql

[Django]

#15081: When running tests you cannot use data that is inserted the
/sql/model.sql
+---
  Reporter:  maesjoch   | Owner:  nobody
Status:  closed | Milestone:
 Component:  Testing framework  |   Version:  1.2   
Resolution:  worksforme |  Keywords:  custom sql
 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
  * needs_tests:  => 0
  * needs_docs:  => 0
  * resolution:  => worksforme

Old description:

> Consider following case:
> #model
> class sqltest(models.Model):
>
> name = models.CharField(max_length=100, unique=True)
>
> #test
>
> from django.test import TestCase
> from testapp.app_test.models import sqltest
>
> class SimpleTest(TestCase):
> def test_basic_addition(self):
> s = sqltest.objects.get(name='test1')
> self.assertTrue(s)
>

> #in /sql/sqltest.py
> insert into app_test_sqltest (name) values ('test1');
> insert into app_test_sqltest (name) values ('test2');
> insert into app_test_sqltest (name) values ('test3');
>

> When running your tests will not find the test1 entry. This is not
> consistent with how django docs explain it (although not that much
> testing information on custom sql).
>
> Was this by design or is it an actual bug I do not know.

New description:

 Consider following case:

 #model
 {{{
 class sqltest(models.Model):

 name = models.CharField(max_length=100, unique=True)
 }}}

 #test
 {{{
 from django.test import TestCase
 from testapp.app_test.models import sqltest

 class SimpleTest(TestCase):
 def test_basic_addition(self):
 s = sqltest.objects.get(name='test1')
 self.assertTrue(s)
 }}}

 #in /sql/sqltest.py
 {{{
 insert into app_test_sqltest (name) values ('test1');
 insert into app_test_sqltest (name) values ('test2');
 insert into app_test_sqltest (name) values ('test3');
 }}}

 When running your tests will not find the test1 entry. This is not
 consistent with how django docs explain it (although not that much testing
 information on custom sql).

 Was this by design or is it an actual bug I do not know.

Comment:

 I can't reproduce this. The test described passes as expected for me under
 SQLite and Postgres.

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

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

Re: [Django] #8190: Utilise help_text for TabularInline in Admin

[Django]

#8190: Utilise help_text for TabularInline in Admin
---+
  Reporter:  glenjamin | Owner:  nobody
Status:  new   | Milestone:
 Component:  django.contrib.admin  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by glic3rinu):

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

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

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

Re: [Django] #10060: Multiple table annotation failure

[Django]

#10060: Multiple table annotation failure
--+-
  Reporter:  svsha...@intellecap.net  | Owner: 
Status:  new  | Milestone: 
 Component:  ORM aggregation  |   Version:  SVN
Resolution:   |  Keywords: 
 Stage:  Accepted | Has_patch:  0  
Needs_docs:  0|   Needs_tests:  0  
Needs_better_patch:  0|  
--+-
Comment (by thamedave):

 Another victim.

 This bug means that you can't use annotations at all unless you know
 exactly what is going to happen to your QuerySet later.  Functions cannot
 expect that any QuerySet passed as a parameter is capable of being
 annotated as it may already have been done.

 I am a reasonably to Django, but it seems odd to me that this has remained
 a known bug for 2 years without anyone working on it, or a the
 documentation being changed to reflect the lack of functionality.  I
 understand russell's logic that bugs should not be documented, but if this
 cannot be fixed, then surely it should be removed from intended 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-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #10972: Use Expressions with Annotations

[Django]

#10972: Use Expressions with Annotations
--+-
  Reporter:  m...@donaldrichardson.net  | Owner:
  
Status:  new  | Milestone:  

 Component:  ORM aggregation  |   Version:  SVN 

Resolution:   |  Keywords:  expression 
aggregation aggregates annotation
 Stage:  Accepted | Has_patch:  1   

Needs_docs:  0|   Needs_tests:  0   

Needs_better_patch:  1|  
--+-
Changes (by danfairs):

 * cc: danfairs (added)

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

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

Re: [Django] #5833: Custom FilterSpecs

[Django]

#5833: Custom FilterSpecs
---+
  Reporter:  Honza_Kral| Owner:  jkocherhans
 
Status:  assigned  | Milestone: 
 
 Component:  django.contrib.admin  |   Version:  SVN
 
Resolution:|  Keywords:  nfa-someday 
list_filter filterspec nfa-changelist ep2008
 Stage:  Accepted  | Has_patch:  1  
 
Needs_docs:  1 |   Needs_tests:  1  
 
Needs_better_patch:  0 |  
---+
Changes (by shanx):

 * cc: re...@maykinmedia.nl (added)

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

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

[Django] #15081: When running tests you cannot use data that is inserted the /sql/model.sql

[Django]

#15081: When running tests you cannot use data that is inserted the
/sql/model.sql
---+
 Reporter:  maesjoch   |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Testing framework  | Version:  1.2   
 Keywords:  custom sql |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 Consider following case:
 #model
 class sqltest(models.Model):

 name = models.CharField(max_length=100, unique=True)

 #test

 from django.test import TestCase
 from testapp.app_test.models import sqltest

 class SimpleTest(TestCase):
 def test_basic_addition(self):
 s = sqltest.objects.get(name='test1')
 self.assertTrue(s)


 #in /sql/sqltest.py
 insert into app_test_sqltest (name) values ('test1');
 insert into app_test_sqltest (name) values ('test2');
 insert into app_test_sqltest (name) values ('test3');


 When running your tests will not find the test1 entry. This is not
 consistent with how django docs explain it (although not that much testing
 information on custom sql).

 Was this by design or is it an actual bug I do not know.

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

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

Re: [Django] #15080: collectstatic with fabric example should use -v0 to speed it up

[Django]

#15080: collectstatic with fabric example should use -v0 to speed it up
---+
  Reporter:  hvdklauw  | Owner:  nobody 
   
Status:  new   | Milestone:  1.3
   
 Component:  Contrib apps  |   Version:  1.3-beta   
   
Resolution:|  Keywords:  staticfiles, 
collectstatic, fabric
 Stage:  Unreviewed| Has_patch:  1  
   
Needs_docs:  0 |   Needs_tests:  0  
   
Needs_better_patch:  0 |  
---+
Changes (by hvdklauw):

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

[Django] #15080: collectstatic with fabric example should use -v0 to speed it up

[Django]

#15080: collectstatic with fabric example should use -v0 to speed it up
+---
 Reporter:  hvdklauw|   Owner:  nobody
   Status:  new |   Milestone:  1.3   
Component:  Contrib apps| Version:  1.3-beta  
 Keywords:  staticfiles, collectstatic, fabric  |   Stage:  Unreviewed
Has_patch:  0   |  
+---
 I found out that using collectstatic through fabric makes for a very slow
 process.
 The reason is that collectstatic by default outputs all the files it's
 collecting, which fabric has to pipe, which makes it very slow.

 The fix is simple: pass a -v0
 Also a --noinput should be added because fabric doesn't support the
 interactivity till 1.0 is released.

 I think the documentation should reflect this

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

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

[Django] #15079: django/core/cache/__init__.py missing import

[Django]

#15079: django/core/cache/__init__.py missing import
--+-
 Reporter:  jaylett   |   Owner:  nobody
   Status:  new   |   Milestone:  1.3   
Component:  Cache system  | Version:  SVN   
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 On creating settings.CACHE without a default, Django tries to raise
 ImproperlyConfigured, but cannot because it's not defined in
 django/core/cache/__init__.py. It needs:

 from django.core.exceptions import ImproperlyConfigured

 in the imports.

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

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

[Changeset] r15204 - in django/trunk: django/contrib/auth docs/releases docs/topics

[noreply]

Author: SmileyChris
Date: 2011-01-14 02:31:14 -0600 (Fri, 14 Jan 2011)
New Revision: 15204

Modified:
   django/trunk/django/contrib/auth/__init__.py
   django/trunk/docs/releases/1.3.txt
   django/trunk/docs/topics/auth.txt
Log:
Change the lack of supports_inactive_user on an auth backend to a
!PendingDeprecationWarning (refs #14249), fixing some bad links in the
1.3 release docs and a typo.

Modified: django/trunk/django/contrib/auth/__init__.py
===
--- django/trunk/django/contrib/auth/__init__.py2011-01-14 05:04:14 UTC 
(rev 15203)
+++ django/trunk/django/contrib/auth/__init__.py2011-01-14 08:31:14 UTC 
(rev 15204)
@@ -33,7 +33,7 @@
 
 if not hasattr(cls, 'supports_inactive_user'):
 warn("Authentication backends without a `supports_inactive_user` 
attribute are deprecated. Please define it in %s." % cls,
- DeprecationWarning)
+ PendingDeprecationWarning)
 cls.supports_inactive_user = False
 return cls()
 

Modified: django/trunk/docs/releases/1.3.txt
===
--- django/trunk/docs/releases/1.3.txt  2011-01-14 05:04:14 UTC (rev 15203)
+++ django/trunk/docs/releases/1.3.txt  2011-01-14 08:31:14 UTC (rev 15204)
@@ -151,7 +151,7 @@
 the response. The final output of the response is not computed until
 it is needed, later in the response process.
 
-For more details, see the :ref:`documentation `
+For more details, see the :doc:`documentation `
 on the :class:`~django.template.TemplateResponse` class.
 
 Caching changes
@@ -172,8 +172,8 @@
 Lastly, support for pylibmc_ has been added to the memcached cache
 backend.
 
-For more details, see the :ref:`documentation on
-caching in Django`.
+For more details, see the :doc:`documentation on
+caching in Django`.
 
 .. _pylibmc: http://sendapatch.se/projects/pylibmc/
 
@@ -183,7 +183,7 @@
 If you provide a custom auth backend with ``supports_inactive_user`` set to
 ``True``, an inactive user model will check the backend for permissions.
 This is useful for further centralizing the permission handling. See the
-:ref:`authentication docs ` for more details.
+:doc:`authentication docs ` for more details.
 
 GeoDjango
 ~

Modified: django/trunk/docs/topics/auth.txt
===
--- django/trunk/docs/topics/auth.txt   2011-01-14 05:04:14 UTC (rev 15203)
+++ django/trunk/docs/topics/auth.txt   2011-01-14 08:31:14 UTC (rev 15204)
@@ -1644,7 +1644,7 @@
 
 An inactive user is a one that is authenticated but has its attribute
 ``is_active`` set to ``False``. However this does not mean they are not
-authrozied to do anything. For example they are allowed to activate their
+authorized to do anything. For example they are allowed to activate their
 account.
 
 The support for anonymous users in the permission system allows for

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