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

[Django]

#10405: quoted class names in foreign key definition causes 'str' object has no
attribute '_default_manager'
-+-
   Reporter:  danbrwn|Owner:  mitsuhiko
   Type:  Bug|   Status:  new
  Milestone: |Component:  Database layer
Version:  1.2|  (models, ORM)
 Resolution: | Severity:  Normal
   Triage Stage:  Accepted   | Keywords:  foreign,key,quoted
Needs documentation:  0  |Has patch:  0
Patch needs improvement:  0  |  Needs tests:  0
-+-

Comment (by tehfink ):

 Interestingly, I've noticed this AttributeError is not raised if the
 quoted class name passed to the ForeignKey is 'auth.User'…perhaps because
 'django.contrib.auth' is usually the first installed app in
 INSTALLED_APPS?

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

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

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

[Django]

#10405: quoted class names in foreign key definition causes 'str' object has no
attribute '_default_manager'
-+-
   Reporter:  danbrwn|Owner:  mitsuhiko
   Type:  Bug|   Status:  new
  Milestone: |Component:  Database layer
Version:  1.2|  (models, ORM)
 Resolution: | Severity:  Normal
   Triage Stage:  Accepted   | Keywords:  foreign,key,quoted
Needs documentation:  0  |Has patch:  0
Patch needs improvement:  0  |  Needs tests:  0
-+-
Changes (by tehfink ):

 * cc: djsnickles@… (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] #14917: Error in the sample code under "Using an inline formset in a view"

[Django]

#14917: Error in the sample code under "Using an inline formset in a view"
+-
   Reporter:  baddox|Owner:  nobody
   Type:  Bug   |   Status:  new
  Milestone:|Component:  Documentation
Version:  1.2   | Severity:  Normal
 Resolution:| Keywords:
   Triage Stage:  Accepted  |Has patch:  0
Needs documentation:  0 |  Needs tests:  0
Patch needs improvement:  0 |
+-
Changes (by jaddison):

 * type:   => Bug
 * severity:   => Normal


-- 
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] #14909: Adding custom command requires code duplication from Command.handle() if one want to use options like verbosity.

[Django]

#14909: Adding custom command requires code duplication from Command.handle() if
one want to use options like verbosity.
---+
   Reporter:  zimnyx   |Owner:  nobody
   Type:  New feature  |   Status:  new
  Milestone:  2.0  |Component:  Core (Other)
Version:  SVN  | Severity:  Normal
 Resolution:   | Keywords:
   Triage Stage:  Accepted |Has patch:  0
Needs documentation:  0|  Needs tests:  0
Patch needs improvement:  0|
---+
Changes (by jaddison):

 * type:   => New feature
 * severity:   => Normal


-- 
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] #14904: TextField with unique (or in unique_together) constraint breaks for large inputs in Postgres

[Django]

#14904: TextField with unique (or in unique_together) constraint breaks for 
large
inputs in Postgres
-+-
   Reporter:  jorn   |Owner:  nobody
   Type:  Bug|   Status:  new
  Milestone: |Component:  Database layer
Version:  1.2|  (models, ORM)
 Resolution: | Severity:  Normal
   Triage Stage:  Accepted   | Keywords:  postgresql, index,
Needs documentation:  0  |  textfield
Patch needs improvement:  0  |Has patch:  0
 |  Needs tests:  0
-+-
Changes (by jaddison):

 * type:   => Bug
 * severity:   => Normal


-- 
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] #14903: wsgiref usage

[Django]

#14903: wsgiref usage
-+-
   Reporter:  maxbublis  |Owner:  nobody
   Type: |   Status:  new
  Cleanup/optimization   |Component:  Core (Other)
  Milestone: | Severity:  Normal
Version:  SVN| Keywords:
 Resolution: |Has patch:  1
   Triage Stage:  Accepted   |  Needs tests:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by jaddison):

 * type:   => Cleanup/optimization
 * severity:   => Normal


-- 
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] #14898: Move validate_sql functionality into backend

[Django]

#14898: Move validate_sql functionality into backend
-+-
   Reporter:  Xof|Owner:  nobody
   Type: |   Status:  new
  Cleanup/optimization   |Component:  Database layer
  Milestone: |  (models, ORM)
Version:  1.3-alpha  | Severity:  Normal
 Resolution: | Keywords:
   Triage Stage:  Accepted   |Has patch:  0
Needs documentation:  0  |  Needs tests:  0
Patch needs improvement:  0  |
-+-
Changes (by jaddison):

 * type:   => Cleanup/optimization
 * severity:   => Normal


-- 
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
   Type:  Bug|   Status:  new
  Milestone: |Component:  Core (Other)
Version:  1.2| Severity:  Normal
 Resolution: | Keywords:  threadsafety
   Triage Stage:  Accepted   |  translation
Needs documentation:  0  |Has patch:  1
Patch needs improvement:  0  |  Needs tests:  1
-+-
Changes (by jaddison):

 * 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] #14893: TypeError when accessing deferred (defer(..)) geometry field when using proxy geographic model

[Django]

#14893: TypeError when accessing deferred (defer(..)) geometry field when using
proxy geographic model
-+-
   Reporter:  mal|Owner:  nobody
   Type:  Bug|   Status:  new
  Milestone: |Component:  GIS
Version:  SVN| Severity:  Normal
 Resolution: | Keywords:  proxy, gis, defer,
   Triage Stage:  Accepted   |  TypeError
Needs documentation:  0  |Has patch:  0
Patch needs improvement:  0  |  Needs tests:  0
-+-
Changes (by jaddison):

 * type:   => Bug
 * severity:   => Normal


-- 
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] #14891: ManyToManyRelatedField uses different Manager than ForeignKey-field

[Django]

#14891: ManyToManyRelatedField uses different Manager than ForeignKey-field
-+-
   Reporter:  sdksho@…   |Owner:  nobody
   Type:  New|   Status:  new
  feature|Component:  Database layer
  Milestone: |  (models, ORM)
Version:  1.2| Severity:  Normal
 Resolution: | Keywords:  Manager
   Triage Stage:  Design |  ManyToManyField
  decision needed|  use_for_related_fields
Needs documentation:  0  |Has patch:  0
Patch needs improvement:  0  |  Needs tests:  0
-+-
Changes (by jaddison):

 * type:   => New feature
 * severity:   => Normal


Comment:

 At best, this is a documentation update; at worst, possible backwards
 incompatibilities as already mentioned (not my words!).  Regardless,
 marking this as 'new feature'.

-- 
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] #14887: select_related() does not work with Proxy models and multi-table inheritance

[Django]

#14887: select_related() does not work with Proxy models and multi-table
inheritance
-+-
   Reporter:  Ara|Owner:  nobody
  Anjargolian  |   Status:  new
   Type:  New|Component:  Database layer
  feature|  (models, ORM)
  Milestone: | Severity:  Normal
Version:  1.2| Keywords:  proxy select_related
 Resolution: |  inheritance
   Triage Stage:  Accepted   |Has patch:  0
Needs documentation:  0  |  Needs tests:  0
Patch needs improvement:  0  |
-+-
Changes (by jaddison):

 * type:   => New feature
 * severity:   => Normal


Comment:

 This would be a nice-to-have addition to existing functionality - marking
 as 'new feature'.

-- 
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] #14886: GeoModelAdmin forms cannot be used with WMS in formats other than image/jpeg

[Django]

#14886: GeoModelAdmin forms cannot be used with WMS in formats other than
image/jpeg
---+--
   Reporter:  slinkp   |Owner:  nobody
   Type:  New feature  |   Status:  new
  Milestone:   |Component:  GIS
Version:  1.2  | Severity:  Normal
 Resolution:   | Keywords:
   Triage Stage:  Accepted |Has patch:  1
Needs documentation:  0|  Needs tests:  0
Patch needs improvement:  0|
---+--
Changes (by jaddison):

 * type:   => New feature
 * severity:   => Normal


Comment:

 As this adds to existing functionality, I'm marking it as a 'new feature'.

-- 
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] #14881: Do not assume ``User.id`` to be an integer in django.contrib.auth's pasword reset feature

[Django]

#14881: Do not assume ``User.id`` to be an integer in django.contrib.auth's 
pasword
reset feature
-+-
   Reporter:  jonash |Owner:  nobody
   Type:  New|   Status:  new
  feature|Component:  contrib.auth
  Milestone: | Severity:  Normal
Version:  SVN| Keywords:
 Resolution: |Has patch:  1
   Triage Stage:  Design |  Needs tests:  1
  decision needed|
Needs documentation:  1  |
Patch needs improvement:  1  |
-+-
Changes (by jaddison):

 * type:   => New feature
 * severity:   => Normal


-- 
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
   Type:  Bug|   Status:  assigned
  Milestone: |Component:  Database layer
Version:  SVN|  (models, ORM)
 Resolution: | Severity:  Normal
   Triage Stage:  Accepted   | Keywords:  aggregate,
Needs documentation:  0  |  postgresql, charfield
Patch needs improvement:  1  |Has patch:  1
 |  Needs tests:  1
-+-
Changes (by jaddison):

 * type:   => Bug
 * severity:   => Normal


-- 
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] #14877: ModelFormSet.save() with a deleted form should work even if the model has already been deleted

[Django]

#14877: ModelFormSet.save() with a deleted form should work even if the model 
has
already been deleted
-+--
   Reporter:  andornaut  |Owner:  nobody
   Type:  Bug|   Status:  new
  Milestone: |Component:  Forms
Version:  1.3-alpha  | Severity:  Normal
 Resolution: | Keywords:
   Triage Stage:  Accepted   |Has patch:  0
Needs documentation:  0  |  Needs tests:  0
Patch needs improvement:  0  |
-+--
Changes (by jaddison):

 * type:   => Bug
 * severity:   => Normal


-- 
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] #14876: Q | Q with nullable related fields generates INNER JOIN where it should be LEFT JOIN

[Django]

#14876: Q | Q with nullable related fields generates INNER JOIN where it should 
be
LEFT JOIN
-+-
   Reporter: |Owner:  nobody
  simonpercivall |   Status:  new
   Type:  Bug|Component:  Database layer
  Milestone: |  (models, ORM)
Version:  1.2| Severity:  Normal
 Resolution: | Keywords:  Q,inner join,nullable
   Triage Stage:  Accepted   |Has patch:  0
Needs documentation:  0  |  Needs tests:  0
Patch needs improvement:  0  |
-+-
Changes (by jaddison):

 * type:   => Bug
 * severity:   => Normal


-- 
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] #14874: remove js-confirms on changelist

[Django]

#14874: remove js-confirms on changelist
-+-
   Reporter: |Owner:  nobody
  sehmaschine@…  |   Status:  new
   Type:  Bug|Component:  contrib.admin
  Milestone: | Severity:  Normal
Version:  SVN| Keywords:
 Resolution: |Has patch:  0
   Triage Stage:  Design |  Needs tests:  0
  decision needed|
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by jaddison):

 * type:   => Bug
 * severity:   => Normal


-- 
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] #14845: Refactor backend connection-creation process

[Django]

#14845: Refactor backend connection-creation process
-+-
   Reporter:  Xof|Owner:  nobody
   Type:  New|   Status:  new
  feature|Component:  Database layer
  Milestone: |  (models, ORM)
Version:  1.3-alpha  | Severity:  Normal
 Resolution: | Keywords:
   Triage Stage:  Accepted   |Has patch:  0
Needs documentation:  0  |  Needs tests:  0
Patch needs improvement:  0  |
-+-
Changes (by jaddison):

 * type:   => New feature
 * severity:   => Normal


-- 
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] #14844: i18n blocktrans tag pluralization feature limited by gettext constraints and unique local tag context

[Django]

#14844: i18n blocktrans tag pluralization feature limited by gettext constraints
and unique local tag context
+
   Reporter:  ramiro|Owner:  nobody
   Type:  Bug   |   Status:  new
  Milestone:|Component:  Internationalization
Version:  SVN   | Severity:  Normal
 Resolution:| Keywords:
   Triage Stage:  Accepted  |Has patch:  0
Needs documentation:  0 |  Needs tests:  0
Patch needs improvement:  0 |
+
Changes (by jaddison):

 * type:   => Bug
 * severity:   => Normal
 * 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] #14836: Improve semantics of docs:

[Django]

#14836: Improve semantics of docs:
-+-
   Reporter:  cogat  |Owner:  cogat
   Type:  Bug|   Status:  new
  Milestone: |Component:  Djangoproject.com Web
Version:  1.2|  site
 Resolution: | Severity:  Normal
   Triage Stage:  Accepted   | Keywords:  sprintdec2010
Needs documentation:  0  |Has patch:  0
Patch needs improvement:  0  |  Needs tests:  0
-+-
Changes (by jaddison):

 * type:   => Bug
 * severity:   => Normal


-- 
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] #14834: Colour issues in CSS - particularly documentation

[Django]

#14834: Colour issues in CSS - particularly documentation
+-
   Reporter:  cogat |Owner:  cogat
   Type:  Bug   |   Status:  new
  Milestone:|Component:  Documentation
Version:  1.2   | Severity:  Normal
 Resolution:| Keywords:  sprintdec2010
   Triage Stage:  Accepted  |Has patch:  1
Needs documentation:  0 |  Needs tests:  0
Patch needs improvement:  1 |
+-
Changes (by jaddison):

 * type:   => Bug
 * severity:   => Normal
 * 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] #14832: Impossible to create inline objects if form validates but is unchanged

[Django]

#14832: Impossible to create inline objects if form validates but is unchanged
+-
   Reporter:  julien|Owner:  nobody
   Type:  Bug   |   Status:  new
  Milestone:|Component:  contrib.admin
Version:  1.2   | Severity:  Normal
 Resolution:| Keywords:  sprintdec2010
   Triage Stage:  Accepted  |Has patch:  0
Needs documentation:  0 |  Needs tests:  0
Patch needs improvement:  0 |
+-
Changes (by jaddison):

 * type:   => Bug
 * severity:   => Normal


-- 
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] #14831: Django Template Style Guide

[Django]

#14831: Django Template Style Guide
-+-
   Reporter:  DrMeers|Owner:  nobody
   Type:  New|   Status:  new
  feature|Component:  Documentation
  Milestone: | Severity:  Normal
Version:  1.2| Keywords:  template, style,
 Resolution: |  format
   Triage Stage:  Accepted   |Has patch:  0
Needs documentation:  0  |  Needs tests:  0
Patch needs improvement:  0  |
-+-
Changes (by anonymous):

 * type:   => New feature
 * severity:   => Normal


-- 
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] #15758: en_format is removed, but DEFAULT_ constants is still there

[Django]

#15758: en_format is removed, but DEFAULT_ constants is still there
+---
   Reporter:  void  |Owner:  nobody
   Type:  Bug   |   Status:  new
  Milestone:  1.4   |Component:  Forms
Version:  SVN   | Severity:  Release blocker
 Resolution:| Keywords:
   Triage Stage:  Accepted  |Has patch:  0
Needs documentation:  0 |  Needs tests:  0
Patch needs improvement:  0 |
+---
Changes (by russellm):

 * severity:  Normal => Release blocker
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * milestone:   => 1.4
 * needs_docs:   => 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.

[Django] #15761: Clarity

[Django]

#15761: Clarity
---+--
 Reporter:  chris.is.fun+django@…  | Owner:  nobody
 Type:  Cleanup/optimization   |Status:  new
Milestone: | Component:  Documentation
  Version:  1.3|  Severity:  Normal
 Keywords:  tutorial   |  Triage Stage:  Unreviewed
Has patch:  0  |
---+--
 Three suggestions to make this clearer for us newbs.


 First, when you refer to /django/contrib/ it would be good to give a few
 examples of where that might be, like for Ubuntu it's /var/python-
 support/python2.6/django/contrib/. That wasn't obvious to me.

 Second, '''Use the template system''' was unclear in the following way.

 {{{
 {{ poll.question }}
 
 {% for choice in poll.choice_set.all %}
 {{ choice.choice }}
 {% endfor %}
 
 }}}



 it's unclear which "poll" is being referred to:  the model Poll, the
 foreign key poll, or the poll that was passed from p through a dictionary
 in the view. (I think "view" is the place it was passed.)

 Also it's confusing when you refer to a set as X and a member of the set
 as X. Maybe in the above you could do

 {{{
 {% for c in poll_fk.choice_set.all %}
 {{c.choice}}
 {% endfor%}
 }}}

 or maybe it's {{{ {{choice.c}} }}}, I can't tell whether the set or the
 member comes first.




 Finally choice_set is an infelicitous word because "choice set" could
 refer to the result of like a SQL query or many other sets of choices.
 Maybe in a newer version of the tutorial you could name the models
 differently. How about "polls" and "answers" ?

-- 
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] #15760: Feature: JS Hooks for Dynamic Inlines

[Django]

#15760: Feature: JS Hooks for Dynamic Inlines
---+--
   Reporter:  mlavin   |Owner:  nobody
   Type:  New feature  |   Status:  new
  Milestone:   |Component:  contrib.admin
Version:  SVN  | Severity:  Normal
 Resolution:   | Keywords:  inlines jquery
   Triage Stage:  Accepted |Has patch:  1
Needs documentation:  1|  Needs tests:  0
Patch needs improvement:  0|
---+--
Changes (by julien):

 * 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] #15760: Feature: JS Hooks for Dynamic Inlines

[Django]

#15760: Feature: JS Hooks for Dynamic Inlines
---+--
   Reporter:  mlavin   |Owner:  nobody
   Type:  New feature  |   Status:  new
  Milestone:   |Component:  contrib.admin
Version:  SVN  | Severity:  Normal
 Resolution:   | Keywords:  inlines jquery
   Triage Stage:  Unreviewed   |Has patch:  1
Needs documentation:  1|  Needs tests:  0
Patch needs improvement:  0|
---+--
Changes (by mlavin):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 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.

[Django] #15760: Feature: JS Hooks for Dynamic Inlines

[Django]

#15760: Feature: JS Hooks for Dynamic Inlines
+--
 Reporter:  mlavin  | Owner:  nobody
 Type:  New feature |Status:  new
Milestone:  | Component:  contrib.admin
  Version:  SVN |  Severity:  Normal
 Keywords:  inlines jquery  |  Triage Stage:  Unreviewed
Has patch:  1   |
+--
 It is difficult to access the newly added row when working with dynamic
 inlines. This makes it difficult to use widgets which require javascript
 bindings (such as auto-complete widgets) in the inlines. I believe this is
 the issue that someone was trying to raise in #15693. While the formset
 plugin does allow for passing method to be called when a new row is added,
 this is always already populated by admin/edit_inline/stacked.html and
 admin/edit_inline/tabular.html. If you want to include another method to
 be run you need to override these templates completely.

 I've attached a patch which adds two events to the formset plugin:
 `formsetadd` and `formsetdelete` which are fired by the add and delete
 rows respectively. The example usage would be
 {{{
 django.jQuery('.add-row a').live('formsetadd', function(e, row) {
 console.log('Formset add!');
 console.log($(row));
 });
 }}}

-- 
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] #11671: Aggregations add extra values to ValuesQuerySets :: another usecase

[Django]

#11671: Aggregations add extra values to ValuesQuerySets :: another usecase
-+---
   Reporter:  richard@…  |Owner:
   Type:  Bug|   Status:  new
  Milestone: |Component:  ORM aggregation
Version:  SVN| Severity:  Normal
 Resolution: | Keywords:
   Triage Stage:  Accepted   |Has patch:  0
Needs documentation:  0  |  Needs tests:  0
Patch needs improvement:  0  |
-+---
Changes (by anonymous):

 * version:  1.1 => SVN


Comment:

 Patching this would be very helpfull as, this feature would be usefull in
 clustering (geodjango)


 {{{
 e.objects.extra(select={'cluster':'substring(mortons_code for
 
10)'}).annotate(objects_in_cluster=Count('cluster')).order_by('objects_in_cluster')
 }}}


 same error:

 {{{
 FieldError: Cannot resolve keyword 'cluster' into field. Choices are:
 }}}

 .

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

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

[Changeset] r16016 - in django/trunk: django/contrib/gis/db/backends/oracle django/contrib/gis/db/backends/spatialite django/db/backends django/db/backends/dummy django/db/backends/mysql django/db/ba

[noreply]

Author: ramiro
Date: 2011-04-04 17:19:17 -0700 (Mon, 04 Apr 2011)
New Revision: 16016

Modified:
   django/trunk/django/contrib/gis/db/backends/oracle/operations.py
   django/trunk/django/contrib/gis/db/backends/spatialite/operations.py
   django/trunk/django/db/backends/__init__.py
   django/trunk/django/db/backends/dummy/base.py
   django/trunk/django/db/backends/mysql/base.py
   django/trunk/django/db/backends/oracle/base.py
   django/trunk/django/db/backends/postgresql_psycopg2/operations.py
   django/trunk/django/db/backends/sqlite3/base.py
   django/trunk/tests/regressiontests/backends/tests.py
Log:
Fixed #13630 -- Made __init__ methods of all DB backends' DatabaseOperations 
classes take a `connection` argument. Thanks calexium for the report.

Modified: django/trunk/django/contrib/gis/db/backends/oracle/operations.py
===
--- django/trunk/django/contrib/gis/db/backends/oracle/operations.py
2011-04-04 15:43:56 UTC (rev 16015)
+++ django/trunk/django/contrib/gis/db/backends/oracle/operations.py
2011-04-05 00:19:17 UTC (rev 16016)
@@ -133,8 +133,7 @@
 truncate_params = {'relate' : None}
 
 def __init__(self, connection):
-super(OracleOperations, self).__init__()
-self.connection = connection
+super(OracleOperations, self).__init__(connection)
 
 def convert_extent(self, clob):
 if clob:

Modified: django/trunk/django/contrib/gis/db/backends/spatialite/operations.py
===
--- django/trunk/django/contrib/gis/db/backends/spatialite/operations.py
2011-04-04 15:43:56 UTC (rev 16015)
+++ django/trunk/django/contrib/gis/db/backends/spatialite/operations.py
2011-04-05 00:19:17 UTC (rev 16016)
@@ -110,8 +110,7 @@
 geometry_functions.update(distance_functions)
 
 def __init__(self, connection):
-super(DatabaseOperations, self).__init__()
-self.connection = connection
+super(DatabaseOperations, self).__init__(connection)
 
 # Determine the version of the SpatiaLite library.
 try:

Modified: django/trunk/django/db/backends/__init__.py
===
--- django/trunk/django/db/backends/__init__.py 2011-04-04 15:43:56 UTC (rev 
16015)
+++ django/trunk/django/db/backends/__init__.py 2011-04-05 00:19:17 UTC (rev 
16016)
@@ -388,7 +388,8 @@
 """
 compiler_module = "django.db.models.sql.compiler"
 
-def __init__(self):
+def __init__(self, connection):
+self.connection = connection
 self._cache = None
 
 def autoinc_sql(self, table, column):

Modified: django/trunk/django/db/backends/dummy/base.py
===
--- django/trunk/django/db/backends/dummy/base.py   2011-04-04 15:43:56 UTC 
(rev 16015)
+++ django/trunk/django/db/backends/dummy/base.py   2011-04-05 00:19:17 UTC 
(rev 16016)
@@ -59,7 +59,7 @@
 super(DatabaseWrapper, self).__init__(*args, **kwargs)
 
 self.features = BaseDatabaseFeatures(self)
-self.ops = DatabaseOperations()
+self.ops = DatabaseOperations(self)
 self.client = DatabaseClient(self)
 self.creation = BaseDatabaseCreation(self)
 self.introspection = DatabaseIntrospection(self)

Modified: django/trunk/django/db/backends/mysql/base.py
===
--- django/trunk/django/db/backends/mysql/base.py   2011-04-04 15:43:56 UTC 
(rev 16015)
+++ django/trunk/django/db/backends/mysql/base.py   2011-04-05 00:19:17 UTC 
(rev 16016)
@@ -23,7 +23,7 @@
 raise ImproperlyConfigured("MySQLdb-1.2.1p2 or newer is required; you have 
%s" % Database.__version__)
 
 from MySQLdb.converters import conversions
-from MySQLdb.constants import FIELD_TYPE, FLAG, CLIENT
+from MySQLdb.constants import FIELD_TYPE, CLIENT
 
 from django.db import utils
 from django.db.backends import *
@@ -279,7 +279,7 @@
 
 self.server_version = None
 self.features = DatabaseFeatures(self)
-self.ops = DatabaseOperations()
+self.ops = DatabaseOperations(self)
 self.client = DatabaseClient(self)
 self.creation = DatabaseCreation(self)
 self.introspection = DatabaseIntrospection(self)

Modified: django/trunk/django/db/backends/oracle/base.py
===
--- django/trunk/django/db/backends/oracle/base.py  2011-04-04 15:43:56 UTC 
(rev 16015)
+++ django/trunk/django/db/backends/oracle/base.py  2011-04-05 00:19:17 UTC 
(rev 16016)
@@ -84,8 +84,8 @@
 def autoinc_sql(self, table, column):
 # To simulate auto-incrementing primary keys in Oracle, we have to
 # create a sequence and a trigger.
-sq_name = get_sequence_name(table)
-tr_name = get_trigger_name(table)
+sq_name = self._get_sequen

Re: [Django] #11868: Multiple sort in admin changelist

[Django]

#11868: Multiple sort in admin changelist
-+-
   Reporter: |Owner:  bendavis78
  bendavis78 |   Status:  assigned
   Type:  New|Component:  contrib.admin
  feature| Severity:  Normal
  Milestone: | Keywords:  admin sort multisort
Version:  SVN|  ordering order
 Resolution: |Has patch:  1
   Triage Stage:  Accepted   |  Needs tests:  1
Needs documentation:  0  |
Patch needs improvement:  1  |
-+-
Changes (by julien):

 * stage:  Design decision needed => 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] #11868: Multiple sort in admin changelist

[Django]

#11868: Multiple sort in admin changelist
-+-
   Reporter: |Owner:  bendavis78
  bendavis78 |   Status:  assigned
   Type:  New|Component:  contrib.admin
  feature| Severity:  Normal
  Milestone: | Keywords:  admin sort multisort
Version:  SVN|  ordering order
 Resolution: |Has patch:  1
   Triage Stage:  Design |  Needs tests:  1
  decision needed|
Needs documentation:  0  |
Patch needs improvement:  1  |
-+-
Changes (by julien):

 * needs_better_patch:  0 => 1
 * needs_tests:  0 => 1


Comment:

 #11695 and #4926 were closed as duplicates.

 The reason why the admin currently forces the use of just one field for
 ordering is merely for a lack of a better UI. And I think that the UI
 approach suggested here is the right one.

 The patch needs to be updated to work with current trunk. It is also
 important to make it work if the ordering is changed via overriding the
 ModelAdmin queryset (see #7309).

-- 
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] #11695: Modified change list default sort

[Django]

#11695: Modified change list default sort
-+-
   Reporter:  Rupe   |Owner:  nobody
   Type: |   Status:  closed
  Uncategorized  |Component:  contrib.admin
  Milestone: | Severity:  Normal
Version:  SVN| Keywords:  change list default
 Resolution:  duplicate  |  sort model-sort
   Triage Stage:  Design |Has patch:  1
  decision needed|  Needs tests:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by julien):

 * status:  new => closed
 * resolution:   => duplicate
 * type:   => Uncategorized
 * severity:   => Normal


Comment:

 Closing as a duplicate of #11868 which, although newer, suggests a better
 approach UI-wise.

-- 
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] #4926: Ordering in admin listview ignores ordering in admin options

[Django]

#4926: Ordering in admin listview ignores ordering in admin options
-+-
   Reporter:  Glin   |Owner:  nobody
 |   Status:  closed
   Type:  Bug|Component:  contrib.admin
  Milestone: | Severity:  Normal
Version:  SVN| Keywords:  nfa-someday nfa-
 Resolution:  duplicate  |  changelist
   Triage Stage: |Has patch:  1
  Someday/Maybe  |  Needs tests:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by julien):

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


Comment:

 Closing as a duplicate of #11868 which, although newer, suggests a better
 approach UI-wise and has a more recent 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] #11674: documentation clarifications on ModelForms & ModelFormsets Meta fields

[Django]

#11674: documentation clarifications on ModelForms & ModelFormsets Meta fields
-+-
   Reporter: |Owner:  nobody
  david.h.haas@… |   Status:  new
   Type: |Component:  Documentation
  Cleanup/optimization   | Severity:  Normal
  Milestone: | Keywords:  ModelForm, Meta
Version:  SVN|  class, easy-pickings
 Resolution: |Has patch:  0
   Triage Stage:  Accepted   |  Needs tests:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by julien):

 * keywords:  ModelForm, Meta class => ModelForm, Meta class, easy-pickings
 * type:   => Cleanup/optimization
 * severity:   => Normal


-- 
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] #15757: get_and_delete_messages, removed in [15975], is still alive

[Django]

#15757: get_and_delete_messages, removed in [15975], is still alive
--+
   Reporter:  void|Owner:  nobody
   Type:  Bug |   Status:  closed
  Milestone:  |Component:  contrib.auth
Version:  SVN | Severity:  Normal
 Resolution:  invalid | Keywords:
   Triage Stage:  Unreviewed  |Has patch:  0
Needs documentation:  0   |  Needs tests:  0
Patch needs improvement:  0   |
--+
Changes (by russellm):

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


Comment:

 You've got something going on with your checkout -- possibly stale .pyc
 files, or a second checkout in your PYTHONPATH. The usage of
 get_and_delete_messages in
 
[http://code.djangoproject.com/browser/django/trunk/django/contrib/messages/api.py#L44
 contrib.messages.api line 44] has been 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] #11652: Simultaneous editing of a record via the admin interface silently overwrites

[Django]

#11652: Simultaneous editing of a record via the admin interface silently
overwrites
-+-
   Reporter:  David  |Owner:  nobody
  Findlay   |   Status:  new
   Type:  New|Component:  contrib.admin
  feature| Severity:  Normal
  Milestone: | Keywords:
Version:  1.1|Has patch:  0
 Resolution: |  Needs tests:  0
   Triage Stage:  Design |
  decision needed|
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by julien):

 * type:   => New feature
 * severity:   => Normal


Comment:

 See #11313 for a related issue.

-- 
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] #11313: list_editable fields don't support 'save' in multiuser environment

[Django]

#11313: list_editable fields don't support 'save' in multiuser environment
--+-
   Reporter:  margieroginski  |Owner:  nobody
   Type:  New feature |   Status:  reopened
  Milestone:  1.3 |Component:  contrib.admin
Version:  1.1-beta-1  | Severity:  Normal
 Resolution:  | Keywords:
   Triage Stage:  Accepted|Has patch:  0
Needs documentation:  0   |  Needs tests:  0
Patch needs improvement:  0   |
--+-

Comment (by julien):

 See #11652 for a related issue.

-- 
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] #12885: GenericRelation fails to join the related table from a inherited model

[Django]

#12885: GenericRelation fails to join the related table from a inherited model
+
   Reporter:  semenov   |Owner:  nobody
   Type:  Bug   |   Status:  new
  Milestone:|Component:  contrib.contenttypes
Version:  1.1   | Severity:  Normal
 Resolution:| Keywords:
   Triage Stage:  Accepted  |Has patch:  0
Needs documentation:  0 |  Needs tests:  0
Patch needs improvement:  0 |
+
Changes (by anonymous):

 * component:  Database layer (models, ORM) => contrib.contenttypes


-- 
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] #12728: loadata/flush issues given GenericRelation, model inheritance and postgres

[Django]

#12728: loadata/flush issues given GenericRelation, model inheritance and 
postgres
-+-
   Reporter:  pragmar|Owner:  nobody
   Type:  Bug|   Status:  new
  Milestone: |Component:  contrib.contenttypes
Version:  SVN| Severity:  Normal
 Resolution: | Keywords:
   Triage Stage:  Accepted   |  psycopg2.ProgrammingError,
Needs documentation:  0  |  GenericRelation
Patch needs improvement:  0  |Has patch:  0
 |  Needs tests:  0
-+-
Changes (by anonymous):

 * component:  Database layer (models, ORM) => contrib.contenttypes


-- 
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] #11634: OpenLayers default position

[Django]

#11634: OpenLayers default position
+--
   Reporter:  dalkvist  |Owner:  nobody
   Type:  Bug   |   Status:  new
  Milestone:|Component:  GIS
Version:  SVN   | Severity:  Normal
 Resolution:| Keywords:
   Triage Stage:  Accepted  |Has patch:  1
Needs documentation:  0 |  Needs tests:  1
Patch needs improvement:  0 |
+--
Changes (by julien):

 * type:   => Bug
 * severity:   => Normal
 * 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] #15759: list_editable should respect per-object permissions

[Django]

#15759: list_editable should respect per-object permissions
+-
   Reporter:  jdunck|Owner:  nobody
   Type:  Bug   |   Status:  new
  Milestone:|Component:  contrib.admin
Version:  1.3   | Severity:  Normal
 Resolution:| Keywords:
   Triage Stage:  Accepted  |Has patch:  0
Needs documentation:  0 |  Needs tests:  0
Patch needs improvement:  0 |
+-
Changes (by julien):

 * stage:  Unreviewed => Accepted


Comment:

 Yes, this makes a lot of sense. The trick will be to annotate the result
 list in a way that doesn't impact performance too much.

-- 
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] #15705: Localflavor for Croatia

[Django]

#15705: Localflavor for Croatia
---+---
   Reporter:  zmasek   |Owner:  zmasek
   Type:  New feature  |   Status:  new
  Milestone:   |Component:  contrib.localflavor
Version:  SVN  | Severity:  Normal
 Resolution:   | Keywords:  localflavor croatia
   Triage Stage:  Accepted |Has patch:  1
Needs documentation:  0|  Needs tests:  0
Patch needs improvement:  0|
---+---

Comment (by julien):

 It would be great if you could also add tests for your patch in
 source:django/trunk/tests/regressiontests/localflavor

 There currently aren't many tests for localflavors and it'd be good to set
 a good example. Plus that will be good training for your testing skills ;)

-- 
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] #11595: Fixture validation errors should report their data

[Django]

#11595: Fixture validation errors should report their data
-+-
   Reporter:  freyley|Owner:  nobody
   Type: |   Status:  new
  Cleanup/optimization   |Component:  Core (Serialization)
  Milestone: | Severity:  Normal
Version:  1.0| Keywords:  easy-pickings
 Resolution: |Has patch:  0
   Triage Stage:  Accepted   |  Needs tests:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by julien):

 * keywords:   => easy-pickings
 * type:   => Cleanup/optimization
 * severity:   => Normal


Old description:

> For example, here's what django/db/models/fields/__init__.py has for
> lines 341-348:
>
> def to_python(self, value):
> if value is None:
> return value
> try:
>  return int(value)
> except (TypeError, ValueError):
> raise exceptions.ValidationError(
> _("This value must be an integer.") )
>
> Changing line 348 to:
>
>  _("(%s) must be an integer." % value) )
>
> means that when you convert a text field to a joined object, you know
> which one's broken where. (Other places in that file do the same thing)

New description:

 For example, here's what django/db/models/fields/__init__.py has for lines
 341-348:

 def to_python(self, value):
 if value is None:
 return value
 try:
  return int(value)
 except (TypeError, ValueError):
 raise exceptions.ValidationError(
 _("This value must be an integer.") )

 Changing line 348 to:

  _("(%s) must be an integer." % value) )

 means that when you convert a text field to a joined object, you know
 which one's broken where. (Other places in that file do the same thing)

--

-- 
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] #11581: URLField verify_exists blocks 401 respones

[Django]

#11581: URLField verify_exists blocks 401 respones
-+
   Reporter:  rlaager@…  |Owner:  nobody
   Type:  Bug|   Status:  new
  Milestone: |Component:  Core (Other)
Version:  1.0| Severity:  Normal
 Resolution: | Keywords:
   Triage Stage:  Accepted   |Has patch:  0
Needs documentation:  0  |  Needs tests:  0
Patch needs improvement:  0  |
-+
Changes (by julien):

 * component:  Uncategorized => Core (Other)
 * type:   => Bug
 * severity:   => Normal
 * stage:  Design decision needed => Accepted


Comment:

 I'd argue that a 401 verifies that the url actually exists. By the way,
 the doc defines "does not exist" as "returns 404":
 
http://docs.djangoproject.com/en/dev/ref/validators/#django.core.validators.URLValidator

-- 
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] #15759: list_editable should respect per-object permissions

[Django]

#15759: list_editable should respect per-object permissions
--+-
   Reporter:  jdunck  |Owner:  nobody
   Type:  Bug |   Status:  new
  Milestone:  |Component:  contrib.admin
Version:  1.3 | Severity:  Normal
   Keywords:  | Triage Stage:  Unreviewed
  Has patch:  0   |  Needs documentation:  0
Needs tests:  0   |  Patch needs improvement:  0
--+-
 Currently, list_editable for admin displays form fields for all objects,
 even if an auth backend supports per-object permissions.

 This allows editing of objects even if the user shouldn't be able to.

 If there's a backend that supports per-object permissions, only those rows
 which allow editing should have edit fields.

 I think this means that FormSet created in changelist_view needs to be
 passed a result_list which is annotated with per-object permission flags,
 and modelform_factory should respect those flags.

-- 
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] #15705: Localflavor for Croatia

[Django]

#15705: Localflavor for Croatia
---+---
   Reporter:  zmasek   |Owner:  zmasek
   Type:  New feature  |   Status:  new
  Milestone:   |Component:  contrib.localflavor
Version:  SVN  | Severity:  Normal
 Resolution:   | Keywords:  localflavor croatia
   Triage Stage:  Accepted |Has patch:  1
Needs documentation:  0|  Needs tests:  0
Patch needs improvement:  0|
---+---
Changes (by julien):

 * stage:  Ready for checkin => Accepted


Comment:

 Replying to [comment:4 zmasek]:
 > I'm considering adding another field for custom license plates. If I
 find it useful to have (as opposed to having an ordinary non-validated
 text input), should I make another ticket or add to this one?

 You can add it to this one. I'm just moving back to accepted so someone
 gets a change to review your new 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] #14091: Fix incorrect quoting in connection.queries

[Django]

#14091: Fix incorrect quoting in connection.queries
-+-
   Reporter:  danielr|Owner:  aaugustin
   Type:  Bug|   Status:  new
  Milestone: |Component:  Database layer
Version:  1.2|  (models, ORM)
 Resolution: | Severity:  Normal
   Triage Stage:  Accepted   | Keywords:
Needs documentation:  0  |Has patch:  1
Patch needs improvement:  0  |  Needs tests:  0
-+-

Comment (by ikelly):

 I've run the test under Oracle, and it passes.

-- 
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] #15695: Add "url_name" to HttpRequest

[Django]

#15695: Add "url_name" to HttpRequest
-+-
   Reporter:  nischu7|Owner:  nobody
   Type:  New|   Status:  new
  feature|Component:  Core (Other)
  Milestone: | Severity:  Normal
Version:  1.3| Keywords:
 Resolution: |Has patch:  1
   Triage Stage:  Design |  Needs tests:  1
  decision needed|
Needs documentation:  1  |
Patch needs improvement:  0  |
-+-

Comment (by nischu7):

 As I already stated in the 2nd comment, I'd just store the ResolverMatch
 object as it is since it contains everything we need (view callback
 function, args, kwargs, the url name, as well as the app name). Should I
 submit another 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.

[Django] #15758: en_format is removed, but DEFAULT_ constants is still there

[Django]

#15758: en_format is removed, but DEFAULT_ constants is still there
--+---
 Reporter:  void  | Owner:  nobody
 Type:  Bug   |Status:  new
Milestone:| Component:  Forms
  Version:  SVN   |  Severity:  Normal
 Keywords:|  Triage Stage:  Unreviewed
Has patch:  0 |
--+---
 en_format helper is removed in [15983], but DEFAULT_DATE_INPUT_FORMATS,
 DEFAULT_TIME_INPUT_FORMATS, DEFAULT_DATETIME_INPUT_FORMATS constants is
 there and call undefined function. This does not trigger exception only
 because of lazy() wrapper call.

-- 
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] #15757: get_and_delete_messages, removed in [15975], is still alive

[Django]

#15757: get_and_delete_messages, removed in [15975], is still alive
--+-
 Reporter:  void  | Owner:  nobody
 Type:  Bug   |Status:  new
Milestone:| Component:  contrib.auth
  Version:  SVN   |  Severity:  Normal
 Keywords:|  Triage Stage:  Unreviewed
Has patch:  0 |
--+-
 Method get_and_delete_messages(), removed in [15975], is still alive in
 django.contrib.messages.api (line 44) and AnonymousUser.
 This results in stack staces like:


 {{{
 File "/Users/voidus/Documents/workspace/django-
 trunk/django/template/response.py", line 155, in resolve_context
 return RequestContext(self._request, context,
 current_app=self._current_app)

   File "/Users/voidus/Documents/workspace/django-
 trunk/django/template/context.py", line 177, in __init__
 self.update(processor(request))

   File "/Users/voidus/Documents/workspace/django-
 trunk/django/contrib/auth/context_processors.py", line 58, in auth
 'messages': messages.get_messages(request),

   File "/Users/voidus/Documents/workspace/django-
 trunk/django/contrib/messages/api.py", line 44, in get_messages
 return lazy(memoize(get_user().get_and_delete_messages, {}, 0),
 list)()

 AttributeError: 'User' object has no attribute 'get_and_delete_messages'
 }}}

-- 
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] #15729: Cache middleware issues after restart when using mod_wsgi with PyLibMC

[Django]

#15729: Cache middleware issues after restart when using mod_wsgi with PyLibMC
--+---
   Reporter:  jsdalton|Owner:  nobody
   Type:  Bug |   Status:  new
  Milestone:  |Component:  Core (Cache system)
Version:  1.3 | Severity:  Normal
 Resolution:  | Keywords:
   Triage Stage:  Unreviewed  |Has patch:  0
Needs documentation:  0   |  Needs tests:  0
Patch needs improvement:  0   |
--+---

Comment (by jsdalton):

 Replying to [comment:3 toxik]:
 > It's actually not even a fault pylibmc can handle - the underlying
 libmemcached library should be handling this. There are patches floating
 around the internet regarding libmemcached's handling of failures but I
 would suggest pushing for this issue on the libmemcached mailing list.

 Yeah, I don't know. I guess I just feel like if you're deploying on a
 stack that's "recommended" by the official Django documentation and a
 failry typical action within that stack (restarting memcached service)
 causes an application error within Django that literally brings your
 application to a halt, then that's perhaps something that should at least
 be mentioned in the documentation? I mean, I saw the addition of PyLibMC
 and had heard good things about it, and went through the trouble of
 configuring and deploying it, and only very fortunately caught the issue
 while it was still staging so that it did not make it production. It seems
 like a huge red flag to using the library.

 But I completely understand your line of reasoning. It's not something it
 would appear Django can do anything about directly, but by the same token
 should that library be supported?

-- 
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] #15756: Template regression with property lookups

[Django]

#15756: Template regression with property lookups
-+-
   Reporter:  Keryn  |Owner:  nobody
  Knight|   Status:  closed
   Type:  Bug|Component:  Template system
  Milestone: | Severity:  Normal
Version:  1.3| Keywords:
 Resolution:  invalid|Has patch:  0
   Triage Stage: |  Needs tests:  0
  Unreviewed |
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by lrekucki):

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


Comment:

 This is actually a fix of previous inconsistent behaviour. See Django 1.3
 release notes: http://docs.djangoproject.com/en/dev/releases/1.3
 /#callables-in-templates

 PS. A similar "problem" involving classes was reported in #15660.

-- 
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] #15755: Admin should allow for configurable login handling support

[Django]

#15755: Admin should allow for configurable login handling support
---+-
   Reporter:  metzen   |Owner:  nobody
   Type:  New feature  |   Status:  new
  Milestone:   |Component:  contrib.admin
Version:  SVN  | Severity:  Normal
 Resolution:   | Keywords:
   Triage Stage:  Unreviewed   |Has patch:  1
Needs documentation:  0|  Needs tests:  0
Patch needs improvement:  0|
---+-

Comment (by metzen):

 This is actually the approach I'm currently taking in my project, but was
 interested in achieving the result in a bit of simpler way.  In the common
 case of using the default admin site, it would be nice to just be able to
 change 1 settings.py configuration without worrying about subclassing.

 Since the current patch preserves backward compatibility, I viewed the
 fact that it applies globally to all admin site instances as a desired
 effect.  Selectively choosing individual admin site instance to have login
 handling enabled could then be achieved through sub-classing.

 However, I do understand if there is resistance to this idea.

-- 
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] #15756: Template regression with property lookups

[Django]

#15756: Template regression with property lookups
+
 Reporter:  Keryn Knight   | Owner:  nobody
 Type:  Bug |Status:  new
Milestone:  | Component:  Template system
  Version:  1.3 |  Severity:  Normal
 Keywords:  |  Triage Stage:  Unreviewed
Has patch:  0   |
+
 Whilst upgrading from 1.2.5 to 1.3, a colleague discovered a somewhat
 weird and problematic variable lookup issue in the template system. I've
 attempted to compress it down into a replicable test. I've tested this on
 Windows and Mac, both running Python 2.6 and Django 1.2.5 & 1.3

 {{{
 from django.template import Context, Template

 class A(object):
 name = 'A'
 def __init__(self, anything):
 ''' this is the crux of the problem? '''
 pass

 class B(A):
 name = u'B'


 class C(B):
 name = u'C'

 out = Template('{% for c in class_list %}{{ c.name }}{% endfor %}')

 # this works under 1.2.5, but not 1.3
 fail_list = (A, B, C)
 # this works under both.
 pass_list = (A(1), B(2), C(3))

 # using classes; expected historic output u'ABC', in 1.3 returns u''
 out.render(Context({'class_list': fail_list}))
 # using instantiated objects, always returns u'ABC'
 out.render(Context({'class_list': pass_list}))
 }}}

 Interestingly, if the __init__ method of the class doesn't take additional
 parameters (ie: remove the ''anything'' kwarg), it seems to be fine. I
 have absolutely no clue about the inner workings of the template compiler,
 but I'm presuming it does some sort of clever variable resolution that's
 changed in this edge case.

 Symptomatic of my ignorance of the templating voodoo is that I don't
 really know how to summarise the problem, so the title may be better
 expressed, and I may have missed pre-existing tickets for the same thing.

-- 
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] #3591: add support for custom app_label and verbose_name

[Django]

#3591: add support for custom app_label and verbose_name
-+
   Reporter:  jkocherhans|Owner:  adrian
   Type:  New feature|   Status:  reopened
  Milestone:  1.4|Component:  Core (Other)
Version:  SVN| Severity:  Normal
 Resolution: | Keywords:
   Triage Stage:  Fixed on a branch  |Has patch:  1
Needs documentation:  0  |  Needs tests:  0
Patch needs improvement:  0  |
-+
Changes (by sfllaw):

 * cc: sfllaw@… (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] #15755: Admin should allow for configurable login handling support

[Django]

#15755: Admin should allow for configurable login handling support
---+-
   Reporter:  metzen   |Owner:  nobody
   Type:  New feature  |   Status:  new
  Milestone:   |Component:  contrib.admin
Version:  SVN  | Severity:  Normal
 Resolution:   | Keywords:
   Triage Stage:  Unreviewed   |Has patch:  1
Needs documentation:  0|  Needs tests:  0
Patch needs improvement:  0|
---+-

Comment (by lrekucki):

 A global settings is not an option (you can have more then one admin
 instance). You can achieve exactly the same by overriding {{{login()}}}
 and/or {{{admin_view()}}} methods using a subclass of {{{AdminSite}}}.

-- 
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] #15721: {% include %} and RequestContext fails since r15795

[Django]

#15721: {% include %} and RequestContext fails since r15795
+---
   Reporter:  mk|Owner:  SmileyChris
   Type:  Bug   |   Status:  assigned
  Milestone:|Component:  Template system
Version:  1.3   | Severity:  Release blocker
 Resolution:| Keywords:
   Triage Stage:  Accepted  |Has patch:  1
Needs documentation:  0 |  Needs tests:  0
Patch needs improvement:  0 |
+---
Changes (by lukeplant):

 * keywords:  regression =>
 * severity:  Normal => Release 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] #7596: Multiple Database Inserts using 1 query

[Django]

#7596: Multiple Database Inserts using 1 query
-+-
   Reporter:  erikcw |Owner:  nobody
   Type: |   Status:  new
  Uncategorized  |Component:  Database layer
  Milestone: |  (models, ORM)
Version:  SVN| Severity:  Normal
 Resolution: | Keywords:  database, create,
   Triage Stage:  Accepted   |  multirow, feature
Needs documentation:  0  |Has patch:  0
Patch needs improvement:  0  |  Needs tests:  0
-+-
Changes (by sfllaw):

 * cc: sfllaw@… (added)
 * type:   => Uncategorized
 * severity:   => Normal


-- 
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] #15568: IntegrityError rises from test test_generic_key_deletion when it runs with the test test_generic_key_cross_database_protection for the INNODB

[Django]

#15568: IntegrityError rises from test test_generic_key_deletion when it runs 
with
the test test_generic_key_cross_database_protection for the INNODB
-+-
   Reporter: |Owner:  nobody
  rahul.priyadarshi@…|   Status:  reopened
   Type:  Bug|Component:  contrib.contenttypes
  Milestone: | Severity:  Normal
Version:  1.3-rc1| Keywords:
 Resolution: |Has patch:  0
   Triage Stage:  Accepted   |  Needs tests:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by anonymous):

 * component:  Database layer (models, ORM) => contrib.contenttypes


-- 
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] #13768: Bug in Django ORM when filtering with 'in' lookup and None in values list (1.1.x and 1.2.x)

[Django]

#13768: Bug in Django ORM when filtering with 'in' lookup and None in values 
list
(1.1.x and 1.2.x)
-+-
   Reporter:  chronos|Owner:  nobody
   Type:  Bug|   Status:  new
  Milestone:  1.3|Component:  Database layer
Version:  1.2|  (models, ORM)
 Resolution: | Severity:  Normal
   Triage Stage:  Accepted   | Keywords:  None, NULL, in,
Needs documentation:  0  |  postgres, postgresql
Patch needs improvement:  0  |Has patch:  0
 |  Needs tests:  0
-+-

Comment (by anonymous):

 #13579 is a 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] #15755: Admin should allow for configurable login handling support (was: Admin should allow for configurable support login handling)

[Django]

#15755: Admin should allow for configurable login handling support
---+-
   Reporter:  metzen   |Owner:  nobody
   Type:  New feature  |   Status:  new
  Milestone:   |Component:  contrib.admin
Version:  SVN  | Severity:  Normal
 Resolution:   | Keywords:
   Triage Stage:  Unreviewed   |Has patch:  1
Needs documentation:  0|  Needs tests:  0
Patch needs improvement:  0|
---+-
Changes (by metzen):

 * needs_docs:   => 0
 * needs_better_patch:   => 0
 * needs_tests:   => 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] #15755: Admin should allow for configurable support login handling

[Django]

#15755: Admin should allow for configurable support login handling
-+--
 Reporter:  metzen   | Owner:  nobody
 Type:  New feature  |Status:  new
Milestone:   | Component:  contrib.admin
  Version:  SVN  |  Severity:  Normal
 Keywords:   |  Triage Stage:  Unreviewed
Has patch:  1|
-+--
 In its current implementation, the contrib.admin application attempts to
 handle user authentication by displaying a login form for any request
 where the user does not have permission to view (either because they are
 unauthenticated, or their user account fails the is_active and is_staff
 test).

 In cases where authentication is being handled by an external system
 (e.g., Apache .htaccess or Google Accounts auth on App Engine), it can be
 confusing for users to see this login form when their account does not
 have permission to access the admin, as in some cases, the credentials
 they use might not correspond to what is stored in the Django auth table.

 I'd like to propose a configuration knob to allow the choice for whether
 the admin app attempts to perform user authentication at all, and instead
 just relies on all users to be pre-authenticated.

-- 
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] #15754: Сalling _media method many times while getting media value

[Django]

#15754: Сalling _media method many times while getting media value
--+---
 Reporter:  sakkada   | Owner:  nobody
 Type:  Cleanup/optimization  |Status:  new
Milestone:  1.3   | Component:  Forms
  Version:  1.3   |  Severity:  Normal
 Keywords:  media_property|  Triage Stage:  Unreviewed
Has patch:  1 |
--+---
 File '''django.forms.widgets.py''', function '''media_property''',
 subfunction '''_media''':

 {{{
 if hasattr(super(cls, self), 'media'):
 base = super(cls, self).media
 else:
 base = Media()
 }}}

 "media" attribute of class "cls" is created in the metaclass
 MediaDefiningClass from method "_media" decorated with "property", so when
 you call '''hasattr(super(cls, self), 'media')''', "_media" also calling
 (specifics of the "property"). That's why "_media" method (in property)
 calling many times, and the number of calls is growing exponentially as
 the number of ancestor classes. To prevent it, exclude 'hasattr' calls
 from code. Possible solution is

 {{{
 base = getattr(super(cls, self), 'media', None) or Media()
 }}}

 or

 {{{
 try:
 base = super(cls, self).media
 except AttributeError:
 base = Media()
 }}}

 IMHO, first solution better than using try/except.

-- 
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] #13201: Broken link in 0.96 template docs

[Django]

#13201: Broken link in 0.96 template docs
-+-
   Reporter: |Owner:  andymckay
  kcmarshall |   Status:  closed
   Type: |Component:  Djangoproject.com Web
  Uncategorized  |  site
  Milestone: | Severity:  Normal
Version:  0.96   | Keywords:  link
 Resolution:  wontfix|Has patch:  1
   Triage Stage:  Design |  Needs tests:  0
  decision needed|
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by lukeplant):

 * status:  new => closed
 * resolution:   => wontfix
 * type:   => Uncategorized
 * severity:   => Normal


Comment:

 0.96 docs are no longer online or supported.

-- 
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] #15753: test_simple_sitemap fails after executing test_requestsite_sitemap when Sites app and FetchFromCacheMiddleware are installed.

[Django]

#15753: test_simple_sitemap fails after executing test_requestsite_sitemap when
Sites app and FetchFromCacheMiddleware are installed.
--+
   Reporter:  lucho   |Owner:  nobody
   Type:  Bug |   Status:  new
  Milestone:  |Component:  contrib.sitemaps
Version:  1.3 | Severity:  Normal
 Resolution:  | Keywords:
   Triage Stage:  Unreviewed  |Has patch:  0
Needs documentation:  0   |  Needs tests:  0
Patch needs improvement:  0   |
--+
Changes (by lucho):

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


Comment:

 Sites = django.contrib.sites

-- 
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] #15753: test_simple_sitemap fails after executing test_requestsite_sitemap when Sites app and FetchFromCacheMiddleware are installed.

[Django]

#15753: test_simple_sitemap fails after executing test_requestsite_sitemap when
Sites app and FetchFromCacheMiddleware are installed.
---+-
 Reporter:  lucho  | Owner:  nobody
 Type:  Bug|Status:  new
Milestone: | Component:  contrib.sitemaps
  Version:  1.3|  Severity:  Normal
 Keywords: |  Triage Stage:  Unreviewed
Has patch:  0  |
---+-
 test_simple_sitemap fails after executing test_requestsite_sitemap when
 Sites app and FetchFromCacheMiddleware are installed.

 The error:

 {{{
 ==
  FAIL: test_simple_sitemap
 (django.contrib.sitemaps.tests.basic.SitemapTests)
  A simple sitemap can be rendered
  --
  Traceback (most recent call last):
File "/usr/local/lib/python2.6/dist-
 packages/Django-1.3-py2.6.egg/django/contrib/sitemaps/tests/basic.py",
 line 70, in test_simple_sitemap
  """ % (self.base_url, date.today().strftime('%Y-%m-%d')))
  AssertionError: '\nhttp://www.sitemaps.org/schemas/sitemap/0.9";>\nhttp://testserver/location/2011-04-04never0.5\n\n'
 != '\nhttp://www.sitemaps.org/schemas/sitemap/0.9";>\nhttp://example.com/location/2011-04-04never0.5\n\n'

 }}}


 The way to reproduce it:
 1. Use Sites app in your project
 2. Use FetchFromCacheMiddleware middleware in your project
 3. Run the sitemaps.SitemapTests suite

 The code that triggers the problem is this
 
[http://code.djangoproject.com/browser/django/trunk/django/contrib/sitemaps/tests/basic.py#L144]

 {{{
 # Which does that - setting the Site app as not installed and requesting
 the url
 Site._meta.installed = False
 response = self.client.get('/simple/sitemap.xml')
 }}}

 If I execute the test case separate (./manage.py test
 sitemaps.SitemapTests.test_simple_sitemap) no error is observed, but
 executing the whole test suite leads to error in test_simple_sitemap which
 is executed right after the test_requestsite_sitemap.

 If I comment out the test_requestsite_sitemap, no problem is observed.
 If I '''don't use (comment out) FetchFromCacheMiddleware''', no problem is
 observed.

 This makes me think that it is some problem related to caching.

-- 
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] #15752: test_simple_sitemap fails after executing test_requestsite_sitemap when Sites app is installed

[Django]

#15752: test_simple_sitemap fails after executing test_requestsite_sitemap when
Sites app is installed
--+
   Reporter:  lucho   |Owner:  nobody
   Type:  Bug |   Status:  closed
  Milestone:  |Component:  contrib.sitemaps
Version:  1.3 | Severity:  Normal
 Resolution:  invalid | Keywords:
   Triage Stage:  Unreviewed  |Has patch:  0
Needs documentation:  0   |  Needs tests:  0
Patch needs improvement:  0   |
--+
Changes (by lucho):

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


-- 
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] #13008: @never_cache decorator should add 'no-cache' & 'must-revalidate'

[Django]

#13008: @never_cache decorator should add  'no-cache' & 'must-revalidate'
+---
   Reporter:  harm  |Owner:  nobody
   Type:  Bug   |   Status:  new
  Milestone:|Component:  Core (Cache system)
Version:  1.2-beta  | Severity:  Normal
 Resolution:| Keywords:
   Triage Stage:  Accepted  |Has patch:  0
Needs documentation:  0 |  Needs tests:  1
Patch needs improvement:  0 |
+---
Changes (by lukeplant):

 * type:   => Bug
 * severity:   => Normal


Comment:

 @kmtracey - I just realised, we don't see those annoying pages about not
 being able to view the page because they happen when the page has been set
 to never cache/store AND was the result of a POST. Since we always re-
 direct after a POST in Django admin, we don't see those pages, and the web
 browser is happy to silently re-request the page, since the pages in
 history are always the result of GET requests. Well done us!

-- 
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] #2705: [patch] Add optional FOR UPDATE clause to QuerySets

[Django]

#2705: [patch] Add optional FOR UPDATE clause to QuerySets
-+-
   Reporter:  Hawkeye|Owner:  brunobraga
   Type:  New|   Status:  assigned
  feature|Component:  Database layer
  Milestone: |  (models, ORM)
Version:  SVN| Severity:  Normal
 Resolution: | Keywords:
   Triage Stage:  Accepted   |Has patch:  1
Needs documentation:  0  |  Needs tests:  0
Patch needs improvement:  0  |
-+-

Comment (by danfairs):

 Replying to [comment:80 jacob]:
 > One nit: `docs/ref/models/querysets.txt` claims:
 >

 ...

 > But `docs/ref/databases.txt` claims:
 >
 >MySQL does not support the ``NOWAIT`` option to the ``SELECT ... FOR
 UPDATE``
 >statement. However, you may call the ``select_for_update()`` method
 of a
 >queryset with ``nowait=True``. In that case, the argument will be
 silently
 >discarded and the generated query will block until the requested lock
 can be
 >acquired.

 ...

 >
 > These don't agree, and looking at the code it appears the first claim is
 correct. So something needs to be updated there.

 Ah, good spot. We changed the behaviour of using select_for_update on
 backends which don't support NOWAIT from a silent failure to raising a
 DatabaseError a while back. Looks like I failed to update the docs. I'll
 amend the patch (together with Carl's comments).

 >
 > Otherwise looks RFC to me.

 Great.

-- 
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] #2705: [patch] Add optional FOR UPDATE clause to QuerySets

[Django]

#2705: [patch] Add optional FOR UPDATE clause to QuerySets
-+-
   Reporter:  Hawkeye|Owner:  brunobraga
   Type:  New|   Status:  assigned
  feature|Component:  Database layer
  Milestone: |  (models, ORM)
Version:  SVN| Severity:  Normal
 Resolution: | Keywords:
   Triage Stage:  Accepted   |Has patch:  1
Needs documentation:  0  |  Needs tests:  0
Patch needs improvement:  0  |
-+-

Comment (by danfairs):

 Replying to [comment:79 carljm]:
 > Have you run the full test suite with this patch applied, at least on
 the commonly-available DB backends where the suite takes reasonable time
 (SQLite, Postgres)?

 Yes - well, I had done towards the end of last week! I'll update to
 current Django trunk, rerun before and after on all backends, and make
 sure that there are no more failures with the patch than without.

 >
 > There's a "select_related" where it should be "select_for_update" in the
 documentation section of this patch.

 Good spot - I'll fix that.

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

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

Re: [Django] #15752: test_simple_sitemap fails after executing test_requestsite_sitemap when Sites app is installed

[Django]

#15752: test_simple_sitemap fails after executing test_requestsite_sitemap when
Sites app is installed
--+
   Reporter:  lucho   |Owner:  nobody
   Type:  Bug |   Status:  new
  Milestone:  |Component:  contrib.sitemaps
Version:  1.3 | Severity:  Normal
 Resolution:  | Keywords:
   Triage Stage:  Unreviewed  |Has patch:  0
Needs documentation:  0   |  Needs tests:  0
Patch needs improvement:  0   |
--+
Changes (by lucho):

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


Comment:

 If I comment out the test_requestsite_sitemap, no problem is observed.

-- 
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] #15752: test_simple_sitemap fails after executing test_requestsite_sitemap when Sites app is installed

[Django]

#15752: test_simple_sitemap fails after executing test_requestsite_sitemap when
Sites app is installed
---+-
 Reporter:  lucho  | Owner:  nobody
 Type:  Bug|Status:  new
Milestone: | Component:  contrib.sitemaps
  Version:  1.3|  Severity:  Normal
 Keywords: |  Triage Stage:  Unreviewed
Has patch:  0  |
---+-
 test_simple_sitemap fails after executing test_requestsite_sitemap when
 Sites app is installed.

 {{{
  ==
  FAIL: test_simple_sitemap
 (django.contrib.sitemaps.tests.basic.SitemapTests)
  A simple sitemap can be rendered
  --
  Traceback (most recent call last):
File "/usr/local/lib/python2.6/dist-
 packages/Django-1.3-py2.6.egg/django/contrib/sitemaps/tests/basic.py",
 line 70, in test_simple_sitemap
  """ % (self.base_url, date.today().strftime('%Y-%m-%d')))
  AssertionError: '\nhttp://www.sitemaps.org/schemas/sitemap/0.9";>\nhttp://testserver/location/2011-04-04never0.5\n\n'
 != '\nhttp://www.sitemaps.org/schemas/sitemap/0.9";>\nhttp://example.com/location/2011-04-04never0.5\n\n'

 }}}

 If I execute the test case separate (./manage.py test
 sitemaps.SitemapTests.test_simple_sitemap) no error is observed, but
 executing the whole test suite leads to error in test_simple_sitemap which
 is executed right after the test_requestsite_sitemap.

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

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

[Changeset] r16015 - django/trunk/django/contrib/gis/db/backends/postgis

[noreply]

Author: adrian
Date: 2011-04-04 08:43:56 -0700 (Mon, 04 Apr 2011)
New Revision: 16015

Modified:
   django/trunk/django/contrib/gis/db/backends/postgis/creation.py
Log:
Fixed geodjango postgis/creation.py to use postgresql_psycopg2 instead of 
legacy postgresql module that was removed recently

Modified: django/trunk/django/contrib/gis/db/backends/postgis/creation.py
===
--- django/trunk/django/contrib/gis/db/backends/postgis/creation.py 
2011-04-04 12:39:21 UTC (rev 16014)
+++ django/trunk/django/contrib/gis/db/backends/postgis/creation.py 
2011-04-04 15:43:56 UTC (rev 16015)
@@ -1,5 +1,5 @@
 from django.conf import settings
-from django.db.backends.postgresql.creation import DatabaseCreation
+from django.db.backends.postgresql_psycopg2.creation import DatabaseCreation
 
 class PostGISCreation(DatabaseCreation):
 geom_index_type = 'GIST'

-- 
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] #15751: test_requestsite_sitemap in SitemapTests is setting Site._meta.installed to False permanently

[Django]

#15751: test_requestsite_sitemap in SitemapTests is setting 
Site._meta.installed to
False permanently
-+-
   Reporter:  lucho  |Owner:  nobody
   Type:  Bug|   Status:  closed
  Milestone: |Component:  contrib.sitemaps
Version:  1.3| Severity:  Normal
 Resolution:  invalid| Keywords:
   Triage Stage: |  test_requestsite_sitemap
  Unreviewed |Has patch:  0
Needs documentation:  0  |  Needs tests:  0
Patch needs improvement:  0  |
-+-
Changes (by lucho):

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


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

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

Re: [Django] #15102: find_template returns compiled Template object instead of template source

[Django]

#15102: find_template returns compiled Template object instead of template 
source
-+-
   Reporter:  vmanchev   |Owner:  vmanchev
   Type: |   Status:  assigned
  Uncategorized  |Component:  Template system
  Milestone: | Severity:  Normal
Version:  1.3| Keywords:  find_template
 Resolution: |  template source
   Triage Stage:  Design |Has patch:  1
  decision needed|  Needs tests:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by adamnfish):

 * version:  1.2 => 1.3
 * type:   => Uncategorized
 * severity:   => Normal


Comment:

 The problem with dropping support for fetching just the template's source
 is that it makes it much harder to integrate another template language
 into projects. If find_template_source exists, we can use it to fetch
 templates in a way that is well documented without having to resort to
 additional settings or duplication of Django's code. The key is that
 developers should be able to specify the correct Loaders and customise
 their template locations in a template-agnostic fashion.

 For developers who created their projects prior to v1.2, the auto-
 generated TEMPLATE_LOADERS setting has always pointed at the old (now
 deprecated) loader and only now, having upgraded to Django 1.3 are they a)
 seeing loud deprecation warnings and b) finding that these warnings cannot
 easily be worked around!

 The new implementation couples the Loader classes to Django's Template
 object in line 48 of loader.py (1.3 tag) `template =
 get_template_from_string(source, origin, template_name)`. This is a real
 shame, because Django has cleverly fetched the source and template_name
 which is exactly what is needed to integrate another template language!

 I agree that altering `find_template`'s signature doesn't feel like the
 correct approach - ideally `find_template_source` will make a re-
 appearance. It could use the `load_template_source` method of each Loader
 defined in the settings to fetch the actual source without creating a
 Django Template object.

 I also think that the variables should be renamed to properly reflect
 whether they refer to the source (a string or string-like-object
 representing the template's source code) or a template instance (a Django
 template object with a render method). This is a very important
 distinction but it is very hard to tell the difference for a given
 location by looking at Django's source code. (one has to follow the
 variable all the way up the call chain to check if
 `get_template_from_string` has already been called on it!)

 Let me know if this sounds sensible and I can look into implementing these
 changes.

-- 
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] #2705: [patch] Add optional FOR UPDATE clause to QuerySets

[Django]

#2705: [patch] Add optional FOR UPDATE clause to QuerySets
-+-
   Reporter:  Hawkeye|Owner:  brunobraga
   Type:  New|   Status:  assigned
  feature|Component:  Database layer
  Milestone: |  (models, ORM)
Version:  SVN| Severity:  Normal
 Resolution: | Keywords:
   Triage Stage:  Accepted   |Has patch:  1
Needs documentation:  0  |  Needs tests:  0
Patch needs improvement:  0  |
-+-

Comment (by jacob):

 One nit: `docs/ref/models/querysets.txt` claims:

   Passing ``nowait=True`` to ``select_for_update`` using database backends
 that
   do not support ``nowait``, such as MySQL, will cause a ``DatabaseError``
 to be
   raised. This is in order to prevent code unexpectedly blocking.

 But `docs/ref/databases.txt` claims:

MySQL does not support the ``NOWAIT`` option to the ``SELECT ... FOR
 UPDATE``
statement. However, you may call the ``select_for_update()`` method of
 a
queryset with ``nowait=True``. In that case, the argument will be
 silently
discarded and the generated query will block until the requested lock
 can be
acquired.

 These don't agree, and looking at the code it appears the first claim is
 correct. So something needs to be updated there.

 Otherwise looks RFC to me.

-- 
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] #12792: admin templates get wrong perms on installation in 1.1.1 tarball

[Django]

#12792: admin templates get wrong perms on installation in 1.1.1 tarball
-+-
   Reporter:  tjboring   |Owner:  nobody
   Type: |   Status:  closed
  Uncategorized  |Component:  Template system
  Milestone: | Severity:  Normal
Version:  1.1| Keywords:  templates,
 Resolution:  needsinfo  |  installation
   Triage Stage:  Accepted   |Has patch:  0
Needs documentation:  0  |  Needs tests:  0
Patch needs improvement:  0  |
-+-
Changes (by lukeplant):

 * status:  new => closed
 * resolution:   => needsinfo
 * type:   => Uncategorized
 * severity:   => Normal


-- 
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] #15751: test_requestsite_sitemap in SitemapTests is setting Site._meta.installed to False permanently

[Django]

#15751: test_requestsite_sitemap in SitemapTests is setting 
Site._meta.installed to
False permanently
--+-
 Reporter:  lucho | Owner:  nobody
 Type:  Bug   |Status:  new
Milestone:| Component:  contrib.sitemaps
  Version:  1.3   |  Severity:  Normal
 Keywords:  test_requestsite_sitemap  |  Triage Stage:  Unreviewed
Has patch:  0 |
--+-
 test_requestsite_sitemap in SitemapTests is setting Site._meta.installed
 to False permanently -
 
[http://code.djangoproject.com/browser/django/trunk/django/contrib/sitemaps/tests/basic.py#L147]

 This prevents the remaining tests in the suit to be executed correct, when
 django.contrib.sites is installed app.

 The observed result: SitemapTests.test_simple_sitemap failed.

 {{{
 ==
 FAIL: test_simple_sitemap
 (django.contrib.sitemaps.tests.basic.SitemapTests)
 A simple sitemap can be rendered
 --
 Traceback (most recent call last):
   File "/usr/local/lib/python2.6/dist-
 packages/Django-1.3-py2.6.egg/django/contrib/sitemaps/tests/basic.py",
 line 70, in test_simple_sitemap
 """ % (self.base_url, date.today().strftime('%Y-%m-%d')))
 AssertionError: '\nhttp://www.sitemaps.org/schemas/sitemap/0.9";>\nhttp://testserver/location/2011-04-04never0.5\n\n'
 != '\nhttp://www.sitemaps.org/schemas/sitemap/0.9";>\nhttp://example.com/location/2011-04-04never0.5\n\n'

 }}}


 The problem: setUp determines incorrect the base_url, because
 Site._meta.installed was set permanently to False in
 test_requestsite_sitemap and never set back to correct value.

 
[http://code.djangoproject.com/browser/django/trunk/django/contrib/sitemaps/tests/basic.py#L18]
 {{{
 def setUp(self):
 if Site._meta.installed:
 self.base_url = 'http://example.com'
 else:
 self.base_url = 'http://testserver'
 }}}

-- 
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] #15727: out of the box support for CSP would totally rock!

[Django]

#15727: out of the box support for CSP would totally rock!
-+-
   Reporter:  db.pub.mail@…  |Owner:  nobody
   Type:  New feature|   Status:  new
  Milestone: |Component:  HTTP handling
Version:  1.2| Severity:  Normal
 Resolution: | Keywords:
   Triage Stage:  Someday/Maybe  |Has patch:  0
Needs documentation:  0  |  Needs tests:  0
Patch needs improvement:  0  |
-+-

Comment (by lukeplant):

 Replying to [comment:5 d1b]:
 > a new template tag could be added to transform inline js into js
 included and served from a given location(that the CSP policy allows).

 Sounds wonderful! Patch welcome :-)

 (To explain what may not come over well on Trac: I'm implying that there
 are multiple significant problems with this suggestion that would need to
 be solved before it was practical. A solution to them isn't necessarily
 impossible, but will at least require quite a lot of work. What is written
 above is only one step away from saying "A new 'magic wand' feature could
 be added to Django that makes the problems with using CSP disappear, and
 then it would be sensible to add it". Indeed it would be...).


 > I sent an email reply but it was blocked :/


 I don't know what you mean by an email reply - all emails sent from Trac
 are from the 'nore...@djangoproject.com' address.

-- 
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] #2705: [patch] Add optional FOR UPDATE clause to QuerySets

[Django]

#2705: [patch] Add optional FOR UPDATE clause to QuerySets
-+-
   Reporter:  Hawkeye|Owner:  brunobraga
   Type:  New|   Status:  assigned
  feature|Component:  Database layer
  Milestone: |  (models, ORM)
Version:  SVN| Severity:  Normal
 Resolution: | Keywords:
   Triage Stage:  Accepted   |Has patch:  1
Needs documentation:  0  |  Needs tests:  0
Patch needs improvement:  0  |
-+-

Comment (by carljm):

 Replying to [comment:76 danfairs]:
 > OK - now 1.3 is out of the door, is there any chance this could be re-
 reviewed? The existing patch still applies to trunk (as of r15941) and the
 select_for_update tests pass on all backends.

 Have you run the full test suite with this patch applied, at least on the
 commonly-available DB backends where the suite takes reasonable time
 (SQLite, Postgres)?

 There's a "select_related" where it should be "select_for_update" in the
 documentation section of this 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] #15705: Localflavor for Croatia

[Django]

#15705: Localflavor for Croatia
-+-
   Reporter:  zmasek |Owner:  zmasek
   Type:  New|   Status:  new
  feature|Component:  contrib.localflavor
  Milestone: | Severity:  Normal
Version:  SVN| Keywords:  localflavor croatia
 Resolution: |Has patch:  1
   Triage Stage:  Ready for  |  Needs tests:  0
  checkin|
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-

Comment (by zmasek):

 Replying to [comment:3 julien]:
 > Thank you for your contribution!
 I'm considering adding another field for custom license plates. If I find
 it useful to have (as opposed to having an ordinary non-validated text
 input), should I make another ticket or add to this one?

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #15750: smtp.EmailBackend won't use empty username/password

[Django]

#15750: smtp.EmailBackend won't use empty username/password
--+---
   Reporter:  thialfihar  |Owner:  nobody
   Type:  Bug |   Status:  new
  Milestone:  |Component:  Core (Mail)
Version:  1.3-beta| Severity:  Normal
 Resolution:  | Keywords:
   Triage Stage:  Unreviewed  |Has patch:  0
Needs documentation:  0   |  Needs tests:  0
Patch needs improvement:  0   |
--+---
Changes (by thialfihar):

 * cc: thialfihar (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] #15750: smtp.EmailBackend won't use empty username/password (was: smtp.EmailBackend won't use non-empty username/password)

[Django]

#15750: smtp.EmailBackend won't use empty username/password
--+---
   Reporter:  thialfihar  |Owner:  nobody
   Type:  Bug |   Status:  new
  Milestone:  |Component:  Core (Mail)
Version:  1.3-beta| Severity:  Normal
 Resolution:  | Keywords:
   Triage Stage:  Unreviewed  |Has patch:  0
Needs documentation:  0   |  Needs tests:  0
Patch needs improvement:  0   |
--+---
Changes (by thialfihar):

 * needs_better_patch:   => 0
 * needs_docs:   => 0
 * needs_tests:   => 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] #15750: smtp.EmailBackend won't use non-empty username/password

[Django]

#15750: smtp.EmailBackend won't use non-empty username/password
+
 Reporter:  thialfihar  | Owner:  nobody
 Type:  Bug |Status:  new
Milestone:  | Component:  Core (Mail)
  Version:  1.3-beta|  Severity:  Normal
 Keywords:  |  Triage Stage:  Unreviewed
Has patch:  0   |
+
 Assuming settings.EMAIL_HOST_USER and/or settings.EMAIL_HOST_PASSWORD is
 non-empty, then something like this won't work:
 {{{
 connection = get_connection(host='mail.host.com', port=1234, username='',
 password='')
 send_mail(..., connection=connection)
 }}}
 Because !EmailBackend.!__init!__ does this:
 {{{
 self.username = username or settings.EMAIL_HOST_USER
 self.password = password or settings.EMAIL_HOST_PASSWORD
 }}}
 and therefore will default to settings.EMAIL_HOST_USER and
 settings.EMAIL_HOST_PASSWORD.

 And then !EmailBackend.open() will attempt SMTP authentication:
 {{{
 if self.username and self.password:
 self.connection.login(self.username, self.password)
 }}}

 A workaround to prevent the login then would be:
 {{{
 connection = get_connection(host='mail.host.com', port=1234)
 connection.username = '' # or None
 connection.password = '' # or None
 send_mail(..., connection=connection)
 }}}

 A possible fix might be in !EmailBackend.!__init!__:
 {{{
 if username is None:
 self.username = settings.EMAIL_HOST_USER
 else:
 self.username = username
 if password is None:
 self.password = settings.EMAIL_HOST_PASSWORD
 else:
 self.password = password
 }}}

 I'm not sure whether an empty string as username and password in order to
 prevent SMTP authentication is frowned upon and only None should be used.
 If that's the case, then perhaps !EmailBackend shouldn't use '''any'''
 defaults if, for instance, a different host is passed.

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

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

[Changeset] r16014 - django/trunk/django/views

[noreply]

Author: andrewgodwin
Date: 2011-04-04 05:39:21 -0700 (Mon, 04 Apr 2011)
New Revision: 16014

Modified:
   django/trunk/django/views/static.py
Log:
Fixed #15613: Don't send content-length headers for non-regular files. Thanks 
to jaylett.

Modified: django/trunk/django/views/static.py
===
--- django/trunk/django/views/static.py 2011-04-04 03:42:46 UTC (rev 16013)
+++ django/trunk/django/views/static.py 2011-04-04 12:39:21 UTC (rev 16014)
@@ -5,6 +5,7 @@
 
 import mimetypes
 import os
+import stat
 import posixpath
 import re
 import urllib
@@ -58,7 +59,8 @@
 return HttpResponseNotModified(mimetype=mimetype)
 response = HttpResponse(open(fullpath, 'rb').read(), mimetype=mimetype)
 response["Last-Modified"] = http_date(statobj.st_mtime)
-response["Content-Length"] = statobj.st_size
+if stat.S_ISREG(statobj.st_mode):
+response["Content-Length"] = statobj.st_size
 if encoding:
 response["Content-Encoding"] = encoding
 return response

-- 
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] #15721: {% include %} and RequestContext fails since r15795

[Django]

#15721: {% include %} and RequestContext fails since r15795
+---
   Reporter:  mk|Owner:  SmileyChris
   Type:  Bug   |   Status:  assigned
  Milestone:|Component:  Template system
Version:  1.3   | Severity:  Normal
 Resolution:| Keywords:  regression
   Triage Stage:  Accepted  |Has patch:  1
Needs documentation:  0 |  Needs tests:  0
Patch needs improvement:  0 |
+---
Changes (by d1b):

 * cc: d1b (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] #6526: Add remove/escape/replace functions to markdown filter

[Django]

#6526: Add remove/escape/replace functions to markdown filter
---+---
   Reporter:  taojian  |Owner:  nobody
   Type:  New feature  |   Status:  reopened
  Milestone:  1.4  |Component:  contrib.markup
Version:  SVN  | Severity:  Normal
 Resolution:   | Keywords:  markup markdown
   Triage Stage:  Accepted |Has patch:  1
Needs documentation:  1|  Needs tests:  1
Patch needs improvement:  1|
---+---
Changes (by d1b):

 * cc: d1b (added)
 * severity:   => Normal


-- 
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] #15749: Unable to set custom formatter class in LOGGING setting (dictConfig format)

[Django]

#15749: Unable to set custom formatter class in LOGGING setting (dictConfig 
format)
---+-
   Reporter:  marcel.dancak@…  |Owner:  nobody
   Type:  Bug  |   Status:  closed
  Milestone:   |Component:  Uncategorized
Version:  1.3  | Severity:  Normal
 Resolution:  invalid  | Keywords:
   Triage Stage:  Unreviewed   |Has patch:  0
Needs documentation:  0|  Needs tests:  0
Patch needs improvement:  0|
---+-
Changes (by kmtracey):

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


Comment:

 What you describe happening matches the Python doc, so I don't think this
 is a bug in Django. Per the docs for the
 [http://docs.python.org/library/logging.html#logging-config-dictschema
 dictConfig dictionary schema], 'class' is not a key searched for in the
 confuring dict for a formatter. Just 'format' and 'datefmt' are special
 for that config dictionary, and as documented a logging.Formatter instance
 is created. The docs do mention "custom instantiation"; you may want the
 special key '()' in place of where you have 'class', see the docs here:
 http://docs.python.org/library/logging.html#dictionary-schema-details
 (though I have not played with this myself, so I am not entirely sure if
 '()' can be used directly in place of where you have 'class').

-- 
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] #13751: Avoid open redirect issue with whitelist

[Django]

#13751: Avoid open redirect issue with whitelist
-+-
   Reporter:  anonymous  |Owner:  nobody
   Type:  New|   Status:  new
  feature|Component:  HTTP handling
  Milestone:  1.3| Severity:  Normal
Version:  SVN| Keywords:  open redirect,
 Resolution: |  security
   Triage Stage:  Accepted   |Has patch:  1
Needs documentation:  0  |  Needs tests:  0
Patch needs improvement:  1  |
-+-
Changes (by d1b):

 * cc: d1b (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] #14808: i18n is not safe.

[Django]

#14808: i18n is not safe.
+---
   Reporter:  steveire  |Owner:  nobody
   Type:  Bug   |   Status:  new
  Milestone:|Component:  Template system
Version:  1.2   | Severity:  Normal
 Resolution:| Keywords:
   Triage Stage:  Accepted  |Has patch:  0
Needs documentation:  0 |  Needs tests:  0
Patch needs improvement:  0 |
+---
Changes (by d1b):

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

[Django]

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

 * cc: andybak (added)
 * type:   => Uncategorized
 * severity:   => Normal


-- 
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] #7025: SafeUnicode.split() should return a list of SafeUnicode objects

[Django]

#7025: SafeUnicode.split() should return a list of SafeUnicode objects
---+
   Reporter:  guettli  |Owner:  nobody
   Type:  New feature  |   Status:  closed
  Milestone:   |Component:  Core (Other)
Version:  SVN  | Severity:  Normal
 Resolution:  wontfix  | Keywords:
   Triage Stage:  Accepted |Has patch:  1
Needs documentation:  0|  Needs tests:  0
Patch needs improvement:  1|
---+
Changes (by guettli):

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


Comment:

 I (the original author of this ticket) will close this again:
 safestring.splitlines() ist not safe! Your content could include
 CDATA sections with newlines. Please leave this closed.

-- 
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] #15693: Support broken for custom widgets in inlines Jquery based Add new

[Django]

#15693: Support broken for custom widgets in inlines Jquery based Add new 
--+-
   Reporter:  brillgen|Owner:  nobody
   Type:  Bug |   Status:  closed
  Milestone:  |Component:  contrib.admin
Version:  1.2 | Severity:  Normal
 Resolution:  needsinfo   | Keywords:
   Triage Stage:  Unreviewed  |Has patch:  0
Needs documentation:  0   |  Needs tests:  0
Patch needs improvement:  0   |
--+-
Changes (by julien):

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


Comment:

 This report is a bit too vague. If you're experiencing an issue, please
 reopen and provide a more detailed use case, or even better some code we
 can test. Also, it'd be useful if you could track when (if) this actually
 got broken.

-- 
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] #15749: Unable to set custom formatter class in LOGGING setting (dictConfig format)

[Django]

#15749: Unable to set custom formatter class in LOGGING setting (dictConfig 
format)
-+--
 Reporter:  marcel.dancak@…  | Owner:  nobody
 Type:  Bug  |Status:  new
Milestone:   | Component:  Uncategorized
  Version:  1.3  |  Severity:  Normal
 Keywords:   |  Triage Stage:  Unreviewed
Has patch:  0|
-+--
 Following logging configuration in settings.py does ignore 'class'
 parameter and creates logging.Formatter instance:
 {{{
 LOGGING = {
 'version': 1,
 'formatters': {
 'colored': {
 'class': 'myproject.logging.ColoredFormatter',
 'format': '%(levelname).1s: [%(asctime)s] %(message)s
 (%(name)s)',
 'datefmt': '%H:%M:%S'
 }
 },
 ...
 }
 }}}

 In previous Django versions without logging support I was successfully
 loading configuration with logging.config.fileConfig function, where
 configuration file contained following lines:

 {{{
 [formatter_coloredFormatter]
 class=myproject.logging.ColoredFormatter
 format=%(levelname).1s: [%(asctime)s] %(message)s (%(name)s)
 datefmt=%H:%M:%S
 }}}

 So I guess dictConfig format should allow to configure the same parameters
 as other methods and therefore it should be a bug. Because I'm using
 Python 2.5.2, I'm not sure if this is problem of Python's builtin logging
 module or in Django (if you did some modifications to make it compatible
 with older Python versions), so I rather report it here.

 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.