Re: [Django] #14269: It is impossible to run full Django test suite on Oracle because there is 100m maxsize limit for test tablespace

[Django]

#14269: It is impossible to run full Django test suite on Oracle because there 
is
100m maxsize limit  for test tablespace
---+
  Reporter:  andrewsk  | Owner:  andrewsk
Status:  closed| Milestone:  
 Component:  Database layer (models, ORM)  |   Version:  SVN 
Resolution:  duplicate |  Keywords:  
 Stage:  Accepted  | Has_patch:  1   
Needs_docs:  0 |   Needs_tests:  0   
Needs_better_patch:  0 |  
---+
Changes (by russellm):

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

Comment:

 This was duplicated and then closed (with an almost identical patch) as
 #14630.

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

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

Re: [Django] #14628: Document which settings can be changed at runtime

[Django]

#14628: Document which settings can be changed at runtime
+---
  Reporter:  NicoEchaniz| Owner:  nobody  
Status:  new| Milestone:  
 Component:  Documentation  |   Version:  1.2 
Resolution: |  Keywords:  settings django.conf
 Stage:  Accepted   | Has_patch:  0   
Needs_docs:  0  |   Needs_tests:  0   
Needs_better_patch:  0  |  
+---
Changes (by NicoEchaniz):

 * cc: n...@rakar.com (added)

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

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

[Changeset] r14496 - django/branches/releases/1.2.X/tests/regressiontests/templates

[noreply]

Author: russellm
Date: 2010-11-07 22:42:13 -0600 (Sun, 07 Nov 2010)
New Revision: 14496

Modified:
   django/branches/releases/1.2.X/tests/regressiontests/templates/context.py
   django/branches/releases/1.2.X/tests/regressiontests/templates/custom.py
   django/branches/releases/1.2.X/tests/regressiontests/templates/parser.py
   django/branches/releases/1.2.X/tests/regressiontests/templates/unicode.py
Log:
[1.2.X] Corrected some backporting errors in the template tests.

Modified: 
django/branches/releases/1.2.X/tests/regressiontests/templates/context.py
===
--- django/branches/releases/1.2.X/tests/regressiontests/templates/context.py   
2010-11-07 23:10:35 UTC (rev 14495)
+++ django/branches/releases/1.2.X/tests/regressiontests/templates/context.py   
2010-11-08 04:42:13 UTC (rev 14496)
@@ -1,6 +1,7 @@
 # coding: utf-8
+from unittest import TestCase
+
 from django.template import Context
-from django.utils.unittest import TestCase
 
 
 class ContextTests(TestCase):

Modified: 
django/branches/releases/1.2.X/tests/regressiontests/templates/custom.py
===
--- django/branches/releases/1.2.X/tests/regressiontests/templates/custom.py
2010-11-07 23:10:35 UTC (rev 14495)
+++ django/branches/releases/1.2.X/tests/regressiontests/templates/custom.py
2010-11-08 04:42:13 UTC (rev 14496)
@@ -1,5 +1,6 @@
+from unittest import TestCase
+
 from django import template
-from django.utils.unittest import TestCase
 
 
 class CustomTests(TestCase):

Modified: 
django/branches/releases/1.2.X/tests/regressiontests/templates/parser.py
===
--- django/branches/releases/1.2.X/tests/regressiontests/templates/parser.py
2010-11-07 23:10:35 UTC (rev 14495)
+++ django/branches/releases/1.2.X/tests/regressiontests/templates/parser.py
2010-11-08 04:42:13 UTC (rev 14496)
@@ -1,9 +1,10 @@
 """
 Testing some internals of the template processing. These are *not* examples to 
be copied in user code.
 """
+from unittest import TestCase
+
 from django.template import (TokenParser, FilterExpression, Parser, Variable,
 TemplateSyntaxError)
-from django.utils.unittest import TestCase
 
 
 class ParserTests(TestCase):

Modified: 
django/branches/releases/1.2.X/tests/regressiontests/templates/unicode.py
===
--- django/branches/releases/1.2.X/tests/regressiontests/templates/unicode.py   
2010-11-07 23:10:35 UTC (rev 14495)
+++ django/branches/releases/1.2.X/tests/regressiontests/templates/unicode.py   
2010-11-08 04:42:13 UTC (rev 14496)
@@ -1,7 +1,8 @@
 # -*- coding: utf-8 -*-
+from unittest import TestCase
+
 from django.template import Template, TemplateEncodingError, Context
 from django.utils.safestring import SafeData
-from django.utils.unittest import TestCase
 
 
 class UnicodeTests(TestCase):
@@ -25,5 +26,5 @@
 # they all render the same (and are returned as unicode objects and
 # "safe" objects as well, for auto-escaping purposes).
 self.assertEqual(t1.render(c3), t2.render(c3))
-self.assertIsInstance(t1.render(c3), unicode)
-self.assertIsInstance(t1.render(c3), SafeData)
+self.assertTrue(isinstance(t1.render(c3), unicode))
+self.assertTrue(isinstance(t1.render(c3), SafeData))

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

Re: [Django] #14641: grammar and accuracy fixes for documentation

[Django]

#14641: grammar and accuracy fixes for documentation
+---
  Reporter:  programmerq| Owner:  nobody
Status:  new| Milestone:  1.3   
 Component:  Documentation  |   Version:  SVN   
Resolution: |  Keywords:
 Stage:  Ready for checkin  | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by Alex):

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

[Django] #14641: grammar and accuracy fixes for documentation

[Django]

#14641: grammar and accuracy fixes for documentation
---+
 Reporter:  programmerq|   Owner:  nobody
   Status:  new|   Milestone:  1.3   
Component:  Documentation  | Version:  SVN   
 Keywords: |   Stage:  Unreviewed
Has_patch:  1  |  
---+
 I have scanned the docs looking for errors, and came up with these three
 things that needed correcting: incorrect usage of 'its', extraneous word,
 and the PROFANITIES_LIST default value as of changeset [13996].

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

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

Re: [Django] #14640: Add elapsed request time to the development server log

[Django]

#14640: Add elapsed request time to the development server log
+---
  Reporter:  vaughnkoch | Owner:  vaughnkoch
 
Status:  assigned   | Milestone:  1.3   
 
 Component:  HTTP handling  |   Version:  1.2   
 
Resolution: |  Keywords:  log time development 
server
 Stage:  Unreviewed | Has_patch:  1 
 
Needs_docs:  0  |   Needs_tests:  0 
 
Needs_better_patch:  0  |  
+---
Comment (by vaughnkoch):

 Accepted ticket as per instructions in 'Submitting patches' on this site.

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

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

Re: [Django] #14640: Add elapsed request time to the development server log

[Django]

#14640: Add elapsed request time to the development server log
+---
  Reporter:  vaughnkoch | Owner:  vaughnkoch
 
Status:  assigned   | Milestone:  1.3   
 
 Component:  HTTP handling  |   Version:  1.2   
 
Resolution: |  Keywords:  log time development 
server
 Stage:  Unreviewed | Has_patch:  1 
 
Needs_docs:  0  |   Needs_tests:  0 
 
Needs_better_patch:  0  |  
+---
Changes (by vaughnkoch):

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

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

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

[Django] #14640: Add elapsed request time to the development server log

[Django]

#14640: Add elapsed request time to the development server log
---+
   Reporter:  vaughnkoch   |Owner:  nobody
 Status:  new  |Milestone:  1.3   
  Component:  HTTP handling|  Version:  1.2   
   Keywords:  log time development server  |Stage:  Unreviewed
  Has_patch:  1|   Needs_docs:  0 
Needs_tests:  0|   Needs_better_patch:  0 
---+
 When doing performance testing on your code, it's helpful to see how long
 a request takes to be served.
 This ticket/patch adds the elapsed time in seconds to the end of each HTTP
 request line in the development server log.

 Example:
 {{{
 Validating models...
 0 errors found

 Django version 1.2.1, using settings 'weeplaces.settings'
 Development server is running at http://127.0.0.1:8000/
 Quit the server with CTRL-BREAK.
 [07/Nov/2010 15:57:17] "GET / HTTP/1.1" 200 11308 0.26
 [07/Nov/2010 15:57:27] "GET /media/css/reset.css HTTP/1.1" 304 0 0.05
 }}}
 The 0.26 for the first GET request indicates that it took a quarter of a
 second to serve the root page.

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

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

[Changeset] r14495 - django/branches/releases/1.2.X/docs/internals

[noreply]

Author: gabrielhurley
Date: 2010-11-07 17:10:35 -0600 (Sun, 07 Nov 2010)
New Revision: 14495

Modified:
   django/branches/releases/1.2.X/docs/internals/committers.txt
Log:
[1.2.X] Backporting myself to the 1.2.X docs/internals/committers.txt... and 
fixing the typo in Jeremy's bio (again). :)

Backport of [14056] from trunk.

Modified: django/branches/releases/1.2.X/docs/internals/committers.txt
===
--- django/branches/releases/1.2.X/docs/internals/committers.txt
2010-11-07 23:03:47 UTC (rev 14494)
+++ django/branches/releases/1.2.X/docs/internals/committers.txt
2010-11-07 23:10:35 UTC (rev 14495)
@@ -292,7 +292,7 @@
 Matt is also responsible for Django's Oracle support.
 
 Jeremy Dunck
-Jeremy the lead developer of Pegasus News, a personalized local site based
+Jeremy is the lead developer of Pegasus News, a personalized local site 
based
 in Dallas, Texas. An early contributor to Greasemonkey and Django, he sees
 technology as a tool for communication and access to knowledge.
 
@@ -311,6 +311,18 @@
 
 .. _simon meers: http://simonmeers.com/
 
+`Gabriel Hurley`_
+Gabriel has been working with Django since 2008, shortly after the 1.0
+release. Convinced by his business partner that Python and Django were the
+right direction for the company, he couldn't have been more happy with the
+decision. His contributions range across many areas in Django, but years of
+copy-editing and an eye for detail lead him to be particularly at home
+while working on Django's documentation.
+
+Gabriel works as a web developer in Berkeley, CA, USA.
+
+.. _gabriel hurley: http://strikeawe.com/
+
 Developers Emeritus
 ===
 

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

[Changeset] r14494 - django/branches/releases/1.2.X/docs/ref

[noreply]

Author: gabrielhurley
Date: 2010-11-07 17:03:47 -0600 (Sun, 07 Nov 2010)
New Revision: 14494

Modified:
   django/branches/releases/1.2.X/docs/ref/request-response.txt
Log:
[1.2.X] Fixed #11877 -- Documented that HttpRequest.get_host() fails behind 
multiple reverse proxies, and added an example middleware solution. Thanks to 
Tom Evans for the report, and arnav for the patch.

Backport of [14493] from trunk.

Modified: django/branches/releases/1.2.X/docs/ref/request-response.txt
===
--- django/branches/releases/1.2.X/docs/ref/request-response.txt
2010-11-07 23:02:24 UTC (rev 14493)
+++ django/branches/releases/1.2.X/docs/ref/request-response.txt
2010-11-07 23:03:47 UTC (rev 14494)
@@ -189,17 +189,40 @@
 
 .. method:: HttpRequest.get_host()
 
-   .. versionadded:: 1.0
+.. versionadded:: 1.0
 
-   Returns the originating host of the request using information from the
-   ``HTTP_X_FORWARDED_HOST`` and ``HTTP_HOST`` headers (in that order). If
-   they don't provide a value, the method uses a combination of
-   ``SERVER_NAME`` and ``SERVER_PORT`` as detailed in `PEP 333`_.
+Returns the originating host of the request using information from the
+``HTTP_X_FORWARDED_HOST`` and ``HTTP_HOST`` headers (in that order). If
+they don't provide a value, the method uses a combination of
+``SERVER_NAME`` and ``SERVER_PORT`` as detailed in `PEP 333`_.
 
-   .. _PEP 333: http://www.python.org/dev/peps/pep-0333/
+.. _PEP 333: http://www.python.org/dev/peps/pep-0333/
 
-   Example: ``"127.0.0.1:8000"``
+Example: ``"127.0.0.1:8000"``
 
+.. note:: The :meth:`~HttpRequest.get_host()` method fails when the host is
+behind multiple proxies. One solution is to use middleware to rewrite
+the proxy headers, as in the following example::
+
+class MultipleProxyMiddleware(object):
+FORWARDED_FOR_FIELDS = [
+'HTTP_X_FORWARDED_FOR',
+'HTTP_X_FORWARDED_HOST',
+'HTTP_X_FORWARDED_SERVER',
+]
+
+def process_request(self, request):
+"""
+Rewrites the proxy headers so that only the most
+recent proxy is used.
+"""
+for field in self.FORWARDED_FOR_FIELDS:
+if field in request.META:
+if ',' in request.META[field]:
+parts = request.META[field].split(',')
+request.META[field] = parts[-1].strip()
+
+
 .. method:: HttpRequest.get_full_path()
 
Returns the ``path``, plus an appended query string, if applicable.

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

[Changeset] r14493 - django/trunk/docs/ref

[noreply]

Author: gabrielhurley
Date: 2010-11-07 17:02:24 -0600 (Sun, 07 Nov 2010)
New Revision: 14493

Modified:
   django/trunk/docs/ref/request-response.txt
Log:
Fixed #11877 -- Documented that HttpRequest.get_host() fails behind multiple 
reverse proxies, and added an example middleware solution. Thanks to Tom Evans 
for the report, and arnav for the patch.

Modified: django/trunk/docs/ref/request-response.txt
===
--- django/trunk/docs/ref/request-response.txt  2010-11-07 21:46:03 UTC (rev 
14492)
+++ django/trunk/docs/ref/request-response.txt  2010-11-07 23:02:24 UTC (rev 
14493)
@@ -210,17 +210,40 @@
 
 .. method:: HttpRequest.get_host()
 
-   .. versionadded:: 1.0
+.. versionadded:: 1.0
 
-   Returns the originating host of the request using information from the
-   ``HTTP_X_FORWARDED_HOST`` and ``HTTP_HOST`` headers (in that order). If
-   they don't provide a value, the method uses a combination of
-   ``SERVER_NAME`` and ``SERVER_PORT`` as detailed in `PEP 333`_.
+Returns the originating host of the request using information from the
+``HTTP_X_FORWARDED_HOST`` and ``HTTP_HOST`` headers (in that order). If
+they don't provide a value, the method uses a combination of
+``SERVER_NAME`` and ``SERVER_PORT`` as detailed in `PEP 333`_.
 
-   .. _PEP 333: http://www.python.org/dev/peps/pep-0333/
+.. _PEP 333: http://www.python.org/dev/peps/pep-0333/
 
-   Example: ``"127.0.0.1:8000"``
+Example: ``"127.0.0.1:8000"``
 
+.. note:: The :meth:`~HttpRequest.get_host()` method fails when the host is
+behind multiple proxies. One solution is to use middleware to rewrite
+the proxy headers, as in the following example::
+
+class MultipleProxyMiddleware(object):
+FORWARDED_FOR_FIELDS = [
+'HTTP_X_FORWARDED_FOR',
+'HTTP_X_FORWARDED_HOST',
+'HTTP_X_FORWARDED_SERVER',
+]
+
+def process_request(self, request):
+"""
+Rewrites the proxy headers so that only the most
+recent proxy is used.
+"""
+for field in self.FORWARDED_FOR_FIELDS:
+if field in request.META:
+if ',' in request.META[field]:
+parts = request.META[field].split(',')
+request.META[field] = parts[-1].strip()
+
+
 .. method:: HttpRequest.get_full_path()
 
Returns the ``path``, plus an appended query string, if applicable.

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

Re: [Django] #14634: Sessions are unnecessarily complex

[Django]

#14634: Sessions are unnecessarily complex
--+-
  Reporter:  PaulM| Owner:  PaulM
Status:  new  | Milestone:  1.3  
 Component:  django.contrib.sessions  |   Version:  1.2  
Resolution:   |  Keywords:   
 Stage:  Accepted | Has_patch:  0
Needs_docs:  0|   Needs_tests:  0
Needs_better_patch:  0|  
--+-
Comment (by lukeplant):

 Personally I'm in favour of fixing #14579 to enable a cookie backend.

 There is also a pretty good argument for retaining this check even when
 storing the data in a 'trusted' datastore - essentially that not all
 pieces of infrastructure are equally trusted or equally open to attack,
 and layers of security are good.

 Consider a situation where the attacker has write access to the database,
 but not read or write access to the source code of the application. In
 many situations, that will be 'game over' as far as security is concerned,
 but not all. Alternatively, consider the case where the attacker has write
 access to part of the filesystem, or the cache backend, but nothing else,
 and the app is using the filesystem or cache session backend. Now, it is
 relatively easy to create 'pickled' values that will execute arbitrary
 commands when unpickled (not just provide arbitrary values). So, without
 this tamper check, a breach of filesystem/cache/database will escalate
 into the ability to execute arbitrary commands.

 A real life situation where this might occur is a shared hosting
 environment where the '/tmp' directory is used for the filesystem session
 backend — which is the default directory for the filesystem session
 backend. Since this directory is often world-writable (even if the files
 created there are not world readable), an attacker could well use this to
 do arbitrary code injection. A quick check on a server I know suggests
 this might well be a very practical attack since I can see hundreds of
 files in /tmp that appear to be PHP session files.  Although I can't read
 them, I think I can delete them easily, and if they were Django session
 files with no tamper check then I could replace them with some malicious
 data. The owners of the corresponding web apps certainly have some
 security issues - I can delete all of their sessions - but with a tamper
 check in place, it is no worse than that.

 So, I'm pretty strongly in favour of keeping this layer of protection. It
 is a worthwhile check given the escalation of privileges it could prevent
 in some fairly likely situations.

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

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

Re: [Django] #14638: to_python howto documentation improvement

[Django]

#14638: to_python howto documentation improvement
+---
  Reporter:  maraujop   | Owner:  nobody 
Status:  new| Milestone: 
 Component:  Documentation  |   Version:  SVN
Resolution: |  Keywords:  to_python, model, field
 Stage:  Accepted   | Has_patch:  0  
Needs_docs:  0  |   Needs_tests:  0  
Needs_better_patch:  0  |  
+---
Changes (by gabrielhurley):

  * needs_better_patch:  => 0
  * stage:  Unreviewed => Accepted
  * summary:  to_python documentation is not comprehensible => to_python
  howto documentation improvement
  * needs_tests:  => 0
  * needs_docs:  => 0

Comment:

 On the one hand, the docs ''are'' correct. When not using `SubfieldBase`,
 the `to_python()` method gets called (primarily) to convert data returned
 by the DB into the appropriate Python type. It is only when you're using
 `SubfieldBase` that `to_python()` is called on every assignment of a value
 to the field. So the split in the documentation is there for a reason, and
 neither description is wrong.

 On the other hand, I will agree that if you are googling for what
 `to_python()` does you'll likely land on the latter section first, and
 offering a more general introduction to the method and it's various
 ''possible'' uses before launching into the details of its most common use
 would be helpful.

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

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

[Changeset] r14492 - django/branches/releases/1.2.X/docs/topics

[noreply]

Author: ramiro
Date: 2010-11-07 15:46:03 -0600 (Sun, 07 Nov 2010)
New Revision: 14492

Modified:
   django/branches/releases/1.2.X/docs/topics/install.txt
Log:
[1.2.X] Completed and enhanced links to database-specific notes from the 
install docs.

Backport of [14491] from trunk

Modified: django/branches/releases/1.2.X/docs/topics/install.txt
===
--- django/branches/releases/1.2.X/docs/topics/install.txt  2010-11-07 
21:42:11 UTC (rev 14491)
+++ django/branches/releases/1.2.X/docs/topics/install.txt  2010-11-07 
21:46:03 UTC (rev 14492)
@@ -84,22 +84,24 @@
 * If you're using PostgreSQL, you'll need the psycopg_ package. Django supports
   both version 1 and 2. (When you configure Django's database layer, specify
   either ``postgresql`` [for version 1] or ``postgresql_psycopg2`` [for 
version 2].)
+  You might want to refer to our :ref:`PostgreSQL notes ` for
+  further technical details specific to this database.
 
   If you're on Windows, check out the unofficial `compiled Windows version`_.
 
 * If you're using MySQL, you'll need MySQLdb_, version 1.2.1p2 or higher. You
-  will also want to read the database-specific notes for the :doc:`MySQL
-  backend `.
+  will also want to read the database-specific :ref:`notes for the MySQL
+  backend `.
 
 * If you're using SQLite and Python 2.4, you'll need pysqlite_. Use version
   2.0.3 or higher. Python 2.5 ships with an SQLite wrapper in the standard
   library, so you don't need to install anything extra in that case. Please
-  read the SQLite backend :ref:`notes`.
+  read the :ref:`SQLite backend notes `.
 
 * If you're using Oracle, you'll need a copy of cx_Oracle_, but please
-  read the database-specific notes for the
-  :ref:`Oracle backend ` for important information
-  regarding supported versions of both Oracle and ``cx_Oracle``.
+  read the database-specific :ref:`notes for the Oracle backend `
+  for important information regarding supported versions of both Oracle and
+  ``cx_Oracle``.
 
 * If you're using an unofficial 3rd party backend, please consult the
   documentation provided for any additional requirements.

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

[Changeset] r14491 - django/trunk/docs/topics

[noreply]

Author: ramiro
Date: 2010-11-07 15:42:11 -0600 (Sun, 07 Nov 2010)
New Revision: 14491

Modified:
   django/trunk/docs/topics/install.txt
Log:
Completed and enhanced links to database-specific notes from the install docs.

Modified: django/trunk/docs/topics/install.txt
===
--- django/trunk/docs/topics/install.txt2010-11-07 21:02:49 UTC (rev 
14490)
+++ django/trunk/docs/topics/install.txt2010-11-07 21:42:11 UTC (rev 
14491)
@@ -95,22 +95,24 @@
 * If you're using PostgreSQL, you'll need the psycopg_ package. Django supports
   both version 1 and 2. (When you configure Django's database layer, specify
   either ``postgresql`` [for version 1] or ``postgresql_psycopg2`` [for 
version 2].)
+  You might want to refer to our :ref:`PostgreSQL notes ` for
+  further technical details specific to this database.
 
   If you're on Windows, check out the unofficial `compiled Windows version`_.
 
 * If you're using MySQL, you'll need MySQLdb_, version 1.2.1p2 or higher. You
-  will also want to read the database-specific notes for the :doc:`MySQL
-  backend `.
+  will also want to read the database-specific :ref:`notes for the MySQL
+  backend `.
 
 * If you're using SQLite and Python 2.4, you'll need pysqlite_. Use version
   2.0.3 or higher. Python 2.5 ships with an SQLite wrapper in the standard
   library, so you don't need to install anything extra in that case. Please
-  read the SQLite backend :ref:`notes`.
+  read the :ref:`SQLite backend notes `.
 
 * If you're using Oracle, you'll need a copy of cx_Oracle_, but please
-  read the database-specific notes for the
-  :ref:`Oracle backend ` for important information
-  regarding supported versions of both Oracle and ``cx_Oracle``.
+  read the database-specific :ref:`notes for the Oracle backend `
+  for important information regarding supported versions of both Oracle and
+  ``cx_Oracle``.
 
 * If you're using an unofficial 3rd party backend, please consult the
   documentation provided for any additional requirements.
@@ -285,7 +287,7 @@
.. code-block:: bash
 
ln -s WORKING-DIR/django-trunk/django/bin/django-admin.py /usr/local/bin
-   
+
(In the above line, change WORKING-DIR to match the full path to your new
``django-trunk`` directory.)
 

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

Re: [Django] #373: Add support for multiple-column primary keys

[Django]

#373: Add support for multiple-column primary keys
---+
  Reporter:  jacob | Owner:  dcramer 
Status:  assigned  | Milestone:  
 Component:  Database layer (models, ORM)  |   Version:  
Resolution:|  Keywords:  database
 Stage:  Accepted  | Has_patch:  0   
Needs_docs:  0 |   Needs_tests:  0   
Needs_better_patch:  0 |  
---+
Changes (by anonymous):

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

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

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

[Changeset] r14490 - django/branches/releases/1.2.X/django/db/backends/oracle

[noreply]

Author: ramiro
Date: 2010-11-07 15:02:49 -0600 (Sun, 07 Nov 2010)
New Revision: 14490

Modified:
   django/branches/releases/1.2.X/django/db/backends/oracle/creation.py
Log:
[1.2.X] Fixed some Oracle backend test DB creation code bugs.

Made saving of modified settings compatible with multi-db, removed dead and 
superfluous code.

Backport of [14489] from trunk

Modified: django/branches/releases/1.2.X/django/db/backends/oracle/creation.py
===
--- django/branches/releases/1.2.X/django/db/backends/oracle/creation.py
2010-11-07 20:58:46 UTC (rev 14489)
+++ django/branches/releases/1.2.X/django/db/backends/oracle/creation.py
2010-11-07 21:02:49 UTC (rev 14490)
@@ -1,5 +1,4 @@
 import sys, time
-from django.core import management
 from django.db.backends.creation import BaseDatabaseCreation
 
 TEST_DATABASE_PREFIX = 'test_'
@@ -39,7 +38,9 @@
 'URLField': 'VARCHAR2(%(max_length)s)',
 }
 
-remember = {}
+def __init__(self, connection):
+self.remember = {}
+super(DatabaseCreation, self).__init__(connection)
 
 def _create_test_db(self, verbosity=1, autoclobber=False):
 TEST_NAME = self._test_database_name()
@@ -135,9 +136,6 @@
 'tblspace_temp': TEST_TBLSPACE_TMP,
 }
 
-self.remember['user'] = self.connection.settings_dict['USER']
-self.remember['passwd'] = self.connection.settings_dict['PASSWORD']
-
 cursor = self.connection.cursor()
 time.sleep(1) # To avoid "database is being accessed by other users" 
errors.
 if self._test_user_create():
@@ -214,35 +212,13 @@
 name = self.connection.settings_dict['TEST_NAME']
 except AttributeError:
 pass
-except:
-raise
 return name
 
 def _test_database_create(self):
-name = True
-try:
-if self.connection.settings_dict['TEST_CREATE']:
-name = True
-else:
-name = False
-except KeyError:
-pass
-except:
-raise
-return name
+return self.connection.settings_dict.get('TEST_CREATE', True)
 
 def _test_user_create(self):
-name = True
-try:
-if self.connection.settings_dict['TEST_USER_CREATE']:
-name = True
-else:
-name = False
-except KeyError:
-pass
-except:
-raise
-return name
+return self.connection.settings_dict.get('TEST_USER_CREATE', True)
 
 def _test_database_user(self):
 name = TEST_DATABASE_PREFIX + self.connection.settings_dict['USER']
@@ -251,8 +227,6 @@
 name = self.connection.settings_dict['TEST_USER']
 except KeyError:
 pass
-except:
-raise
 return name
 
 def _test_database_passwd(self):
@@ -262,8 +236,6 @@
 name = self.connection.settings_dict['TEST_PASSWD']
 except KeyError:
 pass
-except:
-raise
 return name
 
 def _test_database_tblspace(self):
@@ -273,8 +245,6 @@
 name = self.connection.settings_dict['TEST_TBLSPACE']
 except KeyError:
 pass
-except:
-raise
 return name
 
 def _test_database_tblspace_tmp(self):
@@ -284,6 +254,4 @@
 name = self.connection.settings_dict['TEST_TBLSPACE_TMP']
 except KeyError:
 pass
-except:
-raise
 return name

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

[Changeset] r14489 - django/trunk/django/db/backends/oracle

[noreply]

Author: ramiro
Date: 2010-11-07 14:58:46 -0600 (Sun, 07 Nov 2010)
New Revision: 14489

Modified:
   django/trunk/django/db/backends/oracle/creation.py
Log:
Fixed some Oracle backend test DB creation code bugs.

Made saving of modified settings compatible with multi-db, removed dead and 
superfluous code.

Modified: django/trunk/django/db/backends/oracle/creation.py
===
--- django/trunk/django/db/backends/oracle/creation.py  2010-11-07 16:02:22 UTC 
(rev 14488)
+++ django/trunk/django/db/backends/oracle/creation.py  2010-11-07 20:58:46 UTC 
(rev 14489)
@@ -1,5 +1,4 @@
 import sys, time
-from django.core import management
 from django.db.backends.creation import BaseDatabaseCreation
 
 TEST_DATABASE_PREFIX = 'test_'
@@ -39,7 +38,9 @@
 'URLField': 'VARCHAR2(%(max_length)s)',
 }
 
-remember = {}
+def __init__(self, connection):
+self.remember = {}
+super(DatabaseCreation, self).__init__(connection)
 
 def _create_test_db(self, verbosity=1, autoclobber=False):
 TEST_NAME = self._test_database_name()
@@ -131,9 +132,6 @@
 'tblspace_temp': TEST_TBLSPACE_TMP,
 }
 
-self.remember['user'] = self.connection.settings_dict['USER']
-self.remember['passwd'] = self.connection.settings_dict['PASSWORD']
-
 cursor = self.connection.cursor()
 time.sleep(1) # To avoid "database is being accessed by other users" 
errors.
 if self._test_user_create():
@@ -210,35 +208,13 @@
 name = self.connection.settings_dict['TEST_NAME']
 except AttributeError:
 pass
-except:
-raise
 return name
 
 def _test_database_create(self):
-name = True
-try:
-if self.connection.settings_dict['TEST_CREATE']:
-name = True
-else:
-name = False
-except KeyError:
-pass
-except:
-raise
-return name
+return self.connection.settings_dict.get('TEST_CREATE', True)
 
 def _test_user_create(self):
-name = True
-try:
-if self.connection.settings_dict['TEST_USER_CREATE']:
-name = True
-else:
-name = False
-except KeyError:
-pass
-except:
-raise
-return name
+return self.connection.settings_dict.get('TEST_USER_CREATE', True)
 
 def _test_database_user(self):
 name = TEST_DATABASE_PREFIX + self.connection.settings_dict['USER']
@@ -247,8 +223,6 @@
 name = self.connection.settings_dict['TEST_USER']
 except KeyError:
 pass
-except:
-raise
 return name
 
 def _test_database_passwd(self):
@@ -258,8 +232,6 @@
 name = self.connection.settings_dict['TEST_PASSWD']
 except KeyError:
 pass
-except:
-raise
 return name
 
 def _test_database_tblspace(self):
@@ -269,8 +241,6 @@
 name = self.connection.settings_dict['TEST_TBLSPACE']
 except KeyError:
 pass
-except:
-raise
 return name
 
 def _test_database_tblspace_tmp(self):
@@ -280,6 +250,4 @@
 name = self.connection.settings_dict['TEST_TBLSPACE_TMP']
 except KeyError:
 pass
-except:
-raise
 return name

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

Re: [Django] #14639: admin.site.register() does not check if the model is abstract (gives weird error)

[Django]

#14639: admin.site.register() does not check if the model is abstract (gives 
weird
error)
---+
  Reporter:  vdboor| Owner:  nobody
Status:  new   | Milestone:
 Component:  django.contrib.admin  |   Version:  1.2   
Resolution:|  Keywords:  error-messages
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by vdboor):

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

Comment:

 Addition: it produces even more weird errors in the admin_tools dashboard,
 when viewing a specific app:

 {{{
 Caught AttributeError while rendering: 'NoneType' object has no attribute
 '_meta'
 }}}

 which happens somewhere in the `contenttypes` framework:

 {{{
 File "/usr/lib/python2.6/site-
 packages/admin_tools/dashboard/templatetags/admin_tools_dashboard_tags.py"
 in admin_tools_render_dashboard_css
   90. dashboard = get_dashboard(context, location)
 File "/usr/lib/python2.6/site-packages/admin_tools/dashboard/utils.py" in
 get_dashboard
   21. return get_app_index_dashboard(context)
 File "/usr/lib/python2.6/site-packages/admin_tools/dashboard/utils.py" in
 get_app_index_dashboard
   71. return getattr(mod, inst)(app_title, model_list)
 File "/usr/lib/python2.6/site-
 packages/admin_tools/dashboard/dashboards.py" in __init__
   304. include_list=self.get_app_content_types(),
 File "/usr/lib/python2.6/site-
 packages/admin_tools/dashboard/dashboards.py" in get_app_content_types
   184. in self.get_app_model_classes()]
 File "/usr/lib/python2.6/site-
 packages/django/contrib/contenttypes/models.py" in get_for_model
   40. self._add_to_cache(self.db, ct)
 File "/usr/lib/python2.6/site-
 packages/django/contrib/contenttypes/models.py" in _add_to_cache
   70. key = (model._meta.app_label,
 model._meta.object_name.lower())
 }}}

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

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

[Django] #14639: admin.site.register() does not check if the model is abstract (gives weird error)

[Django]

#14639: admin.site.register() does not check if the model is abstract (gives 
weird
error)
--+-
 Reporter:  vdboor|   Owner:  nobody
   Status:  new   |   Milestone:
Component:  django.contrib.admin  | Version:  1.2   
 Keywords:  error-messages|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 When an abstract model is registered with `admin.site.register()` it
 produces the following error later on:

 {{{
 type object '...' has no attribute '_default_manager'
 }}}

 This error does not make much sense unless you're already have more
 intimate knowledge of the framework. [[br]]
 To ease the learning curve of new developers, I think it would make sense
 to check whether the model is abstract or not.

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

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

Re: [Django] #4979: Admin does not allow removal of an image from an ImageField after it has been set, even if null=True and blank=True

[Django]

#4979: Admin does not allow removal of an image from an ImageField after it has
been set, even if null=True and blank=True
---+
  Reporter:  robvdl| Owner:  nobody
Status:  closed| Milestone:
 Component:  django.contrib.admin  |   Version:  SVN   
Resolution:  fixed |  Keywords:  ImageField
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  1 |  
---+
Comment (by jezdez):

 Indeed, thanks.

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

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

Re: [Django] #14571: Update jQuery to v1.4.3

[Django]

#14571: Update jQuery to v1.4.3
---+
  Reporter:  robhudson | Owner:  nobody
Status:  new   | Milestone:  1.3   
 Component:  django.contrib.admin  |   Version:  1.2   
Resolution:|  Keywords:  jquery
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by jezdez):

  * stage:  Unreviewed => Accepted
  * milestone:  => 1.3

Comment:

 Using a hosted version seems not like a good idea given potential uses of
 Django in intranets etc. Updating jQuery seems reasonable though.

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

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

Re: [Django] #4979: Admin does not allow removal of an image from an ImageField after it has been set, even if null=True and blank=True

[Django]

#4979: Admin does not allow removal of an image from an ImageField after it has
been set, even if null=True and blank=True
---+
  Reporter:  robvdl| Owner:  nobody
Status:  closed| Milestone:
 Component:  django.contrib.admin  |   Version:  SVN   
Resolution:  fixed |  Keywords:  ImageField
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  1 |  
---+
Changes (by dcramer):

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

Comment:

 This appears to have been fixed in [13968]

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

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

[Django] #14638: to_python documentation is not comprehensible

[Django]

#14638: to_python documentation is not comprehensible
-+--
 Reporter:  maraujop |   Owner:  nobody
   Status:  new  |   Milestone:
Component:  Documentation| Version:  SVN   
 Keywords:  to_python, model, field  |   Stage:  Unreviewed
Has_patch:  0|  
-+--
 Reading this:
 [http://docs.djangoproject.com/en/dev/howto/custom-model-
 fields/#django.db.models.to_python]

 Anyone would think that to_python is a model method in charge of
 converting a value extracted from a DB to a python type. Beforehand in the
 documentation there is a way better explanation of this method.

 [http://docs.djangoproject.com/en/dev/howto/custom-model-fields
 /#modelforms-and-custom-fields]

 I honestly think it should be redone, I lost ages trying to figure out
 what this method was for.

 Thanks, regards
 Miguel Araujo

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

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

Re: [Django] #14571: Update jQuery to v1.4.3

[Django]

#14571: Update jQuery to v1.4.3
---+
  Reporter:  robhudson | Owner:  nobody
Status:  new   | Milestone:
 Component:  django.contrib.admin  |   Version:  1.2   
Resolution:|  Keywords:  jquery
 Stage:  Unreviewed| Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by anonymous):

 Maybe better use CDN hosted copy of jquery instead of including it in
 distribution?

 http://docs.jquery.com/Downloading_jQuery#CDN_Hosted_jQuery

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

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

Re: [Django] #14637: There may an Internationalization bug in Forms

[Django]

#14637: There may an Internationalization bug in Forms
-+--
  Reporter:  thefm...@gmail.com  | Owner:  nobody  
Status:  new | Milestone:  
 Component:  Forms   |   Version:  1.2 
Resolution:  |  Keywords:  Internationalization
 Stage:  Unreviewed  | Has_patch:  0   
Needs_docs:  0   |   Needs_tests:  0   
Needs_better_patch:  0   |  
-+--
Changes (by thefm...@gmail.com):

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

Comment:

 I check the code

 there is no

 "Ensure this value has at least %(min)d characters (it has %(length)d)."

 in forms/fields.py

 may be in 1.2 we use in core/validators.py

 {{{
 class MinLengthValidator(BaseValidator):
 compare = lambda self, a, b: a < b
 clean   = lambda self, x: len(x)
 message = _(u'Ensure this value has at least %(limit_value)d
 characters (it has %(show_value)d).')
 code = 'min_length'
 }}}

 so maybe po file should be update?

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

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

[Django] #14637: There may an Internationalization bug in Forms

[Django]

#14637: There may an Internationalization bug in Forms
--+-
 Reporter:  thefm...@gmail.com|   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Forms | Version:  1.2   
 Keywords:  Internationalization  |   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 set

 LANGUAGE_CODE = 'zh-CN'

 and

 create a form


 {{{
 class RegisterForm(forms.Form):
 userName = forms.EmailField(max_length=80, label=u'电子邮箱');
 userPass1 = forms.CharField(widget=forms.PasswordInput, min_length=6,
 max_length=30, label=u'用户密码');
 userPass2 = forms.CharField(widget=forms.PasswordInput, min_length=6,
 max_length=30, label=u'确认密码');
 }}}

 when I type 3 word in userPass1

 according to django.po in site-
 packages/django/conf/locale/zh_Cn/LC_MESSAGE/django.po


 it should be
 {{{
 #: forms/fields.py:139
 #, python-format
 msgid "Ensure this value has at least %(min)d characters (it has
 %(length)d)."
 msgstr "确保该值最少为 %(min)d  个字符（其长度为 %(length)d）。"
 }}}

 but I just got a English error msg instead of a Chinese one

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

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

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

[noreply]

Author: Alex
Date: 2010-11-07 10:02:22 -0600 (Sun, 07 Nov 2010)
New Revision: 14488

Modified:
   django/trunk/django/core/handlers/base.py
   django/trunk/tests/regressiontests/middleware_exceptions/tests.py
Log:
Fixed #13684 -- if settings.ROOT_URLCONF isn't defined don't blow up with an 
UnboundLocalError.

Modified: django/trunk/django/core/handlers/base.py
===
--- django/trunk/django/core/handlers/base.py   2010-11-07 15:41:17 UTC (rev 
14487)
+++ django/trunk/django/core/handlers/base.py   2010-11-07 16:02:22 UTC (rev 
14488)
@@ -73,13 +73,15 @@
 from django.conf import settings
 
 try:
+# Setup default url resolver for this thread, this code is outside
+# the try/except so we don't get a spurious "unbound local
+# variable" exception in the event an exception is raised before
+# resolver is set
+urlconf = settings.ROOT_URLCONF
+urlresolvers.set_urlconf(urlconf)
+resolver = urlresolvers.RegexURLResolver(r'^/', urlconf)
 try:
-# Setup default url resolver for this thread.
-urlconf = settings.ROOT_URLCONF
-urlresolvers.set_urlconf(urlconf)
-resolver = urlresolvers.RegexURLResolver(r'^/', urlconf)
 response = None
-
 # Apply request middleware
 for middleware_method in self._request_middleware:
 response = middleware_method(request)
@@ -239,4 +241,3 @@
 if script_url:
 return force_unicode(script_url[:-len(environ.get('PATH_INFO', ''))])
 return force_unicode(environ.get('SCRIPT_NAME', u''))
-

Modified: django/trunk/tests/regressiontests/middleware_exceptions/tests.py
===
--- django/trunk/tests/regressiontests/middleware_exceptions/tests.py   
2010-11-07 15:41:17 UTC (rev 14487)
+++ django/trunk/tests/regressiontests/middleware_exceptions/tests.py   
2010-11-07 16:02:22 UTC (rev 14488)
@@ -1,8 +1,9 @@
 import sys
 
-from django.test import TestCase
+from django.conf import settings
 from django.core.signals import got_request_exception
 from django.http import HttpResponse
+from django.test import TestCase
 
 
 class TestException(Exception):
@@ -694,3 +695,19 @@
 self.assert_middleware_usage(pre_middleware,  True,  True,  True, 
False)
 self.assert_middleware_usage(bad_middleware,  True,  True,  True,  
True)
 self.assert_middleware_usage(post_middleware, True,  True,  True,  
True)
+
+
+_missing = object()
+class RootUrlconfTests(TestCase):
+def test_missing_root_urlconf(self):
+try:
+original_ROOT_URLCONF = settings.ROOT_URLCONF
+del settings.ROOT_URLCONF
+except AttributeError:
+original_ROOT_URLCONF = _missing
+self.assertRaises(AttributeError,
+self.client.get, "/middleware_exceptions/view/"
+)
+
+if original_ROOT_URLCONF is not _missing:
+settings.ROOT_URLCONF = original_ROOT_URLCONF

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

[Changeset] r14487 - django/trunk/tests/regressiontests/requests

[noreply]

Author: Alex
Date: 2010-11-07 09:41:17 -0600 (Sun, 07 Nov 2010)
New Revision: 14487

Modified:
   django/trunk/tests/regressiontests/requests/tests.py
Log:
Make the requests test use unittest2, rather than the system unittest.

Modified: django/trunk/tests/regressiontests/requests/tests.py
===
--- django/trunk/tests/regressiontests/requests/tests.py2010-11-07 
15:21:47 UTC (rev 14486)
+++ django/trunk/tests/regressiontests/requests/tests.py2010-11-07 
15:41:17 UTC (rev 14487)
@@ -1,15 +1,14 @@
-from datetime import datetime, timedelta
 import time
+from datetime import datetime, timedelta
 from StringIO import StringIO
-import unittest
 
-from django.http import HttpRequest, HttpResponse, parse_cookie
-from django.core.handlers.wsgi import WSGIRequest, LimitedStream
 from django.core.handlers.modpython import ModPythonRequest
+from django.core.handlers.wsgi import WSGIRequest, LimitedStream
+from django.http import HttpRequest, HttpResponse, parse_cookie
+from django.utils import unittest
 from django.utils.http import cookie_date
 
 class RequestsTests(unittest.TestCase):
-
 def test_httprequest(self):
 request = HttpRequest()
 self.assertEqual(request.GET.keys(), [])

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

Re: [Django] #14014: Admin Add user view: Clicking 'Save and add another' button still shows extended user detail form

[Django]

#14014: Admin Add user view: Clicking 'Save and add another' button still shows
extended user detail form
---+
  Reporter:  ramiro| Owner:  nobody
Status:  reopened  | Milestone:
 Component:  django.contrib.admin  |   Version:  1.2   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by Atr3ides):

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

Comment:

 This breaks the two steps behavior of the user creation flow. When
 creating a new user and hitting "Save", you are now redirected to User
 model change list instead of entering editing mode for adding additional
 user profile.

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

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

[Changeset] r14486 - django/trunk/docs/topics/i18n

[noreply]

Author: Alex
Date: 2010-11-07 09:21:47 -0600 (Sun, 07 Nov 2010)
New Revision: 14486

Modified:
   django/trunk/docs/topics/i18n/localization.txt
Log:
Fixed #14636 -- corrected bad formatting in the docs, which was resulting in an 
invalid link.

Modified: django/trunk/docs/topics/i18n/localization.txt
===
--- django/trunk/docs/topics/i18n/localization.txt  2010-11-07 09:23:12 UTC 
(rev 14485)
+++ django/trunk/docs/topics/i18n/localization.txt  2010-11-07 15:21:47 UTC 
(rev 14486)
@@ -8,7 +8,7 @@
 
 .. _`Creating language files`: how-to-create-language-files_
 .. _`locale aware date, time and numbers input/output in forms`: 
format-localization_
-.. _`controlling localization in templates`: topic-l10n-templates
+.. _`controlling localization in templates`: topic-l10n-templates_
 
 .. seealso::
 
@@ -318,7 +318,7 @@
 to use a space as a thousand separator, instead of the default for English,
 a comma.
 
-.. topic-l10n-templates:
+.. _topic-l10n-templates:
 
 Controlling localization in templates
 =

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

[Django] #14636: Bad link on localization page

[Django]

#14636: Bad link on localization page
---+
 Reporter:  steveire   |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Uncategorized  | Version:  1.2   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 This page:

 http://docs.djangoproject.com/en/dev/topics/i18n/localization/#format-
 localization

 has a link to here:

 http://docs.djangoproject.com/en/dev/topics/i18n/localization/topic-l10n-
 templates/

 which does not exist.

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

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

Re: [Django] #14635: Documentation improvement on setting up django with OpenBSD

[Django]

#14635: Documentation improvement on setting up django with OpenBSD
+---
  Reporter:  pgur...@gmail.com  | Owner:  nobody
Status:  closed | Milestone:
 Component:  Documentation  |   Version:  1.2   
Resolution:  invalid|  Keywords:  django openbsd
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Comment (by gabrielhurley):

 No problem! Just wanted to make sure my understanding was correct ;-)

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

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

Re: [Django] #14635: Documentation improvement on setting up django with OpenBSD

[Django]

#14635: Documentation improvement on setting up django with OpenBSD
+---
  Reporter:  pgur...@gmail.com  | Owner:  nobody
Status:  closed | Milestone:
 Component:  Documentation  |   Version:  1.2   
Resolution:  invalid|  Keywords:  django openbsd
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by pgur...@gmail.com):

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

Comment:

 You know what, you are correct, this has to be on the OpenBSD help rather
 than django, (hindsight 20/20). I think django pretty much works the same
 way, the only wrinkle might be, there is not explanation for chroot'ed
 environment, but then again, this should be in covered in the OS help
 rather than django help. Sorry for the noise.

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

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

Re: [Django] #14634: Sessions are unnecessarily complex

[Django]

#14634: Sessions are unnecessarily complex
--+-
  Reporter:  PaulM| Owner:  PaulM
Status:  new  | Milestone:  1.3  
 Component:  django.contrib.sessions  |   Version:  1.2  
Resolution:   |  Keywords:   
 Stage:  Accepted | Has_patch:  0
Needs_docs:  0|   Needs_tests:  0
Needs_better_patch:  0|  
--+-
Changes (by gabrielhurley):

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

Comment:

 This seems like a reasonable assessment to me, and I'm +1 on not doing
 unnecessary checks... as for the solution, it sounds alright, though I
 haven't looked deeply into the code there.

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

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

Re: [Django] #14635: Documentation improvement on setting up django with OpenBSD

[Django]

#14635: Documentation improvement on setting up django with OpenBSD
+---
  Reporter:  pgur...@gmail.com  | Owner:  nobody
Status:  new| Milestone:
 Component:  Documentation  |   Version:  1.2   
Resolution: |  Keywords:  django openbsd
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by gabrielhurley):

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

Comment:

 To my reading, there is nothing unique to OpenBSD in the steps you've
 described. As far as I can tell what you've described is the particular
 path you used for `FastCGIExternalServer` (`mysite.fcgi` in the docs). The
 fact that this path should be customized is explained in the
 [http://docs.djangoproject.com/en/1.2/howto/deployment/fastcgi
 /#specifying-the-location-of-the-fastcgi-server preceding section].

 If I'm missing something here, or you have a suggestion for how the
 existing docs could make these steps more clear please give specifics. At
 present, I'm not seeing what's so different here that it deserves to be
 covered in its own right.

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

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

[Changeset] r14485 - in django/branches/releases/1.2.X/docs: . howto ref ref/contrib/admin ref/templates topics

[noreply]

Author: gabrielhurley
Date: 2010-11-07 03:23:12 -0600 (Sun, 07 Nov 2010)
New Revision: 14485

Added:
   django/branches/releases/1.2.X/docs/ref/contrib/admin/admindocs.txt
Modified:
   django/branches/releases/1.2.X/docs/howto/custom-model-fields.txt
   django/branches/releases/1.2.X/docs/index.txt
   django/branches/releases/1.2.X/docs/ref/contrib/admin/index.txt
   django/branches/releases/1.2.X/docs/ref/middleware.txt
   django/branches/releases/1.2.X/docs/ref/templates/builtins.txt
   django/branches/releases/1.2.X/docs/topics/templates.txt
Log:
[1.2.X] Fixed #12975 -- Moved the docs for contrib.admindocs out of the 
template docs and into their own reference section, and significantly improved 
the documentation of what admindocs can do. Thanks to jabapyth for the report, 
and whiteinge for the patch.

Backport of [14484] from trunk.

Modified: django/branches/releases/1.2.X/docs/howto/custom-model-fields.txt
===
--- django/branches/releases/1.2.X/docs/howto/custom-model-fields.txt   
2010-11-07 09:21:55 UTC (rev 14484)
+++ django/branches/releases/1.2.X/docs/howto/custom-model-fields.txt   
2010-11-07 09:23:12 UTC (rev 14485)
@@ -292,10 +292,11 @@
 As always, you should document your field type, so users will know what it is.
 In addition to providing a docstring for it, which is useful for developers,
 you can also allow users of the admin app to see a short description of the
-field type via the ``django.contrib.admindocs`` application. To do this simply
-provide descriptive text in a ``description`` class attribute of your custom 
field.
-In the above example, the type description displayed by the ``admindocs`` 
application
-for a ``HandField`` will be 'A hand of cards (bridge style)'.
+field type via the :doc:`django.contrib.admindocs
+` application. To do this simply provide
+descriptive text in a ``description`` class attribute of your custom field. In
+the above example, the type description displayed by the ``admindocs``
+application for a ``HandField`` will be 'A hand of cards (bridge style)'.
 
 Useful methods
 --

Modified: django/branches/releases/1.2.X/docs/index.txt
===
--- django/branches/releases/1.2.X/docs/index.txt   2010-11-07 09:21:55 UTC 
(rev 14484)
+++ django/branches/releases/1.2.X/docs/index.txt   2010-11-07 09:23:12 UTC 
(rev 14485)
@@ -161,7 +161,7 @@
 Other batteries included
 
 
-* :doc:`Admin site ` | :doc:`Admin actions 
`
+* :doc:`Admin site ` | :doc:`Admin actions 
` | :doc:`Admin documentation 
generator`
 * :doc:`Authentication `
 * :doc:`Cache system `
 * :doc:`Conditional content processing 
`

Added: django/branches/releases/1.2.X/docs/ref/contrib/admin/admindocs.txt
===
--- django/branches/releases/1.2.X/docs/ref/contrib/admin/admindocs.txt 
(rev 0)
+++ django/branches/releases/1.2.X/docs/ref/contrib/admin/admindocs.txt 
2010-11-07 09:23:12 UTC (rev 14485)
@@ -0,0 +1,161 @@
+
+The Django admin documentation generator
+
+
+.. module:: django.contrib.admindocs
+:synopsis: Django's admin documentation generator.
+
+.. currentmodule:: django.contrib.admindocs
+
+Django's :mod:`~django.contrib.admindocs` app pulls documentation from the
+docstrings of models, views, template tags, and template filters for any app in
+:setting:`INSTALLED_APPS` and makes that documentation available from the
+:mod:`Django admin `.
+
+In addition to providing offline documentation for all template tags and
+template filters that ship with Django, you may utilize admindocs to quickly
+document your own code.
+
+Overview
+
+
+To activate the :mod:`~django.contrib.admindocs`, you will need to do
+the following:
+
+* Add :mod:`django.contrib.admindocs` to your :setting:`INSTALLED_APPS`.
+* Add ``(r'^admin/doc/', include('django.contrib.admindocs.urls'))`` to
+  your :data:`urlpatterns`. Make sure it's included *before* the
+  ``r'^admin/'`` entry, so that requests to ``/admin/doc/`` don't get
+  handled by the latter entry.
+* Install the docutils Python module (http://docutils.sf.net/).
+* **Optional:** Linking to templates requires the :setting:`ADMIN_FOR`
+  setting to be configured.
+* **Optional:** Using the admindocs bookmarklets requires the
+  :mod:`XViewMiddleware` to be installed.
+
+Once those steps are complete, you can start browsing the documentation by
+going to your admin interface and clicking the "Documentation" link in the
+upper right of the page.
+
+Documentation helpers
+=
+
+The following special markup can be used in your docstrings to easily create
+hyperlinks to other components:
+
+=   ===
+Django 

[Changeset] r14484 - in django/trunk/docs: . howto ref ref/contrib/admin ref/templates topics

[noreply]

Author: gabrielhurley
Date: 2010-11-07 03:21:55 -0600 (Sun, 07 Nov 2010)
New Revision: 14484

Added:
   django/trunk/docs/ref/contrib/admin/admindocs.txt
Modified:
   django/trunk/docs/howto/custom-model-fields.txt
   django/trunk/docs/index.txt
   django/trunk/docs/ref/contrib/admin/index.txt
   django/trunk/docs/ref/middleware.txt
   django/trunk/docs/ref/templates/builtins.txt
   django/trunk/docs/topics/templates.txt
Log:
Fixed #12975 -- Moved the docs for contrib.admindocs out of the template docs 
and into their own reference section, and significantly improved the 
documentation of what admindocs can do. Thanks to jabapyth for the report, and 
whiteinge for the patch.

Modified: django/trunk/docs/howto/custom-model-fields.txt
===
--- django/trunk/docs/howto/custom-model-fields.txt 2010-11-07 01:44:32 UTC 
(rev 14483)
+++ django/trunk/docs/howto/custom-model-fields.txt 2010-11-07 09:21:55 UTC 
(rev 14484)
@@ -292,10 +292,11 @@
 As always, you should document your field type, so users will know what it is.
 In addition to providing a docstring for it, which is useful for developers,
 you can also allow users of the admin app to see a short description of the
-field type via the ``django.contrib.admindocs`` application. To do this simply
-provide descriptive text in a ``description`` class attribute of your custom 
field.
-In the above example, the type description displayed by the ``admindocs`` 
application
-for a ``HandField`` will be 'A hand of cards (bridge style)'.
+field type via the :doc:`django.contrib.admindocs
+` application. To do this simply provide
+descriptive text in a ``description`` class attribute of your custom field. In
+the above example, the type description displayed by the ``admindocs``
+application for a ``HandField`` will be 'A hand of cards (bridge style)'.
 
 Useful methods
 --

Modified: django/trunk/docs/index.txt
===
--- django/trunk/docs/index.txt 2010-11-07 01:44:32 UTC (rev 14483)
+++ django/trunk/docs/index.txt 2010-11-07 09:21:55 UTC (rev 14484)
@@ -161,7 +161,7 @@
 Other batteries included
 
 
-* :doc:`Admin site ` | :doc:`Admin actions 
`
+* :doc:`Admin site ` | :doc:`Admin actions 
` | :doc:`Admin documentation 
generator`
 * :doc:`Authentication `
 * :doc:`Cache system `
 * :doc:`Conditional content processing 
`
@@ -192,7 +192,6 @@
 * :doc:`Validators `
 * Function-based generic views (Deprecated) 
:doc:`Overview` | :doc:`Built-in generic 
views` | :doc:`Migration 
guide`
 
-
 The Django open-source project
 ==
 

Added: django/trunk/docs/ref/contrib/admin/admindocs.txt
===
--- django/trunk/docs/ref/contrib/admin/admindocs.txt   
(rev 0)
+++ django/trunk/docs/ref/contrib/admin/admindocs.txt   2010-11-07 09:21:55 UTC 
(rev 14484)
@@ -0,0 +1,161 @@
+
+The Django admin documentation generator
+
+
+.. module:: django.contrib.admindocs
+:synopsis: Django's admin documentation generator.
+
+.. currentmodule:: django.contrib.admindocs
+
+Django's :mod:`~django.contrib.admindocs` app pulls documentation from the
+docstrings of models, views, template tags, and template filters for any app in
+:setting:`INSTALLED_APPS` and makes that documentation available from the
+:mod:`Django admin `.
+
+In addition to providing offline documentation for all template tags and
+template filters that ship with Django, you may utilize admindocs to quickly
+document your own code.
+
+Overview
+
+
+To activate the :mod:`~django.contrib.admindocs`, you will need to do
+the following:
+
+* Add :mod:`django.contrib.admindocs` to your :setting:`INSTALLED_APPS`.
+* Add ``(r'^admin/doc/', include('django.contrib.admindocs.urls'))`` to
+  your :data:`urlpatterns`. Make sure it's included *before* the
+  ``r'^admin/'`` entry, so that requests to ``/admin/doc/`` don't get
+  handled by the latter entry.
+* Install the docutils Python module (http://docutils.sf.net/).
+* **Optional:** Linking to templates requires the :setting:`ADMIN_FOR`
+  setting to be configured.
+* **Optional:** Using the admindocs bookmarklets requires the
+  :mod:`XViewMiddleware` to be installed.
+
+Once those steps are complete, you can start browsing the documentation by
+going to your admin interface and clicking the "Documentation" link in the
+upper right of the page.
+
+Documentation helpers
+=
+
+The following special markup can be used in your docstrings to easily create
+hyperlinks to other components:
+
+=   ===
+Django ComponentreStructuredText roles
+=   ===
+Models 

[Django] #14635: Documentation improvement on setting up django with OpenBSD

[Django]

#14635: Documentation improvement on setting up django with OpenBSD
---+
 Reporter:  pgur...@gmail.com  |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Documentation  | Version:  1.2   
 Keywords:  django openbsd |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 I found it really hard to configure django on OpenBSD (stock Apache). I
 eventually figured it out and it works and would like to add this to the
 documentation. I think this will be useful. This requires few changes to
 httpd.conf

 1. Create directory called django under /var/www/htdocs
 2. Create django project under /var/www/htdocs/django
 3. Create NEW_PROJECT.fcgi file under /var/www/htdocs/django (Name of the
 filename matters, because this will be used in !VirtualHost)

 Under !VirtualHost configuration for default htdocs access
 Add the following lines

 {{{
 
 ... snip ...
 RewriteEngine On
 RewriteRule ^/(media.*)$ /$1 [QSA,L,PT]
 RewriteCond %{REQUEST_FILENAME} !-f
 RewriteRule ^/django/NEW_PROJECT/(.*)$ /django/NEW_PROJECT.fcgi/$1 [QSA,L]
 ... snip ...
 

 }}}
 Enable ExecCGI options for /var/www/htdocs directory

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

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

Re: [Django] #14548: Aggregates docs are misleading (or there is a bug in the aggregate code)

[Django]

#14548: Aggregates docs are misleading (or there is a bug in the aggregate code)
+---
  Reporter:  PaulM  | Owner:  nobody
Status:  new| Milestone:  1.3   
 Component:  Documentation  |   Version:  1.2   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Comment (by gabrielhurley):

 I'd be +1 on a `default` argument for aggregates.

 For an extra win, documenting the new `default` argument's default
 value(s) would also solve the current documentation problem! Can we
 reclassify this ticket as "ORM Aggregation" and call it a feature request,
 then?

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

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

[Django] #14634: Sessions are unnecessarily complex

[Django]

#14634: Sessions are unnecessarily complex
-+--
 Reporter:  PaulM|   Owner:  PaulM 
   Status:  new  |   Milestone:  1.3   
Component:  django.contrib.sessions  | Version:  1.2   
 Keywords:   |   Stage:  Unreviewed
Has_patch:  0|  
-+--
 Django includes
 
[http://code.djangoproject.com/browser/django/trunk/django/contrib/sessions/backends
 several backends] for storing session data. None of these store data in a
 manner that is accessible to clients. The backends rely on trusted
 infrastructure: the database, the cache, or the filesystem.

 For all of recorded history (since the earliest svn checkins), Django has
 
[http://code.djangoproject.com/browser/django/trunk/django/contrib/sessions/backends/base.py#L91
 stored session data in an obfuscated format]. We pickle the data, hash it,
 and store the hash + base64(data). To retrieve session data,
 
[http://code.djangoproject.com/browser/django/trunk/django/contrib/sessions/backends/base.py#L97
 we do the opposite]: pull the string from our trusted backend, hash the
 data, compare to the stored hash, and then if it matches, return it.

 My best guess is that this is a holdover from an earlier era when
 Ellington stored session data client side in cookies. None of the default
 backends support this, and it [http://code.djangoproject.com/ticket/14579
 may not currently be possible].

 This means that we are running significant extra code every time we hit
 the session store. We trust the supplied backends, but we don't know that
 a user hasn't subclassed
 
[http://code.djangoproject.com/browser/django/trunk/django/contrib/sessions/backends/base.py
 the base backend] to depend on this hashing behavior.

 I propose that we rework the base backend to include an
 `InsecureSessionBase` which our provided backends subclass. This new class
 will provide simple key/value behavior without the hashing. We will retain
 the current hashing behavior in the `SessionBase` class for backwards
 compatibility, and it will inherit from `InsecureSessionBase` for all
 other methods.

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

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

Re: [Django] #14633: Reorganize settings reference docs

[Django]

#14633: Reorganize settings reference docs
+---
  Reporter:  gabrielhurley  | Owner:  gabrielhurley
Status:  assigned   | Milestone:  1.3  
 Component:  Documentation  |   Version:  1.2  
Resolution: |  Keywords:   
 Stage:  Accepted   | Has_patch:  0
Needs_docs:  0  |   Needs_tests:  0
Needs_better_patch:  0  |  
+---
Changes (by PaulM):

  * stage:  Unreviewed => Accepted

Comment:

 I'm in favor of Option 1 including the app name. It's how I would go
 looking for those settings.

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

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

Re: [Django] #14633: Reorganize settings reference docs

[Django]

#14633: Reorganize settings reference docs
+---
  Reporter:  gabrielhurley  | Owner:  gabrielhurley
Status:  assigned   | Milestone:  1.3  
 Component:  Documentation  |   Version:  1.2  
Resolution: |  Keywords:   
 Stage:  Unreviewed | Has_patch:  0
Needs_docs:  0  |   Needs_tests:  0
Needs_better_patch:  0  |  
+---
Changes (by gabrielhurley):

  * status:  new => assigned
  * needs_better_patch:  => 0
  * needs_tests:  => 0
  * needs_docs:  => 0

Old description:

> Currently, `docs/ref/settings` contains an alphabetical list of most of
> the settings contained in `conf/global_settings.py`, including those for
> some contrib apps (`auth`, `sessions`, ...). However, settings for a
> handful of contrib apps (`comments`, `staticfiles`, ...) live in their
> respective `/docs/ref/contrib/[app]` documentation files.
>
> AFAICS the settings reference ought to encompass **all** of the settings
> contained in the `global_settings` module if it is going to be a "full
> list of all available settings" as it claims.
>
> We don't want to overload that document, though, and maintaining some
> sort of logical grouping is necessary. jezdez and I discussed this issue
> briefly on IRC, and decided it might be helpful to create a section
> within `docs/ref/settings` specifically for contrib app settings.
>
> The ultimate structure could look like this:
> {{{
> Settings
>  |-- Available settings
> |-- Core settings
> |-- Contrib settings
> |-- (App name?)
>  |-- Deprecated settings
> }}}
>
> or more simply:
>
> {{{
> Settings
>  |-- Core settings
>  |-- Contrib settings
>  |-- (App name?)
>  |-- Deprecated settings
> }}}
>
> The contrib app docs could then point to the appropriate section of the
> settings reference.
>
> As another alternative structure, the settings reference could be grouped
> according to the organization of `global_settings.py` (shown here in
> alphabetical order):
>
> {{{
> Settings
>  |-- Authentication
>  |-- Cache
>  |-- Comments
>  |-- Core
>  |-- CSRF
>  |-- Fixtures
>  |-- Logging
>  |-- Messages
>  |-- Middleware
>  |-- Sessions
>  |-- Staticfiles
>  |-- Testing
> }}

New description:

 Currently, `docs/ref/settings` contains an alphabetical list of most of
 the settings contained in `conf/global_settings.py`, including those for
 some contrib apps (`auth`, `sessions`, ...). However, settings for a
 handful of contrib apps (`comments`, `staticfiles`, ...) live in their
 respective `/docs/ref/contrib/[app]` documentation files.

 AFAICS the settings reference ought to encompass '''all''' of the settings
 contained in the `global_settings` module if it is going to be a "full
 list of all available settings" as it claims.

 We don't want to overload that document, though, and maintaining some sort
 of logical grouping is necessary. jezdez and I discussed this issue
 briefly on IRC, and decided it might be helpful to create a section within
 `docs/ref/settings` specifically for contrib app settings.

 The ultimate structure could look like this:
 {{{
 Settings
  |-- Available settings
 |-- Core settings
 |-- Contrib settings
 |-- (App name?)
  |-- Deprecated settings
 }}}

 or more simply:

 {{{
 Settings
  |-- Core settings
  |-- Contrib settings
  |-- (App name?)
  |-- Deprecated settings
 }}}

 The contrib app docs could then point to the appropriate section of the
 settings reference.

 As another alternative structure, the settings reference could be grouped
 according to the organization of `global_settings.py` (shown here in
 alphabetical order):

 {{{
 Settings
  |-- Authentication
  |-- Cache
  |-- Comments
  |-- Core
  |-- CSRF
  |-- Fixtures
  |-- Logging
  |-- Messages
  |-- Middleware
  |-- Sessions
  |-- Staticfiles
  |-- Testing
 }}}

Comment:

 Added a missing "}" to the code formatting. ::sigh::

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

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

[Django] #14633: Reorganize settings reference docs

[Django]

#14633: Reorganize settings reference docs
---+
 Reporter:  gabrielhurley  |   Owner:  gabrielhurley
   Status:  new|   Milestone:  1.3  
Component:  Documentation  | Version:  1.2  
 Keywords: |   Stage:  Unreviewed   
Has_patch:  0  |  
---+
 Currently, `docs/ref/settings` contains an alphabetical list of most of
 the settings contained in `conf/global_settings.py`, including those for
 some contrib apps (`auth`, `sessions`, ...). However, settings for a
 handful of contrib apps (`comments`, `staticfiles`, ...) live in their
 respective `/docs/ref/contrib/[app]` documentation files.

 AFAICS the settings reference ought to encompass **all** of the settings
 contained in the `global_settings` module if it is going to be a "full
 list of all available settings" as it claims.

 We don't want to overload that document, though, and maintaining some sort
 of logical grouping is necessary. jezdez and I discussed this issue
 briefly on IRC, and decided it might be helpful to create a section within
 `docs/ref/settings` specifically for contrib app settings.

 The ultimate structure could look like this:
 {{{
 Settings
  |-- Available settings
 |-- Core settings
 |-- Contrib settings
 |-- (App name?)
  |-- Deprecated settings
 }}}

 or more simply:

 {{{
 Settings
  |-- Core settings
  |-- Contrib settings
  |-- (App name?)
  |-- Deprecated settings
 }}}

 The contrib app docs could then point to the appropriate section of the
 settings reference.

 As another alternative structure, the settings reference could be grouped
 according to the organization of `global_settings.py` (shown here in
 alphabetical order):

 {{{
 Settings
  |-- Authentication
  |-- Cache
  |-- Comments
  |-- Core
  |-- CSRF
  |-- Fixtures
  |-- Logging
  |-- Messages
  |-- Middleware
  |-- Sessions
  |-- Staticfiles
  |-- Testing
 }}

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

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