[Django] #9447: ifequal should be chainable(and,or)

[Django]

#9447: ifequal should be chainable(and,or)
+---
 Reporter:  [EMAIL PROTECTED]  |   Owner:  nobody
   Status:  new |   Milestone:
Component:  Template system | Version:  1.0   
 Keywords:  ifequal,and,or  |   Stage:  Unreviewed
Has_patch:  0   |  
+---
 The {% if %} tag supports '''and''' and '''or''' - it'd be handy if {%
 ifequal %} did as well.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #9446: Apparent discrepancy between online documentation and how the code works for custom File Storage system

[Django]

#9446: Apparent discrepancy between online documentation and how the code works
for custom File Storage system
-+--
 Reporter:  xhad |   Owner:  nobody
   Status:  new  |   Milestone:  post-1.0  
Component:  Documentation| Version:  SVN   
 Keywords:  file storage, documentation  |   Stage:  Unreviewed
Has_patch:  0|  
-+--
 The online documentation for writing custom File Storage systems says that
 the {{{_save}}} method must be overridden and "No return value is
 expected." (http://docs.djangoproject.com/en/dev/howto/custom-file-storage
 /#save-name-content).

 However, the inherited {{{save}}} method in
 {{{django/core/files/storage.py}}} contains these lines (45-48):
 {{{
 name = self._save(name, content)

 # Store filenames with forward slashes, even on Windows
 return force_unicode(name.replace('\\', '/'))
 }}}
 The obvious problem is that returning nothing from the {{{_save}}} method
 causes the last line to throw an error like this:
 {{{
 AttributeError: 'NoneType' object has no attribute 'replace'
 }}}

 From what I can tell, the documentation should state that the {{{_save}}}
 method should be implemented so that it returns the name of the file that
 was written to in the end.  This seems to be consistent with how the code
 is really implemented and how the {{{FileSystemStorage}}} class is
 implemented in the same file.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #9445: New contrib - django-install

[Django]

#9445: New contrib - django-install
---+
 Reporter:  italomaia  |   Owner:  nobody
   Status:  new|   Milestone:  post-1.0  
Component:  Uncategorized  | Version:  1.0   
 Keywords:  new contrib|   Stage:  Unreviewed
Has_patch:  0  |  
---+
 I would like to suggest a new contrib to django. This contrib should allow
 someone to add a app to a existing project, on-the-fly, right through a
 web interface. That would be a big differecial for the project, and would
 make the whole "working with django" thing a lot easier. With '''django-
 install''', django would became '''REALLY pluggable'''. Here are the
 details i made some nights ago:[[BR]]

 {{{
 It should let people add apps to django on the fly! With the real deal
 running, while you add your app, and more,
 it should let you configure the app! I was thinking, why INSTALLED_APPS is
 within settings.py?
 It '''doesn't have to be there''', and more, it would be better if it
 wasn't! It should go in a sweet .py(maybe a yaml) file where a nice,
 friend of everybody, contrib could mess up on it's own, add apps and
 stuff. Apps should get a default template
 to became pluggable, like have a configuration file of its own and pre-
 defined urls and template configuration.

 And more! This new contrib, should be able to edit the apps urls as well,
 on the fly,
 so, one would be able to add his apps, configure the project template
 folders and edit the urls all nice and just start working.
 It would became kind of a lego play. You create the project, add the apps,
 configure them, and there, you would have a
 django project up and running.

 One more details, it should be required from apps to have a special file
 called app_settings.py, where the app settings would go.
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #6095: Add the ability to manually create M2M intermediary models

[Django]

#6095: Add the ability to manually create M2M intermediary models
---+
  Reporter:  jacob | Owner:  floguy  
Status:  closed| Milestone:  1.0 beta
 Component:  Database layer (models, ORM)  |   Version:  SVN 
Resolution:  fixed |  Keywords:  
 Stage:  Accepted  | Has_patch:  1   
Needs_docs:  1 |   Needs_tests:  0   
Needs_better_patch:  1 |  
---+
Changes (by micsco):

 * cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL 
PROTECTED],
 [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],
 [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],
 [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],
 [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],
 jshaffer, dan90, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],
 apollo13, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],
 christian, [EMAIL PROTECTED], [EMAIL PROTECTED], mmalone (removed)

Comment:

 [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],
 [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],
 [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],
 [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],
 [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],
 jshaffer, dan90, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],
 apollo13, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],
 christian, [EMAIL PROTECTED], [EMAIL PROTECTED], mmalone

 Removed the above addresses as this ticket is closed and spam is
 attacking, if anyone has any issues add yourself back :).

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #9444: [1.1 Pony] AnonymousUser that you can set specific permissions for

[Django]

#9444: [1.1 Pony] AnonymousUser that you can set specific permissions for
--+-
 Reporter:  Digitalxero   |   Owner:  nobody
   Status:  new   |   Milestone:  post-1.0  
Component:  Authentication| Version:  1.0   
 Keywords:  Feature Request, Version 1.1  |   Stage:  Unreviewed
Has_patch:  1 |  
--+-
 The reason for this patch is because I do not like having to special case
 permissions for the AnonymousUser for every model I wish to allow them
 access to.

 I am working on an ACL that has no concept of User per say, it is using a
 generic relationship to maintain a list of subjects and objects that it
 controls, so subject and object can be any Model. In the ACL you will
 primarily use it for Users and Groups as subject and other models as
 objects, but you could potentially restrict one Models access to another
 (why I dont know but you can).

 The fact that the AnonymousUser has no model makes it impossible for me to
 add them as a subject to my ACL, or for any other permissions system to
 manage them other then special casing. Special casing is all well and good
 when you are not doing Row level permissions, as there are not going to be
 that many special cases, but once you start getting into row level
 permissions there could potentially be hundreds (or thousands) of cases
 when I would need to do special casing just for the AnonymousUser, which
 is very un-DRY (IMHO)

 This patch allows the creation of a user with the username
 BuiltinDjangoAnonymousUser, and will return an instance of that User (if
 it exists) instead of the AnonymousUser class. I added checking in the
 actual user model for this special user so that it will still return the
 proper values for is_authenticated, and is_anonymous, and so that noone
 could login as the special anonymous user. I also added a management
 command to create the new Anonymous User, and a signal listener to ask if
 you want to create one when you first install the Auth app.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #8593: Image upload in Windows changes filename to lowercase

[Django]

#8593: Image upload in Windows changes filename to lowercase
---+
  Reporter:  robvdl| Owner:  nobody 
   
Status:  new   | Milestone: 
   
 Component:  File uploads/storage  |   Version:  1.0
   
Resolution:|  Keywords:  upload image 
lowercase
 Stage:  Accepted  | Has_patch:  0  
   
Needs_docs:  0 |   Needs_tests:  0  
   
Needs_better_patch:  0 |  
---+
Comment (by kmtracey):

 #9442 was a dup, it also has a suggested fix.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9442: django/utils/os_py -> safe_join converts file name to lower case when it is a bad idea and this causes incompatibilities with windows / linux

[Django]

#9442: django/utils/os_py -> safe_join converts file name to lower case when it 
is
a bad idea and this causes incompatibilities with windows / linux
---+
  Reporter:  dawidjoubert  | Owner:  nobody
Status:  closed| Milestone:
 Component:  File uploads/storage  |   Version:  1.0   
Resolution:  duplicate |  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by kmtracey):

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

Comment:

 #8593 already reports this.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9436: New documentations patches are inconsistent with contributing.txt

[Django]

#9436: New documentations patches are inconsistent with contributing.txt
+---
  Reporter:  telenieko  | Owner:  telenieko
Status:  assigned   | Milestone:   
 Component:  Documentation  |   Version:  SVN  
Resolution: |  Keywords:   
 Stage:  Ready for checkin  | Has_patch:  1
Needs_docs:  0  |   Needs_tests:  0
Needs_better_patch:  0  |  
+---
Changes (by telenieko):

  * status:  new => assigned
  * needs_better_patch:  => 0
  * needs_tests:  => 0
  * version:  1.0 => SVN
  * owner:  nobody => telenieko
  * needs_docs:  => 0
  * has_patch:  0 => 1
  * stage:  Unreviewed => Ready for checkin

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #9443: get_url not returning correct URL on Windows platforms

[Django]

#9443: get_url not returning correct URL on Windows platforms
---+
 Reporter:  dawidjoubert   |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Uncategorized  | Version:  1.0   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 When calling the attribute .url on an ImageField() while running on
 Windows where the MEDIA_ROOT is = 'X:/sss' the url returned is incorrect.

 The reason is because in
 django.core.files.storage.FileSystemStorage.url(self, name) ( file
 django/core/files/storage.py line 213 ) the function urlparse.urljoin is
 called as such:

 return urlparse.urljoin(self.base_url, name).replace('\\', '/')

 For the test case self.base_url = 'http://static.klettings.dev/' and name
 = 'Z:\htdocs\uploads\54286.jpg' which returns a value of
 'Z:/htdocs/uploads/CIMG1335.JPG' instead of
 'http://static.klettings.dev/uploads/CIMG1335.JPG'

 The fix / patch for this is:

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9443: get_url not returning correct URL on Windows platforms

[Django]

#9443: get_url not returning correct URL on Windows platforms
+---
  Reporter:  dawidjoubert   | Owner:  nobody
Status:  closed | Milestone:
 Component:  Uncategorized  |   Version:  1.0   
Resolution:  invalid|  Keywords:
 Stage:  Accepted   | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by dawidjoubert):

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

Comment:

 Shit wrong bug report.

 Some admin please delete this.

 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #9442: django/utils/os_py -> safe_join converts file name to lower case when it is a bad idea and this causes incompatibilities with windows / linux

[Django]

#9442: django/utils/os_py -> safe_join converts file name to lower case when it 
is
a bad idea and this causes incompatibilities with windows / linux
--+-
 Reporter:  dawidjoubert  |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  File uploads/storage  | Version:  1.0   
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 Overview:
 The function safe_join() is called throughout the django code base to
 safely join a base path with other paths inbetween and returns a
 normalised absolute version of the final path.

 Bug:
 It calls an underlying function normcase() to normalise the path wich
 converts the case of the path to all lower case where Python is run in a
 windows environment. This works all happy chappy where the underlying file
 system is case insensitive but causes havoc where the underlying file
 system is actually a mapped network drive.

 The solution:
 Replacing normcase() with normpath() gives all the usual benefits of
 normcase() but without the case conversion

 More Motivation:
 Quite frankly it is a horrible horrible idea for the name under which the
 field is saved in the database to differ from the name under which it is
 saved on hard disk. Even on an all Windows setup there could be major
 headaches where infrastructure want to perhaps move static files onto
 their own server and decide to use linux to do so.

 Plainly put: If the file name is saved as 'uploads/CIMG1335.jpg' in the
 database then the file name on the hard drive must be exactly
 uploads/CIMG1335.jpg with the only exception possibly being made that the
 brackets can be convert to '\\' when working on the Windows platform.

 My recommendation:
 Replace normcase() with normpath() in django.utils._os.py

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #9441: wrong settings control referred to in "file uploads" doc

[Django]

#9441: wrong settings control referred to in "file uploads" doc
---+
 Reporter:  gsf|   Owner:  nobody
   Status:  new|   Milestone:
Component:  Documentation  | Version:  SVN   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 Typo there.  Patch attached.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #9440: GMarker icon personalization feature in django.contrib.gis.maps.google

[Django]

#9440: GMarker icon personalization feature in django.contrib.gis.maps.google
-+--
   Reporter:  aromano|Owner:  nobody
 Status:  new|Milestone:
  Component:  Uncategorized  |  Version:  1.0   
   Keywords: |Stage:  Unreviewed
  Has_patch:  1  |   Needs_docs:  0 
Needs_tests:  0  |   Needs_better_patch:  0 
-+--
 Hi all,
 I found it great to have an integrate Google Maps support into Django.
 However, these modules still do not feature the chance to personalize a
 GMarker using your own icons, so I have fixed this by adding such a
 feature into my version. In order to do this, I had to change two files
 (django/contrib/gis/maps/google/overlays.py and
 django/contrib/gis/templates/gis/google/js/google-map.js). The patches are
 attached here to this ticket. Feel free to do whatever you want with them.

 Thank you all,
 Angelo Romano

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9438: Integrate django-testmaker functionality into Django

[Django]

#9438: Integrate django-testmaker functionality into Django
+---
  Reporter:  ericholscher   | Owner:  ericholscher
Status:  new| Milestone:  
 Component:  Testing framework  |   Version:  1.0 
Resolution: |  Keywords:  
 Stage:  Unreviewed | Has_patch:  0   
Needs_docs:  0  |   Needs_tests:  0   
Needs_better_patch:  0  |  
+---
Changes (by ericholscher):

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

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9439: Broken links in comment moderation templates

[Django]

#9439: Broken links in comment moderation templates
--+-
  Reporter:  neithere | Owner:  nobody
Status:  new  | Milestone:
 Component:  django.contrib.comments  |   Version:  SVN   
Resolution:   |  Keywords:
 Stage:  Unreviewed   | Has_patch:  1 
Needs_docs:  0|   Needs_tests:  0 
Needs_better_patch:  0|  
--+-
Changes (by neithere):

  * needs_better_patch:  => 0
  * has_patch:  0 => 1
  * 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #9439: Broken links in comment moderation templates

[Django]

#9439: Broken links in comment moderation templates
-+--
 Reporter:  neithere |   Owner:  nobody
   Status:  new  |   Milestone:
Component:  django.contrib.comments  | Version:  SVN   
 Keywords:   |   Stage:  Unreviewed
Has_patch:  0|  
-+--
 Some templates contain references to a non-existent `permalink` attribute
 of the Comment model instead of the actual `get_absolute_url`:

   -
 source:django/trunk/django/contrib/comments/templates/comments/approve.html
   -
 source:django/trunk/django/contrib/comments/templates/comments/delete.html
   -
 source:django/trunk/django/contrib/comments/templates/comments/flag.html

 This results in broken "cancel" links.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #9438: Integrate django-testmaker functionality into Django

[Django]

#9438: Integrate django-testmaker functionality into Django
---+
 Reporter:  ericholscher   |   Owner:  ericholscher
   Status:  new|   Milestone:  
Component:  Testing framework  | Version:  1.0 
 Keywords: |   Stage:  Unreviewed  
Has_patch:  0  |  
---+
 This is a feature request. It will hold a patch against Django 1.0.x that
 adds functionality into the test suite.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #8968: No way to utilize `next` parameter to redirect after comment deletion

[Django]

#8968: No way to utilize `next` parameter to redirect after comment deletion
--+-
  Reporter:  Dzhus| Owner:  nobody  
Status:  new  | Milestone:  
 Component:  django.contrib.comments  |   Version:  1.0 
Resolution:   |  Keywords:  comments
 Stage:  Unreviewed   | Has_patch:  1   
Needs_docs:  0|   Needs_tests:  0   
Needs_better_patch:  0|  
--+-
Comment (by neithere):

 The little change introduced in the existing patch should apply to all
 django.contrib.comments.moderation methods that expect the `next` argument
 (which simply can't be in the path as it's a path itself). These methods
 are approve(), delete() and flag().

 I think that `next=None` should be removed from method signatures, too. In
 this case the `next` variable would be undefined in the POST handling
 code, so we should either get its value from POST or simply pass
 `next=None` to next_redirect() because the latter can get the same data
 itself.

 Or did I miss something?

 (By the way, a non-existent `comment.permalink` is used instead of the
 actual `comment.get_absolute_url` in
 source:django/trunk/django/contrib/comments/templates/comments/delete.html
 and friends. That's a bit off-topic though.)

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9367: EmailMultiAlternatives does not properly handle attachments

[Django]

#9367: EmailMultiAlternatives does not properly handle attachments
+---
  Reporter:  loekje | Owner:  nobody
Status:  new| Milestone:
 Component:  Uncategorized  |   Version:  1.0   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by loekje):

  * has_patch:  0 => 1

Comment:

 Patch has been attached. In the patch the EmailMultiAlternatives wraps the
 multipart/alternative views in a multipart/mixed message that also
 includes the attachments. The changes made to EmailMessage are merely for
 reusing code in the derived EmailMutliAlternatives class. In the original
 EmailMultiAlternatives all attachments (including the alternative views)
 would be attached as multipart/alternative. As a result of this the
 alternative views are correctly presented in the browser, however the
 attachments are also considered to be an alternative view (instead of the
 real attachment they 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #6095: Add the ability to manually create M2M intermediary models

[Django]

#6095: Add the ability to manually create M2M intermediary models
---+
  Reporter:  jacob | Owner:  floguy  
Status:  closed| Milestone:  1.0 beta
 Component:  Database layer (models, ORM)  |   Version:  SVN 
Resolution:  fixed |  Keywords:  
 Stage:  Accepted  | Has_patch:  1   
Needs_docs:  1 |   Needs_tests:  0   
Needs_better_patch:  1 |  
---+
Changes (by zgoda):

 * cc: [EMAIL PROTECTED] (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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #6095: Add the ability to manually create M2M intermediary models

[Django]

#6095: Add the ability to manually create M2M intermediary models
---+
  Reporter:  jacob | Owner:  floguy  
Status:  closed| Milestone:  1.0 beta
 Component:  Database layer (models, ORM)  |   Version:  SVN 
Resolution:  fixed |  Keywords:  
 Stage:  Accepted  | Has_patch:  1   
Needs_docs:  1 |   Needs_tests:  0   
Needs_better_patch:  1 |  
---+
Changes (by anonymous):

 * cc: [EMAIL PROTECTED] (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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Changeset] r9277 - in django/branches/releases/1.0.X: . django/contrib/admin/templates/admin tests/regressiontests/admin_views

[noreply]

Author: kmtracey
Date: 2008-10-24 14:18:10 -0500 (Fri, 24 Oct 2008)
New Revision: 9277

Modified:
   django/branches/releases/1.0.X/
   
django/branches/releases/1.0.X/django/contrib/admin/templates/admin/change_form.html
   django/branches/releases/1.0.X/tests/regressiontests/admin_views/tests.py
Log:
[1.0.X] Fixed #7179 -- Changed breadcrumbs on the add page so that a link to 
the change view is not included when the user doesn't have permission for that 
view. Also added tests to ensure the link is not there when it shouldn't be, 
and there when it should be. Thanks for the report & patch alen__ribic. 



Property changes on: django/branches/releases/1.0.X
___
Name: svnmerge-integrated
   - 
/django/trunk:1-9097,9099-9102,9104-9109,9111,9113-9144,9146-9151,9153-9156,9158-9159,9161-9187,9189-9247,9249-9262,9264-9274
   + 
/django/trunk:1-9097,9099-9102,9104-9109,9111,9113-9144,9146-9151,9153-9156,9158-9159,9161-9187,9189-9247,9249-9262,9264-9276

Modified: 
django/branches/releases/1.0.X/django/contrib/admin/templates/admin/change_form.html
===
--- 
django/branches/releases/1.0.X/django/contrib/admin/templates/admin/change_form.html
2008-10-24 19:14:24 UTC (rev 9276)
+++ 
django/branches/releases/1.0.X/django/contrib/admin/templates/admin/change_form.html
2008-10-24 19:18:10 UTC (rev 9277)
@@ -16,7 +16,7 @@
 
  {% trans "Home" %} ›
  {{ app_label|capfirst|escape }} › 
- {{ opts.verbose_name_plural|capfirst }} ›
+ {% if has_change_permission %}{{ 
opts.verbose_name_plural|capfirst }}{% else %}{{ 
opts.verbose_name_plural|capfirst }}{% endif %} › 
  {% if add %}{% trans "Add" %} {{ opts.verbose_name }}{% else %}{{ 
original|truncatewords:"18" }}{% endif %}
 
 {% endif %}{% endblock %}

Modified: 
django/branches/releases/1.0.X/tests/regressiontests/admin_views/tests.py
===
--- django/branches/releases/1.0.X/tests/regressiontests/admin_views/tests.py   
2008-10-24 19:14:24 UTC (rev 9276)
+++ django/branches/releases/1.0.X/tests/regressiontests/admin_views/tests.py   
2008-10-24 19:18:10 UTC (rev 9277)
@@ -327,6 +327,11 @@
 # Add user may login and POST to add view, then redirect to admin root
 self.client.get('/test_admin/admin/')
 self.client.post('/test_admin/admin/', self.adduser_login)
+addpage = self.client.get('/test_admin/admin/admin_views/article/add/')
+self.failUnlessEqual(addpage.status_code, 200)
+change_list_link = 'Articles ›'
+self.failIf(change_list_link in addpage.content,
+'User restricted to add permission is given link to change 
list view in breadcrumbs.')
 post = self.client.post('/test_admin/admin/admin_views/article/add/', 
add_dict)
 self.assertRedirects(post, '/test_admin/admin/')
 self.failUnlessEqual(Article.objects.all().count(), 4)
@@ -335,6 +340,10 @@
 # Super can add too, but is redirected to the change list view
 self.client.get('/test_admin/admin/')
 self.client.post('/test_admin/admin/', self.super_login)
+addpage = self.client.get('/test_admin/admin/admin_views/article/add/')
+self.failUnlessEqual(addpage.status_code, 200)
+self.failIf(change_list_link not in addpage.content,
+'Unrestricted user is not given link to change list view 
in breadcrumbs.')
 post = self.client.post('/test_admin/admin/admin_views/article/add/', 
add_dict)
 self.assertRedirects(post, '/test_admin/admin/admin_views/article/')
 self.failUnlessEqual(Article.objects.all().count(), 5)


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #6095: Add the ability to manually create M2M intermediary models

[Django]

#6095: Add the ability to manually create M2M intermediary models
---+
  Reporter:  jacob | Owner:  floguy  
Status:  closed| Milestone:  1.0 beta
 Component:  Database layer (models, ORM)  |   Version:  SVN 
Resolution:  fixed |  Keywords:  
 Stage:  Accepted  | Has_patch:  1   
Needs_docs:  1 |   Needs_tests:  0   
Needs_better_patch:  1 |  
---+
Changes (by jcd):

 * cc: [EMAIL PROTECTED] (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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Changeset] r9276 - in django/trunk: django/contrib/admin/templates/admin tests/regressiontests/admin_views

[noreply]

Author: kmtracey
Date: 2008-10-24 14:14:24 -0500 (Fri, 24 Oct 2008)
New Revision: 9276

Modified:
   django/trunk/django/contrib/admin/templates/admin/change_form.html
   django/trunk/tests/regressiontests/admin_views/tests.py
Log:
Fixed #7179 -- Changed breadcrumbs on the add page so that a link to the change 
view is not included when the user doesn't have permission for that view.  Also 
added tests to ensure the link is not there when it shouldn't be, and there 
when it should be.  Thanks for the report & patch alen__ribic.


Modified: django/trunk/django/contrib/admin/templates/admin/change_form.html
===
--- django/trunk/django/contrib/admin/templates/admin/change_form.html  
2008-10-24 18:13:35 UTC (rev 9275)
+++ django/trunk/django/contrib/admin/templates/admin/change_form.html  
2008-10-24 19:14:24 UTC (rev 9276)
@@ -16,7 +16,7 @@
 
  {% trans "Home" %} ›
  {{ app_label|capfirst|escape }} › 
- {{ opts.verbose_name_plural|capfirst }} ›
+ {% if has_change_permission %}{{ 
opts.verbose_name_plural|capfirst }}{% else %}{{ 
opts.verbose_name_plural|capfirst }}{% endif %} › 
  {% if add %}{% trans "Add" %} {{ opts.verbose_name }}{% else %}{{ 
original|truncatewords:"18" }}{% endif %}
 
 {% endif %}{% endblock %}

Modified: django/trunk/tests/regressiontests/admin_views/tests.py
===
--- django/trunk/tests/regressiontests/admin_views/tests.py 2008-10-24 
18:13:35 UTC (rev 9275)
+++ django/trunk/tests/regressiontests/admin_views/tests.py 2008-10-24 
19:14:24 UTC (rev 9276)
@@ -327,6 +327,11 @@
 # Add user may login and POST to add view, then redirect to admin root
 self.client.get('/test_admin/admin/')
 self.client.post('/test_admin/admin/', self.adduser_login)
+addpage = self.client.get('/test_admin/admin/admin_views/article/add/')
+self.failUnlessEqual(addpage.status_code, 200)
+change_list_link = 'Articles ›'
+self.failIf(change_list_link in addpage.content,
+'User restricted to add permission is given link to change 
list view in breadcrumbs.')
 post = self.client.post('/test_admin/admin/admin_views/article/add/', 
add_dict)
 self.assertRedirects(post, '/test_admin/admin/')
 self.failUnlessEqual(Article.objects.all().count(), 4)
@@ -335,6 +340,10 @@
 # Super can add too, but is redirected to the change list view
 self.client.get('/test_admin/admin/')
 self.client.post('/test_admin/admin/', self.super_login)
+addpage = self.client.get('/test_admin/admin/admin_views/article/add/')
+self.failUnlessEqual(addpage.status_code, 200)
+self.failIf(change_list_link not in addpage.content,
+'Unrestricted user is not given link to change list view 
in breadcrumbs.')
 post = self.client.post('/test_admin/admin/admin_views/article/add/', 
add_dict)
 self.assertRedirects(post, '/test_admin/admin/admin_views/article/')
 self.failUnlessEqual(Article.objects.all().count(), 5)


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #2493: Error "reset"ing app with self-referencing ForeignKey

[Django]

#2493: Error "reset"ing app with self-referencing ForeignKey
---+
  Reporter:  [EMAIL PROTECTED]   | Owner:  nobody 
Status:  new   | Milestone: 
 Component:  Database layer (models, ORM)  |   Version:  SVN
Resolution:|  Keywords:  sprintdec01
 Stage:  Design decision needed| Has_patch:  0  
Needs_docs:  0 |   Needs_tests:  1  
Needs_better_patch:  0 |  
---+
Comment (by anonymous):

 [http://discount-designer-sunglasses.clearance-outlets.com/ Buy Discount
 Armani Sunglasses]
 [http://discount-designer-sunglasses.clearance-outlets.com/ Cheap
 Authentic Armani Sunglasses sale]

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #2473: [patch] 'in' QuerySet operator generates invalid SQL for empty list

[Django]

#2473: [patch] 'in' QuerySet operator generates invalid SQL for empty list
---+
  Reporter:  [EMAIL PROTECTED] | Owner:  mtredinnick
Status:  closed| Milestone: 
 Component:  Database layer (models, ORM)  |   Version: 
Resolution:  fixed |  Keywords: 
 Stage:  Unreviewed| Has_patch:  1  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Comment (by anonymous):

 [http://http://discount-designer-sunglasses.clearance-outlets.com/ Buy
 Discount Coach Sunglasses]
 [http://http://discount-designer-sunglasses.clearance-outlets.com/ Cheap
 Authentic Coach Sunglasses sale]

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #6398: Add optional {% default %} clause to {% for %} template tag

[Django]

#6398: Add optional {% default %} clause to {% for %} template tag
--+-
  Reporter:  jezdez   | Owner:  jezdez   
Status:  assigned | Milestone:  post-1.0 
 Component:  Template system  |   Version:  SVN  
Resolution:   |  Keywords:  easy-pickings
 Stage:  Accepted | Has_patch:  1
Needs_docs:  0|   Needs_tests:  0
Needs_better_patch:  0|  
--+-
Comment (by anonymous):

 [http://http://discount-designer-sunglasses.clearance-outlets.com/ Buy
 Discount Armani Sunglasses]
 [http://http://discount-designer-sunglasses.clearance-outlets.com/ Cheap
 Authentic Armani Sunglasses sale]

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #6860: Improvements for the new paginator

[Django]

#6860: Improvements for the new paginator
-+--
  Reporter:  Alberto García Hierro <[EMAIL PROTECTED]>  | 
Owner:  nobody   
Status:  new | Milestone:   

 Component:  Core framework  |   Version:  
SVN  
Resolution:  |  Keywords:  
paginator
 Stage:  Design decision needed  | Has_patch:  
1
Needs_docs:  1   |   Needs_tests:  
0
Needs_better_patch:  0   |  
-+--
Comment (by anonymous):

 [http://www.attraction-theory.com/ how to attract girls]
 [http://www.attraction-theory.com/ The Alpha Male System]

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #4748: contrib.auth: Increase length of names of permissions

[Django]

#4748: contrib.auth: Increase length of names of permissions
---+
  Reporter:  Thomas Güttler <[EMAIL PROTECTED]>  | Owner:  
nobody  
Status:  new   | Milestone: 
 
 Component:  django.contrib.admin  |   Version:  SVN
 
Resolution:|  Keywords:  
dbchange
 Stage:  Accepted  | Has_patch:  1  
 
Needs_docs:  0 |   Needs_tests:  0  
 
Needs_better_patch:  0 |  
---+
Comment (by anonymous):

 [http://www.attraction-theory.com/ GuyGetsGirl.com]
 [http://www.attraction-theory.com/ how to attract women]

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #7524: Not concrete exception when urls module imports invalid modules.

[Django]

#7524: Not concrete exception when urls module imports invalid modules.
+---
  Reporter:  Petr Marhoun <[EMAIL PROTECTED]>  | Owner:  nobody
Status:  closed | Milestone:  
1.0   
 Component:  Core framework |   Version:  
SVN   
Resolution:  fixed  |  Keywords:

 Stage:  Accepted   | Has_patch:  1 

Needs_docs:  0  |   Needs_tests:  0 

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

 [http://www.attraction-theory.com/ Learn How to seduce women girls]
 [http://www.attraction-theory.com/ how to attract girls]
 [http://www.attraction-theory.com/ attract women make women laugh]
 [http://www.attraction-theory.com/ Become an alpha male]

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #2910: [patch] Add extension support to Markdown filter

[Django]

#2910: [patch] Add extension support to Markdown filter
+---
  Reporter:  [EMAIL PROTECTED]   | Owner:  wayla  
Status:  closed | Milestone: 
 Component:  Contrib apps   |   Version:  SVN
Resolution:  fixed  |  Keywords:  markup markdown
 Stage:  Ready for checkin  | Has_patch:  1  
Needs_docs:  0  |   Needs_tests:  0  
Needs_better_patch:  0  |  
+---
Comment (by anonymous):

 [http://www.attraction-theory.com/ Learn How to seduce women girls]
 [http://www.attraction-theory.com/ how to attract women]
 [http://www.attraction-theory.com/ guygetsgirl]
 [http://www.attraction-theory.com/ The Alpha Male System]

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #7510: ModelAdmin should be able to use a non-default manager

[Django]

#7510: ModelAdmin should be able to use a non-default manager
-+--
  Reporter:  tom | Owner:  Alex
Status:  new | Milestone:  post-1.0
 Component:  django.contrib.admin|   Version:  SVN 
Resolution:  |  Keywords:  
 Stage:  Design decision needed  | Has_patch:  1   
Needs_docs:  0   |   Needs_tests:  0   
Needs_better_patch:  0   |  
-+--
Comment (by anonymous):

 [http://www.designer-handbags-purses.com/coach/ Buy Cheap Coach Purses
 Handbags]
 [http://www.designer-handbags-purses.com/coach/ BUY COACH PURSE COACH ERGO
 SIGNATURE BIFOLD MINI WALLET]

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #4620: Custom labels for choices in ModelChoiceField

[Django]

#4620: Custom labels for choices in ModelChoiceField
-+--
  Reporter:  Bill Fenner <[EMAIL PROTECTED]>  | Owner:  jacob
Status:  closed  | Milestone:   
 Component:  Forms   |   Version:  SVN  
Resolution:  fixed   |  Keywords:   
 Stage:  Accepted| Has_patch:  1
Needs_docs:  0   |   Needs_tests:  0
Needs_better_patch:  0   |  
-+--
Comment (by anonymous):

 [http://www.designer-handbags-purses.com/coach/ Buy Cheap Authentic Coach
 Purses]
 [http://www.designer-handbags-purses.com/coach/ BUY COACH PURSE MADISON
 MIRRORED METALLIC SMALL WALLET]

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #4036: Spanish (es) localflavor

[Django]

#4036: Spanish (es) localflavor
-+--
  Reporter:  [EMAIL PROTECTED]   | Owner:  garcia_marc  
   
Status:  closed  | Milestone:   
   
 Component:  django.contrib.localflavor  |   Version:  SVN  
   
Resolution:  fixed   |  Keywords:  spanish es 
l10n i18n localflavor
 Stage:  Ready for checkin   | Has_patch:  1
   
Needs_docs:  0   |   Needs_tests:  0
   
Needs_better_patch:  0   |  
-+--
Comment (by anonymous):

 [http://www.designer-handbags-purses.com/coach/ Buy Discount Authentic
 Coach Handbags & Purses]
 [http://www.designer-handbags-purses.com/coach/ BUY COACH MADISON LEATHER
 SMALL WALLET]

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #6095: Add the ability to manually create M2M intermediary models

[Django]

#6095: Add the ability to manually create M2M intermediary models
---+
  Reporter:  jacob | Owner:  floguy  
Status:  closed| Milestone:  1.0 beta
 Component:  Database layer (models, ORM)  |   Version:  SVN 
Resolution:  fixed |  Keywords:  
 Stage:  Accepted  | Has_patch:  1   
Needs_docs:  1 |   Needs_tests:  0   
Needs_better_patch:  1 |  
---+
Comment (by anonymous):

 [http://www.designer-handbags-purses.com/ Buy coach signature carly
 handbag] - [http://www.designer-handbags-purses.com/ Cheap Coach handbags
 purses & women's accessories]

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #9437: OperationalError under fastcgi when maxrequests=1 is set

[Django]

#9437: OperationalError under fastcgi when maxrequests=1 is set
---+
 Reporter:  mattxbart  |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Contrib apps   | Version:  SVN   
 Keywords:  gis geodjango  |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 I'm trying to run django (with a contrib.gis model) under fastcgi with the
 maxrequests=1 parameter so I don't have to restart the process to see code
 changes:
 {{{
 $ python manage.py runfcgi --settings=myproject.settings method=prefork
 pidfile=/var/run/myproject.pid host=127.0.0.1 port=7778 maxrequests=1
 }}}

 I'm using nginx on the front end with postgresql_psycopg2. When I remove
 the GIS contrib portion from my model (and use the regular
 django.db.models) I no longer get the error.

 My '''models.py''' (it does not seem to matter if I have a geometry field
 in the model or not):

 {{{
 from django.contrib.gis.db import models
 from django.conf import settings
 from django.contrib.sites.models import Site
 from django.core.files import File

 class Drawing(models.Model):
 title = models.CharField(max_length=255)
 slug = models.SlugField()
 date = models.DateTimeField()
 created = models.DateTimeField(auto_now=True)

 objects = models.GeoManager()

 def get_absolute_url(self):
 domain = Site.objects.get(id=settings.SITE_ID).domain
 return "%s/drawings/%s/" % (domain,self.slug)

 def __unicode__(self):
 return self.title
 }}}

 '''Traceback:'''
 {{{
 File "/usr/local/lib/python2.5/site-packages/django/core/handlers/base.py"
 in get_response
   77. request.path_info)
 File "/usr/local/lib/python2.5/site-packages/django/core/urlresolvers.py"
 in resolve
   181. sub_match = pattern.resolve(new_path)
 File "/usr/local/lib/python2.5/site-packages/django/core/urlresolvers.py"
 in resolve
   179. for pattern in self.urlconf_module.urlpatterns:
 File "/usr/local/lib/python2.5/site-packages/django/core/urlresolvers.py"
 in _get_urlconf_module
   198. self._urlconf_module = __import__(self.urlconf_name,
 {}, {}, [''])
 File "/home/mbartolome/projects/gis/spec/urls.py" in 
   6. from gis.tilecache import views as t_views
 File "/home/mbartolome/projects/gis/tilecache/views.py" in 
   4. from gis.cwagrid.models import CWAGrid
 File "/home/mbartolome/projects/gis/cwagrid/models.py" in 
   6. class CWAGrid(models.Model):
 File "/home/mbartolome/projects/gis/cwagrid/models.py" in CWAGrid
   9. geom = models.MultiPolygonField(srid=2230, db_column='the_geom')
 File "/usr/local/lib/python2.5/site-
 packages/django/contrib/gis/db/models/fields/__init__.py" in __init__
   45. self._unit, self._unit_name, self._spheroid =
 get_srid_info(srid)
 File "/usr/local/lib/python2.5/site-packages/django/contrib/gis/models.py"
 in get_srid_info
   261. cur.execute(stmt)
 File "/usr/local/lib/python2.5/site-packages/django/db/backends/util.py"
 in execute
   19. return self.cursor.execute(sql, params)

 Exception Type: OperationalError at /spec/
 Exception Value: server closed the connection unexpectedly
 This probably means the server terminated abnormally
 before or while processing the request.
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Changeset] r9275 - in django/branches/releases/1.0.X: . tests/regressiontests/queries

[noreply]

Author: kmtracey
Date: 2008-10-24 13:13:35 -0500 (Fri, 24 Oct 2008)
New Revision: 9275

Modified:
   django/branches/releases/1.0.X/
   django/branches/releases/1.0.X/tests/regressiontests/queries/models.py
Log:
[1.0.X] Fixed #9411 -- Changed the test from r9081 to be more robust across 
different database backends. 

Backport of [9254] from trunk (I neglected to mention in the ticket this 
affected 1.0.X branch).

Also updated svnmerge metadata; all eligible fixes have been backported and all 
others blocked.



Property changes on: django/branches/releases/1.0.X
___
Name: svnmerge-integrated
   - 
/django/trunk:1-9097,9099-9102,9104-9109,9111,9113-9144,9146-9151,9153-9156,9158-9159,9161-9187,9189-9245
   + 
/django/trunk:1-9097,9099-9102,9104-9109,9111,9113-9144,9146-9151,9153-9156,9158-9159,9161-9187,9189-9247,9249-9262,9264-9274

Modified: django/branches/releases/1.0.X/tests/regressiontests/queries/models.py
===
--- django/branches/releases/1.0.X/tests/regressiontests/queries/models.py  
2008-10-24 16:39:28 UTC (rev 9274)
+++ django/branches/releases/1.0.X/tests/regressiontests/queries/models.py  
2008-10-24 18:13:35 UTC (rev 9275)
@@ -974,11 +974,12 @@
 >>> expected == result
 True
 
-Make sure bump_prefix() (an internal Query method) doesn't (re-)break.
->>> query = Tag.objects.values_list('id').order_by().query
->>> query.bump_prefix()
->>> print query.as_sql()[0]
-SELECT U0."id" FROM "queries_tag" U0
+Make sure bump_prefix() (an internal Query method) doesn't (re-)break. It's
+sufficient that this query runs without error.
+>>> qs = Tag.objects.values_list('id', flat=True).order_by('id')
+>>> qs.query.bump_prefix()
+>>> list(qs)
+[1, 2, 3, 4, 5]
 
 Calling order_by() with no parameters removes any existing ordering on the
 model. But it should still be possible to add new ordering after that.


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #5863: list_display does not allow functions of referenced objects

[Django]

#5863: list_display does not allow functions of referenced objects
---+
  Reporter:  Beat Bolli <[EMAIL PROTECTED]>  | Owner:  nobody   
   
Status:  reopened  | Milestone: 
 
 Component:  django.contrib.admin  |   Version:  SVN
 
Resolution:|  Keywords:  
list_display
 Stage:  Design decision needed| Has_patch:  1  
 
Needs_docs:  1 |   Needs_tests:  0  
 
Needs_better_patch:  1 |  
---+
Comment (by kmtracey):

 Replying to [comment:14 danros]:
 >
 > Can I add that I would very much like this functionality for my project.
 In fact the lack of this functionality led me to give up on the admin
 interface and create my own thing that did do that!

 It was easier to write your own admin than write some trivial !ModelAdmin
 methods that returned the information you were interested in?

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #5863: list_display does not allow functions of referenced objects

[Django]

#5863: list_display does not allow functions of referenced objects
---+
  Reporter:  Beat Bolli <[EMAIL PROTECTED]>  | Owner:  nobody   
   
Status:  reopened  | Milestone: 
 
 Component:  django.contrib.admin  |   Version:  SVN
 
Resolution:|  Keywords:  
list_display
 Stage:  Design decision needed| Has_patch:  1  
 
Needs_docs:  1 |   Needs_tests:  0  
 
Needs_better_patch:  1 |  
---+
Comment (by danros):

 Replying to [comment:13 pihentagy]:
 > What's the common situation where user's would really like to see the
 value of a field in a related model instead of just the text
 representation of the related model?  I'm just not seeing that as a very
 common need, meaning when you need it if you have to write a little extra
 code it's no big deal.  It's not boilerplate if you only have to do it in
 rare situations.  I'm looking for something a little more concrete as
 motivation than mom and apple pie goodness.

 Can I add that I would very much like this functionality for my project.
 In fact the lack of this functionality led me to give up on the admin
 interface and create my own thing that did do that!

 Being able to mix-in related model fields is very useful for creating a
 'dashboard' style admin page which I would think is a very common
 requirement.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Changeset] r9274 - django/branches/releases/1.0.X

[noreply]

Author: kmtracey
Date: 2008-10-24 11:39:28 -0500 (Fri, 24 Oct 2008)
New Revision: 9274

Modified:
   django/branches/releases/1.0.X/
Log:
[1.0.X] block [9248] (feature) and [9263] (updated translation) from svnmerge 
consideration.



Property changes on: django/branches/releases/1.0.X
___
Name: svnmerge-blocked
   - /django/trunk:9098,9103,9110,9112,9145,9152,9157,9160,9188
   + /django/trunk:9098,9103,9110,9112,9145,9152,9157,9160,9188,9248,9263


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #3512: Add "required" & "error" CSS classes to form rows in as_* methods

[Django]

#3512: Add "required" & "error" CSS classes to form rows in as_* methods
+---
  Reporter:  Waylan Limberg <[EMAIL PROTECTED]>  | Owner:  
nobody
Status:  reopened   | Milestone:
 Component:  Forms  |   Version:  SVN   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  1 
Needs_docs:  1  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by gonz):

 * cc: gonz (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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #2507: [patch] LDAPBackend in django/contrib/auth/backends.py

[Django]

#2507: [patch] LDAPBackend in django/contrib/auth/backends.py
---+
  Reporter:  [EMAIL PROTECTED]  | Owner:  nobody
Status:  new   | Milestone:
 Component:  Contrib apps  |   Version:  SVN   
Resolution:|  Keywords:  ldap,usernames
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  1 |  
---+
Changes (by spkane):

 * cc: [EMAIL PROTECTED] (added)
  * keywords:  => ldap,usernames

Comment:

 ldapauth.patch (4.5 kB) - added by spkane on 10/24/08 10:33:11.
 This patch is reasonably specific to my needs, but I would bet hard
 money, that this is an issue faced by other people, so a more robust
 version of this patch should likely be considered. The issue is that the
 best thing for me to use as a username within our LDAP implementation is
 the prefix of the email address, since it is the only thing guaranteed to
 be unique (we have many employees with the same name). However, our email
 addresses are, [EMAIL PROTECTED] Django does not allow a period
 in the username, so I added some logic to handle the username (for django)
 and the ldap_username separately and use the proper one in the proper
 place. Basically, the users login as "sean_kane" and the ldap backend
 converts that to "sean.kane" when talking to the ldap server and then uses
 "sean_kane" when talking to the Django server.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9431: UNIQUE index on VARCHAR(256+) causes failure on MySQL 5.0 with InnoDB tables, a slightly higher threshold for MyISAM

[Django]

#9431: UNIQUE index on VARCHAR(256+) causes failure on MySQL 5.0 with InnoDB
tables, a slightly higher threshold for MyISAM
---+
  Reporter:  adamnelson| Owner:  adamnelson
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  1.0   
Resolution:|  Keywords:  mysql 
 Stage:  Accepted  | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by adamnelson):

 To be clear, I'll still write the patch without impacting support for
 MySQL 4.0.  I already have the patch - just wanted to test it first before
 posting.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9405: [patch] DatabaseOperations should track its own connection

[Django]

#9405: [patch] DatabaseOperations should track its own connection
---+
  Reporter:  Tarken| Owner:  nobody 
  
Status:  closed| Milestone: 
  
 Component:  Database layer (models, ORM)  |   Version:  1.0
  
Resolution:  wontfix   |  Keywords:  multiple 
database
 Stage:  Unreviewed| Has_patch:  1  
  
Needs_docs:  0 |   Needs_tests:  0  
  
Needs_better_patch:  0 |  
---+
Comment (by Tarken):

 An advance warning: I apologize if this sounds a bit snippy, it's not
 meant to; mild hangover and coffee hasn't kicked in yet. :)

 I honestly have to disagree, and you assertion that "It shouldn't be doing
 anything that requires access to an active connection." is proven false by
 what is changed in this patch. The Oracle backend, in regex_lookup(),
 grabs a cursor. The PostgreSQL backend does as well in
 _get_postgres_version(). django-pyodbc also references properties of the
 connection in both sql_flush() and field_cast_sql().

 True, this is not a "necessary" change at the moment, but it works, does
 not change the API as far as users are concerned, and provides an extra
 bit of caution. In the case of what I am currently doing with Django (as
 mentioned in my comment on #1142 and on the django-developers mailing
 list), this is an absolutely necessary patch. Without it, I end up calling
 the psycopg2 operations for an MS SQL connection.

 One piece of your comment I'm not 100% clear on though is the statement,
 "It's not immediately clear that it's the right approach for multiple
 database support." Regardless of what direction the multiple database
 support takes, would it not be cleanest to have these things keep tabs on
 their own information? If, for example, the 'using' proposal ends up being
 implemented, the methods mentioned above which do reference an active
 connection will either need to figure out what connection is being used
 and reference that one, or do exactly what's being offered up here.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #6148: Add generic support for database schemas

[Django]

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

Status:  new   | Milestone: 

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

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

Needs_docs:  0 |   Needs_tests:  0  

Needs_better_patch:  1 |  
---+
Changes (by bhagany):

 * cc: [EMAIL PROTECTED] (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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9431: UNIQUE index on VARCHAR(256+) causes failure on MySQL 5.0 with InnoDB tables, a slightly higher threshold for MyISAM

[Django]

#9431: UNIQUE index on VARCHAR(256+) causes failure on MySQL 5.0 with InnoDB
tables, a slightly higher threshold for MyISAM
---+
  Reporter:  adamnelson| Owner:  adamnelson
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  1.0   
Resolution:|  Keywords:  mysql 
 Stage:  Accepted  | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by adamnelson):

 I agree although I can't find anywhere where there is a minimum version
 number for MySQL on Django in any of the official docs or even in the base
 object.  After trudging through the lists, I see talk of deprecating MySQL
 4.0 nearly 2 years ago but it seems to be a dead topic.  Ostensibly MySQL
 3.23 would even work in the current codebase since MySQLdb supports it.  I
 honestly don't think that anybody could run Django 1.0 on MySQL 4.0 using
 many of the core Django apps currently out there without running into
 serious problems - mostly related to the lack of robust unicode support
 before 4.1.

 MySQL 4.1 would be the only reasonable minimum but virtually nobody is
 using it which is why I think MySQL 5.0 is the realistic minimum.  I'll
 send my previous email to the group as I can't imagine that anybody would
 be able to run Django 1.0 on MySQL 4.0 in a reliable fashion right now and
 MySQL 5.0 has been stable for 3 years.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #7295: quotes, escaping and translation of string literals handled inconsistently in templates

[Django]

#7295: quotes, escaping and translation of string literals handled 
inconsistently
in templates
--+-
  Reporter:  akaihola | Owner:  nobody 
Status:  new  | Milestone:  post-1.0   
 Component:  Template system  |   Version:  SVN
Resolution:   |  Keywords:  tplrf-fixed
 Stage:  Accepted | Has_patch:  1  
Needs_docs:  0|   Needs_tests:  1  
Needs_better_patch:  0|  
--+-
Changes (by anonymous):

  * keywords:  => tplrf-fixed

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #7806: django.template refactoring

[Django]

#7806: django.template refactoring
--+-
  Reporter:  emulbreh | Owner:  nobody  
Status:  new  | Milestone:  post-1.0
 Component:  Template system  |   Version:  SVN 
Resolution:   |  Keywords:  tplrf   
 Stage:  Accepted | Has_patch:  1   
Needs_docs:  1|   Needs_tests:  1   
Needs_better_patch:  1|  
--+-
Comment (by emulbreh):

 This would also fix #9315.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9315: Keyword arguments with spaces and the url tag

[Django]

#9315: Keyword arguments with spaces and the url tag
--+-
  Reporter:  alexisbellido| Owner:  nobody  
Status:  new  | Milestone:  
 Component:  Template system  |   Version:  1.0 
Resolution:   |  Keywords:  url, tplrf-fixed
 Stage:  Unreviewed   | Has_patch:  0   
Needs_docs:  0|   Needs_tests:  0   
Needs_better_patch:  0|  
--+-
Changes (by emulbreh):

  * keywords:  url => url, tplrf-fixed
  * needs_better_patch:  => 0
  * needs_tests:  => 0
  * needs_docs:  => 0

Comment:

 This would be fixed by #7806.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9419: Russian translation for "Currently:"

[Django]

#9419: Russian translation for "Currently:"
---+
  Reporter:  anonymous | Owner:  nobody 

Status:  new   | Milestone: 

 Component:  Translations  |   Version:  1.0

Resolution:|  Keywords:  Currently, russian, 
translation
 Stage:  Unreviewed| Has_patch:  0  

Needs_docs:  0 |   Needs_tests:  0  

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

 Мне "объект" не нравится, очень канцелярское слово. Может "Текущий файл:"?
 Для картинок, вроде, тоже годится.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #3515: CSS improvements for newforms

[Django]

#3515: CSS improvements for newforms
-+--
  Reporter:  Simon Litchfield <[EMAIL PROTECTED]>  | Owner:  
nobody
Status:  reopened| Milestone:   
 
 Component:  Forms   |   Version:  
SVN   
Resolution:  |  Keywords:   
 
 Stage:  Design decision needed  | Has_patch:  
1 
Needs_docs:  1   |   Needs_tests:  
1 
Needs_better_patch:  0   |  
-+--
Changes (by gonz):

 * cc: gonz (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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9419: Russian translation for "Currently:"

[Django]

#9419: Russian translation for "Currently:"
---+
  Reporter:  anonymous | Owner:  nobody 

Status:  new   | Milestone: 

 Component:  Translations  |   Version:  1.0

Resolution:|  Keywords:  Currently, russian, 
translation
 Stage:  Unreviewed| Has_patch:  0  

Needs_docs:  0 |   Needs_tests:  0  

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

 Может тогда использовать "Текущий объект:"? "Сейчас:" вполне подходит, но
 звучит немного странно...

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #2727: [patch] is not JSON serializable

[Django]

#2727: [patch] is not JSON serializable
-+--
  Reporter:  msamoylov   | Owner:  adrian
Status:  closed  | Milestone:
 Component:  Validators  |   Version:  SVN   
Resolution:  fixed   |  Keywords:
 Stage:  Unreviewed  | Has_patch:  1 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Comment (by anonymous):

 [http://www.designer-handbags-purses.com/ Buy Discount Coach Handbags &
 Purses] for less at [http://www.designer-handbags-purses.com/ www
 .designer-handbags-purses.com]

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Django] #9436: New documentations patches are inconsistent with contributing.txt

[Django]

#9436: New documentations patches are inconsistent with contributing.txt
---+
 Reporter:  telenieko  |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Documentation  | Version:  1.0   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 There are some ".. versionadded:: development" strings in trunk's
 documentation.

 According to contributing.txt (1) and somehow to a relevant thread(2)
 those should read: .. versionadded:: 1.1

 1: [http://docs.djangoproject.com/en/dev/internals/contributing/#how-to-
 document-new-features contributing.txt]
 2: [http://groups.google.com/group/django-
 developers/browse_thread/thread/64a0e0e22cedf9db/b2d896f800d99bda a
 revelant thread]

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9433: File locking broken on AFP mounts

[Django]

#9433: File locking broken on AFP mounts
---+
  Reporter:  rndblnch  | Owner:  nobody
Status:  new   | Milestone:
 Component:  File uploads/storage  |   Version:  1.0   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by anonymous):

  * has_patch:  0 => 1

Comment:

 Replying to [comment:1 mtredinnick]:
 > We're not going to revert that change for one particular sort of
 filesystem on one particular operating system, since it fixes a much
 broader class of problems. That would be very counter-productive.
 I understand that, that is why i said it is a workaround (not a fix).
 I mentioned it because it can help other people before we find a proper
 fix.

 [[BR]]



 > So the real solution here is coming up with a way to work out when that
 locking attempt won't work. Since we're using the recommended approach to
 file locking, file systems that don't support it will need specific
 workarounds (or a warning saying one can't use them for that purpose).
 Assuming POSIX-like behaviour is quite valid, but exceptional handling for
 edge-cases is reasonable if we can detect them.

 The problem is that the behaviour is not consistant on the whole
 filesystem: local volumes are ok, volumes mounted via AFP are not.
 So special casing at import-time of django.core.files.locks id not
 possible.
 I propose the following solution:
 in the "posix" case, enclosing the calls to fcntl.lockf in a try block and
 in case of IOError for "Operation not supported" error, defaults silently
 to do nothing (which is the fallback already used when fcntl is not
 available.

 I've attached a patch against trunk.


 [[BR]]



 > You have one of these filesystems available. So can you look up how we
 can detect the problem? Does `flock()` work in those cases and, if so, is
 it possible to try `lockf()` and, if that fails, fall back to `flock()`?
 Do some experiments and see what you can come up with.

 Falling back to flock does not help, it's a do nothing operation on AFP
 volumes.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9394: Reverse relation lookups with a multi-table inherited model produces extraneous queries

[Django]

#9394: Reverse relation lookups with a multi-table inherited model produces
extraneous queries
---+
  Reporter:  ikelly| Owner:  mtredinnick
Status:  assigned  | Milestone: 
 Component:  Database layer (models, ORM)  |   Version:  SVN
Resolution:|  Keywords: 
 Stage:  Accepted  | Has_patch:  0  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Changes (by mtredinnick):

  * summary:  Querying a many-to-many intermediate model from a manager on
  a multi-table inherited model produces
  extraneous queries => Reverse relation lookups
  with a multi-table inherited model produces
  extraneous queries

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9394: Querying a many-to-many intermediate model from a manager on a multi-table inherited model produces extraneous queries

[Django]

#9394: Querying a many-to-many intermediate model from a manager on a 
multi-table
inherited model produces extraneous queries
---+
  Reporter:  ikelly| Owner:  mtredinnick
Status:  assigned  | Milestone: 
 Component:  Database layer (models, ORM)  |   Version:  SVN
Resolution:|  Keywords: 
 Stage:  Accepted  | Has_patch:  0  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Changes (by mtredinnick):

  * owner:  nobody => mtredinnick
  * status:  new => assigned
  * stage:  Unreviewed => Accepted

Comment:

 Turns out this doesn't have anything in particular to do with many-to-many
 and "through". It's actually a general wart in the way reverse relations
 work with model inheritance. From a bit of poking around, it might be a
 little fiddly to get it working efficiently, too. However, I've got a test
 case now that demonstrates the problem, so I'll poke at it some more.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9381: Errors in django.contib.auth PasswordResetTest

[Django]

#9381: Errors in django.contib.auth PasswordResetTest
-+--
  Reporter:  kit1980 | Owner:  nobody  
Status:  closed  | Milestone:  
 Component:  Authentication  |   Version:  SVN 
Resolution:  invalid |  Keywords:  PasswordResetTest, tests
 Stage:  Unreviewed  | Has_patch:  1   
Needs_docs:  0   |   Needs_tests:  0   
Needs_better_patch:  0   |  
-+--
Comment (by kit1980):

 Replying to [comment:1 mtredinnick]:
 Yes, thanks.
 The real problem was in my registration/password_reset_email.html
 template: it had hardcoded path to /accounts/password/reset/confirm/
 instead of {% url %} tag.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9218: KeyError in validate_unique when primary_key is in fields and it's empty in form

[Django]

#9218: KeyError in validate_unique when primary_key is in fields and it's empty 
in
form
---+
  Reporter:  romke <[EMAIL PROTECTED]>  | Owner:  nobody
   
Status:  new   | Milestone: 
  
 Component:  Forms |   Version:  SVN
  
Resolution:|  Keywords:  KeyError, 
validate_unique, custom primary_key
 Stage:  Accepted  | Has_patch:  1  
  
Needs_docs:  0 |   Needs_tests:  0  
  
Needs_better_patch:  0 |  
---+
Comment (by julianb):

 My form didn't work at all. I can confirm that this patch fixes it.
 Thanks!

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9307: Pickling support for Oracle Query classes

[Django]

#9307: Pickling support for Oracle Query classes
---+
  Reporter:  mtredinnick   | Owner:  mtredinnick
Status:  new   | Milestone: 
 Component:  Database layer (models, ORM)  |   Version:  1.0
Resolution:|  Keywords: 
 Stage:  Accepted  | Has_patch:  0  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Comment (by mtredinnick):

 Attempts to try and do this using a `__new__()` method, which felt
 cleaner, were measurably slower. Given the number of times we create new
 `Query` classes, I've decided that pragmatism beats theoretical perfection
 here. So I'll go with Justin's latest 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Changeset] r9273 - in django/branches/releases/1.0.X/django/db: backends/oracle models/sql

[noreply]

Author: mtredinnick
Date: 2008-10-24 04:40:12 -0500 (Fri, 24 Oct 2008)
New Revision: 9273

Modified:
   django/branches/releases/1.0.X/django/db/backends/oracle/query.py
   django/branches/releases/1.0.X/django/db/models/sql/query.py
Log:
[1.0.X] Fixed #9307 -- Added the ability to pickle the Query class used by the
Oracle backend.

This allows Querysets to be cached for Oracle and should provide a model for
adding pickling support to other (external) database backends that need a
custom Query class.

Thanks to Justin Bronn for some assistance with this patch.

Backport of r9272 from trunk.


Modified: django/branches/releases/1.0.X/django/db/backends/oracle/query.py
===
--- django/branches/releases/1.0.X/django/db/backends/oracle/query.py   
2008-10-24 09:36:22 UTC (rev 9272)
+++ django/branches/releases/1.0.X/django/db/backends/oracle/query.py   
2008-10-24 09:40:12 UTC (rev 9273)
@@ -25,6 +25,18 @@
 pass
 
 class OracleQuery(QueryClass):
+def __reduce__(self):
+"""
+Enable pickling for this class (normal pickling handling doesn't
+work as Python can only pickle module-level classes by default).
+"""
+if hasattr(QueryClass, '__getstate__'):
+assert hasattr(QueryClass, '__setstate__')
+data = self.__getstate__()
+else:
+data = self.__dict__
+return (unpickle_query_class, (QueryClass,), data)
+
 def resolve_columns(self, row, fields=()):
 # If this query has limit/offset information, then we expect the
 # first column to be an extra "_RN" column that we need to throw
@@ -120,3 +132,17 @@
 
 _classes[QueryClass] = OracleQuery
 return OracleQuery
+
+def unpickle_query_class(QueryClass):
+"""
+Utility function, called by Python's unpickling machinery, that handles
+unpickling of Oracle Query subclasses.
+"""
+# XXX: Would be nice to not have any dependency on cx_Oracle here. Since
+# modules can't be pickled, we need a way to know to load the right module.
+import cx_Oracle
+
+klass = query_class(QueryClass, cx_Oracle)
+return klass.__new__(klass)
+unpickle_query_class.__safe_for_unpickling__ = True
+

Modified: django/branches/releases/1.0.X/django/db/models/sql/query.py
===
--- django/branches/releases/1.0.X/django/db/models/sql/query.py
2008-10-24 09:36:22 UTC (rev 9272)
+++ django/branches/releases/1.0.X/django/db/models/sql/query.py
2008-10-24 09:40:12 UTC (rev 9273)
@@ -27,9 +27,9 @@
 except NameError:
 from sets import Set as set # Python 2.3 fallback
 
-__all__ = ['Query']
+__all__ = ['Query', 'BaseQuery']
 
-class Query(object):
+class BaseQuery(object):
 """
 A single SQL query.
 """
@@ -1757,7 +1757,9 @@
 # Use the backend's custom Query class if it defines one. Otherwise, use the
 # default.
 if connection.features.uses_custom_query_class:
-Query = connection.ops.query_class(Query)
+Query = connection.ops.query_class(BaseQuery)
+else:
+Query = BaseQuery
 
 def get_order_dir(field, default='ASC'):
 """


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Changeset] r9272 - in django/trunk/django/db: backends/oracle models/sql

[noreply]

Author: mtredinnick
Date: 2008-10-24 04:36:22 -0500 (Fri, 24 Oct 2008)
New Revision: 9272

Modified:
   django/trunk/django/db/backends/oracle/query.py
   django/trunk/django/db/models/sql/query.py
Log:
Fixed #9307 -- Added the ability to pickle the Query class used by the Oracle
backend.

This allows Querysets to be cached for Oracle and should provide a model for
adding pickling support to other (external) database backends that need a
custom Query class.

Thanks to Justin Bronn for some assistance with this patch.


Modified: django/trunk/django/db/backends/oracle/query.py
===
--- django/trunk/django/db/backends/oracle/query.py 2008-10-24 09:30:53 UTC 
(rev 9271)
+++ django/trunk/django/db/backends/oracle/query.py 2008-10-24 09:36:22 UTC 
(rev 9272)
@@ -25,6 +25,18 @@
 pass
 
 class OracleQuery(QueryClass):
+def __reduce__(self):
+"""
+Enable pickling for this class (normal pickling handling doesn't
+work as Python can only pickle module-level classes by default).
+"""
+if hasattr(QueryClass, '__getstate__'):
+assert hasattr(QueryClass, '__setstate__')
+data = self.__getstate__()
+else:
+data = self.__dict__
+return (unpickle_query_class, (QueryClass,), data)
+
 def resolve_columns(self, row, fields=()):
 # If this query has limit/offset information, then we expect the
 # first column to be an extra "_RN" column that we need to throw
@@ -120,3 +132,17 @@
 
 _classes[QueryClass] = OracleQuery
 return OracleQuery
+
+def unpickle_query_class(QueryClass):
+"""
+Utility function, called by Python's unpickling machinery, that handles
+unpickling of Oracle Query subclasses.
+"""
+# XXX: Would be nice to not have any dependency on cx_Oracle here. Since
+# modules can't be pickled, we need a way to know to load the right module.
+import cx_Oracle
+
+klass = query_class(QueryClass, cx_Oracle)
+return klass.__new__(klass)
+unpickle_query_class.__safe_for_unpickling__ = True
+

Modified: django/trunk/django/db/models/sql/query.py
===
--- django/trunk/django/db/models/sql/query.py  2008-10-24 09:30:53 UTC (rev 
9271)
+++ django/trunk/django/db/models/sql/query.py  2008-10-24 09:36:22 UTC (rev 
9272)
@@ -27,9 +27,9 @@
 except NameError:
 from sets import Set as set # Python 2.3 fallback
 
-__all__ = ['Query']
+__all__ = ['Query', 'BaseQuery']
 
-class Query(object):
+class BaseQuery(object):
 """
 A single SQL query.
 """
@@ -1757,7 +1757,9 @@
 # Use the backend's custom Query class if it defines one. Otherwise, use the
 # default.
 if connection.features.uses_custom_query_class:
-Query = connection.ops.query_class(Query)
+Query = connection.ops.query_class(BaseQuery)
+else:
+Query = BaseQuery
 
 def get_order_dir(field, default='ASC'):
 """


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Changeset] r9271 - django/branches/releases/1.0.X/docs/howto/deployment

[noreply]

Author: mtredinnick
Date: 2008-10-24 04:30:53 -0500 (Fri, 24 Oct 2008)
New Revision: 9271

Modified:
   django/branches/releases/1.0.X/docs/howto/deployment/modpython.txt
Log:
[1.0.X] Fixed #9434 -- Added a note to the mod_python docs regarding requiring
PythonInterpreter in different VirtualHost blocks that share the same server
name. Thanks to Graham Dumpleton for the clarification.

Backport of r9268 from trunk.


Modified: django/branches/releases/1.0.X/docs/howto/deployment/modpython.txt
===
--- django/branches/releases/1.0.X/docs/howto/deployment/modpython.txt  
2008-10-24 09:30:04 UTC (rev 9270)
+++ django/branches/releases/1.0.X/docs/howto/deployment/modpython.txt  
2008-10-24 09:30:53 UTC (rev 9271)
@@ -160,7 +160,8 @@
 SetEnv DJANGO_SETTINGS_MODULE mysite.other_settings
 
 
-If you need to put two Django installations within the same ``VirtualHost``,
+If you need to put two Django installations within the same ``VirtualHost``
+(or in different ``VirtualHost`` blocks that share the same server name),
 you'll need to take a special precaution to ensure mod_python's cache doesn't
 mess things up. Use the ``PythonInterpreter`` directive to give different
  directives separate interpreters::


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Changeset] r9270 - django/branches/releases/1.0.X/docs/topics/db

[noreply]

Author: mtredinnick
Date: 2008-10-24 04:30:04 -0500 (Fri, 24 Oct 2008)
New Revision: 9270

Modified:
   django/branches/releases/1.0.X/docs/topics/db/queries.txt
Log:
[1.0.X] Fixed #9432 -- Revived documentation of ~Q usage.

Backport of r9267 from trunk.


Modified: django/branches/releases/1.0.X/docs/topics/db/queries.txt
===
--- django/branches/releases/1.0.X/docs/topics/db/queries.txt   2008-10-24 
09:29:27 UTC (rev 9269)
+++ django/branches/releases/1.0.X/docs/topics/db/queries.txt   2008-10-24 
09:30:04 UTC (rev 9270)
@@ -601,8 +601,12 @@
 WHERE question LIKE 'Who%' OR question LIKE 'What%'
 
 You can compose statements of arbitrary complexity by combining ``Q`` objects
-with the ``&`` and ``|`` operators. You can also use parenthetical grouping.
+with the ``&`` and ``|`` operators and use parenthetical grouping. Also, ``Q``
+objects can be negated using the ``~`` operator, allowing for combined lookups
+that combine both a normal query and a negated (``NOT``) query::
 
+Q(question__startswith='Who') | ~Q(pub_date__year=2005)
+
 Each lookup function that takes keyword-arguments (e.g. ``filter()``,
 ``exclude()``, ``get()``) can also be passed one or more ``Q`` objects as
 positional (not-named) arguments. If you provide multiple ``Q`` object


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Changeset] r9269 - in django/branches/releases/1.0.X/docs: ref topics/http

[noreply]

Author: mtredinnick
Date: 2008-10-24 04:29:27 -0500 (Fri, 24 Oct 2008)
New Revision: 9269

Modified:
   django/branches/releases/1.0.X/docs/ref/request-response.txt
   django/branches/releases/1.0.X/docs/topics/http/views.txt
Log:
[1.0.X] Fixed #9430 -- Fixed documentation references to the HttpResponse
classes for returning HTTP status codes other than 200.

Backport of r9266 from trunk.


Modified: django/branches/releases/1.0.X/docs/ref/request-response.txt
===
--- django/branches/releases/1.0.X/docs/ref/request-response.txt
2008-10-24 09:26:09 UTC (rev 9268)
+++ django/branches/releases/1.0.X/docs/ref/request-response.txt
2008-10-24 09:29:27 UTC (rev 9269)
@@ -525,6 +525,8 @@
 .. _HTTP Status code: 
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10
 
 
+.. _ref-httpresponse-subclasses:
+
 HttpResponse subclasses
 ---
 

Modified: django/branches/releases/1.0.X/docs/topics/http/views.txt
===
--- django/branches/releases/1.0.X/docs/topics/http/views.txt   2008-10-24 
09:26:09 UTC (rev 9268)
+++ django/branches/releases/1.0.X/docs/topics/http/views.txt   2008-10-24 
09:29:27 UTC (rev 9269)
@@ -64,11 +64,13 @@
 Returning errors
 
 
-Returning HTTP error codes in Django is easy. We've already mentioned the
-:class:`HttpResponseNotFound`, :class:`HttpResponseForbidden`,
-:class:`HttpResponseServerError`, etc., subclasses; just return an instance of 
one
-of those subclasses instead of a normal :class:`HttpResponse` in order to 
signify
-an error. For example::
+Returning HTTP error codes in Django is easy. There are subclasses of
+:class:`~django.http.HttpResponse` for a number of common HTTP status codes
+other than 200 (which means *"OK"*). You can find the full list of available
+subclasses in the :ref:`request/response `
+documentation.  Just return an instance of one of those subclasses instead of
+a normal :class:`~django.http.HttpResponse` in order to signify an error. For
+example::
 
 def my_view(request):
 # ...
@@ -77,6 +79,18 @@
 else:
 return HttpResponse('Page was found')
 
+There isn't a specialized subclass for every possible HTTP response code,
+since many of them aren't going to be that common. However, as documented in
+the :class:`~django.http.HttpResponse` documentation, you can also pass the
+HTTP status code into the constructor for :class:`~django.http.HttpResponse`
+to create a return class for any status code you like. For example::
+
+def my_view(request):
+# ...
+
+# Return a "created" (201) response code.
+return HttpResponse(status=201)
+
 Because 404 errors are by far the most common HTTP error, there's an easier way
 to handle those errors.
 


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Changeset] r9268 - django/trunk/docs/howto/deployment

[noreply]

Author: mtredinnick
Date: 2008-10-24 04:26:09 -0500 (Fri, 24 Oct 2008)
New Revision: 9268

Modified:
   django/trunk/docs/howto/deployment/modpython.txt
Log:
Fixed #9434 -- Added a note to the mod_python docs regarding requiring
PythonInterpreter in different VirtualHost blocks that share the same server
name. Thanks to Graham Dumpleton for the clarification.


Modified: django/trunk/docs/howto/deployment/modpython.txt
===
--- django/trunk/docs/howto/deployment/modpython.txt2008-10-24 09:25:32 UTC 
(rev 9267)
+++ django/trunk/docs/howto/deployment/modpython.txt2008-10-24 09:26:09 UTC 
(rev 9268)
@@ -160,7 +160,8 @@
 SetEnv DJANGO_SETTINGS_MODULE mysite.other_settings
 
 
-If you need to put two Django installations within the same ``VirtualHost``,
+If you need to put two Django installations within the same ``VirtualHost``
+(or in different ``VirtualHost`` blocks that share the same server name),
 you'll need to take a special precaution to ensure mod_python's cache doesn't
 mess things up. Use the ``PythonInterpreter`` directive to give different
  directives separate interpreters::


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Changeset] r9267 - django/trunk/docs/topics/db

[noreply]

Author: mtredinnick
Date: 2008-10-24 04:25:32 -0500 (Fri, 24 Oct 2008)
New Revision: 9267

Modified:
   django/trunk/docs/topics/db/queries.txt
Log:
Fixed #9432 -- Revived documentation of ~Q usage.


Modified: django/trunk/docs/topics/db/queries.txt
===
--- django/trunk/docs/topics/db/queries.txt 2008-10-24 09:24:42 UTC (rev 
9266)
+++ django/trunk/docs/topics/db/queries.txt 2008-10-24 09:25:32 UTC (rev 
9267)
@@ -601,8 +601,12 @@
 WHERE question LIKE 'Who%' OR question LIKE 'What%'
 
 You can compose statements of arbitrary complexity by combining ``Q`` objects
-with the ``&`` and ``|`` operators. You can also use parenthetical grouping.
+with the ``&`` and ``|`` operators and use parenthetical grouping. Also, ``Q``
+objects can be negated using the ``~`` operator, allowing for combined lookups
+that combine both a normal query and a negated (``NOT``) query::
 
+Q(question__startswith='Who') | ~Q(pub_date__year=2005)
+
 Each lookup function that takes keyword-arguments (e.g. ``filter()``,
 ``exclude()``, ``get()``) can also be passed one or more ``Q`` objects as
 positional (not-named) arguments. If you provide multiple ``Q`` object


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Changeset] r9266 - in django/trunk/docs: ref topics/http

[noreply]

Author: mtredinnick
Date: 2008-10-24 04:24:42 -0500 (Fri, 24 Oct 2008)
New Revision: 9266

Modified:
   django/trunk/docs/ref/request-response.txt
   django/trunk/docs/topics/http/views.txt
Log:
Fixed #9430 -- Fixed documentation references to the HttpResponse classes for
returning HTTP status codes other than 200.


Modified: django/trunk/docs/ref/request-response.txt
===
--- django/trunk/docs/ref/request-response.txt  2008-10-24 07:46:59 UTC (rev 
9265)
+++ django/trunk/docs/ref/request-response.txt  2008-10-24 09:24:42 UTC (rev 
9266)
@@ -525,6 +525,8 @@
 .. _HTTP Status code: 
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10
 
 
+.. _ref-httpresponse-subclasses:
+
 HttpResponse subclasses
 ---
 

Modified: django/trunk/docs/topics/http/views.txt
===
--- django/trunk/docs/topics/http/views.txt 2008-10-24 07:46:59 UTC (rev 
9265)
+++ django/trunk/docs/topics/http/views.txt 2008-10-24 09:24:42 UTC (rev 
9266)
@@ -64,11 +64,13 @@
 Returning errors
 
 
-Returning HTTP error codes in Django is easy. We've already mentioned the
-:class:`HttpResponseNotFound`, :class:`HttpResponseForbidden`,
-:class:`HttpResponseServerError`, etc., subclasses; just return an instance of 
one
-of those subclasses instead of a normal :class:`HttpResponse` in order to 
signify
-an error. For example::
+Returning HTTP error codes in Django is easy. There are subclasses of
+:class:`~django.http.HttpResponse` for a number of common HTTP status codes
+other than 200 (which means *"OK"*). You can find the full list of available
+subclasses in the :ref:`request/response `
+documentation.  Just return an instance of one of those subclasses instead of
+a normal :class:`~django.http.HttpResponse` in order to signify an error. For
+example::
 
 def my_view(request):
 # ...
@@ -77,6 +79,18 @@
 else:
 return HttpResponse('Page was found')
 
+There isn't a specialized subclass for every possible HTTP response code,
+since many of them aren't going to be that common. However, as documented in
+the :class:`~django.http.HttpResponse` documentation, you can also pass the
+HTTP status code into the constructor for :class:`~django.http.HttpResponse`
+to create a return class for any status code you like. For example::
+
+def my_view(request):
+# ...
+
+# Return a "created" (201) response code.
+return HttpResponse(status=201)
+
 Because 404 errors are by far the most common HTTP error, there's an easier way
 to handle those errors.
 


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #4604: session-based messages

[Django]

#4604: session-based messages
--+-
  Reporter:  Sean Patrick Hogan <[EMAIL PROTECTED]>  | Owner:  
SmileyChris
Status:  new  | Milestone:  
   
 Component:  Contrib apps |   Version:  
SVN
Resolution:   |  Keywords:  
   
 Stage:  Accepted | Has_patch:  
1  
Needs_docs:  0|   Needs_tests:  
0  
Needs_better_patch:  1|  
--+-
Changes (by zgoda):

 * cc: [EMAIL PROTECTED] (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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9419: Russian translation for "Currently:"

[Django]

#9419: Russian translation for "Currently:"
---+
  Reporter:  anonymous | Owner:  nobody 

Status:  new   | Milestone: 

 Component:  Translations  |   Version:  1.0

Resolution:|  Keywords:  Currently, russian, 
translation
 Stage:  Unreviewed| Has_patch:  0  

Needs_docs:  0 |   Needs_tests:  0  

Needs_better_patch:  0 |  
---+
Changes (by isagalaev):

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

Comment:

 "Современно" действительно кошмарно :-). Но мне кажется, что "Текущий"
 тоже не очень хорошо, потому что прилагательное придется согласовывать с
 именем поля по роду ("Фотография - текущий:"). Тут лучше всего пойдет
 наречие типа "Сейчас:"

 

 "Современно" is really ugly :-). But I think that "Текущий" is also not
 very good since an adjective has to be made agree with a field name in
 gender. It's better to use here an adverb (that doesn't has gender) like
 "Сейчас:"

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #8974: ModelChoiceField raises "ValueError: invalid literal for int() with base 10: 'abc'" when non-numerical value is supplied

[Django]

#8974: ModelChoiceField raises "ValueError: invalid literal for int() with base
10: 'abc'" when non-numerical value is supplied
+---
  Reporter:  burp_  | Owner:  nobody
Status:  new| Milestone:
 Component:  Uncategorized  |   Version:  1.0   
Resolution: |  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Comment (by guettli):

 The dpaste snippet has expired.

 To burp_: Please make the code available again.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Changeset] r9265 - django/branches/releases/1.0.X/django/conf/locale/zh_CN/LC_MESSAGES

[noreply]

Author: mtredinnick
Date: 2008-10-24 02:46:59 -0500 (Fri, 24 Oct 2008)
New Revision: 9265

Modified:
   django/branches/releases/1.0.X/django/conf/locale/zh_CN/LC_MESSAGES/django.mo
   django/branches/releases/1.0.X/django/conf/locale/zh_CN/LC_MESSAGES/django.po
Log:
[1.0.X] Fixed #9339 -- Small update to the Simplified Chinese translation from 
lidaobing.

This is the same typo fix as r9264 on trunk.


Modified: 
django/branches/releases/1.0.X/django/conf/locale/zh_CN/LC_MESSAGES/django.mo
===
(Binary files differ)

Modified: 
django/branches/releases/1.0.X/django/conf/locale/zh_CN/LC_MESSAGES/django.po
===
--- 
django/branches/releases/1.0.X/django/conf/locale/zh_CN/LC_MESSAGES/django.po   
2008-10-24 07:36:47 UTC (rev 9264)
+++ 
django/branches/releases/1.0.X/django/conf/locale/zh_CN/LC_MESSAGES/django.po   
2008-10-24 07:46:59 UTC (rev 9265)
@@ -1262,7 +1262,7 @@
 
 #: contrib/auth/models.py:143
 msgid "Designates that this user has all permissions without explicitly 
assigning them."
-msgstr "指明用户是否可以登录到这个管理站点。"
+msgstr "指明该用户缺省拥有所有权限。"
 
 #: contrib/auth/models.py:144
 msgid "last login"


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #9372: Updated Slovak (sk) translation

[Django]

#9372: Updated Slovak (sk) translation
---+
  Reporter:  mandre| Owner:  nobody  
Status:  closed| Milestone:  post-1.0
 Component:  Translations  |   Version:  SVN 
Resolution:  fixed |  Keywords:  
 Stage:  Unreviewed| Has_patch:  0   
Needs_docs:  0 |   Needs_tests:  0   
Needs_better_patch:  0 |  
---+
Changes (by mtredinnick):

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

Comment:

 As noted in [http://groups.google.com/group/Django-
 I18N/browse_frm/thread/a4b02c277de1872e this message to django-i18n], I'm
 only applying this to trunk. After it's had a chance for a few people to
 look at it, you might want to create a patch against the django-1.0.X
 branch as well.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #3712: Starting other processes in a view gives me some weird results.

[Django]

#3712: Starting other processes in a view gives me some weird results.
-+--
  Reporter:  Ino Pua <[EMAIL PROTECTED]>  | Owner:  adrian
Status:  closed  | Milestone:
 Component:  Core framework  |   Version:  SVN   
Resolution:  duplicate   |  Keywords:
 Stage:  Unreviewed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by mtredinnick):

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

Comment:

 Appears to be a duplicate of #9286 and since that's already open, I'm
 reclosing this one (the other ticket has more information available). If
 you have ''new'' information to help diagnosing #9286, please add it there
 (but use the "preview" button first and fix the formatting, since your
 comment here is unreadable). If you are just indicating that you also see
 the problem, there's not much point adding a comment, since we already
 know the issue exists.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Changeset] r9264 - django/trunk/django/conf/locale/zh_CN/LC_MESSAGES

[noreply]

Author: mtredinnick
Date: 2008-10-24 02:36:47 -0500 (Fri, 24 Oct 2008)
New Revision: 9264

Modified:
   django/trunk/django/conf/locale/zh_CN/LC_MESSAGES/django.mo
   django/trunk/django/conf/locale/zh_CN/LC_MESSAGES/django.po
Log:
Fixed #9339 -- Small update to the Simplified Chinese translation from 
lidaobing.


Modified: django/trunk/django/conf/locale/zh_CN/LC_MESSAGES/django.mo
===
(Binary files differ)

Modified: django/trunk/django/conf/locale/zh_CN/LC_MESSAGES/django.po
===
--- django/trunk/django/conf/locale/zh_CN/LC_MESSAGES/django.po 2008-10-24 
07:35:31 UTC (rev 9263)
+++ django/trunk/django/conf/locale/zh_CN/LC_MESSAGES/django.po 2008-10-24 
07:36:47 UTC (rev 9264)
@@ -1262,7 +1262,7 @@
 
 #: contrib/auth/models.py:143
 msgid "Designates that this user has all permissions without explicitly 
assigning them."
-msgstr "指明用户是否可以登录到这个管理站点。"
+msgstr "指明该用户缺省拥有所有权限。"
 
 #: contrib/auth/models.py:144
 msgid "last login"


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #3712: Starting other processes in a view gives me some weird results.

[Django]

#3712: Starting other processes in a view gives me some weird results.
-+--
  Reporter:  Ino Pua <[EMAIL PROTECTED]>  | Owner:  adrian
Status:  reopened| Milestone:
 Component:  Core framework  |   Version:  SVN   
Resolution:  |  Keywords:
 Stage:  Unreviewed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by krzysieksilnia):

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

Comment:

 = Heading =

 Environment:

 Request Method: GET
 Request URL: http://IP:8080/stop/
 Django Version: 1.0-final-SVN-unknown
 Python Version: 2.4.4
 Installed Applications:
 ['django.contrib.auth',
  'django.contrib.contenttypes',
  'django.contrib.sessions',
  'django.contrib.sites',
  'mysite.s1']
 Installed Middleware:
 ('django.middleware.common.CommonMiddleware',
  'django.contrib.sessions.middleware.SessionMiddleware',
  'django.contrib.auth.middleware.AuthenticationMiddleware')


 Traceback:
 File "/usr/lib/python2.4/site-packages/django/core/handlers/base.py" in
 get_response
   86. response = callback(request, *callback_args,
 **callback_kwargs)
 File "/home/user/Django-1.0/django/bin/mysite/../mysite/urls.py" in stop
   13. cmdname = request['cmd']

 Exception Type: TypeError at /stop/
 Exception Value: unsubscriptable object
 = Subheading =

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Changeset] r9262 - django/branches/releases/1.0.X/docs/howto

[noreply]

Author: mtredinnick
Date: 2008-10-24 02:21:04 -0500 (Fri, 24 Oct 2008)
New Revision: 9262

Modified:
   django/branches/releases/1.0.X/docs/howto/custom-model-fields.txt
Log:
[1.0.X] Fixed #9424 -- Typo fix.

Backport of r9258 from trunk.


Modified: django/branches/releases/1.0.X/docs/howto/custom-model-fields.txt
===
--- django/branches/releases/1.0.X/docs/howto/custom-model-fields.txt   
2008-10-24 07:20:29 UTC (rev 9261)
+++ django/branches/releases/1.0.X/docs/howto/custom-model-fields.txt   
2008-10-24 07:21:04 UTC (rev 9262)
@@ -167,7 +167,7 @@
 kwargs['max_length'] = 104
 super(HandField, self).__init__(*args, **kwargs)
 
-Our ``HandField`` accept most of the standard field options (see the list
+Our ``HandField`` accepts most of the standard field options (see the list
 below), but we ensure it has a fixed length, since it only needs to hold 52
 card values plus their suits; 104 characters in total.
 


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Changeset] r9261 - django/branches/releases/1.0.X/docs/ref/models

[noreply]

Author: mtredinnick
Date: 2008-10-24 02:20:29 -0500 (Fri, 24 Oct 2008)
New Revision: 9261

Modified:
   django/branches/releases/1.0.X/docs/ref/models/querysets.txt
Log:
[1.0.X] Fixed #9420 -- Fixed an exception type in the documentation of
Queryset.get().  Based on a suggestion from daveyjoe.

Backport of r9257 from trunk.


Modified: django/branches/releases/1.0.X/docs/ref/models/querysets.txt
===
--- django/branches/releases/1.0.X/docs/ref/models/querysets.txt
2008-10-24 07:19:45 UTC (rev 9260)
+++ django/branches/releases/1.0.X/docs/ref/models/querysets.txt
2008-10-24 07:20:29 UTC (rev 9261)
@@ -743,11 +743,13 @@
 Returns the object matching the given lookup parameters, which should be in
 the format described in `Field lookups`_.
 
-``get()`` raises ``AssertionError`` if more than one object was found.
+``get()`` raises ``MultipleObjectsReturned`` if more than one object was
+found. The ``MultipleObjectsReturned`` exception is an attribute of the model
+class.
 
-``get()`` raises a ``DoesNotExist`` exception if an object wasn't found for the
-given parameters. The ``DoesNotExist`` exception is an attribute of the model
-class. Example::
+``get()`` raises a ``DoesNotExist`` exception if an object wasn't found for
+the given parameters. This exception is also an attribute of the model class.
+Example::
 
 Entry.objects.get(id='foo') # raises Entry.DoesNotExist
 


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #6094: core handlers do not catch middleware exceptions

[Django]

#6094: core handlers do not catch middleware exceptions
+---
  Reporter:  gwilson| Owner:  gwilson 
Status:  assigned   | Milestone:  post-1.0
 Component:  HTTP handling  |   Version:  SVN 
Resolution: |  Keywords:  
 Stage:  Accepted   | Has_patch:  1   
Needs_docs:  0  |   Needs_tests:  0   
Needs_better_patch:  0  |  
+---
Changes (by isagalaev):

 * cc: [EMAIL PROTECTED] (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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Changeset] r9260 - django/branches/releases/1.0.X/docs/ref/models

[noreply]

Author: mtredinnick
Date: 2008-10-24 02:19:45 -0500 (Fri, 24 Oct 2008)
New Revision: 9260

Modified:
   django/branches/releases/1.0.X/docs/ref/models/querysets.txt
Log:
[1.0.X] Fixed #9390 -- Restored some documentation about select_related() that
was accidentally lost in the docs refactor.

Backport of r9256 from trunk.


Modified: django/branches/releases/1.0.X/docs/ref/models/querysets.txt
===
--- django/branches/releases/1.0.X/docs/ref/models/querysets.txt
2008-10-24 07:19:07 UTC (rev 9259)
+++ django/branches/releases/1.0.X/docs/ref/models/querysets.txt
2008-10-24 07:19:45 UTC (rev 9260)
@@ -511,8 +511,8 @@
 p = b.author # Hits the database.
 c = p.hometown   # Hits the database.
 
-Note that ``select_related()`` does not follow foreign keys that have
-``null=True``.
+Note that, by default, ``select_related()`` does not follow foreign keys that
+have ``null=True``.
 
 Usually, using ``select_related()`` can vastly improve performance because your
 app can avoid many database calls. However, in situations with deeply nested
@@ -527,9 +527,44 @@
 p = b.author # Doesn't hit the database.
 c = p.hometown   # Requires a database call.
 
+Sometimes you only want to access specific models that are related to your root
+model, not all of the related models. In these cases, you can pass the related
+field names to ``select_related()`` and it will only follow those relations.
+You can even do this for models that are more than one relation away by
+separating the field names with double underscores, just as for filters. For
+example, if you have this model::
+
+class Room(models.Model):
+# ...
+building = models.ForeignKey(...)
+
+class Group(models.Model):
+# ...
+teacher = models.ForeignKey(...)
+room = models.ForeignKey(Room)
+subject = models.ForeignKey(...)
+
+...and you only needed to work with the ``room`` and ``subject`` attributes,
+you could write this::
+
+g = Group.objects.select_related('room', 'subject')
+
+This is also valid::
+
+g = Group.objects.select_related('room__building', 'subject')
+
+...and would also pull in the ``building`` relation.
+
+You can only refer to ``ForeignKey`` relations in the list of fields passed to
+``select_related``. You *can* refer to foreign keys that have ``null=True``
+(unlike the default ``select_related()`` call). It's an error to use both a
+list of fields and the ``depth`` parameter in the same ``select_related()``
+call, since they are conflicting options.
+
 .. versionadded:: 1.0
 
-The ``depth`` argument is new in Django version 1.0.
+Both the ``depth`` argument and the ability to specify field names in the call
+to ``select_related()`` are new in Django version 1.0.
 
 ``extra(select=None, where=None, params=None, tables=None, order_by=None, 
select_params=None)``
 
~~~


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Changeset] r9259 - in django/branches/releases/1.0.X: django/forms docs/ref/forms

[noreply]

Author: mtredinnick
Date: 2008-10-24 02:19:07 -0500 (Fri, 24 Oct 2008)
New Revision: 9259

Modified:
   django/branches/releases/1.0.X/django/forms/fields.py
   django/branches/releases/1.0.X/docs/ref/forms/validation.txt
Log:
[1.0.X] Fixed #9384 -- Fixed a couple of typos. Thanks, Thomas G?\195?\188ttler 
and romke.

Backport of r9255 from trunk.


Modified: django/branches/releases/1.0.X/django/forms/fields.py
===
--- django/branches/releases/1.0.X/django/forms/fields.py   2008-10-24 
07:16:23 UTC (rev 9258)
+++ django/branches/releases/1.0.X/django/forms/fields.py   2008-10-24 
07:19:07 UTC (rev 9259)
@@ -667,7 +667,7 @@
 self.coerce = kwargs.pop('coerce', lambda val: val)
 self.empty_value = kwargs.pop('empty_value', '')
 super(TypedChoiceField, self).__init__(*args, **kwargs)
-
+
 def clean(self, value):
 """
 Validate that the value is in self.choices and can be coerced to the
@@ -676,12 +676,12 @@
 value = super(TypedChoiceField, self).clean(value)
 if value == self.empty_value or value in EMPTY_VALUES:
 return self.empty_value
-
+
 # Hack alert: This field is purpose-made to use with Field.to_python as
 # a coercion function so that ModelForms with choices work. However,
-# Django's Field.to_python raises 
django.core.exceptions.ValidationError,
-# which is a *different* exception than
-# django.forms.utils.ValidationError. So unfortunatly we need to catch
+# Django's Field.to_python raises
+# django.core.exceptions.ValidationError, which is a *different*
+# exception than django.forms.util.ValidationError. So we need to catch
 # both.
 try:
 value = self.coerce(value)

Modified: django/branches/releases/1.0.X/docs/ref/forms/validation.txt
===
--- django/branches/releases/1.0.X/docs/ref/forms/validation.txt
2008-10-24 07:16:23 UTC (rev 9258)
+++ django/branches/releases/1.0.X/docs/ref/forms/validation.txt
2008-10-24 07:19:07 UTC (rev 9259)
@@ -100,10 +100,10 @@
 
 When you really do need to attach the error to a particular field, you should
 store (or amend) a key in the `Form._errors` attribute. This attribute is an
-instance of a ``django.form.utils.ErrorDict`` class. Essentially, though, it's
+instance of a ``django.forms.util.ErrorDict`` class. Essentially, though, it's
 just a dictionary. There is a key in the dictionary for each field in the form
 that has an error. Each value in the dictionary is a
-``django.form.utils.ErrorList`` instance, which is a list that knows how to
+``django.forms.util.ErrorList`` instance, which is a list that knows how to
 display itself in different ways. So you can treat `_errors` as a dictionary
 mapping field names to lists.
 


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Changeset] r9258 - django/trunk/docs/howto

[noreply]

Author: mtredinnick
Date: 2008-10-24 02:16:23 -0500 (Fri, 24 Oct 2008)
New Revision: 9258

Modified:
   django/trunk/docs/howto/custom-model-fields.txt
Log:
Fixed #9424 -- Typo fix.


Modified: django/trunk/docs/howto/custom-model-fields.txt
===
--- django/trunk/docs/howto/custom-model-fields.txt 2008-10-24 07:15:52 UTC 
(rev 9257)
+++ django/trunk/docs/howto/custom-model-fields.txt 2008-10-24 07:16:23 UTC 
(rev 9258)
@@ -167,7 +167,7 @@
 kwargs['max_length'] = 104
 super(HandField, self).__init__(*args, **kwargs)
 
-Our ``HandField`` accept most of the standard field options (see the list
+Our ``HandField`` accepts most of the standard field options (see the list
 below), but we ensure it has a fixed length, since it only needs to hold 52
 card values plus their suits; 104 characters in total.
 


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Changeset] r9257 - django/trunk/docs/ref/models

[noreply]

Author: mtredinnick
Date: 2008-10-24 02:15:52 -0500 (Fri, 24 Oct 2008)
New Revision: 9257

Modified:
   django/trunk/docs/ref/models/querysets.txt
Log:
Fixed #9420 -- Fixed an exception type in the documentation of Queryset.get().
Based on a suggestion from daveyjoe.


Modified: django/trunk/docs/ref/models/querysets.txt
===
--- django/trunk/docs/ref/models/querysets.txt  2008-10-24 07:15:07 UTC (rev 
9256)
+++ django/trunk/docs/ref/models/querysets.txt  2008-10-24 07:15:52 UTC (rev 
9257)
@@ -743,11 +743,13 @@
 Returns the object matching the given lookup parameters, which should be in
 the format described in `Field lookups`_.
 
-``get()`` raises ``AssertionError`` if more than one object was found.
+``get()`` raises ``MultipleObjectsReturned`` if more than one object was
+found. The ``MultipleObjectsReturned`` exception is an attribute of the model
+class.
 
-``get()`` raises a ``DoesNotExist`` exception if an object wasn't found for the
-given parameters. The ``DoesNotExist`` exception is an attribute of the model
-class. Example::
+``get()`` raises a ``DoesNotExist`` exception if an object wasn't found for
+the given parameters. This exception is also an attribute of the model class.
+Example::
 
 Entry.objects.get(id='foo') # raises Entry.DoesNotExist
 


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Changeset] r9256 - django/trunk/docs/ref/models

[noreply]

Author: mtredinnick
Date: 2008-10-24 02:15:07 -0500 (Fri, 24 Oct 2008)
New Revision: 9256

Modified:
   django/trunk/docs/ref/models/querysets.txt
Log:
Fixed #9390 -- Restored some documentation about select_related() that was
accidentally lost in the docs refactor.


Modified: django/trunk/docs/ref/models/querysets.txt
===
--- django/trunk/docs/ref/models/querysets.txt  2008-10-24 07:14:30 UTC (rev 
9255)
+++ django/trunk/docs/ref/models/querysets.txt  2008-10-24 07:15:07 UTC (rev 
9256)
@@ -511,8 +511,8 @@
 p = b.author # Hits the database.
 c = p.hometown   # Hits the database.
 
-Note that ``select_related()`` does not follow foreign keys that have
-``null=True``.
+Note that, by default, ``select_related()`` does not follow foreign keys that
+have ``null=True``.
 
 Usually, using ``select_related()`` can vastly improve performance because your
 app can avoid many database calls. However, in situations with deeply nested
@@ -527,9 +527,44 @@
 p = b.author # Doesn't hit the database.
 c = p.hometown   # Requires a database call.
 
+Sometimes you only want to access specific models that are related to your root
+model, not all of the related models. In these cases, you can pass the related
+field names to ``select_related()`` and it will only follow those relations.
+You can even do this for models that are more than one relation away by
+separating the field names with double underscores, just as for filters. For
+example, if you have this model::
+
+class Room(models.Model):
+# ...
+building = models.ForeignKey(...)
+
+class Group(models.Model):
+# ...
+teacher = models.ForeignKey(...)
+room = models.ForeignKey(Room)
+subject = models.ForeignKey(...)
+
+...and you only needed to work with the ``room`` and ``subject`` attributes,
+you could write this::
+
+g = Group.objects.select_related('room', 'subject')
+
+This is also valid::
+
+g = Group.objects.select_related('room__building', 'subject')
+
+...and would also pull in the ``building`` relation.
+
+You can only refer to ``ForeignKey`` relations in the list of fields passed to
+``select_related``. You *can* refer to foreign keys that have ``null=True``
+(unlike the default ``select_related()`` call). It's an error to use both a
+list of fields and the ``depth`` parameter in the same ``select_related()``
+call, since they are conflicting options.
+
 .. versionadded:: 1.0
 
-The ``depth`` argument is new in Django version 1.0.
+Both the ``depth`` argument and the ability to specify field names in the call
+to ``select_related()`` are new in Django version 1.0.
 
 ``extra(select=None, where=None, params=None, tables=None, order_by=None, 
select_params=None)``
 
~~~


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Changeset] r9255 - in django/trunk: django/forms docs/ref/forms

[noreply]

Author: mtredinnick
Date: 2008-10-24 02:14:30 -0500 (Fri, 24 Oct 2008)
New Revision: 9255

Modified:
   django/trunk/django/forms/fields.py
   django/trunk/docs/ref/forms/validation.txt
Log:
Fixed #9384 -- Fixed a couple of typos. Thanks, Thomas G?\195?\188ttler and 
romke.


Modified: django/trunk/django/forms/fields.py
===
--- django/trunk/django/forms/fields.py 2008-10-24 06:24:04 UTC (rev 9254)
+++ django/trunk/django/forms/fields.py 2008-10-24 07:14:30 UTC (rev 9255)
@@ -667,7 +667,7 @@
 self.coerce = kwargs.pop('coerce', lambda val: val)
 self.empty_value = kwargs.pop('empty_value', '')
 super(TypedChoiceField, self).__init__(*args, **kwargs)
-
+
 def clean(self, value):
 """
 Validate that the value is in self.choices and can be coerced to the
@@ -676,12 +676,12 @@
 value = super(TypedChoiceField, self).clean(value)
 if value == self.empty_value or value in EMPTY_VALUES:
 return self.empty_value
-
+
 # Hack alert: This field is purpose-made to use with Field.to_python as
 # a coercion function so that ModelForms with choices work. However,
-# Django's Field.to_python raises 
django.core.exceptions.ValidationError,
-# which is a *different* exception than
-# django.forms.utils.ValidationError. So unfortunatly we need to catch
+# Django's Field.to_python raises
+# django.core.exceptions.ValidationError, which is a *different*
+# exception than django.forms.util.ValidationError. So we need to catch
 # both.
 try:
 value = self.coerce(value)

Modified: django/trunk/docs/ref/forms/validation.txt
===
--- django/trunk/docs/ref/forms/validation.txt  2008-10-24 06:24:04 UTC (rev 
9254)
+++ django/trunk/docs/ref/forms/validation.txt  2008-10-24 07:14:30 UTC (rev 
9255)
@@ -100,10 +100,10 @@
 
 When you really do need to attach the error to a particular field, you should
 store (or amend) a key in the `Form._errors` attribute. This attribute is an
-instance of a ``django.form.utils.ErrorDict`` class. Essentially, though, it's
+instance of a ``django.forms.util.ErrorDict`` class. Essentially, though, it's
 just a dictionary. There is a key in the dictionary for each field in the form
 that has an error. Each value in the dictionary is a
-``django.form.utils.ErrorList`` instance, which is a list that knows how to
+``django.forms.util.ErrorList`` instance, which is a list that knows how to
 display itself in different ways. So you can treat `_errors` as a dictionary
 mapping field names to lists.
 


--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---