Re: [Django] #11400: Add fail_silently parameter to User.email_user

[Django]

#11400: Add fail_silently parameter to User.email_user
---+
  Reporter:  Jug_  | Owner:  nobody  
Status:  new   | Milestone:  
 Component:  Contrib apps  |   Version:  SVN 
Resolution:|  Keywords:  email user fail_silently
 Stage:  Accepted  | Has_patch:  1   
Needs_docs:  0 |   Needs_tests:  0   
Needs_better_patch:  0 |  
---+
Changes (by john_scott):

  * has_patch:  0 => 1

Comment:

 Added patch so `email_user()` passes **kwargs to `send_mail`.

-- 
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] #12330: Tutorials Page 2 missing 'from django.contrib import admin' in urls.py

[Django]

#12330: Tutorials Page 2 missing 'from django.contrib import admin' in urls.py
+---
  Reporter:  dummydata  | Owner:  nobody
Status:  closed | Milestone:
 Component:  Uncategorized  |   Version:  1.1   
Resolution:  invalid|  Keywords:  tutorial admin
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by dummydata):

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

Comment:

 nevermind... stupid user should RTFM.  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] #11394: Should have a Form Variable for the Login method in Auth.Views

[Django]

#11394: Should have a Form Variable for the Login method in Auth.Views
---+
  Reporter:  o...@toxicdesign.com  | Owner:  nobody
Status:  closed| Milestone:
 Component:  Authentication|   Version:  1.0   
Resolution:  duplicate |  Keywords:  views 
 Stage:  Accepted  | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by john_scott):

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

Comment:

 Fix committed by lukeplant in r11618. See #8274

-- 
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] #12330: Tutorials Page 2 missing 'from django.contrib import admin' in urls.py

[Django]

#12330: Tutorials Page 2 missing 'from django.contrib import admin' in urls.py
+---
 Reporter:  dummydata   |   Owner:  nobody
   Status:  new |   Milestone:
Component:  Uncategorized   | Version:  1.1   
 Keywords:  tutorial admin  |   Stage:  Unreviewed
Has_patch:  0   |  
+---
 In the tutorial section that details enabling the admin console, the
 instructions as they are result in an HTTP 500 error (see full error
 below) when attempting access the admin URL.

 Adding from django.contrib import admin to mysite/urls.py
 and restarting the test web server solved the issue.  The import statement
 should be added or clarified in the tutorial.
 [[BR]]
 [[BR]]

 -- ERROR --

 Environment:[[BR]]
 [[BR]]
 Request Method: GET[[BR]]
 Request URL: http://localhost:8000/admin/[[BR]]
 Django Version: 1.1.1[[BR]]
 Python Version: 2.6.4[[BR]]
 Installed Applications:[[BR]]
 ['django.contrib.auth',[[BR]]
  'django.contrib.contenttypes',[[BR]]
  'django.contrib.sessions',[[BR]]
  'django.contrib.sites',[[BR]]
  'django.contrib.admin',[[BR]]
  'inventory.collection'][[BR]]
 [[BR]]
 Installed Middleware:[[BR]]
 ('django.middleware.common.CommonMiddleware',[[BR]]
  'django.contrib.sessions.middleware.SessionMiddleware',[[BR]]
  'django.contrib.auth.middleware.AuthenticationMiddleware')[[BR]]
 [[BR]]
 [[BR]]
 Traceback:[[BR]]
 File
 "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6
 /site-packages/django/core/handlers/base.py" in get_response[[BR]]
   83. request.path_info)[[BR]]
 File
 "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6
 /site-packages/django/core/urlresolvers.py" in resolve[[BR]]
   216. for pattern in self.url_patterns:[[BR]]
 File
 "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6
 /site-packages/django/core/urlresolvers.py" in _get_url_patterns[[BR]]
   245. patterns = getattr(self.urlconf_module, "urlpatterns",
 self.urlconf_module)[[BR]]
 File
 "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6
 /site-packages/django/core/urlresolvers.py" in _get_urlconf_module[[BR]]
   240. self._urlconf_module =
 import_module(self.urlconf_name)[[BR]]
 File
 "/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6
 /site-packages/django/utils/importlib.py" in import_module[[BR]]
   35. __import__(name)[[BR]]
 File "/Users/dru/projects/inventory/../inventory/urls.py" in
 [[BR]]
   17. (r'^admin/', include(admin.site.urls)),[[BR]]
 [[BR]]
 '''Exception Type: NameError at /admin/'''[[BR]]
 '''Exception Value: name 'admin' is not defined'''[[BR]]

-- 
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] #11838: Make syncdb understand "initialdata" directory

[Django]

#11838: Make syncdb understand "initialdata" directory
+---
  Reporter:  skorpan| Owner:  bkonkle   
  
Status:  assigned   | Milestone:  1.2   
  
 Component:  Uncategorized  |   Version:  SVN   
  
Resolution: |  Keywords:  syncdb loaddata 
initial_data
 Stage:  Accepted   | Has_patch:  1 
  
Needs_docs:  0  |   Needs_tests:  0 
  
Needs_better_patch:  0  |  
+---
Comment (by bkonkle):

 I've added a revised patch [attachment:ticket11838-2.diff here] with the
 line numbers referenced correctly.  Thanks for nothing, Macports! :-)

-- 
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] #11838: Make syncdb understand "initialdata" directory

[Django]

#11838: Make syncdb understand "initialdata" directory
+---
  Reporter:  skorpan| Owner:  bkonkle   
  
Status:  assigned   | Milestone:  1.2   
  
 Component:  Uncategorized  |   Version:  SVN   
  
Resolution: |  Keywords:  syncdb loaddata 
initial_data
 Stage:  Accepted   | Has_patch:  1 
  
Needs_docs:  0  |   Needs_tests:  0 
  
Needs_better_patch:  0  |  
+---
Comment (by bkonkle):

 The patch is not applying correctly because of a bug in Macport's version
 of Subversion.  I am removing the Macports-installed Subversion and
 compiling it from source.  I'll re-submit the diff when I'm done.

-- 
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] #11838: Make syncdb understand "initialdata" directory

[Django]

#11838: Make syncdb understand "initialdata" directory
+---
  Reporter:  skorpan| Owner:  bkonkle   
  
Status:  assigned   | Milestone:  1.2   
  
 Component:  Uncategorized  |   Version:  SVN   
  
Resolution: |  Keywords:  syncdb loaddata 
initial_data
 Stage:  Accepted   | Has_patch:  1 
  
Needs_docs:  0  |   Needs_tests:  0 
  
Needs_better_patch:  0  |  
+---
Changes (by bkonkle):

  * has_patch:  0 => 1

Comment:

 I've implemented the feature as Russel described above.  My diff includes
 the changes to the code, tests, and documentation.  Also, since this is my
 first Django contribution, I've added my name to the AUTHORS file. :-)
 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] #11952: HttpResponse Attribute docs refer to "status" when should be "status_code"

[Django]

#11952: HttpResponse Attribute docs refer to "status" when should be 
"status_code"
+---
  Reporter:  pjs| Owner:  nobody
Status:  new| Milestone:
 Component:  Documentation  |   Version:  1.1   
Resolution: |  Keywords:
 Stage:  Ready for checkin  | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by timo):

  * stage:  Unreviewed => Ready for checkin

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

--

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

Re: [Django] #11222: tutorial docs only give the relative location of the templates

[Django]

#11222: tutorial docs only give the relative location of the templates
+---
  Reporter:  cantorman  | Owner:  nobody
Status:  new| Milestone:
 Component:  Documentation  |   Version:  1.0   
Resolution: |  Keywords:
 Stage:  Ready for checkin  | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by timo):

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

Comment:

 seems like a good thing to point out to newbies.

-- 
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] #12329: "template" view decorator, allows to completely isolate views from templates

[Django]

#12329: "template" view decorator, allows to completely isolate views from
templates
---+
 Reporter:  gurunars   |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Uncategorized  | Version:  1.1   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 Well, the key point of this decorator is to let the developer define a
 template for the view in the following way:

 {{{
 @template
 def view_name(request):
 ...
 }}}

 OR

 {{{
 @template("template_name")
 def view_name(request):
 ...
 }}}

 In the first case the decorator automatically composes template's name in
 the following way: "app_name/view_name.html". This is the same name you
 would use in a "render_to_response" shortcut function.

 In the second case you define template's name explicitly. Again use the
 same name you would use for the "render_to_response" shortcut function.

 In both cases the return type can be either a dictionary, an HttpResponse
 or an HttpResponseHolder. The last one is just an extension to
 HttpResponse base class - it has just a single additional parameter called
 "context" (it is a dictionary). The only purpose of HttpResponseHolder is
 to pass a context dictionary to some other decorators for further
 processing. What kind of processing? I will give some examples below.

 '''First''' example is quite trivial. How to pass the "MEDIA_PATH"
 parameter from "settings.py" to all the templates? In this case it is
 really simple - use a decorator as the one just below

 {{{
 from django.conf import settings
 from .template import *

 class media(object):

 def __init__(self, orig_func):
 self.orig_func = orig_func
 #to compose template's name properly
 self.__name__ = self.orig_func.__name__
 self.__module__ = self.orig_func.__module__

 def __call__(self, *args, **kwargs):
 return_val = self.orig_func(*args, **kwargs)
 if isinstance(return_val, HttpResponseHolder):
 return_val.context["MEDIA_URL"] = settings.MEDIA_URL
 elif isinstance(return_val, dict):
 return_val["MEDIA_URL"] = settings.MEDIA_URL
 return return_val
 }}}

 in chain with the "template" decorator

 {{{
 @template()
 @media
 def view_name(request):
 ...
 }}}

 '''Second''' example is little bit more sophisticated but useful. How to
 pass to the template information about the user that is currently logged
 in (user object)? Use the following decorator

 {{{
 from .template import * #HttpResponseHolder

 class user(object):

 def __init__(self, orig_func):
 self.orig_func = orig_func
 #to compose template's name properly
 self.__name__ = self.orig_func.__name__
 self.__module__ = self.orig_func.__module__

 def __call__(self, request, *args, **kwargs):
 return_val = self.orig_func(request, *args, **kwargs)
 if request.user:
 if isinstance(return_val, HttpResponseHolder):
 return_val.context["user"] = request.user
 elif isinstance(return_val, dict):
 return_val["user"] = request.user
 return return_val
 }}}

 again in chain with the "template" decorator

 {{{
 @template()
 @user
 def view_name(request):
 ...
 }}}

 Definitely, writing your own decorators requires some skills in Python.
 But once done they simplify your life a lot.

-- 
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] #12195: cache set method - timeout - documentation

[Django]

#12195: cache set method - timeout - documentation
+---
  Reporter:  galund | Owner:  nobody
Status:  new| Milestone:
 Component:  Documentation  |   Version:  1.1   
Resolution: |  Keywords:
 Stage:  Ready for checkin  | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by timo):

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

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

 * cc: jfishman (added)

Comment:

 +1

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

--

You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #12328: subqueries in django 1.1 behave oddly

[Django]

#12328: subqueries in django 1.1 behave oddly
--+-
 Reporter:  wdoekes   |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Database layer (models, ORM)  | Version:  1.1   
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 Hi, I'm not sure what is wrong exactly. But it looks like subqueries in
 filters (introduced in django 1.1?) do not always work as intended.


 A basic model:
 {{{
 from django.db import models
 class M(models.Model):
 def __unicode__(self):
 return 'M(id=%d)' % self.id
 }}}

 The setup:
 {{{
 $ ./manage shell
 Python 2.5.2 (r252:60911, Jan  4 2009, 21:59:32)
 [GCC 4.3.2] on linux2
 Type "help", "copyright", "credits" or "license" for more information.
 (InteractiveConsole)
 >>> from osso.test.models import M
 >>> M.objects.create(id=1)
 
 >>> M.objects.create(id=2)
 
 >>> M.objects.create(id=3)
 
 >>> M.objects.all()
 [, , ]
 >>> M.objects.order_by('id')[:1]
 []
 >>> M.objects.order_by('id')[:1].delete()
 Traceback (most recent call last):
   File "", line 1, in 
   File "/opt/django11/django/db/models/query.py", line 379, in delete
 "Cannot use 'limit' or 'offset' with delete."
 AssertionError: Cannot use 'limit' or 'offset' with delete.
 }}}

 Bear with me. You have noticed my goal is to delete old records.

 Watch django1.0:
 {{{
 >>> M.objects.filter(id__in=M.objects.order_by('id')[0:1])
 
 TypeError: int() argument must be a string or a number, not 'M'
 >>>
 M.objects.filter(id__in=M.objects.order_by('id')[0:1].values_list('id',
 flat=True))
 []
 >>>
 M.objects.filter(id__in=M.objects.order_by('id')[0:1].values_list('id',
 flat=True)).delete()
 >>> M.objects.all()
 [, ]
 }}}
 That works as intended.

 And now django 1.1:
 {{{
 >>> M.objects.filter(id__in=M.objects.order_by('id')[:1])
 []
 >>> M.objects.filter(id__in=M.objects.order_by('id')[:1]).delete()
 >>> M.objects.all()
 []
 }}}
 (The same happens if I use the values_list() notation as used above.)

 What happens is that the del_query in QuerySet.delete() refers to a newer
 object every time, until all M objects have been deleted.

 The following could be related, or not :)

 After deleting an M object and re-adding it, I notice that ordering in
 subqueries does not work as intended either:
 {{{
 >>> M.objects.order_by('id')
 [, , ]
 >>> M.objects.order_by('id')[0:1]
 []
 >>> M.objects.filter(id__in=M.objects.order_by('id')[0:1])
 []
 >>>
 M.objects.filter(id__in=M.objects.order_by('id')[0:1].values_list('id',
 flat=True))
 []
 }}}

 This was tested with postgresql_psycopg2. With MySQL I cannot reproduce
 it, as it disallows LIMIT in subqueries, sending me an early error instead
 of behaving errantly.

 My current workaround is to wrap "M.objects.order_by('id')[:1]" in a
 list() so I do not get a dynamic object as id\_\_in value. Having to force
 early evaluation is a bit frightening though.

 I assume one should be able to reproduce this easily. If not, I'd be happy
 to share more information about my setup.

 Regards,[[br]]
 Walter Doekes

-- 
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] #12121: deepcopy(model_instance) causes infinite recursion since r11681

[Django]

#12121: deepcopy(model_instance) causes infinite recursion since r11681
---+
  Reporter:  emulbreh  | Owner:  nobody
Status:  closed| Milestone:
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:  fixed |  Keywords:
 Stage:  Unreviewed| Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  1 |  
---+
Comment (by russellm):

 @rfugger - are you reporting that this is *still* a problem? This should
 have been fixed by r11691; if it still exists for Python 2.4.3, then we
 have more work to do; a test case that triggers the infinite recursion
 would be most 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.

Re: [Django] #12121: deepcopy(model_instance) causes infinite recursion since r11681

[Django]

#12121: deepcopy(model_instance) causes infinite recursion since r11681
---+
  Reporter:  emulbreh  | Owner:  nobody
Status:  closed| Milestone:
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:  fixed |  Keywords:
 Stage:  Unreviewed| Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  1 |  
---+
Comment (by rfugger):

 I can confirm this bug on Red Hat under python 2.4.3.  Where I see it is
 attempting to pickle an object for caching (using locmem cache) --
 infinite recursion on Model.__reduce__.

 Using python 2.5 works fine.

-- 
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] #12326: Spelling, /en/dev/intro/tutorial04

[Django]

#12326: Spelling, /en/dev/intro/tutorial04
+---
  Reporter:  mortense   | Owner:  nobody
Status:  new| Milestone:
 Component:  Documentation  |   Version:  1.1   
Resolution: |  Keywords:  typo  
 Stage:  Ready for checkin  | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by timo):

  * needs_better_patch:  => 0
  * needs_tests:  => 0
  * keywords:  spelling => typo
  * needs_docs:  => 0
  * has_patch:  0 => 1
  * stage:  Unreviewed => Ready for checkin

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

--

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

[Django] #12327: Internationalization documentation specifies common middleware after session middleware

[Django]

#12327: Internationalization documentation specifies common middleware after
session middleware
---+
 Reporter:  portante   |   Owner:  nobody
   Status:  new|   Milestone:  1.2   
Component:  Documentation  | Version:  1.1   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 See the topic, [http://docs.djangoproject.com/en/1.0/topics/i18n/#id2 How
 Django Discovers Language Preference]. There is box that shows an example
 of where to locate the {{{LocaleMiddleware}}}, properly following
 {{{SessionMiddleware}}}, but listing {{{CommonMiddleware}}} last.

 In the [http://docs.djangoproject.com/en/1.0/topics/http/middleware
 /#topics-http-middleware middleware] documentation, {{{CommonMiddleware}}}
 is shown listed first. Is there any reason why {{{CommonMiddleware}}} must
 come first or last in either of these cases?

 A note clarifying any dependencies or documenting that there are no
 dependencies might 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.

[Django] #12326: Spelling, /en/dev/intro/tutorial04

[Django]

#12326: Spelling, /en/dev/intro/tutorial04
---+
 Reporter:  mortense   |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Documentation  | Version:  1.1   
 Keywords:  spelling   |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 Page :

   "Delete some the old" should be "Delete some of the old"

-- 
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] #12323: add support for STATIC_URL and STATIC_ROOT

[Django]

#12323: add support for STATIC_URL and STATIC_ROOT
-+--
  Reporter:  nagyv   | Owner:  nobody   
   
Status:  new | Milestone:   
   
 Component:  Core framework  |   Version:  1.1  
   
Resolution:  |  Keywords:  settings, media_url, 
media_root, static_url, static_root
 Stage:  Unreviewed  | Has_patch:  1
   
Needs_docs:  0   |   Needs_tests:  0
   
Needs_better_patch:  0   |  
-+--
Changes (by carljm):

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

Comment:

 I think the primary gain here would be if the form Media could be
 converted to use the new STATIC_ROOT setting rather than MEDIA_ROOT;
 currently form media in reusable apps using relative URL paths is a nasty
 sticking point if you are trying to separate user-uploaded media from
 static assets.

 Also, the [http://docs.djangoproject.com/en/dev/howto/static-files/#howto-
 static-files static file serving] documentation page currently
 demonstrates the creation of a custom setting, STATIC_DOC_ROOT; that could
 perhaps be changed to STATIC_ROOT if this goes through.

-- 
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] #12325: [PATCH]Allow zero moderate_after time

[Django]

#12325: [PATCH]Allow zero moderate_after time
-+--
 Reporter:  zhigang  |   Owner:  nobody
   Status:  new  |   Milestone:
Component:  django.contrib.comments  | Version:  1.1   
 Keywords:  moderation   |   Stage:  Unreviewed
Has_patch:  1|  
-+--
 In the current implement, if we want all comments go to approval queue
 just after a entry is published, you should assign moderate_after a value
 < 0. But moderate_after = 0 makes more sense. This patch allows this.

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

--

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

Re: [Django] #7198: manage.py sql/sqlall/test/etc. errors on apps without models.py files

[Django]

#7198: manage.py sql/sqlall/test/etc. errors on apps without models.py files
-+--
  Reporter:  gav | Owner:  nobody   

Status:  new | Milestone:   

 Component:  Core framework  |   Version:  SVN  

Resolution:  |  Keywords:  management 
command sql sqlall
 Stage:  Design decision needed  | Has_patch:  1

Needs_docs:  0   |   Needs_tests:  0

Needs_better_patch:  0   |  
-+--
Comment (by vak):

 since non-Django apps are de facto accepted since years, why not to
 respect this fact? ==> Let's allow emptyOK and let's skip not nice
 solution with injecting empty models.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-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] #12324: Translation of reset password e-mail subject in french

[Django]

#12324: Translation of reset password e-mail subject in french
---+
 Reporter:  zigarn |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Uncategorized  | Version:  1.1   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 The french translation of 'Password reset on %s' is 'Mot de passe mis à
 jour sur %s' which means 'Password updated on %s'.
 When receiving this e-mail, people can think that password has been
 reseted which is not the case

 The good translation would be 'Mise à jour de mot de passe sur %s'.

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

--

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

Re: [Django] #7028: Better raw_id_fields feedback in newform-admins branch

[Django]

#7028: Better raw_id_fields feedback in newform-admins branch
---+
  Reporter:  Marcob   | Owner:  nobody 
  
Status:  new   | Milestone:  1.2
  
 Component:  django.contrib.admin  |   Version:  SVN
  
Resolution:|  Keywords:  
raw-id-fields nfa-someday
 Stage:  Accepted  | Has_patch:  1  
  
Needs_docs:  0 |   Needs_tests:  1  
  
Needs_better_patch:  1 |  
---+
Comment (by marcob):

 Mrts, I think that we need also to update the label during an add-another:
 {{{
 diff -r be3cfbfcb85b
 lib/django/contrib/admin/media/js/admin/RelatedObjectLookups.js
 --- a/lib/django/contrib/admin/media/js/admin/RelatedObjectLookups.js
 Sat Dec 05 03:10:26 2009 +0100
 +++ b/lib/django/contrib/admin/media/js/admin/RelatedObjectLookups.js
 Sun Dec 06 06:00:58 2009 +0100
 @@ -100,6 +100,13 @@
  SelectBox.add_to_cache(toId, o);
  SelectBox.redisplay(toId);
  }
 +var nameElem = document.getElementById("view_lookup_" + name);
 +if (nameElem) {
 +  var chosedIdHref = String(win.location.href).split(/\/add\//)[0] +
 '/' + newId + '/';
 +  nameElem.innerHTML = '' +
 +html_escape(newRepr) + '';
 +}
  win.close();
  }
 }}}

 Do you agree?

-- 
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] #6148: Add generic support for database schemas

[Django]

#6148: Add generic support for database schemas
---+
  Reporter:  ikelly| Owner:  kmpm   

Status:  assigned  | Milestone: 

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

Resolution:|  Keywords:  oracle 
postgresql mysql schemas
 Stage:  Accepted  | Has_patch:  1  

Needs_docs:  0 |   Needs_tests:  0  

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

 Replying to [comment:39 hejsan]:
 > The app specific schema might for example be specified in the
 __init__.py file in the apps root folder, or in a settings.py file in that
 folder, or just use the apps name. That would solve 99% of use cases IMO.

 This is something for application-specific settings; I don't know if this
 is supported in Django currently. Anyway, each model in your application
 can have the schema specified explicitly, it could be also some
 application constant - like this:

 {{{
 APP_SCHEMA = "myschema"

 class MyModel(models.Model):
   ...
   class Meta:
 db_schema = APP_SCHEMA
 }}}

-- 
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] #12323: add support for STATIC_URL and STATIC_ROOT

[Django]

#12323: add support for STATIC_URL and STATIC_ROOT
--+-
 Reporter:  nagyv |   
Owner:  nobody
   Status:  new   |   
Milestone:
Component:  Core framework| 
Version:  1.1   
 Keywords:  settings, media_url, media_root, static_url, static_root  |   
Stage:  Unreviewed
Has_patch:  1 |  
--+-
 Separating user uploaded media from site-specific media seems to be
 meaningful. Thus a separate STATIC_URL, STATIC_ROOT setting would be
 helpful.
 A description of [http://lincolnloop.com/blog/2008/nov/13/static-media-
 and-django/ this approach is given by Peter Baumgartner].

 The attached patch adds STATIC_URL and STATIC_ROOT to global_settings
 defaulting them to MEDIA_URL and MEDIA_ROOT, respectively.
 The patch works with 1.1 and trunk too.

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