Re: [Django] #15200: ManyToManyField combined with "|" leads to trouble

[Django]

#15200: ManyToManyField combined with "|" leads to trouble
-+--
   Reporter:  vanschelven| Owner:  nobody
 Status:  new| Milestone:
  Component:  Uncategorized  |   Version:  1.2   
 Resolution: |  Keywords:
   Triage Stage:  Unreviewed | Has patch:  0 
Needs documentation:  0  |   Needs tests:  0 
Patch needs improvement:  0  |  
-+--
Changes (by vanschelven):

 * cc: vanschelven (added)
  * needs_docs:  => 0
  * 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.

Re: [Django] #13285: Generic views call populate_xheaders, which breaks caching

[Django]

#13285: Generic views call populate_xheaders, which breaks caching
+---
   Reporter:  carljm| Owner:  nobody
 Status:  reopened  | Milestone:
  Component:  Cache system  |   Version:  1.1   
 Resolution:|  Keywords:
   Triage Stage:  Accepted  | Has patch:  0 
Needs documentation:  0 |   Needs tests:  0 
Patch needs improvement:  0 |  
+---

Comment (by carljm):

 The function-based generic views are now deprecated, and the class-based
 views that replaced them do not call populate_xheaders. So the only
 remaining non-deprecated view in the Django source tree that calls
 populate_xheaders is the flatpage view.

 My take at this point is that the populate_xheaders function itself is a)
 of marginal usefulness, since these sorts of debugging headers can easily
 be added without a generic function for it, b) now barely used within
 Django, c) breaks caching as written, and d) completely undocumented. So,
 barring major objections, I think it should just be removed from Django
 entirely. Since it's undocumented I don't think a deprecation path is
 strictly needed, but to err on the side of caution it could be deprecated
 along the same timeline as the function-based generic views, since they
 all call it.

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

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

Re: [Django] #10259: Error in Mac OS X installation documentation

[Django]

#10259: Error in Mac OS X installation documentation
--+-
   Reporter:  davegallagher   | Owner:  nobody  
  
 Status:  closed  | Milestone:  
  
  Component:  Django Web site |   Version:  
  
 Resolution:  invalid |  Keywords:  mac os, 
installation, macports
   Triage Stage:  Design decision needed  | Has patch:  0   
  
Needs documentation:  1   |   Needs tests:  0   
  
Patch needs improvement:  0   |  
--+-
Changes (by justinlilly):

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


Comment:

 This is no longer in the compiled documentation. It now lives on the wiki
 at http://code.djangoproject.com/wiki/Distributions

 If you would like to update it and apply your patch there, please feel
 free. It might also be appropriate to list homebrew instructions as well,
 if you feel so inclined.

-- 
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] #10178: Bogus timezone listed in documentation

[Django]

#10178: Bogus timezone listed in documentation
---+
   Reporter:  dannyman | Owner:  jacob
 Status:  assigned | Milestone:   
  Component:  Django Web site  |   Version:  1.0  
 Resolution:   |  Keywords:   
   Triage Stage:  Accepted | Has patch:  0
Needs documentation:  0|   Needs tests:  0
Patch needs improvement:  0|  
---+
Changes (by justinlilly):

 * cc: justinlilly@… (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] #14267: Trac Upgrade Tracking Ticket

[Django]

#14267: Trac Upgrade Tracking Ticket
---+
   Reporter:  mitsuhiko| Owner:  mitsuhiko
 Status:  assigned | Milestone:   
  Component:  Django Web site  |   Version:  1.2  
 Resolution:   |  Keywords:   
   Triage Stage:  Accepted | Has patch:  0
Needs documentation:  0|   Needs tests:  0
Patch needs improvement:  0|  
---+
Changes (by justinlilly):

 * cc: justinlilly@… (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] #14338: Search bar on the docs should include 1.2, & 1.1

[Django]

#14338: Search bar on the docs should include 1.2, & 1.1
---+
   Reporter:  varikin  | Owner:  jacobkm

 Status:  new  | Milestone:  1.3

  Component:  Django Web site  |   Version:  1.2

 Resolution:   |  Keywords:  docs search google 
versions
   Triage Stage:  Accepted | Has patch:  1  

Needs documentation:  0|   Needs tests:  0  

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

 * cc: justinlilly@… (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] #7325: Wrong numbers in modeltests.

[Django]

#7325: Wrong numbers in modeltests.
---+
   Reporter:  sebastian_noack  | Owner:  justinlilly
 Status:  assigned | Milestone: 
  Component:  Django Web site  |   Version:  SVN
 Resolution:   |  Keywords: 
   Triage Stage:  Accepted | Has patch:  0  
Needs documentation:  0|   Needs tests:  0  
Patch needs improvement:  0|  
---+
Changes (by justinlilly):

  * stage:  Someday/Maybe => 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] #7325: Wrong numbers in modeltests.

[Django]

#7325: Wrong numbers in modeltests.
---+
   Reporter:  sebastian_noack  | Owner:  justinlilly
 Status:  assigned | Milestone: 
  Component:  Django Web site  |   Version:  SVN
 Resolution:   |  Keywords: 
   Triage Stage:  Someday/Maybe| Has patch:  0  
Needs documentation:  0|   Needs tests:  0  
Patch needs improvement:  0|  
---+
Changes (by justinlilly):

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


-- 
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] #10613: Doc search page links should go to first occurence of search term

[Django]

#10613: Doc search page links should go to first occurence of search term
+---
   Reporter:  adrian_nye@…  | Owner:  jacob 
 Status:  assigned  | Milestone:
  Component:  Django Web site   |   Version:  SVN   
 Resolution:|  Keywords:  search
   Triage Stage:  Accepted  | Has patch:  0 
Needs documentation:  0 |   Needs tests:  0 
Patch needs improvement:  0 |  
+---
Changes (by justinlilly):

  * keywords:  => search
 * cc: justinlilly@… (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] #10700: Searching 1.0 docs -- results link to dev docs

[Django]

#10700: Searching 1.0 docs -- results link to dev docs
---+
   Reporter:  kmtracey | Owner:  jacob 
 Status:  assigned | Milestone:
  Component:  Django Web site  |   Version:  SVN   
 Resolution:   |  Keywords:  search
   Triage Stage:  Accepted | Has patch:  0 
Needs documentation:  0|   Needs tests:  0 
Patch needs improvement:  0|  
---+
Changes (by justinlilly):

 * cc: justinlilly@… (added)
  * keywords:  => search


-- 
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] #12129: distributions checksums

[Django]

#12129: distributions checksums
---+
   Reporter:  while0pass   | Owner:  nobody
 Status:  new  | Milestone:
  Component:  Django Web site  |   Version:
 Resolution:   |  Keywords:
   Triage Stage:  Accepted | Has patch:  0 
Needs documentation:  0|   Needs tests:  0 
Patch needs improvement:  0|  
---+
Changes (by justinlilly):

 * cc: justinlilly@… (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] #12129: distributions checksums

[Django]

#12129: distributions checksums
---+
   Reporter:  while0pass   | Owner:  nobody
 Status:  new  | Milestone:
  Component:  Django Web site  |   Version:
 Resolution:   |  Keywords:
   Triage Stage:  Accepted | Has patch:  0 
Needs documentation:  0|   Needs tests:  0 
Patch needs improvement:  0|  
---+

Comment (by justinlilly):

 Pattern for the checksum is: http://media.djangoproject.com/pgp/Django-{{
 version }}.checksum.txt

 where version is (for the current /download/ page):

 1.3-beta-1
 1.2.4

 As /download/ is a flatpage, it has to be done by someone with admin
 access.

-- 
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] #14083: Python module index on docs page is empty

[Django]

#14083: Python module index on docs page is empty
---+
   Reporter:  JirkaV   | Owner:  justinlilly
 Status:  assigned | Milestone: 
  Component:  Django Web site  |   Version:  1.2
 Resolution:   |  Keywords: 
   Triage Stage:  Accepted | Has patch:  0  
Needs documentation:  0|   Needs tests:  0  
Patch needs improvement:  0|  
---+
Changes (by justinlilly):

  * owner:  nobody => justinlilly
  * 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] #14788: Typos in the footer

[Django]

#14788: Typos in the footer
-+--
   Reporter:  candrea| Owner:  gabrielhurley
 Status:  closed | Milestone:  1.3  
  Component:  Django Web site|   Version:  1.2  
 Resolution:  fixed  |  Keywords:   
   Triage Stage:  Ready for checkin  | Has patch:  1
Needs documentation:  0  |   Needs tests:  0
Patch needs improvement:  0  |  
-+--
Changes (by jacob):

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


Comment:

 Fixed in recent pushes (thanks to Justin Lilly).

-- 
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] #9382: invalid username should give more details

[Django]

#9382: invalid username should give more details
---+
   Reporter:  xiongchiamiov| Owner:  nobody
 Status:  closed   | Milestone:
  Component:  Django Web site  |   Version:  1.0   
 Resolution:  fixed|  Keywords:
   Triage Stage:  Accepted | Has patch:  0 
Needs documentation:  0|   Needs tests:  0 
Patch needs improvement:  0|  
---+
Changes (by jacob):

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


Comment:

 Fixed in recent pushes (thanks to Justin Lilly).

-- 
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] #10068: Search box at top of the page on doc site

[Django]

#10068: Search box at top of the page on doc site
---+
   Reporter:  phoebebright | Owner:  jacob  
 
 Status:  closed   | Milestone: 
 
  Component:  Django Web site  |   Version:  1.0
 
 Resolution:  fixed|  Keywords:  
search,documentation
   Triage Stage:  Accepted | Has patch:  0  
 
Needs documentation:  0|   Needs tests:  0  
 
Patch needs improvement:  0|  
---+
Changes (by jacob):

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


Comment:

 Fixed in recent pushes (thanks to Justin Lilly).

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

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

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

[Django]

#15071: Fix the text in the footer in the documentation
-+--
   Reporter:  aruseni| Owner:  elbarto
 Status:  closed | Milestone: 
  Component:  Django Web site|   Version:  1.2
 Resolution:  fixed  |  Keywords: 
   Triage Stage:  Ready for checkin  | Has patch:  1  
Needs documentation:  0  |   Needs tests:  0  
Patch needs improvement:  0  |  
-+--
Changes (by jacob):

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


Comment:

 Fixed in recent pushes (thanks to Justin Lilly).

-- 
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] #14628: Document which settings can be changed at runtime

[Django]

#14628: Document which settings can be changed at runtime
-+--
   Reporter:  NicoEchaniz| Owner:  nobody  
 Status:  new| Milestone:  
  Component:  Documentation  |   Version:  1.2 
 Resolution: |  Keywords:  settings django.conf
   Triage Stage:  Accepted   | Has patch:  0   
Needs documentation:  0  |   Needs tests:  0   
Patch needs improvement:  0  |  
-+--

Comment (by ramiro):

 Replying to [comment:5 NicoEchaniz]:
 > Documentation should state very clearly that runtime-modification of
 settings is something you should avoid unless you fully understand the
 consecuences.
 > If there were consensus on the proper way to handle the threading issue,
 I think it should be documented too, but an enfatic warning would suffice
 for the time being to discourage people from fiddling with this lightly.

 Nico, I agree with the general intent of this ticket. But just wanted to
 point that what you ask for in this particular paragraph is already
 present in the documentation:
 http://docs.djangoproject.com/en/1.0/topics/settings/#altering-settings-
 at-runtime

-- 
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] #7326: transaction documentation on website isn't completely generated

[Django]

#7326: transaction documentation on website isn't completely generated
---+
   Reporter:  sebastian_noack  | Owner:  nobody
 Status:  closed   | Milestone:
  Component:  Django Web site  |   Version:  SVN   
 Resolution:  invalid  |  Keywords:
   Triage Stage:  Accepted | Has patch:  0 
Needs documentation:  0|   Needs tests:  0 
Patch needs improvement:  0|  
---+
Changes (by justinlilly):

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


Comment:

 Can't reproduce. There is no "Sample API Usage" header on the current
 transaction documentation.

-- 
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] #14924: I18N looks for translations in the reverse order of the apps

[Django]

#14924: I18N looks for translations in the reverse order of the apps
+---
   Reporter:  vanschelven   | Owner:  nobody
 Status:  new   | Milestone:
  Component:  Internationalization  |   Version:  1.2   
 Resolution:|  Keywords:
   Triage Stage:  Accepted  | Has patch:  1 
Needs documentation:  0 |   Needs tests:  0 
Patch needs improvement:  0 |  
+---

Comment (by ramiro):

 `14924.2.diff` (ignore the #10765 reference in the ticket description ,
 should be #5494) contains a further evolution to the patch that:

  * Extends the changes to include building of !JavaScript catalog in the
 `javascript_catalog()` view making it more consistent with the one used
 for Python/templates code translations (paths listed in LOCALE_PATHS is
 taken in account.)
  * As per discussion with Jannis and Claude Paroz, starts the deprecation
 path for inclusion of translations located under the ''project path''.
 The LOCALE_PATH setting can be used for the same task by listing the
 filesystem path to the project level translations. Reationale for this:
* The project path has always been an elusive concept (it is actually
 the directory containing the settings) and there has been a shift in other
 parts of the framework from using it as a reference for location of assets
 at runtime.
* It fails when the settings module is a directory (#10765)
* The `project_dir/locale/` subdir can generate spurious error messages
 when the project directory is included in the python path (default
 behavior of `manage.py runserver`), e.g.:
 `/usr/lib/python2.6/gettext.py:49: ImportWarning: Not importing directory
 '/path/to/project/dir/locale': missing __init__.py`. See also
 http://groups.google.com/group/django-
 users/browse_thread/thread/e8bb9089d9e5be60?pli=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] #9009: Trac should link to report views from tickets

[Django]

#9009: Trac should link to report views from tickets
---+
   Reporter:  simon| Owner:  nobody
 Status:  closed   | Milestone:
  Component:  Django Web site  |   Version:  1.0   
 Resolution:  worksforme   |  Keywords:  trac  
   Triage Stage:  Accepted | Has patch:  0 
Needs documentation:  0|   Needs tests:  0 
Patch needs improvement:  0|  
---+
Changes (by justinlilly):

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


Comment:

 Looks like this has been fixed with the latest Trac upgrade.

-- 
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] #9281: emails are displayed by django bug tracker and harvested by spam robots

[Django]

#9281: emails are displayed by django bug tracker and harvested by spam robots
---+
   Reporter:  orzel| Owner:  jacob
 Status:  closed   | Milestone:   
  Component:  Django Web site  |   Version:  1.2  
 Resolution:  worksforme   |  Keywords:   
   Triage Stage:  Accepted | Has patch:  0
Needs documentation:  0|   Needs tests:  0
Patch needs improvement:  0|  
---+
Changes (by justinlilly):

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


Comment:

 Looks like this has been fixed with the latest Trac upgrade.

-- 
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] #10856: Error: Failed to load processor TracGuideToc

[Django]

#10856: Error: Failed to load processor TracGuideToc
---+
   Reporter:  cwolf127 | Owner:  nobody  
 Status:  closed   | Milestone:  
  Component:  Django Web site  |   Version:  1.0 
 Resolution:  worksforme   |  Keywords:  TracGuideToc TOC
   Triage Stage:  Accepted | Has patch:  0   
Needs documentation:  0|   Needs tests:  0   
Patch needs improvement:  0|  
---+
Changes (by justinlilly):

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


Comment:

 Likely solved with the Trac upgrade.

-- 
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] #13288: 'Community' page double-escapes entities

[Django]

#13288: 'Community' page double-escapes entities
---+
   Reporter:  wandernauta  | Owner:  justinlilly
 Status:  assigned | Milestone: 
  Component:  Django Web site  |   Version:  1.1
 Resolution:   |  Keywords:  site   
   Triage Stage:  Accepted | Has patch:  0  
Needs documentation:  0|   Needs tests:  0  
Patch needs improvement:  0|  
---+
Changes (by justinlilly):

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


-- 
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] #14237: Old version string on the download page + auto checker proposal

[Django]

#14237: Old version string on the download page + auto checker proposal
---+
   Reporter:  Tuttle   | Owner:  anonymous
 Status:  closed   | Milestone:   
  Component:  Django Web site  |   Version:   
 Resolution:  worksforme   |  Keywords:   
   Triage Stage:  Accepted | Has patch:  0
Needs documentation:  0|   Needs tests:  0
Patch needs improvement:  0|  
---+
Changes (by justinlilly):

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


Comment:

 Closing this as the actual issue is fixed. If you would like the other
 issues fixed, please consider opening separate tickets for them.

-- 
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] #15201: CACHE_MIDDLEWARE_ANONYMOUS_ONLY is ugly, misleading, and unnecessary, and should be deprecated

[Django]

#15201: CACHE_MIDDLEWARE_ANONYMOUS_ONLY is ugly, misleading, and unnecessary, 
and
should be deprecated
--+-
 Reporter:  carljm|  Owner:  nobody
   Status:  new   |  Milestone:
Component:  Cache system  |Version:  SVN   
 Keywords:|   Triage Stage:  Unreviewed
Has patch:  0 |  
--+-
 From https://github.com/django/django/pull/4:

 {{{
 There are three supposed benefits of using the cache middleware with
 CACHE_MIDDLEWARE_ANONYMOUS_ONLY set to True:

 1) Don't show user-specific data to the wrong users.
 2) Avoid wasting memory on caching user-specific pages.
 3) Improve performance by caching most pages.
 }}}

 (1) is unnecessary: Django already sets Vary: Cookie headers when the
 session is accessed, which will prevent users from getting another user's
 cached pages. In fact one danger of the current documentation of
 CACHE_MIDDLEWARE_ANONYMOUS_ONLY is that it does not mention Vary: Cookie
 and may mislead users into thinking that CACHE_MIDDLEWARE_ANONYMOUS_ONLY
 is necessary to avoid users being shown wrong cached pages.

 CACHE_MIDDLEWARE_ANONYMOUS_ONLY is only partially effective at (2),
 because it will still cache session-specific pages with Vary: Cookie if a
 user is not logged in, which can blow up caching memory just as much or
 more as authenticated requests, if sessions are used with anonymous users.

 And on the downside, CACHE_MIDDLEWARE_ANONYMOUS_ONLY is far from simple:
 it requires contrib.auth to be installed before it can be used, and is
 tricky to implement correctly (until the fix for #13283 was committed, the
 incorrect implementation in place for years meant that turning
 CACHE_MIDDLEWARE_ANONYMOUS_ONLY on immediately destroyed caching
 efficiency for your entire site, including anonymous pages).

 An alternative hypothetical setting, CACHE_MIDDLEWARE_SKIP_VARY_COOKIE,
 would give users a more accurate model of how caching actually works,
 would remove both the complexity of implementation and the needless
 dependence on contrib.auth, and would be more effective at improving
 caching efficiency (because it would also avoid caching session-dependent-
 but-anonymous requests).

 I think this behavior change should be made in any case; it's a clear
 improvement with no downside that I can see. It would be possible to make
 the behavior change and leave the current (somewhat misleading) setting
 name, to avoid deprecation churn. I think I lean towards going ahead and
 changing the name of the setting too; based on the lack of outcry around
 #13283 I get the impression few users are using
 CACHE_MIDDLEWARE_ANONYMOUS_ONLY anyway, and it's a painless setting name
 switch.

 Thanks to natrius in the above pull request and the #13283 comments for
 these observations.

-- 
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] #14628: Document which settings can be changed at runtime

[Django]

#14628: Document which settings can be changed at runtime
-+--
   Reporter:  NicoEchaniz| Owner:  nobody  
 Status:  new| Milestone:  
  Component:  Documentation  |   Version:  1.2 
 Resolution: |  Keywords:  settings django.conf
   Triage Stage:  Accepted   | Has patch:  0   
Needs documentation:  0  |   Needs tests:  0   
Patch needs improvement:  0  |  
-+--

Comment (by NicoEchaniz):

 I do not agree with your assessment on this matter. Documenting this
 information would be very useful for anyone working on multi-tenancy for
 django projects. There are in fact certain scenarios where multi-tenancy
 is a valid - if not the only - deployment option.

 For reference, I'll add a link to the
 [http://www.revsys.com/officehours/2010/nov/05/#question5 full log of the
 chat session] that inspired the creation of this ticket.

 Documentation should state very clearly that runtime-modification of
 settings is something you should avoid unless you fully understand the
 consecuences.
 If there were consensus on the proper way to handle the threading issue, I
 think it should be documented too, but an enfatic warning would suffice
 for the time being to discourage people from fiddling with this lightly.

 I'd also like to add that this is just a documentation proposal on current
 existing features and as such I don't see how this could be of any harm
 unless it's done carelessly, which I find hard to expect knowing the
 general quality of django documentation.

-- 
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] #13809: FileField open method is only accepting 'rb' modes

[Django]

#13809: FileField open method is only accepting 'rb' modes
+---
   Reporter:  canassa   | Owner:  nobody
 Status:  reopened  | Milestone:
  Component:  File uploads/storage  |   Version:  1.2   
 Resolution:|  Keywords:
   Triage Stage:  Accepted  | Has patch:  0 
Needs documentation:  0 |   Needs tests:  0 
Patch needs improvement:  0 |  
+---
Changes (by yishai@…):

  * component:  Documentation => File uploads/storage


Comment:

 Replying to [comment:3 russellm]:
 > I don't think it's unreasonable to expect that when you access a file
 through a model field, it will be open ready for reading. The best
 solution I can see here is documenting the fact that files are opened "rb"
 when accessed, and if you want to perform write operations, you'll need to
 close the file first.

 I think this is a little more subtle than that; since the underlying file
 object is "automatically" opened (with 'rb' mode) upon direct access, the
 main reason one would call {{{FieldFile.open}}} is to open the file in
 another mode. Having {{{FieldFile.open(mode='w')}}} return a bad file
 descriptor (for writing) without complaining is hardly optimal.

 >
 > I'm open to any other suggestions, but I'll accept this as a
 documentation issue for now.

 Even if deciding that one should always close first before opening the
 file for writing, calling {{{FieldFile.close()}}} is not enough as it will
 skip the underlying file object if it was not opened yet. This code will
 not work:

 {{{
   obj = MyModel.objects.get(pk=1)
   obj.myFileField.close() # would expect this to close the underlying file
 object, so it's ready to be reopened for writing
   obj.myFileField.open('w')
   obj.myFileField.write('something')
 }}}

 If we rewrite {{{FieldFile.close()}}} from:

 {{{
 def close(self):
 file = getattr(self, '_file', None)
 if file is not None:
 file.close()
 }}}

 to:
 {{{
 def close(self):
 self.file.close()
 }}}

 then the above snippet will work as advertised - the underlying file will
 be opened (rb) and then closed again. Currently the snippet needs to be:

 {{{
   obj = MyModel.objects.get(pk=1)
   obj.myFileField.file.close() # works, but hardly nice
   obj.myFileField.open('w')
   obj.myFileField.write('something')
 }}}

 which works, but accessing the underlying (undocumented?) file object
 directly is probably not what we really want here.

-- 
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] #15094: Convert STATICFILES_DIRS into a tuple if set as string

[Django]

#15094: Convert STATICFILES_DIRS into a tuple if set as string
+---
   Reporter:  oxy   | Owner:  nobody
 Status:  closed| Milestone:
  Component:  Contrib apps  |   Version:  SVN   
 Resolution:  wontfix   |  Keywords:
   Triage Stage:  Unreviewed| Has patch:  1 
Needs documentation:  0 |   Needs tests:  0 
Patch needs improvement:  0 |  
+---

Comment (by oxy):

 According to your suggestions I created a second patch and added a test.

-- 
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] #15192: 1.2/tutorial04 refers to class-based generic views

[Django]

#15192: 1.2/tutorial04 refers to class-based generic views
-+--
   Reporter:  MixedContent   | Owner:  nobody
 Status:  closed | Milestone:
  Component:  Uncategorized  |   Version:  1.2   
 Resolution:  fixed  |  Keywords:
   Triage Stage:  Accepted   | Has patch:  0 
Needs documentation:  0  |   Needs tests:  0 
Patch needs improvement:  0  |  
-+--
Changes (by lrekucki):

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


Comment:

 The docs appear to be ok now, so closing this.

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

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

[Django] #15200: ManyToManyField combined with "|" leads to trouble

[Django]

#15200: ManyToManyField combined with "|" leads to trouble
---+
 Reporter:  vanschelven|  Owner:  nobody
   Status:  new|  Milestone:
Component:  Uncategorized  |Version:  1.2   
 Keywords: |   Triage Stage:  Unreviewed
Has patch:  0  |  
---+
 !ManyToManyField combined with "|" leads to trouble.

 Specifically, the outer join that appears to be constructed for manytomany
 field lookups is not well cleaned up with where statements once an "or"
 ("|") is used.

 {{{
 $ cat theapp/models.py
 from django.db import models

 class AnObject(models.Model):
 nr = models.IntegerField()

 class HasRef(models.Model):
 obj = models.ManyToManyField(AnObject)
 field = models.IntegerField()
 }}}

 {{{
 >>> from theapp.models import *
 >>> one = AnObject.objects.create(nr=1)
 >>> two = AnObject.objects.create(nr=2)
 >>> reffer = HasRef.objects.create(field=1)
 >>> reffer.obj.add(one)
 >>> reffer.obj.add(two)
 >>> HasRef.objects.all().filter(field=1)
 []
 >>> HasRef.objects.all().filter(obj=one)
 []
 >>> HasRef.objects.all().filter(models.Q(field=1) | models.Q(obj=one))
 [, ]
 >>> [o.pk for o in HasRef.objects.all().filter(models.Q(field=1) |
 models.Q(obj=one))]
 [1L, 1L]
 }}}

 I don't have the time right now to come up with tests proper, or a patch.
 The problem is real though...

 My workaround:

 {{{
 >>> HasRef.objects.all().filter(models.Q(field=1) |
 models.Q(obj=one)).annotate(models.Count("id"))
 }}}

 The generated query (without workaround)
 {{{
 >>> print HasRef.objects.all().filter(models.Q(field=1) |
 models.Q(obj=AnObject.objects.get(nr=1))).query
 SELECT `theapp_hasref`.`id`, `theapp_hasref`.`field` FROM `theapp_hasref`
 LEFT OUTER JOIN `theapp_hasref_obj` ON (`theapp_hasref`.`id` =
 `theapp_hasref_obj`.`hasref_id`) WHERE (`theapp_hasref`.`field` = 1  OR
 `theapp_hasref_obj`.`anobject_id` = 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] #12919: Ticket submission page should direct security issues to django-security.

[Django]

#12919: Ticket submission page should direct security issues to django-security.
---+
   Reporter:  russellm | Owner:  nobody
 Status:  closed   | Milestone:
  Component:  Django Web site  |   Version:
 Resolution:  fixed|  Keywords:
   Triage Stage:  Accepted | Has patch:  0 
Needs documentation:  0|   Needs tests:  0 
Patch needs improvement:  0|  
---+
Changes (by jacob):

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


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

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

Re: [Django] #13488: Exceptions in GEOS I/O object destructor at process exit

[Django]

#13488: Exceptions in GEOS I/O object destructor at process exit
+---
   Reporter:  mroach@…  | Owner:  jbronn
 Status:  closed| Milestone:  1.3   
  Component:  GIS   |   Version:  1.2   
 Resolution:  fixed |  Keywords:  gis   
   Triage Stage:  Accepted  | Has patch:  1 
Needs documentation:  0 |   Needs tests:  0 
Patch needs improvement:  1 |  
+---

Comment (by jbronn):

 In [15379]:
 {{{
 #!CommitTicketReference repository="" revision="15379"
 [1.2.X] Fixed #13488 -- No longer generate unhandled exceptions that may
 occur when destructors of global GEOS I/O objects are called on process
 termination.

 Backport of r15378 from trunk.
 }}}

-- 
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] #15199: Allow MEDIA_ROOT inside STATIC_ROOT

[Django]

#15199: Allow MEDIA_ROOT inside STATIC_ROOT
--+-
   Reporter:  brutasse| Owner: 
 Status:  new | Milestone:  1.3
  Component:  django.contrib.staticfiles  |   Version:  SVN
 Resolution:  |  Keywords: 
   Triage Stage:  Unreviewed  | Has patch:  1  
Needs documentation:  0   |   Needs tests:  0  
Patch needs improvement:  1   |  
--+-
Changes (by brutasse):

  * needs_docs:  => 0
  * has_patch:  0 => 1
  * needs_tests:  => 0
  * needs_better_patch:  => 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] #13488: Exceptions in GEOS I/O object destructor at process exit

[Django]

#13488: Exceptions in GEOS I/O object destructor at process exit
+---
   Reporter:  mroach@…  | Owner:  jbronn
 Status:  closed| Milestone:  1.3   
  Component:  GIS   |   Version:  1.2   
 Resolution:  fixed |  Keywords:  gis   
   Triage Stage:  Accepted  | Has patch:  1 
Needs documentation:  0 |   Needs tests:  0 
Patch needs improvement:  1 |  
+---
Changes (by jbronn):

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


Comment:

 Fixed in r15378.

-- 
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] #15199: Allow MEDIA_ROOT inside STATIC_ROOT

[Django]

#15199: Allow MEDIA_ROOT inside STATIC_ROOT
+---
 Reporter:  brutasse|  Owner:
   Status:  new |  Milestone:  1.3   
Component:  django.contrib.staticfiles  |Version:  SVN   
 Keywords:  |   Triage Stage:  Unreviewed
Has patch:  0   |  
+---
 I have the following layout:

 {{{
 STATIC_ROOT = '/path/to/static/'
 STATIC_URL = '/static/'

 MEDIA_ROOT = STATIC_ROOT + 'media/'
 MEDIA_URL = STATIC_URL + 'media/'
 }}}

 Basically, MEDIA_ROOT is a subdirectory of STATIC_ROOT.

 With runserver, I won't be able to serve my media files. When I try to
 fetch a media file, the !StaticFilesHandler tries to handle it (since its
 URL starts with STATIC_URL) but no finder will be able to resolve its
 path.

 The handler then raises a 404  even if I have a pattern in my urlconf to
 serve my media files.

 After discussing it on IRC, it looks like two things are needed to support
 this:

 * Patch the contrib.staticfiles handler to specifically ignore anything
 inside MEDIA_URL

 * Add extra checks to the collectstatic management command to make sure
 collectstatic won't write anything inside MEDIA_ROOT (which could
 potentially overwrite some user data).

-- 
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] #15130: Model.validate_unique method doesn't take in account multi-db

[Django]

#15130: Model.validate_unique method doesn't take in account multi-db
---+
   Reporter:  t2y  | Owner:  
 Status:  reopened | Milestone:  1.3 
  Component:  ORM aggregation  |   Version:  1.2 
 Resolution:   |  Keywords:  multi-db
   Triage Stage:  Accepted | Has patch:  1   
Needs documentation:  0|   Needs tests:  0   
Patch needs improvement:  1|  
---+

Comment (by ramiro):

 `15130.3-tests.diff` contains new more granular tests (new model for
 tests, separated the unique_for_{date,month,year} tests). It runs ten new
 tests; five of them by saving first an instance to the 'default' database
 and then trying to save an identical instance to the 'other' DB, and the
 other five in the inverse order.

 Theoretically all of them should fail before applying a fix for this
 ticket, but only the five tests with the 'default', 'other' order do.

-- 
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] #14645: Exclude query with multiple conditions for the same multi-value relation not correct

[Django]

#14645: Exclude query with multiple conditions for the same multi-value relation
not correct
+---
   Reporter:  Ben Buchwald   | 
Owner:  nobody
 Status:  new   | 
Milestone:
  Component:  Database layer (models, ORM)  |   
Version:  1.2   
 Resolution:|  
Keywords:  exclude manytomany
   Triage Stage:  Accepted  | Has 
patch:  0 
Needs documentation:  0 |   Needs 
tests:  0 
Patch needs improvement:  0 |  
+---
Changes (by rma):

 * cc: rma (added)
  * version:  1.1 => 1.2


Comment:

 Can confirm in Django 1.2.4 (Mac OS X 10.6.5) and Django 1.2.3 (Debian
 Squeeze). Multiple conditions in a single exclude() call result in each
 condition being evaluated to a distinct instance, rather than all
 conditions being applied to a single instance.

-- 
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] #15168: feature request - New setting

[Django]

#15168: feature request - New setting
+---
   Reporter:  zay2  | Owner:  nobody
 Status:  closed| Milestone:  1.3   
  Component:  Internationalization  |   Version:  SVN   
 Resolution:  wontfix   |  Keywords:
   Triage Stage:  Unreviewed| Has patch:  0 
Needs documentation:  0 |   Needs tests:  0 
Patch needs improvement:  0 |  
+---

Comment (by bpeschier):

 Replying to [comment:6 zay2]:

 > Now im not saying - "i want to ignore this 1 language when it is not set
 in a cookie"(quoting bpeschier). Im saying that i want the page be in
 language used by target audience. I cant do this with this accept headers
 based language discovery[[BR]]
 >
 > "In your case I would extend the LocaleMiddleware to mirror that; check
 the HTTP_ACCEPT_LANGUAGE in META before handing it to the
 LocaleMiddleware-superclass and rewrite English to Estonian "(quoting
 bpeschier) - There already is default language setting - it just does not
 work in all cases. [[BR]]
 >

 The default language is defined as the language to fall back to when no
 suitable language can be found and since you have an English translation,
 there is a suitable one according to definitions. Making settings which
 breaks this behaviour is not in the interest of Django or developers using
 it (just another setting in an already long list).

 Instead of introducing a setting which is hardly used, a solution could be
 to refactor {{{ get_language_from_request }}} into two distinct parts;
 this means you only have to override a very small function in
 !LocaleMiddleware, which would not call the detection based on headers. It
 would not be hard to create a patch for 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] #15168: feature request - New setting

[Django]

#15168: feature request - New setting
+---
   Reporter:  zay2  | Owner:  nobody
 Status:  closed| Milestone:  1.3   
  Component:  Internationalization  |   Version:  SVN   
 Resolution:  wontfix   |  Keywords:
   Triage Stage:  Unreviewed| Has patch:  0 
Needs documentation:  0 |   Needs tests:  0 
Patch needs improvement:  0 |  
+---

Comment (by zay2):

 You see things from your point of view, so lets give it one more
 shot:[[BR]]

 1) Browsers/Op systems are not available in many small languages and
 therefore the speakers of languages like estonians have to use
 browsers/systems in english and their browsers are therefore in english -
 they may not desire it.[[BR]]

 2) Those users do not know how to change their browsers language - you got
 to know that you and are are HUGE minority - perhaps only 5% of users know
 that they CAN change their browser language. Even less people know how and
 want to change it. [[BR]]

 3) those 95% of people who dont know that they CAN change their browser
 language or know how to, usually visit pages, which are in their own
 language (the language that they speak every day, not the language their
 browser is set to).[[BR]]


 4) I want to make pages that can be seen in default language - the
 language that the target audience of the page uses.[[BR]]

 Now im not saying - "i want to ignore this 1 language when it is not set
 in a cookie"(quoting bpeschier). Im saying that i want the page be in
 language used by target audience. I cant do this with this accept headers
 based language discovery[[BR]]

 "In your case I would extend the LocaleMiddleware to mirror that; check
 the HTTP_ACCEPT_LANGUAGE in META before handing it to the
 LocaleMiddleware-superclass and rewrite English to Estonian "(quoting
 bpeschier) - There already is default language setting - it just does not
 work in all cases. [[BR]]

 "Without the detection, I would get your site in Estonian, which is
 probably jibberish to me."(quoting lrekucki). Well in such cases - You are
 not the target audience. [[BR]]

 Ask your parents or grandparents, if they know what browser accept headers
 or if they can change those. This probably is irrelevant if they come from
 english speaking (or other countries which's languages are spoken by
 millions and millions of people) countries, since they never need to do
 anything like this anyway. Parents & grandparents in countries like
 Estonia, Latvia, Lithuania and so on, dont know about the accept headers
 or such either. But in most cases, their browsers are in english and they
 dont even know that this could be a problem.[[BR]]

 Now we are making the websites for our customers and our customers are
 supposed to know their target audience. If we cant deliver the website
 which its target audience can see in its default language then something
 is wrong. I fixed this wrong by commenting out undesired code. Not very
 DRY. getting everybody, who face similar problem, extending their
 middleware is also not very DRY. Why would all those people have to repeat
 themselves? I still say that such setting option would be best way to
 solve this.

 If i cant change your mind about this - so be it. If im gonna be the only
 one to see sanity in this, then so be it - i know how to fix this. Just
 thought, that this would be nice minor improvement. Moving discussion to
 dev'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-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] #14628: Document which settings can be changed at runtime

[Django]

#14628: Document which settings can be changed at runtime
-+--
   Reporter:  NicoEchaniz| Owner:  nobody  
 Status:  new| Milestone:  
  Component:  Documentation  |   Version:  1.2 
 Resolution: |  Keywords:  settings django.conf
   Triage Stage:  Accepted   | Has patch:  0   
Needs documentation:  0  |   Needs tests:  0   
Patch needs improvement:  0  |  
-+--

Comment (by carljm):

 If we document any settings as "safe to change at runtime", we'd better
 also document that changing settings at runtime (even the otherwise "safe"
 ones) is not safe in a multi-threaded hosting environment (or concurrent
 requests can easily get the wrong setting value).

 Given the number of people hosting in such an environment who may not even
 realize it, I'm not sure we should be documenting anything that encourages
 changing settings at runtime, until we (pie in the sky) fix settings so
 they aren't a global.

-- 
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] #12982: Pony: cache.get_or_set()

[Django]

#12982: Pony: cache.get_or_set()
--+-
   Reporter:  Alex| Owner:  jmeed
 Status:  assigned| Milestone:  1.3  
  Component:  Core framework  |   Version:  SVN  
 Resolution:  |  Keywords:  cache
   Triage Stage:  Accepted| Has patch:  1
Needs documentation:  0   |   Needs tests:  0
Patch needs improvement:  0   |  
--+-
Changes (by snow0x2d0):

  * has_patch:  0 => 1


Comment:

 Not sure how else to go about contacting jmeed. I've gone ahead and added
 my patch, hopefully I'm not stepping on any toes.

-- 
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] #15124: BooleanField should not use False as default (unless provided)

[Django]

#15124: BooleanField should not use False as default (unless provided)
+---
   Reporter:  andrewbadr| Owner:  
nobody  
 Status:  new   | Milestone:
  
  Component:  Database layer (models, ORM)  |   Version:  
1.3-beta
 Resolution:|  Keywords:
  
   Triage Stage:  Design decision needed| Has patch:  1 
  
Needs documentation:  0 |   Needs tests:  0 
  
Patch needs improvement:  0 |  
+---

Comment (by andrewbadr):

 Likely, but the current behavior is (1) wrong, (2) undocumented, (3)
 arguably untested, and (4) has already changed in the past. The bug should
 be fixed for 1.3 but (as Russ says) not backported.

-- 
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] #11475: test.Client.session.save() raises error for anonymous users

[Django]

#11475: test.Client.session.save() raises error for anonymous users
-+--
   Reporter:  egmanoj@…  | Owner:  nobody
 Status:  new| Milestone:
  Component:  Testing framework  |   Version:  1.1-beta-1
 Resolution: |  Keywords:
   Triage Stage:  Accepted   | Has patch:  0 
Needs documentation:  0  |   Needs tests:  0 
Patch needs improvement:  0  |  
-+--
Changes (by nodet):

 * cc: nodet (added)


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

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

[Django] #15198: AuthenticationForm.clean call does not have request set

[Django]

#15198: AuthenticationForm.clean call does not have request set
+---
 Reporter:  Ciantic |  Owner:  nobody
   Status:  new |  Milestone:
Component:  Authentication  |Version:  SVN   
 Keywords:  |   Triage Stage:  Unreviewed
Has patch:  1   |  
+---
 I'm working on per site login system currently.

 It is required to get the site of the request in prior to calling
 ``authenticate()`` so the calls to my auth backend should be either in
 form of:
 {{{
   authenticate(site_id, username, password)
 }}}
 or more general:
 {{{
   authenticate(request, username, password)
 }}}

 If I try to create own `django.contrib.auth.forms.AuthenticationForm` e.g.
 by subclassing, then the login view never sets the `request` attribute of
 auth form.

 So currently I have to recreate whole login view and authentication form
 in order to make per site login. With this simple patch I could just
 subclass AuthenticationForm and override the `clean()` functions call to
 authentication.

 More about my per site endeavours in [http://groups.google.com/group
 /django-developers/browse_thread/thread/7052c23321079295/fbf16f06fa17988c
 django-devs thread], and in
 [http://ciantic.github.com/multisited/README.html my proposal for changes
 to 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] #13618: prepopulated_fields crashes with get_readonly_fields

[Django]

#13618: prepopulated_fields crashes with get_readonly_fields
+---
   Reporter:  tonnzor   | Owner:  tobias
 Status:  assigned  | Milestone:  1.3   
  Component:  django.contrib.admin  |   Version:  SVN   
 Resolution:|  Keywords:
   Triage Stage:  Accepted  | Has patch:  1 
Needs documentation:  0 |   Needs tests:  0 
Patch needs improvement:  0 |  
+---
Changes (by rm_):

 * cc: rm_ (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] #15168: feature request - New setting

[Django]

#15168: feature request - New setting
+---
   Reporter:  zay2  | Owner:  nobody
 Status:  closed| Milestone:  1.3   
  Component:  Internationalization  |   Version:  SVN   
 Resolution:  wontfix   |  Keywords:
   Triage Stage:  Unreviewed| Has patch:  0 
Needs documentation:  0 |   Needs tests:  0 
Patch needs improvement:  0 |  
+---
Changes (by lrekucki):

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


Comment:

 Please don't reopen tickets marked as "won't fix" by core developers
 without prior discussion on [http://groups.google.com/group/django-
 developers django-developers] mailing list.

 As for the ticket itself, the middleware does exactly what I would except,
 both as a programmer and a user. I have my browser set to 'en-US' locale,
 because I prefer so (although I'm a polish speaking person). Without the
 detection, I would get your site in Estonian, which is probably jibberish
 to me.

 Also, your need seems very specific, so I don't think it mandates a
 settings. You can make your own middleware based on the one in core.

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

[Django]

#6148: Add generic support for database schemas
+---
   Reporter:  ikelly| Owner:
 
 Status:  new   | Milestone:
 
  Component:  Database layer (models, ORM)  |   Version:  SVN   
 
 Resolution:|  Keywords:  
oracle postgresql mysql schemas
   Triage Stage:  Accepted  | Has patch:  1 
 
Needs documentation:  0 |   Needs tests:  0 
 
Patch needs improvement:  1 |  
+---
Changes (by ckarrie):

 * cc: ckarrie@… (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] #6148: Add generic support for database schemas

[Django]

#6148: Add generic support for database schemas
+---
   Reporter:  ikelly| Owner:
 
 Status:  new   | Milestone:
 
  Component:  Database layer (models, ORM)  |   Version:  SVN   
 
 Resolution:|  Keywords:  
oracle postgresql mysql schemas
   Triage Stage:  Accepted  | Has patch:  1 
 
Needs documentation:  0 |   Needs tests:  0 
 
Patch needs improvement:  1 |  
+---
Changes (by ckarrie):

 * cc: ckarrie (removed)


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

[Django]

#6148: Add generic support for database schemas
+---
   Reporter:  ikelly| Owner:
 
 Status:  new   | Milestone:
 
  Component:  Database layer (models, ORM)  |   Version:  SVN   
 
 Resolution:|  Keywords:  
oracle postgresql mysql schemas
   Triage Stage:  Accepted  | Has patch:  1 
 
Needs documentation:  0 |   Needs tests:  0 
 
Patch needs improvement:  1 |  
+---
Changes (by ckarrie):

 * cc: ckarrie (added)


Comment:

 I cannot assign a schema to m2m-tables. Tables like
 - auth_group_permissions
 - django_flatpages_sites
 ...and so on are still in my public-Schema.

 I'm using PostgreSQL 8.4 with PostGIS Extension.

 Another problem is the incompatibility with PostGIS: every geometry-
 related colums isn't added to the table.

-- 
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] #13: Related objects interface should be tighter (edit_inline)

[Django]

#13: Related objects interface should be tighter (edit_inline)
+---
   Reporter:  adrian| Owner:  barbuza   

 Status:  reopened  | Milestone:

  Component:  django.contrib.admin  |   Version:  SVN   

 Resolution:|  Keywords:  nfa-someday 
nfa-changelist
   Triage Stage:  Accepted  | Has patch:  1 

Needs documentation:  0 |   Needs tests:  0 

Patch needs improvement:  1 |  
+---

Comment (by dokterbob):

 @jezdez Apparently I could not attach my patch to the message itself. It
 should have become clear in this last edit. :)

-- 
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] #9338: admin-interface: inline formset should have can_order=True when using order_with_respect_to

[Django]

#9338: admin-interface: inline formset should have can_order=True when using
order_with_respect_to
+---
   Reporter:  patrickk  | Owner:  nobody
 Status:  new   | Milestone:
  Component:  Contrib apps  |   Version:  SVN   
 Resolution:|  Keywords:
   Triage Stage:  Accepted  | Has patch:  1 
Needs documentation:  0 |   Needs tests:  0 
Patch needs improvement:  1 |  
+---
Changes (by dokterbob):

 * cc: mathijs@… (added)
  * needs_better_patch:  0 => 1
  * 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] #13: Related objects interface should be tighter (edit_inline)

[Django]

#13: Related objects interface should be tighter (edit_inline)
+---
   Reporter:  adrian| Owner:  barbuza   

 Status:  reopened  | Milestone:

  Component:  django.contrib.admin  |   Version:  SVN   

 Resolution:|  Keywords:  nfa-someday 
nfa-changelist
   Triage Stage:  Accepted  | Has patch:  1 

Needs documentation:  0 |   Needs tests:  0 

Patch needs improvement:  1 |  
+---

Comment (by jezdez):

 Which patch are you referring to?

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #13: Related objects interface should be tighter (edit_inline)

[Django]

#13: Related objects interface should be tighter (edit_inline)
+---
   Reporter:  adrian| Owner:  barbuza   

 Status:  reopened  | Milestone:

  Component:  django.contrib.admin  |   Version:  SVN   

 Resolution:|  Keywords:  nfa-someday 
nfa-changelist
   Triage Stage:  Accepted  | Has patch:  1 

Needs documentation:  0 |   Needs tests:  0 

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

 * cc: mathijs@… (added)
  * has_patch:  0 => 1


Comment:

 So far, it seems that no work has been done on this issue for a long time.
 Meanwhile, I am sure that it is still a feature that many users would like
 to see integrated into the Django admin. Given that, by now, people have
 made the wise decision to ship jQuery with the Django admin, it seems to
 me as about time to start fixing this issue.

 Currently, if `order_with_respect_to` is specifeid in a Model's Meta field
 is specified, a cute `_order` field is indeed added to the Model's
 database table. However (AFAIK because of the underscore), this field is
 not represented at all in the Admin interface. This implies that - for now
 - it is still easier to explicitly add some Integer ordering field to a
 Model rather than using  the much more elegant, available, but
 disfunctional, API that ships with Django.

 As fixing/completing this feature should be fairly easy for someone who's
 used to getting into the debts of the (very scarcely documented)
 Admin/Model internals, it might not even be too unrealistic to have this
 fixed before 1.3 or the first point release after.

 To make it a bit easier, I have made a start by providing this patch which
 fixes at least the `get_ordered_objects` method of Model's `_meta`. This
 causes the Admin to load a non-existant file `dom-drag.js` which should be
 replaced by a jQuery equivalent thereof. Furthermore, the
 InlineModelAdmin's formset should have it's `can_order` parameter set to
 `True`, I believe, to allow for the ordering to get through to the Admin
 in the first place.

 Meanwhile, I have spotted the following tickets relating to this same
 issue - parts of which I used for writing the - still very incomplete -
 patch:
 * #13296
 * #9338
 * #2137

-- 
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] #2137: [patch] order_with_respect_to in M-R has no affect on admin interface

[Django]

#2137: [patch] order_with_respect_to in M-R has no affect on admin interface
+---
   Reporter:  anonymous | Owner:  xian
 Status:  reopened  | Milestone:  
  Component:  django.contrib.admin  |   Version:  
 Resolution:|  Keywords:  
   Triage Stage:  Accepted  | Has patch:  1   
Needs documentation:  0 |   Needs tests:  0   
Patch needs improvement:  0 |  
+---
Changes (by dokterbob):

  * status:  closed => reopened
 * cc: mathijs@… (added)
  * resolution:  duplicate =>


Comment:

 This is not merely a dup. of #2137, allthough it might be part of that
 one. Moreover, it has surely not been fixed.

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

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

[Django] #15197: yaml serialization to HttpResponse fails

[Django]

#15197: yaml serialization to HttpResponse fails
---+
 Reporter:  fourga38   |  Owner:  nobody
   Status:  new|  Milestone:
Component:  Serialization  |Version:  1.2   
 Keywords:  yaml   |   Triage Stage:  Unreviewed
Has patch:  0  |  
---+
 In django.core.serializers.pyyaml, the getvalue() method should check if
 self.stream has also a getvalue() method, which is not the case of
 HttpResponse objects.

-- 
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] #15184: Error when subclassing models.ForeignKey field

[Django]

#15184: Error when subclassing models.ForeignKey field
+---
   Reporter:  rupa108   | Owner:  
nobody 
 Status:  reopened  | Milestone:
 
  Component:  Database layer (models, ORM)  |   Version:  SVN   
 
 Resolution:|  Keywords:  
ForeignKey, models, subclassing
   Triage Stage:  Accepted  | Has patch:  0 
 
Needs documentation:  0 |   Needs tests:  0 
 
Patch needs improvement:  0 |  
+---

Comment (by rupa108):

 Thank's for taking the time to investigate this and sorry for confusing
 things. You're right, I certainly got mixed up and the things I'm trying
 to do should be done differently. Nevertheless I'm glad that you consider
 to make changes here.

-- 
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] #7220: Last_login in django.contrib.auth should has null=True

[Django]

#7220: Last_login in django.contrib.auth should has null=True
--+-
   Reporter:  veena   | Owner:  nobody  

 Status:  new | Milestone:  

  Component:  Contrib apps|   Version:  SVN 

 Resolution:  |  Keywords:  auth last 
login user
   Triage Stage:  Design decision needed  | Has patch:  0   

Needs documentation:  0   |   Needs tests:  0   

Patch needs improvement:  0   |  
--+-

Comment (by sven.hoffmann@…):

 We would like to use the field last_login to determine if a user has ever
 logged in.
 now we need to check if last_login == date_joined to do that but that's
 pretty weird,
 as the user actually has not logged in yet, but has a date for last_login
 set.
 why no just have the field null until first login as suggested in this
 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] #15168: feature request - New setting

[Django]

#15168: feature request - New setting
+---
   Reporter:  zay2  | Owner:  nobody
 Status:  reopened  | Milestone:  1.3   
  Component:  Internationalization  |   Version:  SVN   
 Resolution:|  Keywords:
   Triage Stage:  Unreviewed| Has patch:  0 
Needs documentation:  0 |   Needs tests:  0 
Patch needs improvement:  0 |  
+---

Comment (by bpeschier):

 I think the behaviour you are after is really specific and should not be
 included; you are basically saying "I want to ignore this 1 language when
 it is not set in a cookie". Removing Accept-Language headers would mean
 first time visitors which have set it to Russian for example would get
 Estonian, which is probably also not ideal.

 In your case I would extend the !LocaleMiddleware to mirror that; check
 the HTTP_ACCEPT_LANGUAGE in META before handing it to the
 !LocaleMiddleware-superclass and rewrite English to Estonian (META is
 mutable iirc).

-- 
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] #15180: reverse doesn't check default_args

[Django]

#15180: reverse doesn't check default_args
--+-
   Reporter:  olaf| Owner:  nobody  
 Status:  new | Milestone:  1.3 
  Component:  Core framework  |   Version:  1.3-beta
 Resolution:  |  Keywords:  resolve default_args
   Triage Stage:  Accepted| Has patch:  1   
Needs documentation:  0   |   Needs tests:  1   
Patch needs improvement:  0   |  
--+-

Comment (by olaf):

 Ok, I changed my patch a little bit. I added a new optional parameter to
 the reverse function. If check_default_args is not set(=None), reverse
 tries to find a match the standard way, if it will not succeed it tries
 one time again including the default_args. If it is set to False, it
 behaves just like the current reverse function. If it is set to true, it
 will check them from the beginning.

 I would like to write those test cases, but I don't know how to use
 different url configs. Could you point me to an Howto or give me a small
 example, and I will write them.

 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.

Re: [Django] #15168: feature request - New setting

[Django]

#15168: feature request - New setting
+---
   Reporter:  zay2  | Owner:  nobody
 Status:  reopened  | Milestone:  1.3   
  Component:  Internationalization  |   Version:  SVN   
 Resolution:|  Keywords:
   Triage Stage:  Unreviewed| Has patch:  0 
Needs documentation:  0 |   Needs tests:  0 
Patch needs improvement:  0 |  
+---
Changes (by zay2):

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


-- 
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] #15168: feature request - New setting

[Django]

#15168: feature request - New setting
+---
   Reporter:  zay2  | Owner:  nobody
 Status:  closed| Milestone:  1.3   
  Component:  Internationalization  |   Version:  SVN   
 Resolution:  wontfix   |  Keywords:
   Triage Stage:  Unreviewed| Has patch:  0 
Needs documentation:  0 |   Needs tests:  0 
Patch needs improvement:  0 |  
+---

Comment (by zay2):

 Look- I need the middleware. The middleware works just fine. Its just this
 one specific piece of code in django.utils.translation.trans_real
 get_language_from_request that does not provide the desired results. Like
 i explained in Original Post, language discovery, based on accept headers
 shows pages in undesired language on first visit.

 For that reason forementioned method looks like that in my django install,
 right now:

 {{{
 def get_language_from_request(request):
 """
 Analyzes the request to find what language the user wants the system
 to
 show. Only languages listed in settings.LANGUAGES are taken into
 account.
 If the user requests a sublanguage where we have a main language, we
 send
 out the main language.
 """
 global _accepted
 from django.conf import settings
 globalpath =
 os.path.join(os.path.dirname(sys.modules[settings.__module__].__file__),
 'locale')
 supported = dict(settings.LANGUAGES)

 if hasattr(request, 'session'):
 lang_code = request.session.get('django_language', None)
 if lang_code in supported and lang_code is not None and
 check_for_language(lang_code):
 return lang_code

 lang_code = request.COOKIES.get(settings.LANGUAGE_COOKIE_NAME)

 if lang_code and lang_code not in supported:
 lang_code = lang_code.split('-')[0] # e.g. if fr-ca is not
 supported fallback to fr

 if lang_code and lang_code in supported and
 check_for_language(lang_code):
 return lang_code

 '''
 accept = request.META.get('HTTP_ACCEPT_LANGUAGE', '')
 for accept_lang, unused in parse_accept_lang_header(accept):
 if accept_lang == '*':
 break

 # We have a very restricted form for our language files (no
 encoding
 # specifier, since they all must be UTF-8 and only one possible
 # language each time. So we avoid the overhead of gettext.find()
 and
 # work out the MO file manually.

 # 'normalized' is the root name of the locale in POSIX format
 (which is
 # the format used for the directories holding the MO files).
 normalized = locale.locale_alias.get(to_locale(accept_lang, True))
 if not normalized:
 continue
 # Remove the default encoding from locale_alias.
 normalized = normalized.split('.')[0]

 if normalized in _accepted:
 # We've seen this locale before and have an MO file for it, so
 no
 # need to check again.
 return _accepted[normalized]

 for lang, dirname in ((accept_lang, normalized),
 (accept_lang.split('-')[0], normalized.split('_')[0])):
 if lang.lower() not in supported:
 continue
 langfile = os.path.join(globalpath, dirname, 'LC_MESSAGES',
 'django.mo')
 if os.path.exists(langfile):
 _accepted[normalized] = lang
 return lang
 '''

 return settings.LANGUAGE_CODE
 }}}

 I would need to comment that part of code out from each new django version
 without that setting. With setting check, if i want to use that accept
 headers based lang discovery, commenting out would be unnecessary.

 Did that make it clearer? Why would i want or need to write whole new
 languagemiddleware if all i need is one method out of the way?

 Thanks,
 Alan.

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