Re: [Django] #15237: Django generated Atom/RSS feeds don't specify charset=utf8 in their Content-Type

[Django]

#15237: Django generated Atom/RSS feeds don't specify charset=utf8 in their
Content-Type
-+--
   Reporter:  simon  | Owner:  jasonkotenko
 Status:  assigned   | Milestone:  1.3 
  Component:  RSS framework  |   Version:  1.2 
 Resolution: |  Keywords:  
   Triage Stage:  Accepted   | Has patch:  1   
Needs documentation:  0  |   Needs tests:  0   
Patch needs improvement:  0  |  
-+--
Changes (by jasonkotenko):

 * cc: jasonkotenko (added)
  * has_patch:  0 => 1


Comment:

 Assertion "Atom feeds containing UTF8 characters should be served with a
 Content-Type of "application/atom+xml; charset=utf8"." verified here:
 http://tools.ietf.org/html/rfc2045#section-5.1 (mime-type syntax) and
 here: http://tools.ietf.org/html/rfc3023#section-3.2 (recommendation to
 always set the charset).

 Although it does appear that if the charset is set in the XML declaration,
 i.e.  , then the charset in the
 Content-Type is not required, since everything within that XML document is
 ''supposed'' to be treated as UTF8.  However, it is still recommended so
 will proceed.

 Looks like the code in /django/contrib/syndication/views.py does not set
 the mime-type, it only uses it.  It is the util code in
 /django/utils/feedgenerator.py that sets it, as mentioned above.

 Can't find anything in the docs that requires changing due to this small
 change.

 Added regression test to verify the MIME type is still set with encoding
 in the future.

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

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

Re: [Django] #15237: Django generated Atom/RSS feeds don't specify charset=utf8 in their Content-Type

[Django]

#15237: Django generated Atom/RSS feeds don't specify charset=utf8 in their
Content-Type
-+--
   Reporter:  simon  | Owner:  jasonkotenko
 Status:  assigned   | Milestone:  1.3 
  Component:  RSS framework  |   Version:  1.2 
 Resolution: |  Keywords:  
   Triage Stage:  Accepted   | Has patch:  0   
Needs documentation:  0  |   Needs tests:  0   
Patch needs improvement:  0  |  
-+--
Changes (by jasonkotenko):

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


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

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

Re: [Django] #14138: Apache setup using sqlite3 breaks when performing a field__regex filter

[Django]

#14138: Apache setup using sqlite3 breaks when performing a field__regex filter
+---
   Reporter:  eternicode| Owner:  
nobody 
 Status:  closed| Milestone:
 
  Component:  Database layer (models, ORM)  |   Version:  1.2   
 
 Resolution:  worksforme|  Keywords:  
sqlite3 apache operationalerror databaseerror regex
   Triage Stage:  Unreviewed| Has patch:  0 
 
Needs documentation:  0 |   Needs tests:  0 
 
Patch needs improvement:  0 |  
+---

Comment (by Sashan ):

 Replying to [comment:6 Sashan ]:

 FYI the error message in apache error log when importing re in
 _sqlite_regex()
 looked as follows:
 {{{
 [error] cannot unmarshal code objects in restricted execution mode
 }}}

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

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

Re: [Django] #14138: Apache setup using sqlite3 breaks when performing a field__regex filter

[Django]

#14138: Apache setup using sqlite3 breaks when performing a field__regex filter
+---
   Reporter:  eternicode| Owner:  
nobody 
 Status:  closed| Milestone:
 
  Component:  Database layer (models, ORM)  |   Version:  1.2   
 
 Resolution:  worksforme|  Keywords:  
sqlite3 apache operationalerror databaseerror regex
   Triage Stage:  Unreviewed| Has patch:  0 
 
Needs documentation:  0 |   Needs tests:  0 
 
Patch needs improvement:  0 |  
+---

Comment (by Sashan ):

 So here we have a final summary. There were actually two problems with my
 set up.
 The ImportError was caused by some deficiencies in wscgi module. I've
 fixed by
 using excellent blog entry [http://blog.dscpl.com.au/2010/03/improved-
 wsgi-script-for-use-with.html] by Graham Dumpleton.

 The problem with import of re module in _sqlite_regexp() has been fixed by
 following
 steps discussed here:
 
http://code.google.com/p/modwsgi/wiki/ApplicationIssues#Multiple_Python_Sub_Interpreters

 adding a directive:

 {{{
 WSGIApplicationGroup %{GLOBAL}
 }}}

 saved my day.

 so I think it's not a problem of Django, not a problem of debian, it's
 just changes in wscgi module.

 also the python bindings for sqlite are not needed, since sqlite3 comes by
 default since python2.5.
 I'm running 2.6.

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

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

[Django] #15272: Context object name is translated string

[Django]

#15272: Context object name is translated string
+---
 Reporter:  szczav  |  Owner:  nobody
   Status:  new |  Milestone:
Component:  Generic views   |Version:  SVN   
 Keywords:  generic views context verbose_name  |   Triage Stage:  Unreviewed
Has patch:  0   |  
+---
 I'm using latest trunk. While I was using generic views all was perfect
 until I made some translations. Then some of my views crashed with
 VariableDoesNotExist("Failed lookup for key... I found out that when there
 is no context_object_name defined in generic class view then default value
 of this variable is not a object name, but its translation. In my case
 model name is Company so default context_object_name should be "company"
 and so it is so until I make translations, then it is (in my case)
 "firma". Context variables can't be dependand on translations and should
 be lowercased model name. Now it's inconsistent and may cause crash after
 modifying translations.

 It seems that fix is quite simple: in all methods get_context_object_name
 in ObjectMixins there is line with obj._meta.verbose_name.lower(). It
 should be replaced by obj._meta.object_name.lower().

 Tomorrow I'll try to do patch & tests.

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

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

[Django] #15271: django.contrib.gis.forms.fields.GeometryField should call to_python before cleaning

[Django]

#15271: django.contrib.gis.forms.fields.GeometryField should call to_python 
before
cleaning
--+-
 Reporter:  volrath   |  Owner:  nobody
   Status:  new   |  Milestone:
Component:  GIS   |Version:  SVN   
 Keywords:  gis, field, clean, to_python  |   Triage Stage:  Unreviewed
Has patch:  1 |  
--+-
 GeometryField overrides the default clean method for Field class and
 doesn't take in account the call to `to_python` before cleaning of the
 value.
 This is important because when using GeometryFields in a form you could
 want to render it with a MultiWidget, for example:

 Let's say we create a PointField (which inherits from GeometryField) with
 a MultiWidget that renders to FloatFields (one for each coordinate). This
 widget will return a list with both float values as its value, and that's
 what will be passed to the clean method. On every other field, we know
 that this list will be passed to to_python before calling clean, but with
 GeometryField that's not the case.

 Following that example, you could redefine the to_python method in our new
 PointField class to check if the value is instance of a tuple/list (like
 it's done in a DateTimeField), and transform it to a string representing
 the Point WKT formed with the two values of that list, but you will also
 have to redefine clean method to call `to_python` first and then do the
 cleaning.

 I'm submitting a simple patch to fix this.

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

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

Re: [Django] #14138: Apache setup using sqlite3 breaks when performing a field__regex filter

[Django]

#14138: Apache setup using sqlite3 breaks when performing a field__regex filter
+---
   Reporter:  eternicode| Owner:  
nobody 
 Status:  closed| Milestone:
 
  Component:  Database layer (models, ORM)  |   Version:  1.2   
 
 Resolution:  worksforme|  Keywords:  
sqlite3 apache operationalerror databaseerror regex
   Triage Stage:  Unreviewed| Has patch:  0 
 
Needs documentation:  0 |   Needs tests:  0 
 
Patch needs improvement:  0 |  
+---

Comment (by Sashan ):

 Replying to [comment:4 Sashan ]:
 > Replying to [comment:3 PaulM]:
 > >
 > >   "For an interface to SQLite 3, see the package python-pysqlite1.1,
 python-pysqlite2 or python-apsw."
 > >
 > > -http://packages.debian.org/wheezy/python-sqlite
 >
 > sure you were right, thanks for your help.

 sorry - still no success, once I've cleaned thy .pyc files I got same
 error, even though python-pysqlite2 package
 is installed.

 the apache error log says:
 [Thu Feb 10 22:53:18 2011] [error]
 /usr/lib/pymodules/python2.6/django/db/backends/sqlite3/base.py:243:
 RuntimeWarning: Parent module 'dango.db.backends.sqlite3' not found while
 handling absolute import
 [Thu Feb 10 22:53:18 2011] [error]   import re

 looks like environment is somehow screwed:
 the python path is content is as follows:
 [ '/usr/lib/python2.6', '/usr/lib/python2.6/plat-linux2',
 '/usr/lib/python2.6/lib-tk', '/usr/lib/python2.6/lib-old',
 '/usr/lib/python2.6/lib-dynload', '/usr/local/lib/python2.6/dist-
 packages', '/usr/lib/python2.6/dist-packages', '/usr/lib/python2.6/dist-
 packages/PIL', '/usr/lib/pymodules/python2.6', '/srv/parliament-poll-
 stats/' ]
 the last path is location of my django-site. django is installed in
 /usr/lib/pymodules/python2.6/

 even if I workaround the problem with 'import re' I will get stuck in {%
 url %}, which complains on ImportError if some urls module, which is part
 of my project.
 looks like it is a problem of Debian, not django.

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

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

Re: [Django] #14138: Apache setup using sqlite3 breaks when performing a field__regex filter

[Django]

#14138: Apache setup using sqlite3 breaks when performing a field__regex filter
+---
   Reporter:  eternicode| Owner:  
nobody 
 Status:  closed| Milestone:
 
  Component:  Database layer (models, ORM)  |   Version:  1.2   
 
 Resolution:  worksforme|  Keywords:  
sqlite3 apache operationalerror databaseerror regex
   Triage Stage:  Unreviewed| Has patch:  0 
 
Needs documentation:  0 |   Needs tests:  0 
 
Patch needs improvement:  0 |  
+---

Comment (by Sashan ):

 Replying to [comment:3 PaulM]:
 >
 >   "For an interface to SQLite 3, see the package python-pysqlite1.1,
 python-pysqlite2 or python-apsw."
 >
 > -http://packages.debian.org/wheezy/python-sqlite

 sure you were right, thanks for your help.

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

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

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

[Django]

#811: [patch] IPv6 address field support
--+-
   Reporter:  mattimustang@…  | Owner:  adrian  
   
 Status:  reopened| Milestone:  
   
  Component:  Core framework  |   Version:  SVN 
   
 Resolution:  |  Keywords:  ipv6 
IPAddressField
   Triage Stage:  Accepted| Has patch:  1   
   
Needs documentation:  0   |   Needs tests:  0   
   
Patch needs improvement:  0   |  
--+-
Changes (by mitar):

 * cc: mmitar@… (added)


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

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

Re: [Django] #15261: Admin querystring filters should work for superusers

[Django]

#15261: Admin querystring filters should work for superusers
+---
   Reporter:  cdestigter| Owner:  nobody
 Status:  closed| Milestone:
  Component:  django.contrib.admin  |   Version:  1.2   
 Resolution:  wontfix   |  Keywords:
   Triage Stage:  Unreviewed| Has patch:  1 
Needs documentation:  0 |   Needs tests:  0 
Patch needs improvement:  0 |  
+---

Comment (by cdestigter):

 Yes, I noticed that a similar thing could be achieved by doing something
 like:

 {{{
 def lookup_allowed(self, lookup, value):
 return True
 }}}

 But I see some problems with that approach:
  1. `lookup_allowed()` doesn't have access to the request, so can't tell
 if the user is a superuser. It can only be overridden for everyone, which
 could be a problem in setups with non-superuser staff members.
  2. This requires we use a custom ModelAdmin base for every model in our
 project. And then, it still won't work for Django builtin models like User
 unless we monkey-patch the django BaseModelAdmin class...

 Since superusers have implicit permissions for every model anyway, doesn't
 it seem logical that they should be able to filter by anything they like?

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

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

Re: [Django] #14093: Unable to create a new session key on higher traffic

[Django]

#14093: Unable to create a new session key on higher traffic
---+
   Reporter:  szymon@… | Owner:  nobody 

 Status:  new  | Milestone: 

  Component:  django.contrib.sessions  |   Version:  1.2

 Resolution:   |  Keywords:  session, 
cache, session key
   Triage Stage:  Accepted | Has patch:  1  

Needs documentation:  0|   Needs tests:  0  

Patch needs improvement:  0|  
---+
Changes (by tomevans223):

  * needs_better_patch:  1 => 0


Comment:

 Updated patch does pass tests. I've had a good read of the docs, and
 cannot find anywhere where the format of the session key is discussed, so
 I don't think there are any doc patches required.

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

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

[Django] #15270: augment staticfiles_urlpatterns to accept kwarg 'document_root'

[Django]

#15270: augment staticfiles_urlpatterns to accept kwarg 'document_root'
+---
 Reporter:  carbonXT|  Owner:
   Status:  new |  Milestone:  1.4   
Component:  django.contrib.staticfiles  |Version:  SVN   
 Keywords:  |   Triage Stage:  Unreviewed
Has patch:  0   |  
+---
 I want to be able to trail my urls.py with

 {{{
 urlpatterns += staticfiles_urlpatterns()
 urlpatterns += staticfiles_urlpatterns(prefix=settings.MEDIA_URL,
 document_root=settings.MEDIA_ROOT)
 }}}

 Rather than the currently suggested best practice from the documentation
 (http://docs.djangoproject.com/en/dev/ref/contrib/staticfiles/#serving-
 other-directories):

 {{{
   urlpatterns += staticfiles_urlpatterns()
   if settings.DEBUG:
   urlpatterns += patterns('django.contrib.staticfiles.views',
url(r'^media/(?P.*)$', 'serve',
{'document_root': settings.MEDIA_ROOT}), )
 }}}

 If this is agreed to in principle I'll write up a short patch and submit
 it.  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-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #15269: get_cache method should be documented as part of move to CACHES

[Django]

#15269: get_cache method should be documented as part of move to CACHES
-+--
 Reporter:  abdelazer@…  |  Owner:  nobody
   Status:  new  |  Milestone:
Component:  Documentation|Version:  SVN   
 Keywords:   |   Triage Stage:  Unreviewed
Has patch:  0|  
-+--
 While the move to CACHES is explained in docs/topics/cache.txt, it is not
 clear that this allows the declaration and access of multiple caches.

 An example with more than one (a non-'default') cache should be included.

 An explanation of how to use `get_cache` should be included, perhaps just
 a minor rewording of the docstring?

 {{{
 Function to load a cache backend dynamically. This is flexible by
 design
 to allow different use cases:

 To load a backend with the old URI-based notation::

 cache = get_cache('locmem://')

 To load a backend that is pre-defined in the settings::

 cache = get_cache('default')

 To load a backend with its dotted import path,
 including arbitrary options::

 cache =
 get_cache('django.core.cache.backends.memcached.MemcachedCache', **{
 'LOCATION': '127.0.0.1:11211', 'TIMEOUT': 30,
 })
 }}}

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

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

Re: [Django] #6213: PREPEND_WWW and APPEND_SLASH settings don't work with flatpages middleware

[Django]

#6213: PREPEND_WWW and APPEND_SLASH settings don't work with flatpages 
middleware
--+-
   Reporter:  esaj| Owner:  nobody  

 Status:  reopened| Milestone:  

  Component:  Core framework  |   Version:  SVN 

 Resolution:  |  Keywords:  APPEND_SLASH 
PREPEND_WWW flatpages easy-pickings
   Triage Stage:  Accepted| Has patch:  1   

Needs documentation:  0   |   Needs tests:  0   

Patch needs improvement:  1   |  
--+-
Changes (by sjl):

 * cc: sjl (added)


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

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

Re: [Django] #15263: "now" templatetag doesn't accept locale formats, as docs claim

[Django]

#15263: "now" templatetag doesn't accept locale formats, as docs claim
---+
   Reporter:  danielr  | Owner:  nobody
 Status:  new  | Milestone:
  Component:  Template system  |   Version:  SVN   
 Resolution:   |  Keywords:
   Triage Stage:  Accepted | Has patch:  1 
Needs documentation:  0|   Needs tests:  0 
Patch needs improvement:  0|  
---+
Changes (by creecode@…):

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

Re: [Django] #15268: User.objects.get_or_create has inconsistent behavior

[Django]

#15268: User.objects.get_or_create has inconsistent behavior
--+-
   Reporter:  w004dal | Owner:  nobody
 Status:  new | Milestone:
  Component:  Authentication  |   Version:  1.2   
 Resolution:  |  Keywords:
   Triage Stage:  Unreviewed  | Has patch:  0 
Needs documentation:  0   |   Needs tests:  0 
Patch needs improvement:  0   |  
--+-
Changes (by w004dal):

 * cc: w004dal (added)
  * needs_better_patch:  => 0
  * needs_tests:  => 0
  * needs_docs:  => 0


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

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

[Django] #15268: User.objects.get_or_create has inconsistent behavior

[Django]

#15268: User.objects.get_or_create has inconsistent behavior
+---
 Reporter:  w004dal |  Owner:  nobody
   Status:  new |  Milestone:
Component:  Authentication  |Version:  1.2   
 Keywords:  |   Triage Stage:  Unreviewed
Has patch:  0   |  
+---
 When I use User.objects.get_or_create(username=u, password=p) it should be
 syntactic sugar to:

 try:
   u = User.objects.get(username=u)
   assert u.password == p
   return u
 except User.DoesNotExist:
   return User.objects.create_user(username=u, password=p, email=foo)

 Additionally:

 User.objects.get_or_create(username=u, password=p) raises a database
 inconsistency error if 'u' exists with encrypted password 'p'.

 If 'u' does not exist in the database, the password is stored in clear
 text.

 This issue seems to coincide with an authentication issue in the
 administration console. When an admin tries to change the user's password,
 it is stored in clear text.

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

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

Re: [Django] #15267: now template tag does not recognize predefined formats

[Django]

#15267: now template tag does not recognize predefined formats
--+-
   Reporter:  creecode@…  | Owner:  nobody  
  
 Status:  closed  | Milestone:  
  
  Component:  Template system |   Version:  1.2 
  
 Resolution:  duplicate   |  Keywords:  now template 
tag predefined format
   Triage Stage:  Unreviewed  | Has patch:  1   
  
Needs documentation:  0   |   Needs tests:  0   
  
Patch needs improvement:  0   |  
--+-
Changes (by danielr):

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


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

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

Re: [Django] #15267: now template tag does not recognize predefined formats

[Django]

#15267: now template tag does not recognize predefined formats
--+-
   Reporter:  creecode@…  | Owner:  nobody  
  
 Status:  new | Milestone:  
  
  Component:  Template system |   Version:  1.2 
  
 Resolution:  |  Keywords:  now template 
tag predefined format
   Triage Stage:  Unreviewed  | Has patch:  1   
  
Needs documentation:  0   |   Needs tests:  0   
  
Patch needs improvement:  0   |  
--+-
Changes (by creecode@…):

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


Comment:

 Sorry for the confusion folks.  danielr already created ticket
 [http://code.djangoproject.com/ticket/15263 #15263] for this problem
 during the time (usually 24 hrs or more) I like to wait for potential
 responses to my initial post before proceeding.  I failed to check once
 again after doing so yesterday to see if I could find a ticket related to
 this issue.  danielr hadn't indicated in the user group thread that he was
 going to create a ticket.

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

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

Re: [Django] #14894: translation is not threadsafe

[Django]

#14894: translation is not threadsafe
--+-
   Reporter:  maxbublis   | Owner:  nobody  

 Status:  new | Milestone:  1.3 

  Component:  Core framework  |   Version:  1.2 

 Resolution:  |  Keywords:  threadsafety 
translation
   Triage Stage:  Unreviewed  | Has patch:  1   

Needs documentation:  0   |   Needs tests:  1   

Patch needs improvement:  0   |  
--+-

Comment (by maxbublis):

 Trunk codebase has been slightly changed during past 2 months.
 Iteration over _translations dictionary now is located in
 
[http://code.djangoproject.com/browser/django/trunk/django/utils/translation/trans_real.py#L149
 149 line]
 Changing _translations dictionary now is located in
 
[http://code.djangoproject.com/browser/django/trunk/django/utils/translation/trans_real.py#L181
 181 line]

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

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

Re: [Django] #14894: translation is not threadsafe

[Django]

#14894: translation is not threadsafe
--+-
   Reporter:  maxbublis   | Owner:  nobody  

 Status:  new | Milestone:  1.3 

  Component:  Core framework  |   Version:  1.2 

 Resolution:  |  Keywords:  threadsafety 
translation
   Triage Stage:  Unreviewed  | Has patch:  1   

Needs documentation:  0   |   Needs tests:  1   

Patch needs improvement:  0   |  
--+-
Changes (by jezdez):

  * stage:  Accepted => Unreviewed


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

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

Re: [Django] #14894: translation is not threadsafe

[Django]

#14894: translation is not threadsafe
--+-
   Reporter:  maxbublis   | Owner:  nobody  

 Status:  new | Milestone:  1.3 

  Component:  Core framework  |   Version:  1.2 

 Resolution:  |  Keywords:  threadsafety 
translation
   Triage Stage:  Accepted| Has patch:  1   

Needs documentation:  0   |   Needs tests:  1   

Patch needs improvement:  0   |  
--+-
Changes (by jezdez):

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

Re: [Django] #14894: translation is not threadsafe

[Django]

#14894: translation is not threadsafe
--+-
   Reporter:  maxbublis   | Owner:  nobody  

 Status:  new | Milestone:  1.3 

  Component:  Core framework  |   Version:  1.2 

 Resolution:  |  Keywords:  threadsafety 
translation
   Triage Stage:  Accepted| Has patch:  1   

Needs documentation:  0   |   Needs tests:  0   

Patch needs improvement:  0   |  
--+-

Comment (by maxbublis):

 What about progressing this ticket to "Ready For Checkin" state?

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

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

[Django] #15267: now template tag does not recognize predefined formats

[Django]

#15267: now template tag does not recognize predefined formats
+---
 Reporter:  creecode@…  |  Owner:  nobody
   Status:  new |  Milestone:
Component:  Template system |Version:  1.2   
 Keywords:  now template tag predefined format  |   Triage Stage:  Unreviewed
Has patch:  1   |  
+---
 The documentation for the now template tag <
 http://docs.djangoproject.com/en/dev/ref/templates/builtins/#now > says in
 part...

 Given format can be one of the predefined ones DATE_FORMAT,
 DATETIME_FORMAT, SHORT_DATE_FORMAT or SHORT_DATETIME_FORMAT, or a custom
 format, same as the date filter.

 I tried...

 {% now "DATE_FORMAT" %}

 ...and get back...

 WedAMPSTEPST0FebE_February-0800RFebAMPST

 The predefined format has been processed as a custom format.  I have
 USE_I18N and USE_L10N set to True, and
 LANGUAGE_CODE is 'en-us' in settings.py.  This is happening with Django
 1.2.4, 1.2.5 and appears to effect trunk.

 It appears from a quick glance at the source that the NowNode has no code
 in place to process the predefined formats.

 Here is my initial query about this problem on django users <
 http://groups.google.com/group/django-
 users/browse_thread/thread/cf80ea434c1112e8/ff21567e65d8ccf6#ff21567e65d8ccf6
 >.

 I have attached a patch which I believe brings the code into sync with the
 docs.

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

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

[Django] #15266: "login_required" for "password_change_done" like "password_change"

[Django]

#15266: "login_required" for "password_change_done" like "password_change"
---+
 Reporter:  Stephane   |  Owner:  nobody
   Status:  new|  Milestone:
Component:  Uncategorized  |Version:
 Keywords: |   Triage Stage:  Unreviewed
Has patch:  0  |  
---+
 Hi,

 There is a "login_required" for "password_change", but nothing for
 "password_change_done". It would be better to have:

 {{{
 @login_required
 def password_change_done [...]
 }}}

 Best regards,

 Stephane

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

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

Re: [Django] #14093: Unable to create a new session key on higher traffic

[Django]

#14093: Unable to create a new session key on higher traffic
---+
   Reporter:  szymon@… | Owner:  nobody 

 Status:  new  | Milestone: 

  Component:  django.contrib.sessions  |   Version:  1.2

 Resolution:   |  Keywords:  session, 
cache, session key
   Triage Stage:  Accepted | Has patch:  1  

Needs documentation:  0|   Needs tests:  0  

Patch needs improvement:  1|  
---+
Changes (by timo):

  * needs_better_patch:  0 => 1


Comment:

 Tom, I applied your patch and ran the tests for a quick sanity check.
 Looks like one issue is that django.contrib.sessions.backends.file only
 allows the following characters in cache keys: VALID_KEY_CHARS =
 set("abcdef0123456789").  Not sure if we can modify that set 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-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Re: [Django] #15265: Problem with "__call__" method in Templates

[Django]

#15265: Problem with "__call__" method in Templates
---+
   Reporter:  Stephane | Owner:  nobody  
 Status:  closed   | Milestone:  1.3 
  Component:  Template system  |   Version:  1.3-beta
 Resolution:  wontfix  |  Keywords:  
   Triage Stage:  Unreviewed   | Has patch:  0   
Needs documentation:  0|   Needs tests:  0   
Patch needs improvement:  0|  
---+

Comment (by anonymous):

 Thank you.

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

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

Re: [Django] #15265: Problem with "__call__" method in Templates

[Django]

#15265: Problem with "__call__" method in Templates
---+
   Reporter:  Stephane | Owner:  nobody  
 Status:  closed   | Milestone:  1.3 
  Component:  Template system  |   Version:  1.3-beta
 Resolution:  wontfix  |  Keywords:  
   Triage Stage:  Unreviewed   | Has patch:  0   
Needs documentation:  0|   Needs tests:  0   
Patch needs improvement:  0|  
---+
Changes (by lrekucki):

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


Comment:

 This is most likely a "won't fix". See ticket #15025 and the
 [http://docs.djangoproject.com/en/dev/ref/templates/api/#rendering-a-context
 docs for render]. Citing:

 > If any part of the variable is callable, the template system will try
 calling it.
 >
 > Changed in Django Development version: Previously, only variables that
 originated with an attribute lookup would be called by the template
 system. This change was made for consistency across lookup types.

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

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

Re: [Django] #15265: Problem with "__call__" method in Templates

[Django]

#15265: Problem with "__call__" method in Templates
---+
   Reporter:  Stephane | Owner:  nobody  
 Status:  new  | Milestone:  1.3 
  Component:  Template system  |   Version:  1.3-beta
 Resolution:   |  Keywords:  
   Triage Stage:  Unreviewed   | Has patch:  0   
Needs documentation:  0|   Needs tests:  0   
Patch needs improvement:  0|  
---+
Changes (by anonymous):

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


Comment:

 Sorry, underscores are removed...

 {{{
 class MyDict(object):
 TEST = {"var": "test", "meuh": "test2"}

 def __getitem__(self, key):
 """
 Retrieves a value. Raises a :exc:`KeyError` if *key* does not
 exists.
 """
 return MyDict.TEST[key]

 def __call__(self, **kwargs):
 """
 Puts one or more values into this...
 """
 for key, value in kwargs.items():
 self[key] = value
 }}}

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

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

[Django] #15265: Problem with "__call__" method in Templates

[Django]

#15265: Problem with "__call__" method in Templates
-+--
 Reporter:  Stephane |  Owner:  nobody
   Status:  new  |  Milestone:  1.3   
Component:  Template system  |Version:  1.3-beta  
 Keywords:   |   Triage Stage:  Unreviewed
Has patch:  0|  
-+--
 Hi,

 We have another problem in templates since Django 1.3 when we put dict
 values into template with "__getitem__".

 We create this class for example:

 class MyDict(object):
 TEST = {"var": "test", "meuh": "test2"}

 def __getitem__(self, key):
 """
 Retrieves a value. Raises a :exc:`KeyError` if *key* does not
 exists.
 """
 return MyDict.TEST[key]

 def __call__(self, **kwargs):
 """
 Puts one or more values into this...
 """
 for key, value in kwargs.items():
 self[key] = value

 We add this in a template context:

 test = MyDict()
 return test

 In the template, we want to get the value of "var" key for example:

 {{mydict.var}}

 No output... But if we remove "__call__" method, we have the value: "test"
 (same as before 1.3).

 Best regards,

 Stephane

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

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

Re: [Django] #12635: Process HTTP PUT into request.FILES and request.PUT as done for POST

[Django]

#12635: Process HTTP PUT into request.FILES and request.PUT as done for POST
-+--
   Reporter:  boxm   | Owner:  nobody
 Status:  new| Milestone:  1.3   
  Component:  HTTP handling  |   Version:  SVN   
 Resolution: |  Keywords:  PUT   
   Triage Stage:  Accepted   | Has patch:  0 
Needs documentation:  0  |   Needs tests:  0 
Patch needs improvement:  0  |  
-+--
Changes (by lrekucki):

 * cc: lrekucki@… (added)
  * milestone:  => 1.3


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

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

Re: [Django] #15252: get_static_url in static templatetags

[Django]

#15252: get_static_url in static templatetags
--+-
   Reporter:  ohardy  | Owner:  nobody
 Status:  new | Milestone:
  Component:  django.contrib.staticfiles  |   Version:  SVN   
 Resolution:  |  Keywords:
   Triage Stage:  Design decision needed  | Has patch:  0 
Needs documentation:  0   |   Needs tests:  0 
Patch needs improvement:  0   |  
--+-

Comment (by ohardy):

 Several differences:
 * STATIC_URL is not required since the storage is constructing the URL
 * If a storage wants to build a URL encoded, for example, it is impossible
 to build this URL with STATIC_URL.
 * STATIC_URL been given duplicate such that for S3 storage as we already
 set the URL when you declare storage.

 All these remarks also apply to MEDIA_URL

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

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

Re: [Django] #15244: Documentation needed for RadioFieldRenderer

[Django]

#15244: Documentation needed for RadioFieldRenderer
-+--
   Reporter:  SmileyChris| Owner:  lkeijser   
 Status:  assigned   | Milestone: 
  Component:  Documentation  |   Version:  SVN
 Resolution: |  Keywords:  renderer widget
   Triage Stage:  Ready for checkin  | Has patch:  0  
Needs documentation:  0  |   Needs tests:  0  
Patch needs improvement:  0  |  
-+--
Changes (by lkeijser):

  * status:  new => assigned
  * owner:  nobody => lkeijser
  * version:  => SVN
  * keywords:  => renderer widget
  * stage:  Accepted => Ready for checkin


Comment:

 I've created a patch against the latest trunk (rev. 15487). As this is my
 first patch, format might not be correct so please review.

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

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

Re: [Django] #11383: Admin action 'Delete selected' check only global model delete permission

[Django]

#11383: Admin action 'Delete selected' check only global model delete permission
+---
   Reporter:  krejcik@… | Owner:  nobody
 
 Status:  new   | Milestone:
 
  Component:  django.contrib.admin  |   Version:  SVN   
 
 Resolution:|  Keywords:  delete 
permission admin
   Triage Stage:  Accepted  | Has patch:  0 
 
Needs documentation:  0 |   Needs tests:  0 
 
Patch needs improvement:  0 |  
+---
Changes (by nfg):

 * cc: nils@… (added)


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

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

Re: [Django] #14093: Unable to create a new session key on higher traffic

[Django]

#14093: Unable to create a new session key on higher traffic
---+
   Reporter:  szymon@… | Owner:  nobody 

 Status:  new  | Milestone: 

  Component:  django.contrib.sessions  |   Version:  1.2

 Resolution:   |  Keywords:  session, 
cache, session key
   Triage Stage:  Accepted | Has patch:  1  

Needs documentation:  0|   Needs tests:  0  

Patch needs improvement:  0|  
---+
Changes (by tomevans223):

  * has_patch:  0 => 1


Comment:

 Replacing md5 session key with uuid session key would result in virtually
 zero chance of key collision.

 See attached patch.

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

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

Re: [Django] #9625: ForeignKey data type for certain derived model fields not calculated correctly

[Django]

#9625: ForeignKey data type for certain derived model fields not calculated
correctly
+---
   Reporter:  robbyd| Owner:  nobody
 Status:  closed| Milestone:
  Component:  Database layer (models, ORM)  |   Version:  1.0   
 Resolution:  duplicate |  Keywords:
   Triage Stage:  Accepted  | Has patch:  0 
Needs documentation:  0 |   Needs tests:  0 
Patch needs improvement:  0 |  
+---
Changes (by mmcnickle):

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


Comment:

 Duplicate of [http://code.djangoproject.com/ticket/13774 #13774].

 Closing this bug, even though it was reported first, as the other ticket
 has a workable patch.

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

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

Re: [Django] #15264: Problem with custom cache backend

[Django]

#15264: Problem with custom cache backend
+---
   Reporter:  Stephane  | Owner:  nobody  
 Status:  new   | Milestone:  1.3 
  Component:  Cache system  |   Version:  1.3-beta
 Resolution:|  Keywords:  blocker 
   Triage Stage:  Accepted  | Has patch:  0   
Needs documentation:  0 |   Needs tests:  0   
Patch needs improvement:  0 |  
+---
Changes (by russellm):

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


Comment:

 This is a bug in a new feature, so it's a blocker.

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

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

Re: [Django] #15262: generic views don't populate request.POST when handling PUT

[Django]

#15262: generic views don't populate request.POST when handling PUT
--+-
   Reporter:  kenth   | Owner:  nobody
 Status:  closed  | Milestone:
  Component:  Core framework  |   Version:  SVN   
 Resolution:  duplicate   |  Keywords:
   Triage Stage:  Unreviewed  | Has patch:  0 
Needs documentation:  0   |   Needs tests:  0 
Patch needs improvement:  0   |  
--+-
Changes (by russellm):

  * status:  new => closed
  * resolution:  => duplicate
  * component:  Generic views => Core framework


Comment:

 This isn't a generic view problem -- it's more fundamental than that.
 Django's HTTP handler doesn't contain good support for HTTP verbs that
 aren't GET or PUT.

 This has been reported in the past as #12635.

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

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

Re: [Django] #14286: Support for BigAutoField

[Django]

#14286: Support for BigAutoField
+---
   Reporter:  hongrich  | Owner:  
mmcnickle
 Status:  new   | Milestone:
   
  Component:  Database layer (models, ORM)  |   Version:  SVN   
   
 Resolution:|  Keywords:
   
   Triage Stage:  Accepted  | Has patch:  1 
   
Needs documentation:  0 |   Needs tests:  1 
   
Patch needs improvement:  0 |  
+---
Changes (by mmcnickle):

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

Re: [Django] #15253: 1.1.3, 1.2.4, and 1.3 release notes lack mention of Dec. 2010 security fixes

[Django]

#15253: 1.1.3, 1.2.4, and 1.3 release notes lack mention of Dec. 2010 security
fixes
-+--
   Reporter:  gwilson| Owner:  nobody 
 Status:  reopened   | Milestone: 
  Component:  Documentation  |   Version:  SVN
 Resolution: |  Keywords:  blocker
   Triage Stage:  Accepted   | Has patch:  0  
Needs documentation:  0  |   Needs tests:  0  
Patch needs improvement:  0  |  
-+--
Changes (by russellm):

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


Comment:

 ... and now I've just re-read the ticket title, and you're referring to
 the *December* security release, not yesterday's release.

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

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

Re: [Django] #15263: "now" templatetag doesn't accept locale formats, as docs claim

[Django]

#15263: "now" templatetag doesn't accept locale formats, as docs claim
---+
   Reporter:  danielr  | Owner:  nobody
 Status:  new  | Milestone:
  Component:  Template system  |   Version:  SVN   
 Resolution:   |  Keywords:
   Triage Stage:  Accepted | Has patch:  1 
Needs documentation:  0|   Needs tests:  0 
Patch needs improvement:  0|  
---+
Changes (by ersame):

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


Comment:

 The patch looks OK.

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

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

[Django] #15264: Problem with custom cache backend

[Django]

#15264: Problem with custom cache backend
--+-
 Reporter:  Stephane  |  Owner:  nobody
   Status:  new   |  Milestone:  1.3   
Component:  Cache system  |Version:  1.3-beta  
 Keywords:|   Triage Stage:  Unreviewed
Has patch:  0 |  
--+-
 Hi,

 I have a problem since Django 1.3 to start our project with our custom
 cache backend:
 CACHE_BACKEND =
 "portail.cache.backends.filesandmint://192.168.1.100:11211/"

 This is the error:

  File "/usr/local/lib/python2.6/dist-
 packages/django/core/management/commands/runserver.py", line 81, in
 inner_run
 self.validate(display_num_errors=True)
   File "/usr/local/lib/python2.6/dist-
 packages/django/core/management/base.py", line 243, in validate
 from django.core.management.validation import get_validation_errors
   File "/usr/local/lib/python2.6/dist-
 packages/django/core/management/validation.py", line 3, in 
 from django.contrib.contenttypes.generic import GenericForeignKey,
 GenericRelation
   File "/usr/local/lib/python2.6/dist-
 packages/django/contrib/contenttypes/generic.py", line 13, in 
 from django.contrib.admin.options import InlineModelAdmin,
 flatten_fieldsets
   File "/usr/local/lib/python2.6/dist-
 packages/django/contrib/admin/__init__.py", line 4, in 
 from django.contrib.admin.options import ModelAdmin, HORIZONTAL,
 VERTICAL
   File "/usr/local/lib/python2.6/dist-
 packages/django/contrib/admin/options.py", line 10, in 
 from django.views.decorators.csrf import csrf_protect
   File "/usr/local/lib/python2.6/dist-
 packages/django/views/decorators/csrf.py", line 1, in 
 from django.middleware.csrf import CsrfViewMiddleware
   File "/usr/local/lib/python2.6/dist-packages/django/middleware/csrf.py",
 line 14, in 
 from django.utils.cache import patch_vary_headers
   File "/usr/local/lib/python2.6/dist-packages/django/utils/cache.py",
 line 24, in 
 from django.core.cache import get_cache
   File "/usr/local/lib/python2.6/dist-
 packages/django/core/cache/__init__.py", line 168, in 
 cache = get_cache(DEFAULT_CACHE_ALIAS)
   File "/usr/local/lib/python2.6/dist-
 packages/django/core/cache/__init__.py", line 165, in get_cache
 "Could not find backend '%s': %s" % (backend, e))
 django.core.cache.backends.base.InvalidCacheBackendError: Could not find
 backend 'portail.cache.backends.filesandmint': 'module' object has no
 attribute 'filesandmint'

 But if we change the setting to:
 CACHE_BACKEND =
 "portail.cache.backends.filesandmint.CacheClass://192.168.1.100:11211/"
 The project start...

 Best regards,

 Stephane

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

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

[Django] #15263: "now" templatetag doesn't accept locale formats, as docs claim

[Django]

#15263: "now" templatetag doesn't accept locale formats, as docs claim
-+--
 Reporter:  danielr  |  Owner:  nobody
   Status:  new  |  Milestone:
Component:  Template system  |Version:  SVN   
 Keywords:   |   Triage Stage:  Unreviewed
Has patch:  1|  
-+--
 The documentation on the `now` tag claims that it acts like the `date`
 filter in accepting "DATE_FORMAT" as a shortcut to the locale's current
 date format. However, this is not the case:

 {{{
 >>> t=Template("""{% now "DATE_FORMAT" %}""")
 >>> t.render(Context())
 u'WedPMGMTE_February+RFebPMGMT'
 }}}

 Clearly the string is being interpreted as a literal format, instead of
 being translated to the locale's date format.

 Attached patch fixes this by using the same logic as the `date` filter,
 including a regression test, and slightly tweaks the awkward wording in
 the docs.

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

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

Re: [Django] #11639: Can't remove prepopulated fields from fieldset in ModelAdmin

[Django]

#11639: Can't remove prepopulated fields from fieldset in ModelAdmin
+---
   Reporter:  leanmeandonothingmachine  | Owner:  nobody
 
 Status:  new   | Milestone:  1.3   
 
  Component:  django.contrib.admin  |   Version:  1.3-beta  
 
 Resolution:|  Keywords:  
sprintnov13
   Triage Stage:  Accepted  | Has patch:  1 
 
Needs documentation:  0 |   Needs tests:  0 
 
Patch needs improvement:  0 |  
+---
Changes (by leanmeandonothingmachine):

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


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

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

Re: [Django] #11639: Can't remove prepopulated fields from fieldset in ModelAdmin

[Django]

#11639: Can't remove prepopulated fields from fieldset in ModelAdmin
+---
   Reporter:  leanmeandonothingmachine  | Owner:  nobody
 
 Status:  new   | Milestone:  1.3   
 
  Component:  django.contrib.admin  |   Version:  1.3-beta  
 
 Resolution:|  Keywords:  
sprintnov13
   Triage Stage:  Accepted  | Has patch:  1 
 
Needs documentation:  1 |   Needs tests:  1 
 
Patch needs improvement:  0 |  
+---
Changes (by leanmeandonothingmachine):

  * version:  1.2 => 1.3-beta
  * milestone:  1.4 => 1.3


Comment:

 I updated the patch to include tests and documentation. I also added
 inline support based on the way get_readonly_fields works. Can this be
 considered for 1.3? If it really is too late then change it back to 1.4,
 it would be nice though to have this get some attention.

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

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

Re: [Django] #10932: Allow Min() on CharFields on postgres

[Django]

#10932: Allow Min() on CharFields on postgres
---+
   Reporter:  terrex   | Owner:  wogan
 Status:  assigned | Milestone:   
  Component:  ORM aggregation  |   Version:  1.0  
 Resolution:   |  Keywords:   
   Triage Stage:  Accepted | Has patch:  0
Needs documentation:  0|   Needs tests:  0
Patch needs improvement:  1|  
---+
Changes (by wogan):

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

Re: [Django] #13844: Errors when using character fields for aggregation

[Django]

#13844: Errors when using character fields for aggregation
+---
   Reporter:  zegrep@…  | Owner:  wogan
 Status:  assigned  | Milestone:   
  Component:  Database layer (models, ORM)  |   Version:  1.2  
 Resolution:|  Keywords:   
   Triage Stage:  Accepted  | Has patch:  1
Needs documentation:  0 |   Needs tests:  0
Patch needs improvement:  0 |  
+---
Changes (by wogan):

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


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

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

Re: [Django] #14462: Aggregates default to the database type instead of the field type

[Django]

#14462: Aggregates default to the database type instead of the field type
+---
   Reporter:  WoLpH | Owner:  wogan 
   
 Status:  assigned  | Milestone:
   
  Component:  Database layer (models, ORM)  |   Version:  1.2   
   
 Resolution:|  Keywords:  
aggregate, annotate, type, coerce
   Triage Stage:  Accepted  | Has patch:  0 
   
Needs documentation:  0 |   Needs tests:  0 
   
Patch needs improvement:  0 |  
+---
Changes (by wogan):

  * status:  new => assigned
  * owner:  => wogan


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

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

Re: [Django] #12889: Using annotation unexpectedly returns DecimalFields as floats

[Django]

#12889: Using annotation unexpectedly returns DecimalFields as floats
+---
   Reporter:  KyleMac   | Owner:  wogan 
  
 Status:  assigned  | Milestone:
  
  Component:  Database layer (models, ORM)  |   Version:  SVN   
  
 Resolution:|  Keywords:  
annotate
   Triage Stage:  Accepted  | Has patch:  0 
  
Needs documentation:  0 |   Needs tests:  0 
  
Patch needs improvement:  0 |  
+---
Changes (by wogan):

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

Re: [Django] #14879: Aggregates (Min, Max) for CharField fails with Postgresql

[Django]

#14879: Aggregates (Min, Max) for CharField fails with Postgresql
+---
   Reporter:  wejaay| Owner:  wogan 
  
 Status:  assigned  | Milestone:
  
  Component:  Database layer (models, ORM)  |   Version:  SVN   
  
 Resolution:|  Keywords:  
aggregate, postgresql, charfield
   Triage Stage:  Accepted  | Has patch:  1 
  
Needs documentation:  0 |   Needs tests:  1 
  
Patch needs improvement:  1 |  
+---
Changes (by wogan):

  * owner:  nobody => wogan
  * status:  new => assigned
  * version:  1.2 => SVN


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

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

Re: [Django] #15259: Django Weblog suggested workaround for XMLHttpRequest CSRF fix in 1.2.5 uses wrong jQuery selector

[Django]

#15259: Django Weblog suggested workaround for XMLHttpRequest CSRF fix in 1.2.5
uses wrong jQuery selector
---+
   Reporter:  markhellewell| Owner:  nobody 
 Status:  closed   | Milestone: 
  Component:  Django Web site  |   Version:  1.2
 Resolution:  fixed|  Keywords:  blocker
   Triage Stage:  Accepted | Has patch:  0  
Needs documentation:  0|   Needs tests:  0  
Patch needs improvement:  0|  
---+

Comment (by russellm):

 [http://www.djangoproject.com/weblog/2011/feb/10/security-errata/ Blog
 post has been made]; fixes to release notes will be landing soon.

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

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

Re: [Django] #15262: generic views don't populate request.POST when handling PUT

[Django]

#15262: generic views don't populate request.POST when handling PUT
-+--
   Reporter:  kenth  | Owner:  nobody
 Status:  new| Milestone:
  Component:  Generic views  |   Version:  SVN   
 Resolution: |  Keywords:
   Triage Stage:  Unreviewed | Has patch:  0 
Needs documentation:  0  |   Needs tests:  0 
Patch needs improvement:  0  |  
-+--
Changes (by kenth):

  * needs_docs:  => 0
  * version:  1.2 => SVN
  * needs_tests:  => 0
  * needs_better_patch:  => 0


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

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

[Django] #15262: generic views don't populate request.POST when handling PUT

[Django]

#15262: generic views don't populate request.POST when handling PUT
---+
 Reporter:  kenth  |  Owner:  nobody
   Status:  new|  Milestone:
Component:  Generic views  |Version:  1.2   
 Keywords: |   Triage Stage:  Unreviewed
Has patch:  0  |  
---+
 The new CBVs handle PUT as a synonym for POST, but django.http doesn't
 populate the request.POST & request.FILES for any verb except POST. I
 believe that PUT is being translated as an empty POST, which is not what I
 would have expected.

 The CBV handling of PUT is in several places in
 django/views/generic/edit.py both in redirecting the put method definition
 and the get_form_kwargs() method.

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

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

Re: [Django] #15250: Cannot fill parent model instance in cache

[Django]

#15250: Cannot fill parent model instance in cache
+---
   Reporter:  vzima | Owner:  nobody
 Status:  new   | Milestone:
  Component:  Database layer (models, ORM)  |   Version:  1.2   
 Resolution:|  Keywords:
   Triage Stage:  Accepted  | Has patch:  0 
Needs documentation:  0 |   Needs tests:  0 
Patch needs improvement:  0 |  
+---
Changes (by russellm):

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


Comment:

 Ok - thanks for the extra debug information. Looks like there is something
 going wrong here. As I indicated on #14371, the select_related() isn't
 necessary, but you've clearly shown that the parent object isn't being
 prepopulated as I said, either.

 As a matter of procedure -- this is the sort of situation where it would
 have been ok to reopen the old ticket. It's the same problem, but by
 providing more debugging information you can demonstrate that the
 assertion I made was wrong. If that's the case, its perfectly acceptable
 to reopen an old ticket.

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

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

Re: [Django] #15246: Allow to change session expiration without re-saving session data.

[Django]

#15246: Allow to change session expiration without re-saving session data.
---+
   Reporter:  zimnyx   | Owner:  nobody   
 Status:  new  | Milestone:   
  Component:  django.contrib.sessions  |   Version:  1.3-alpha
 Resolution:   |  Keywords:   
   Triage Stage:  Accepted | Has patch:  0
Needs documentation:  0|   Needs tests:  0
Patch needs improvement:  0|  
---+
Changes (by russellm):

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


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

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

Re: [Django] #15249: Provide access to a debugger within the development server (was: [PATCH] Inline debugging)

[Django]

#15249: Provide access to a debugger within the development server
--+-
   Reporter:  lxsameer| Owner:  lxsameer   
 Status:  new | Milestone: 
  Component:  Core framework  |   Version:  1.2
 Resolution:  |  Keywords:  inline debugger
   Triage Stage:  Accepted| Has patch:  1  
Needs documentation:  0   |   Needs tests:  0  
Patch needs improvement:  1   |  
--+-

Comment (by russellm):

 ... and please don't include [patch] in the subject. We know it has a
 patch -- that's why we have a "has patch" flag on the ticket.

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

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

Re: [Django] #15248: Can not embed a comment bloc in another comment block

[Django]

#15248: Can not embed a comment bloc in another comment block
---+
   Reporter:  postal2600   | Owner:  nobody
 Status:  closed   | Milestone:
  Component:  Template system  |   Version:  1.2   
 Resolution:  wontfix  |  Keywords:
   Triage Stage:  Unreviewed   | Has patch:  0 
Needs documentation:  0|   Needs tests:  0 
Patch needs improvement:  0|  
---+
Changes (by russellm):

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


Comment:

 This isn't an uncommon limitation in many programming languages. because
 it's syntactically ambiguous. In the following template:
 {{{
 {% comment %}{% comment %}{% endcomment %}{% endcomment %}
 }}}
 Is the second {{{ {% comment %} }}} something that is being commented out,
 or the start of a second comment?

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

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

Re: [Django] #15249: [PATCH] Inline debugging

[Django]

#15249: [PATCH] Inline debugging
--+-
   Reporter:  lxsameer| Owner:  lxsameer   
 Status:  new | Milestone: 
  Component:  Core framework  |   Version:  1.2
 Resolution:  |  Keywords:  inline debugger
   Triage Stage:  Accepted| Has patch:  1  
Needs documentation:  0   |   Needs tests:  0  
Patch needs improvement:  1   |  
--+-
Changes (by russellm):

  * needs_better_patch:  0 => 1
  * stage:  Unreviewed => Accepted


Comment:

 As noted [http://groups.google.com/group/django-
 developers/browse_thread/thread/bcb3e959e897150c on django-dev] --
 notionally accepted, but the provided patch won't be the way to do it.
 This isn't something that can be inserted into the base HTTP handler,
 because that code will end up on production servers.

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

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

Re: [Django] #15253: 1.1.3, 1.2.4, and 1.3 release notes lack mention of Dec. 2010 security fixes

[Django]

#15253: 1.1.3, 1.2.4, and 1.3 release notes lack mention of Dec. 2010 security
fixes
-+--
   Reporter:  gwilson| Owner:  nobody 
 Status:  new| Milestone: 
  Component:  Documentation  |   Version:  SVN
 Resolution: |  Keywords:  blocker
   Triage Stage:  Accepted   | Has patch:  0  
Needs documentation:  0  |   Needs tests:  0  
Patch needs improvement:  0  |  
-+--
Changes (by russellm):

  * keywords:  => blocker
  * stage:  Unreviewed => Accepted


Comment:

 1.2.4 notes don't need any change, because it was the 1.2.5 releease :-)

 I committed a note to the 1.2.5 release notes last night in r15478
 (responding to #15245). #15259 indicates that there is a problem with the
 example, but once that is fixed, the same text should be cross ported into
 the 1.3 and 1.1.4 release notes.

 And yes, it is needed in the 1.3 notes, because anyone upgrading from 1.2
 to 1.3 will hit the problem.

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

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

Re: [Django] #15255: DB Cache table creation (createcachetable) ignores the DB Router

[Django]

#15255: DB Cache table creation (createcachetable) ignores the DB Router
+---
   Reporter:  zvikico   | Owner:  nobody  
 Status:  new   | Milestone:  
  Component:  Cache system  |   Version:  1.3-beta
 Resolution:|  Keywords:  
   Triage Stage:  Accepted  | Has patch:  0   
Needs documentation:  0 |   Needs tests:  0   
Patch needs improvement:  0 |  
+---
Changes (by russellm):

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


Comment:

 Agreed - allow_syncdb() instructions should be honored. As a side note,
 there is a related refactoring in the test code
 (db.backends.creation.create_test_db) -- allow_syncdb is being checked
 there prior to invoking the database cache table command.

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

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

Re: [Django] #15256: FormSet does not respect initial values after binding

[Django]

#15256: FormSet does not respect initial values after binding
--+-
   Reporter:  mnbayazit   | Owner:  nobody 
 Status:  closed  | Milestone: 
  Component:  Forms   |   Version:  SVN
 Resolution:  invalid |  Keywords:  formset
   Triage Stage:  Unreviewed  | Has patch:  1  
Needs documentation:  0   |   Needs tests:  0  
Patch needs improvement:  0   |  
--+-
Changes (by russellm):

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


Old description:

> After the form is posted, if an empty form is generated, it will be
> completely empty rather than having the initial values specified on the
> form. I believe we can fix this by modifying `_construct_form` like so:
>
> if self.is_bound and i < self.initial_form_count():
> defaults['data'] = self.data
> defaults['files'] = self.files
>
> And completely remove this chunk from _get_empty_form
>
> if self.is_bound:
> defaults['data'] = self.data
> defaults['files'] = self.files
>
> I don't know why an empty form should behave any differently after the
> formset has been bound... it only seems to be causing problems.

New description:

 After the form is posted, if an empty form is generated, it will be
 completely empty rather than having the initial values specified on the
 form. I believe we can fix this by modifying `_construct_form` like so:
 {{{
 if self.is_bound and i < self.initial_form_count():
 defaults['data'] = self.data
 defaults['files'] = self.files
 }}}
 And completely remove this chunk from _get_empty_form
 {{{
 if self.is_bound:
 defaults['data'] = self.data
 defaults['files'] = self.files
 }}}
 I don't know why an empty form should behave any differently after the
 formset has been bound... it only seems to be causing problems.

--

Comment:

 When providing a bug report, you should spend less time tell us how to fix
 the problem, and more time explaining the problem itself. If you're going
 to provide a code sample, make it a code sample that demonstrates the
 problem.

 I can't work out how to reproduce the problem from the instructions
 provided; closing invalid. Feel free to reopen if you want to provide a
 reproducible test case.

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

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

Re: [Django] #15259: Django Weblog suggested workaround for XMLHttpRequest CSRF fix in 1.2.5 uses wrong jQuery selector

[Django]

#15259: Django Weblog suggested workaround for XMLHttpRequest CSRF fix in 1.2.5
uses wrong jQuery selector
---+
   Reporter:  markhellewell| Owner:  nobody 
 Status:  new  | Milestone: 
  Component:  Django Web site  |   Version:  1.2
 Resolution:   |  Keywords:  blocker
   Triage Stage:  Accepted | Has patch:  0  
Needs documentation:  0|   Needs tests:  0  
Patch needs improvement:  0|  
---+
Changes (by russellm):

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


Comment:

 There are a couple of follow up items that probably bear mentioning:

  * Correcting this error in the example
  * Pointing out the other two minor backwards incompatibilities listed in
 the release notes.

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

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

Re: [Django] #15261: Admin querystring filters should work for superusers

[Django]

#15261: Admin querystring filters should work for superusers
+---
   Reporter:  cdestigter| Owner:  nobody
 Status:  closed| Milestone:
  Component:  django.contrib.admin  |   Version:  1.2   
 Resolution:  wontfix   |  Keywords:
   Triage Stage:  Unreviewed| Has patch:  1 
Needs documentation:  0 |   Needs tests:  0 
Patch needs improvement:  0 |  
+---
Changes (by russellm):

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


Comment:

 I'm not convinced this is a good idea. The list of allowed filters can be
 modified by overriding ModelAdmin.lookup_allowed, which strikes me as a
 much better approach to this problem.

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

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