Re: [Django] #14238: admin-interface and formsets: ordered_forms are not returned in case of errors

[Django]

#14238: admin-interface and formsets: ordered_forms are not returned in case of
errors
+---
  Reporter:  sehmasch...@gmail.com  | Owner:  nobody
Status:  closed | Milestone:
 Component:  django.contrib.admin   |   Version:  1.2   
Resolution:  invalid|  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by julien):

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

Comment:

 I think #11801 is a different issue. In your case, the forms are displayed
 in the wrong order probably because the objects haven't been saved
 (because there was a validation error) and because the ordering is
 probably based on the values that are stored in the database and not the
 values that are temporarily "stored" in the forms. It looks like you would
 have to use some custom javascript to reorder the inlines based on the
 values that are in the forms.

 In any case, there's not much we can do without seeing any specific test
 case, so I'm marking this ticket as invalid. Feel free to reopen if you
 can provide such a detailed test case (e.g. models, admin configurations,
 etc). You may also try asking for help on the Django user mailing list:
 http://groups.google.com/group/django-users/topics

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

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

Re: [Django] #13917: Multiple popup window feature of related objects popup through id_to_windowname

[Django]

#13917: Multiple popup window feature of related objects popup through
id_to_windowname
-+--
  Reporter:  davidcooper | Owner:  nobody
Status:  new | Milestone:
 Component:  django.contrib.admin|   Version:  1.2   
Resolution:  |  Keywords:
 Stage:  Design decision needed  | Has_patch:  1 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  1   |  
-+--
Changes (by julien):

  * needs_better_patch:  => 1
  * stage:  Unreviewed => Design decision needed
  * needs_tests:  => 0
  * needs_docs:  => 0

Comment:

 This sounds interesting. Marking as DDN as it's unclear what the
 implications would be. Could you provide a more specific use case for
 this? Any proof that your suggested change wouldn't break any existing
 code would also be appreciated.

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

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

Re: [Django] #14839: django admin and user model inheritance

[Django]

#14839: django admin and user model inheritance
+---
  Reporter:  anonymous  | Owner:  nobody
Status:  closed | Milestone:
 Component:  Uncategorized  |   Version:  1.2   
Resolution:  invalid|  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by julien):

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

Comment:

 Replying to [ticket:14839 anonymous]:
 > From a functional point of view if I extend the "User" class I want to
 see in the admin only the extended class and not the original "User" class
 so the delete permission on the "User" objects should be implicit if I
 give the delete permission on the UserInfo object.

 Thanks for your suggestion. While this might be an interesting use case,
 this is not how inheritance and permissions are designed to work in
 Django. It seems that what you want to achieve could reasonably easily be
 done with a customised ModelAdmin class. If you need any help about this,
 I suggest you ask on the django user mailing list:
 http://groups.google.com/group/django-users/topics

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

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

Re: [Django] #13774: add optional rel_db_type() method for model field

[Django]

#13774: add optional rel_db_type() method for model field
---+
  Reporter:  Suor  | Owner:  Suor   
   
Status:  reopened  | Milestone: 
   
 Component:  Database layer (models, ORM)  |   Version:  1.2
   
Resolution:|  Keywords:  db, 
ForeignKey, related fields
 Stage:  Accepted  | Has_patch:  1  
   
Needs_docs:  1 |   Needs_tests:  1  
   
Needs_better_patch:  0 |  
---+
Changes (by russellm):

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

Comment:

 Ok - this makes a little more sense now. It still needs tests and
 documentation, however.

 I also have a sneaking suspicion that this may be linked with #11319.

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

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

Re: [Django] #13764: i18n in custom javascript

[Django]

#13764: i18n in custom javascript
---+
  Reporter:  sebastian_noack   | Owner:  nobody
Status:  new   | Milestone:
 Component:  django.contrib.admin  |   Version:  1.2   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  1 |  
---+
Changes (by russellm):

  * needs_better_patch:  0 => 1
  * summary:  i18n in custum javascript [PATCH] => i18n in custom
  javascript
  * stage:  Unreviewed => Accepted

Comment:

 I'm going to accept this as a problem description, but not as a proposed
 fix. The problem clearly exists, but moving i18n into a per-model
 definition seems like the wrong approach to me. This would result in a
 proliferation of little jsi18n scripts, when what you really want is one
 good script that is composed of all the little extensions. There's no
 reason these extensions can't be defined on a per-model basis, but I don't
 see why they need to be served on a per-model basis.

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

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

Re: [Django] #13696: Admin Edit Inline templates only output hidden field for PK when inline_admin_form.has_auto_field

[Django]

#13696: Admin Edit Inline templates only output hidden field for PK when
inline_admin_form.has_auto_field
+---
  Reporter:  evan.rei...@gmail.com  | Owner:  nobody  
Status:  reopened   | Milestone:  
 Component:  django.contrib.admin   |   Version:  1.2 
Resolution: |  Keywords:  inline templates
 Stage:  Accepted   | Has_patch:  0   
Needs_docs:  0  |   Needs_tests:  0   
Needs_better_patch:  0  |  
+---
Changes (by russellm):

  * stage:  Unreviewed => Accepted

Comment:

 The combination of editable=False and a non-auto primary key field appears
 to be the key here. On first inspection, it looks to me like the inlines
 should be looking for a "is primary key and not editable", rather than "is
 AutoField", as the condition for displaying the hidden ID column.

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

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

Re: [Django] #13670: postgis adapter fails to compare against empty string

[Django]

#13670: postgis adapter fails to compare against empty string
---+
  Reporter:  milosu| Owner:  nobody
Status:  new   | Milestone:
 Component:  GIS   |   Version:  1.2   
Resolution:|  Keywords:
 Stage:  Accepted  | Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by russellm):

  * stage:  Unreviewed => Accepted

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

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

Re: [Django] #12789: ConditionalGetMiddleware behavior improvement.

[Django]

#12789: ConditionalGetMiddleware behavior improvement.
-+--
  Reporter:  penzoil | Owner:  nobody   
 
Status:  new | Milestone:   
 
 Component:  Cache system|   Version:  SVN  
 
Resolution:  |  Keywords:  ETag, 
ConditionalGetMiddleware, patch_response_headers
 Stage:  Design decision needed  | Has_patch:  1
 
Needs_docs:  0   |   Needs_tests:  1
 
Needs_better_patch:  0   |  
-+--
Changes (by russellm):

  * stage:  Unreviewed => Design decision needed

Comment:

 Reverting to DDN. The problem seems real, but we need to work out the
 right solution. Some programatic test cases would help considerably.

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

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

Re: [Django] #1908: Having an app name the same as project name breaks manage.py ( unable to import projectname.settings )

[Django]

#1908: Having an app name the same as project name breaks manage.py ( unable to
import projectname.settings )
-+--
  Reporter:  si...@simon.net.nz  | Owner:  adrian
Status:  reopened| Milestone:
 Component:  django-admin.py |   Version:  SVN   
Resolution:  |  Keywords:
 Stage:  Accepted| Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by russellm):

  * stage:  Unreviewed => Accepted

Comment:

 Accepted on the basis that the error message should be more helpful.
 However, "more helpful" in this case should probably be interpreted as
 "don't mess around with PYTHONPATH in the first place". This problem only
 exists because of the way manage.py temporarily alters PYTHONPATH, which
 is a bit of a glitch (and cause of more than a little confusion).

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

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

Re: [Django] #14976: Add is_html flag to contrib.messages

[Django]

#14976: Add is_html flag to contrib.messages
---+
  Reporter:  tedtieken | Owner:  nobody
Status:  new   | Milestone:
 Component:  Contrib apps  |   Version:  1.2   
Resolution:|  Keywords:  safe, messages
 Stage:  Accepted  | Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by lukeplant):

  * summary:  Add is_safe flag to contrib.messages => Add is_html flag to
  contrib.messages
  * stage:  Unreviewed => Accepted

Old description:

> I would like to have add a message.is_safe flag to the Message model of
> the contrib.messages app.[[BR]]
> [[BR]]
> The flag would be set to False by default and could be explicitly
> overridden for trusted messages.  There are times when it would be
> helpful to the end user to include an html link in a message ("Welcome,
> click here to create a profile", "You've sent 25 points to user_b, click
> here to see your balance," etc.), and with the current message system
> there is not a good way to do this.[[BR]]
> [[BR]]
>
> Adding the is_safe flag would require a minor set of backward compatible
> changes:[[BR]]
>
> {{{
> def success(request, message, extra_tags='', fail_silently=False):
> to
> def success(request, message, extra_tags='', fail_silently=False,
> is_safe=False):
>
> def add_message(request, level, message, extra_tags='',
> fail_silently=False):
> to
> def add_message(request, level, message, extra_tags='',
> fail_silently=False, is_safe=False):
>
> def __init__(self, level, message, extra_tags=None):
> to
> def __init__(self, level, message, extra_tags=None, is_safe=False):
>
> #add to __init__
> self.is_safe = is_safe
> }}}
>
> Then in the template: {% if message.is_safe %} {{ message|safe }}{% else
> %}{{ message }}{% endif %}.[[BR]]
> [[BR]]
>

> Alternative ways to do this:[[BR]]
> 1. Run all messages through the safe filter[[BR]]
> This would require a code-wide policy of "make sure you escape anything
> in a message that might have user input" such as if my message is "your
> post %s is now published" % blog.post or "%s has sent you the message %s"
> %(user, message.content).   I would then have to worry about every
> variable I use in a message string, if it could contain script, and if it
> is already escaped (or escape everything again).  I would also have to
> worry if everyone else working on the codebase is doing this correctly.
> [[BR]]
>
> 2.Use a tag[[BR]]
> I could have a policy of adding "safe" to the tags I want to run through
> the safe filter, but this is also fraught with downsides.  Since all tags
> get output into html, the safe flag would end up output to the end user.
> The template logic is less clear and error prone {{ "test" in
> message.extra_tags }} would work, but would return a false positive if
> you tried to use "contest" as a tag.  Granted "contest" as a message tag
> is a rare case; it is just another layer of messiness of security code
> mashed in with markup.[[BR]]
> [[BR]]
> If this isn't violating a core django design precept, I'll get started on
> a patch in the next few days.

New description:

 I would like to have add a message.is_html flag to the Message model of
 the contrib.messages app.

 The flag would be set to False by default and could be explicitly
 overridden for messages that are HTML.  There are times when it would be
 helpful to the end user to include an html link in a message ("Welcome,
 click here to create a profile", "You've sent 25 points to user_b, click
 here to see your balance," etc.), and with the current message system
 there is not a good way to do this.

 Adding the is_html flag would require a minor set of backward compatible
 changes:

 {{{
 def success(request, message, extra_tags='', fail_silently=False):
 to
 def success(request, message, extra_tags='', fail_silently=False,
 is_html=False):

 def add_message(request, level, message, extra_tags='',
 fail_silently=False):
 to
 def add_message(request, level, message, extra_tags='',
 fail_silently=False, is_html=False):

 def __init__(self, level, message, extra_tags=None):
 to
 def __init__(self, level, message, extra_tags=None, is_html=False):

 #add to __init__
 self.is_html = is_html
 }}}

 Then in the template:
 {{{
 {% if message.is_html %}{{ message|safe }}{% else %}{{ message }}{% endif
 %}.
 }}}


 Alternative ways to do this:


  1. Run all messages through the safe filter[[BR]][[BR]]
  This would require a code-wide policy of "make sure you escape anything
 in a message that might have user input" such as if my message is "your
 post %s is now published" % blog.post or "%s has sent you the message %s"
 %(user, message.content).   I would then 

Re: [Django] #14842: Indent the Model Meta Options

[Django]

#14842: Indent the Model Meta Options
+---
  Reporter:  adamv  | Owner:  nobody
Status:  reopened   | Milestone:
 Component:  Documentation  |   Version:  SVN   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  1  |  
+---
Comment (by adamv):

 I'll rebase and re-edit this against trunk, maybe tonight. If not, then
 some time this week.

 As far as the "table names" goes, I'll have to dig up my notes and see why
 I moved it.

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

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

Re: [Django] #14842: Indent the Model Meta Options

[Django]

#14842: Indent the Model Meta Options
+---
  Reporter:  adamv  | Owner:  nobody
Status:  reopened   | Milestone:
 Component:  Documentation  |   Version:  SVN   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  1  |  
+---
Changes (by timo):

  * needs_better_patch:  0 => 1

Comment:

 Hey Adam, unfortunately the patch no longer applies cleanly to trunk.  If
 you can easily rebase, that would be great.  Also, the section "Tables
 names" seems a bit out of place at the top of the page instead of within
 the Options.db_table section.  Is the issue that the link won't resolve
 properly?  If that's the case, I'd say maybe we could remove the table-
 names link and just use the link to Options.db_table instead. Thanks for
 all your work, Tim

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

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

Re: [Django] #9964: Transaction middleware closes the transaction only when it's marked as dirty

[Django]

#9964: Transaction middleware closes the transaction only when it's marked as
dirty
---+
  Reporter:  ishirav   | Owner:  
mtredinnick 
Status:  assigned  | Milestone:  1.3
 
 Component:  Database layer (models, ORM)  |   Version:  1.0-beta-1 
 
Resolution:|  Keywords:  
transactions
 Stage:  Accepted  | Has_patch:  1  
 
Needs_docs:  0 |   Needs_tests:  0  
 
Needs_better_patch:  0 |  
---+
Comment (by shai):

 (in case my last comment wasn't clear: I haven't made changes to the main
 code because I hope my arguments [comment:44 above] convince Jacob and
 Russell that such changes are not necessary.

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

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

[Changeset] r15077 - django/trunk/docs/topics

[noreply]

Author: timo
Date: 2010-12-27 19:04:43 -0600 (Mon, 27 Dec 2010)
New Revision: 15077

Modified:
   django/trunk/docs/topics/class-based-views.txt
Log:
Fixed #14682 - Add a note with an example of the explicit template location for 
class based views.  Thanks PaulM for the suggestion, adamv for the patch.

Modified: django/trunk/docs/topics/class-based-views.txt
===
--- django/trunk/docs/topics/class-based-views.txt  2010-12-28 00:13:13 UTC 
(rev 15076)
+++ django/trunk/docs/topics/class-based-views.txt  2010-12-28 01:04:43 UTC 
(rev 15077)
@@ -154,6 +154,13 @@
 app that defines the model, while the "publisher" bit is just the lowercased
 version of the model's name.
 
+.. note::
+Thus, when (for example) the 
:class:`django.template.loaders.app_directories.Loader`
+template loader is enabled in :setting:`TEMPLATE_LOADERS`, the template
+location would be::
+
+/path/to/project/books/templates/books/publisher_list.html
+
 .. highlightlang:: html+django
 
 This template will be rendered against a context containing a variable called

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

Re: [Django] #14976: Add is_safe flag to contrib.messages

[Django]

#14976: Add is_safe flag to contrib.messages
---+
  Reporter:  tedtieken | Owner:  nobody
Status:  new   | Milestone:
 Component:  Contrib apps  |   Version:  1.2   
Resolution:|  Keywords:  safe, messages
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by tedtieken):

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

Comment:

 * would like to add

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

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

[Django] #14976: Add is_safe flag to contrib.messages

[Django]

#14976: Add is_safe flag to contrib.messages
+---
 Reporter:  tedtieken   |   Owner:  nobody
   Status:  new |   Milestone:
Component:  Contrib apps| Version:  1.2   
 Keywords:  safe, messages  |   Stage:  Unreviewed
Has_patch:  0   |  
+---
 I would like to have add a message.is_safe flag to the Message model of
 the contrib.messages app.[[BR]]
 [[BR]]
 The flag would be set to False by default and could be explicitly
 overridden for trusted messages.  There are times when it would be helpful
 to the end user to include an html link in a message ("Welcome, click here
 to create a profile", "You've sent 25 points to user_b, click here to see
 your balance," etc.), and with the current message system there is not a
 good way to do this.[[BR]]
 [[BR]]

 Adding the is_safe flag would require a minor set of backward compatible
 changes:[[BR]]

 {{{
 def success(request, message, extra_tags='', fail_silently=False):
 to
 def success(request, message, extra_tags='', fail_silently=False,
 is_safe=False):

 def add_message(request, level, message, extra_tags='',
 fail_silently=False):
 to
 def add_message(request, level, message, extra_tags='',
 fail_silently=False, is_safe=False):

 def __init__(self, level, message, extra_tags=None):
 to
 def __init__(self, level, message, extra_tags=None, is_safe=False):

 #add to __init__
 self.is_safe = is_safe
 }}}

 Then in the template: {% if message.is_safe %} {{ message|safe }}{% else
 %}{{ message }}{% endif %}.[[BR]]
 [[BR]]


 Alternative ways to do this:[[BR]]
 1. Run all messages through the safe filter[[BR]]
 This would require a code-wide policy of "make sure you escape anything in
 a message that might have user input" such as if my message is "your post
 %s is now published" % blog.post or "%s has sent you the message %s"
 %(user, message.content).   I would then have to worry about every
 variable I use in a message string, if it could contain script, and if it
 is already escaped (or escape everything again).  I would also have to
 worry if everyone else working on the codebase is doing this correctly.
 [[BR]]

 2.Use a tag[[BR]]
 I could have a policy of adding "safe" to the tags I want to run through
 the safe filter, but this is also fraught with downsides.  Since all tags
 get output into html, the safe flag would end up output to the end user.
 The template logic is less clear and error prone {{ "test" in
 message.extra_tags }} would work, but would return a false positive if you
 tried to use "contest" as a tag.  Granted "contest" as a message tag is a
 rare case; it is just another layer of messiness of security code mashed
 in with markup.[[BR]]
 [[BR]]
 If this isn't violating a core django design precept, I'll get started on
 a patch in the next few days.

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

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

[Changeset] r15076 - django/branches/releases/1.2.X/docs/ref/contrib/gis

[noreply]

Author: timo
Date: 2010-12-27 18:13:13 -0600 (Mon, 27 Dec 2010)
New Revision: 15076

Modified:
   django/branches/releases/1.2.X/docs/ref/contrib/gis/install.txt
Log:
[1.2.X] Fixed #13837 - Add geodjango packages for Ubuntu 10.04; thanks muanis 
and zerok for the patch.

Backport of r15075 from trunk.

Modified: django/branches/releases/1.2.X/docs/ref/contrib/gis/install.txt
===
--- django/branches/releases/1.2.X/docs/ref/contrib/gis/install.txt 
2010-12-28 00:12:49 UTC (rev 15075)
+++ django/branches/releases/1.2.X/docs/ref/contrib/gis/install.txt 
2010-12-28 00:13:13 UTC (rev 15076)
@@ -943,7 +943,8 @@
 
 Use the synaptic package manager to install the following packages::
 
-$ sudo apt-get install binutils libgdal1-1.5.0 postgresql-8.3-postgis 
postgresql-server-dev-8.3 python-psycopg2 python-setuptools
+$ sudo apt-get install binutils libgdal1-1.5.0 postgresql-8.3-postgis \
+postgresql-server-dev-8.3 python-psycopg2 python-setuptools
 
 Afterwards, you may install Django with Python's ``easy_install`` script (the
 Ubuntu package ``python-django`` uses an older version missing several
@@ -969,6 +970,17 @@
 * ``gdal-bin``: for GDAL command line programs like ``ogr2ogr``
 * ``python-gdal`` for GDAL's own Python bindings -- includes interfaces for 
raster manipulation
 
+10.04
+~
+
+In Ubuntu 10.04 LTS PostgreSQL was upgraded to 8.4, as was GDAL, which is now
+at version 1.6.0. Because of that, the package installation mentioned above
+has to be slightly changed::
+
+   $ sudo apt-get install binutils libgdal1-1.6.0 postgresql-8.4-postgis \
+postgresql-server-dev-8.4 python-psycopg2 python-setuptools
+
+
 .. note::
 
 The Ubuntu ``proj`` package does not come with the datum shifting files

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

[Changeset] r15075 - django/trunk/docs/ref/contrib/gis

[noreply]

Author: timo
Date: 2010-12-27 18:12:49 -0600 (Mon, 27 Dec 2010)
New Revision: 15075

Modified:
   django/trunk/docs/ref/contrib/gis/install.txt
Log:
Fixed #13837 - Add geodjango packages for Ubuntu 10.04; thanks muanis and zerok 
for the patch.

Modified: django/trunk/docs/ref/contrib/gis/install.txt
===
--- django/trunk/docs/ref/contrib/gis/install.txt   2010-12-27 23:58:41 UTC 
(rev 15074)
+++ django/trunk/docs/ref/contrib/gis/install.txt   2010-12-28 00:12:49 UTC 
(rev 15075)
@@ -943,7 +943,8 @@
 
 Use the synaptic package manager to install the following packages::
 
-$ sudo apt-get install binutils libgdal1-1.5.0 postgresql-8.3-postgis 
postgresql-server-dev-8.3 python-psycopg2 python-setuptools
+$ sudo apt-get install binutils libgdal1-1.5.0 postgresql-8.3-postgis \
+postgresql-server-dev-8.3 python-psycopg2 python-setuptools
 
 Afterwards, you may install Django with Python's ``easy_install`` script (the
 Ubuntu package ``python-django`` uses an older version missing several
@@ -969,6 +970,17 @@
 * ``gdal-bin``: for GDAL command line programs like ``ogr2ogr``
 * ``python-gdal`` for GDAL's own Python bindings -- includes interfaces for 
raster manipulation
 
+10.04
+~
+
+In Ubuntu 10.04 LTS PostgreSQL was upgraded to 8.4, as was GDAL, which is now
+at version 1.6.0. Because of that, the package installation mentioned above
+has to be slightly changed::
+
+   $ sudo apt-get install binutils libgdal1-1.6.0 postgresql-8.4-postgis \
+postgresql-server-dev-8.4 python-psycopg2 python-setuptools
+
+
 .. note::
 
 The Ubuntu ``proj`` package does not come with the datum shifting files

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

[Changeset] r15074 - django/branches/releases/1.2.X/docs

[noreply]

Author: timo
Date: 2010-12-27 17:58:41 -0600 (Mon, 27 Dec 2010)
New Revision: 15074

Modified:
   django/branches/releases/1.2.X/docs/contents.txt
Log:
[1.2.X] Fixed #13397 - Include third level headings in the TOC. thanks cyang 
for the suggestion, rleland for the patch.

Backport of r15073 from trunk.

Modified: django/branches/releases/1.2.X/docs/contents.txt
===
--- django/branches/releases/1.2.X/docs/contents.txt2010-12-27 23:58:16 UTC 
(rev 15073)
+++ django/branches/releases/1.2.X/docs/contents.txt2010-12-27 23:58:41 UTC 
(rev 15074)
@@ -10,7 +10,7 @@
 index
 
 .. toctree::
-:maxdepth: 2
+:maxdepth: 3
 
 intro/index
 topics/index

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

[Changeset] r15073 - django/trunk/docs

[noreply]

Author: timo
Date: 2010-12-27 17:58:16 -0600 (Mon, 27 Dec 2010)
New Revision: 15073

Modified:
   django/trunk/docs/contents.txt
Log:
Fixed #13397 - Include third level headings in the TOC. thanks cyang for the 
suggestion, rleland for the patch.

Modified: django/trunk/docs/contents.txt
===
--- django/trunk/docs/contents.txt  2010-12-27 23:47:14 UTC (rev 15072)
+++ django/trunk/docs/contents.txt  2010-12-27 23:58:16 UTC (rev 15073)
@@ -10,7 +10,7 @@
 index
 
 .. toctree::
-:maxdepth: 2
+:maxdepth: 3
 
 intro/index
 topics/index

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

[Changeset] r15072 - django/branches/releases/1.2.X/docs/topics/db

[noreply]

Author: timo
Date: 2010-12-27 17:47:14 -0600 (Mon, 27 Dec 2010)
New Revision: 15072

Modified:
   django/branches/releases/1.2.X/docs/topics/db/models.txt
Log:
[1.2.X] Fixed #12313 - Add a note that QuerySet.delete() doesn't necessarily 
call obj.delete(). thanks FunkyELF for the suggestion.

Backport of r15071 from trunk.

Modified: django/branches/releases/1.2.X/docs/topics/db/models.txt
===
--- django/branches/releases/1.2.X/docs/topics/db/models.txt2010-12-27 
23:46:06 UTC (rev 15071)
+++ django/branches/releases/1.2.X/docs/topics/db/models.txt2010-12-27 
23:47:14 UTC (rev 15072)
@@ -751,6 +751,14 @@
 **kwargs`` in your method definitions, you are guaranteed that your
 code will automatically support those arguments when they are added.
 
+.. admonition:: Overriding Delete
+
+Note that the :meth:`~Model.delete()` method for an object is not
+necessarily called when :ref:`deleting objects in bulk using a
+QuerySet`. To ensure customized delete logic
+gets executed, you can use :data:`~django.db.models.signals.pre_save`
+and/or :data:`~django.db.models.signals.post_save` signals.
+
 Executing custom SQL
 
 

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

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

[noreply]

Author: timo
Date: 2010-12-27 17:46:06 -0600 (Mon, 27 Dec 2010)
New Revision: 15071

Modified:
   django/trunk/docs/topics/db/models.txt
Log:
Fixed #12313 - Add a note that QuerySet.delete() doesn't necessarily call 
obj.delete(). thanks FunkyELF for the suggestion.

Modified: django/trunk/docs/topics/db/models.txt
===
--- django/trunk/docs/topics/db/models.txt  2010-12-27 23:30:19 UTC (rev 
15070)
+++ django/trunk/docs/topics/db/models.txt  2010-12-27 23:46:06 UTC (rev 
15071)
@@ -751,6 +751,14 @@
 **kwargs`` in your method definitions, you are guaranteed that your
 code will automatically support those arguments when they are added.
 
+.. admonition:: Overriding Delete
+
+Note that the :meth:`~Model.delete()` method for an object is not
+necessarily called when :ref:`deleting objects in bulk using a
+QuerySet`. To ensure customized delete logic
+gets executed, you can use :data:`~django.db.models.signals.pre_save`
+and/or :data:`~django.db.models.signals.post_save` signals.
+
 Executing custom SQL
 
 

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

[Changeset] r15070 - django/branches/releases/1.2.X/docs/intro

[noreply]

Author: timo
Date: 2010-12-27 17:30:19 -0600 (Mon, 27 Dec 2010)
New Revision: 15070

Modified:
   django/branches/releases/1.2.X/docs/intro/tutorial03.txt
Log:
[1.2.X] Fixed #14890 - Clarify poll "index" page in tutorial. thanks dbaggott 
for the report.

Backport of r15069 from trunk.

Modified: django/branches/releases/1.2.X/docs/intro/tutorial03.txt
===
--- django/branches/releases/1.2.X/docs/intro/tutorial03.txt2010-12-27 
23:29:49 UTC (rev 15069)
+++ django/branches/releases/1.2.X/docs/intro/tutorial03.txt2010-12-27 
23:30:19 UTC (rev 15070)
@@ -29,7 +29,7 @@
 
 In our poll application, we'll have the following four views:
 
-* Poll "archive" page -- displays the latest few polls.
+* Poll "index" page -- displays the latest few polls.
 
 * Poll "detail" page -- displays a poll question, with no results but
   with a form to vote.

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

[Changeset] r15069 - django/trunk/docs/intro

[noreply]

Author: timo
Date: 2010-12-27 17:29:49 -0600 (Mon, 27 Dec 2010)
New Revision: 15069

Modified:
   django/trunk/docs/intro/tutorial03.txt
Log:
Fixed #14890 - Clarify poll "index" page in tutorial. thanks dbaggott for the 
report.

Modified: django/trunk/docs/intro/tutorial03.txt
===
--- django/trunk/docs/intro/tutorial03.txt  2010-12-27 23:27:18 UTC (rev 
15068)
+++ django/trunk/docs/intro/tutorial03.txt  2010-12-27 23:29:49 UTC (rev 
15069)
@@ -29,7 +29,7 @@
 
 In our poll application, we'll have the following four views:
 
-* Poll "archive" page -- displays the latest few polls.
+* Poll "index" page -- displays the latest few polls.
 
 * Poll "detail" page -- displays a poll question, with no results but
   with a form to vote.

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

[Changeset] r15068 - django/trunk/docs/intro

[noreply]

Author: timo
Date: 2010-12-27 17:27:18 -0600 (Mon, 27 Dec 2010)
New Revision: 15068

Modified:
   django/trunk/docs/intro/tutorial04.txt
Log:
Fixed #6550 - Changed generic view portion of the tutorial so it's equivalent 
to "the hard way" results. Thanks Alexandre Dupas for the suggestion.

Modified: django/trunk/docs/intro/tutorial04.txt
===
--- django/trunk/docs/intro/tutorial04.txt  2010-12-27 13:41:57 UTC (rev 
15067)
+++ django/trunk/docs/intro/tutorial04.txt  2010-12-27 23:27:18 UTC (rev 
15068)
@@ -238,7 +238,7 @@
 urlpatterns = patterns('',
 (r'^$',
 ListView.as_view(
-model=Poll,
+queryset=Poll.objects.order_by('-pub_date')[:5],
 context_object_name='latest_poll_list',
 template_name='polls/index.html')),
 (r'^(?P\d+)/$',

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

Re: [Django] #14961: Cannot load admin interface static files when doing tutorial

[Django]

#14961: Cannot load admin interface static files when doing tutorial
--+-
  Reporter:  harriv+dja...@gmail.com  | Owner:  jezdez   
Status:  assigned | Milestone:  1.3  
 Component:  Contrib apps |   Version:  1.3-alpha
Resolution:   |  Keywords:   
 Stage:  Accepted | Has_patch:  0
Needs_docs:  0|   Needs_tests:  0
Needs_better_patch:  0|  
--+-
Comment (by jezdez):

 Seems like https://gist.github.com/d2b873845d5a49627f8e fixes the issue
 for me. Going to add tests tomorrow.

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

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

Re: [Django] #14961: Cannot load admin interface static files when doing tutorial

[Django]

#14961: Cannot load admin interface static files when doing tutorial
--+-
  Reporter:  harriv+dja...@gmail.com  | Owner:  jezdez   
Status:  assigned | Milestone:  1.3  
 Component:  Contrib apps |   Version:  1.3-alpha
Resolution:   |  Keywords:   
 Stage:  Accepted | Has_patch:  0
Needs_docs:  0|   Needs_tests:  0
Needs_better_patch:  0|  
--+-
Comment (by jezdez):

 OK, I was able to reproduce the bug, thanks for the report.

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

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

Re: [Django] #14961: Cannot load admin interface static files when doing tutorial

[Django]

#14961: Cannot load admin interface static files when doing tutorial
--+-
  Reporter:  harriv+dja...@gmail.com  | Owner:  jezdez   
Status:  assigned | Milestone:  1.3  
 Component:  Contrib apps |   Version:  1.3-alpha
Resolution:   |  Keywords:   
 Stage:  Accepted | Has_patch:  0
Needs_docs:  0|   Needs_tests:  0
Needs_better_patch:  0|  
--+-
Changes (by jezdez):

  * owner:  nobody => jezdez
  * status:  new => assigned
  * stage:  Unreviewed => Accepted
  * component:  django-admin.py runserver => Contrib apps
  * milestone:  => 1.3

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

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

Re: [Django] #14961: Cannot load admin interface static files when doing tutorial

[Django]

#14961: Cannot load admin interface static files when doing tutorial
+---
  Reporter:  harriv+dja...@gmail.com| Owner:  nobody   
Status:  new| Milestone:   
 Component:  django-admin.py runserver  |   Version:  1.3-alpha
Resolution: |  Keywords:   
 Stage:  Unreviewed | Has_patch:  0
Needs_docs:  0  |   Needs_tests:  0
Needs_better_patch:  0  |  
+---
Comment (by mlangley):

 I am also experiencing this issue when running 1.3 beta1 on Windows 7. I
 am new to Django and have not diverged from the steps in the tutorial.

 Confirming the specific questions asked earlier:

   * django.contrib.staticfiles is enabled in INSTALLED_APPS
   * DEBUG variable in setting.py is set to True

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

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

[Django] #14975: TransactionTestCases are broken by django.contrib.auth in 1.2.4

[Django]

#14975: TransactionTestCases are broken by django.contrib.auth in 1.2.4
---+
 Reporter:  rpbarlow   |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Testing framework  | Version:  1.2   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 I tried to upgrade my project to 1.2.4, and found that my
 TransactionTestCases were failing. I discovered that they would pass by
 themselves, but they would fail if I ran the django.contrib.auth tests
 first.

 I made a very simple Django project that has an app with a single
 TransactionTestCase. It runs a self.assertTrue(True). If you run the
 testapp test by itself, it will pass, but if you run the auth tests first,
 it will fail in this way:

 {{{
 ==
 ERROR: test_test (testapp.tests.SimpleTest)
 --
 Traceback (most recent call last):
   File "/home/rbarlow/.virtualenvs/titles-db/lib/python2.6/site-
 packages/django/test/testcases.py", line 257, in __call__
 self._pre_setup()
   File "/home/rbarlow/.virtualenvs/titles-db/lib/python2.6/site-
 packages/django/test/testcases.py", line 224, in _pre_setup
 self._fixture_setup()
   File "/home/rbarlow/.virtualenvs/titles-db/lib/python2.6/site-
 packages/django/test/testcases.py", line 236, in _fixture_setup
 call_command('flush', verbosity=0, interactive=False, database=db)
   File "/home/rbarlow/.virtualenvs/titles-db/lib/python2.6/site-
 packages/django/core/management/__init__.py", line 166, in call_command
 return klass.execute(*args, **defaults)
   File "/home/rbarlow/.virtualenvs/titles-db/lib/python2.6/site-
 packages/django/core/management/base.py", line 220, in execute
 output = self.handle(*args, **options)
   File "/home/rbarlow/.virtualenvs/titles-db/lib/python2.6/site-
 packages/django/core/management/base.py", line 351, in handle
 return self.handle_noargs(**options)
   File "/home/rbarlow/.virtualenvs/titles-db/lib/python2.6/site-
 packages/django/core/management/commands/flush.py", line 75, in
 handle_noargs
 emit_post_sync_signal(all_models, verbosity, interactive, db)
   File "/home/rbarlow/.virtualenvs/titles-db/lib/python2.6/site-
 packages/django/core/management/sql.py", line 182, in
 emit_post_sync_signal
 interactive=interactive, db=db)
   File "/home/rbarlow/.virtualenvs/titles-db/lib/python2.6/site-
 packages/django/dispatch/dispatcher.py", line 172, in send
 response = receiver(signal=self, sender=sender, **named)
   File "/home/rbarlow/.virtualenvs/titles-db/lib/python2.6/site-
 packages/django/contrib/auth/management/__init__.py", line 28, in
 create_permissions
 defaults={'name': name, 'content_type': ctype})
   File "/home/rbarlow/.virtualenvs/titles-db/lib/python2.6/site-
 packages/django/db/models/manager.py", line 135, in get_or_create
 return self.get_query_set().get_or_create(**kwargs)
   File "/home/rbarlow/.virtualenvs/titles-db/lib/python2.6/site-
 packages/django/db/models/query.py", line 383, in get_or_create
 transaction.savepoint_rollback(sid, using=self.db)
   File "/home/rbarlow/.virtualenvs/titles-db/lib/python2.6/site-
 packages/django/db/transaction.py", line 242, in savepoint_rollback
 connection._savepoint_rollback(sid)
   File "/home/rbarlow/.virtualenvs/titles-db/lib/python2.6/site-
 packages/django/db/backends/__init__.py", line 61, in _savepoint_rollback
 self.cursor().execute(self.ops.savepoint_rollback_sql(sid))
   File "/home/rbarlow/.virtualenvs/titles-db/lib/python2.6/site-
 packages/django/db/backends/postgresql_psycopg2/base.py", line 44, in
 execute
 return self.cursor.execute(query, args)
 DatabaseError: no such savepoint
 }}}

 I put this into the Testing framework component, but it may be more
 appropriate in the Authentication component.

 Django rocks, thanks for working on it!

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

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

Re: [Django] #14948: Broken routers in 1.2.4: type object 'ModelBase' has no attribute '_meta'

[Django]

#14948: Broken routers in 1.2.4: type object 'ModelBase' has no attribute 
'_meta'
---+
  Reporter:  shell_dweller | Owner:  nobody 

Status:  new   | Milestone: 

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

Resolution:|  Keywords:  router, 
ManyToManyField
 Stage:  Unreviewed| Has_patch:  0  

Needs_docs:  0 |   Needs_tests:  0  

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

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

Re: [Django] #14948: Broken routers in 1.2.4: type object 'ModelBase' has no attribute '_meta'

[Django]

#14948: Broken routers in 1.2.4: type object 'ModelBase' has no attribute 
'_meta'
---+
  Reporter:  shell_dweller | Owner:  nobody 

Status:  new   | Milestone: 

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

Resolution:|  Keywords:  router, 
ManyToManyField
 Stage:  Unreviewed| Has_patch:  0  

Needs_docs:  0 |   Needs_tests:  0  

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

 * cc: fwen...@mozilla.com (added)

Comment:

 I can confirm this. A simple workaround would probably be to catch this in
 the router, but this would be a duct-tape 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-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Django] #14974: Contrib application for i18n functions

[Django]

#14974: Contrib application for i18n functions
---+
 Reporter:  marinho|   Owner:  nobody
   Status:  new|   Milestone:
Component:  Uncategorized  | Version:  SVN   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 Using gettext has been a problem on many projects. It's weird to translate
 and is limited to (static) potfiles (nothing convince me that Pootle
 Server and Rosetta are great ideas, actually they are just quick fixes for
 a bad implemented tool).

 So, I'd like to suggest you to make a contrib app to have all i18n
 functions.

 Not only the existing functions but provide backend system for alternative
 ways to make translations, to replace gettext for database stored message
 strings, or dynamic/smart translations.

 Would be helpful also if the same application has a way to translate
 database objects, like '''django-multilingual''' (1) and '''polyglot'''
 (2) do.

 I can work on it if the idea get approved.

  * (1) http://code.google.com/p/django-multilingual/
  * (2) http://reddes.bvsalud.org/projects/clinical-
 trials/browser/trunk/opentrials/polyglot

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

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

[Django] #14973: AdminEmailHandler doesn't include report.message

[Django]

#14973: AdminEmailHandler doesn't include report.message
+---
 Reporter:  jamstooks   |   Owner:  nobody
   Status:  new |   Milestone:  1.3   
Component:  Core framework  | Version:  1.3-alpha 
 Keywords:  |   Stage:  Unreviewed
Has_patch:  0   |  
+---
 Shouldn't the message from the report be included in the email?

 {{{
 # django/utils/log.py line 89
 message = "%s\n\n%s" % (stack_trace, request_repr)
 }}}

 I wasn't sure what the intension here was for excluding the message, so I
 didn't build a patch for that yet, but it could be something as simple as:

 {{{
 message = "%s\n\n%s\n\n%s" % (record.message, stack_trace, request_repr)
 }}}

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

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

Re: [Django] #14971: Exclude by annotation works as OR rather than AND

[Django]

#14971: Exclude by annotation works as OR rather than AND
---+
  Reporter:  orblivion | Owner:  nobody
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  1.2   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by orblivion):

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

Comment:

 Sorry, the "dg" in the last two examples should be "obj_group".

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

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

Re: [Django] #14948: Broken routers in 1.2.4: type object 'ModelBase' has no attribute '_meta'

[Django]

#14948: Broken routers in 1.2.4: type object 'ModelBase' has no attribute 
'_meta'
---+
  Reporter:  shell_dweller | Owner:  nobody 

Status:  new   | Milestone: 

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

Resolution:|  Keywords:  router, 
ManyToManyField
 Stage:  Unreviewed| Has_patch:  0  

Needs_docs:  0 |   Needs_tests:  0  

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

 (assuming you have created a registered a router that uses
 "model._meta.object_name", of course)

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

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

Re: [Django] #14948: Broken routers in 1.2.4: type object 'ModelBase' has no attribute '_meta'

[Django]

#14948: Broken routers in 1.2.4: type object 'ModelBase' has no attribute 
'_meta'
---+
  Reporter:  shell_dweller | Owner:  nobody 

Status:  new   | Milestone: 

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

Resolution:|  Keywords:  router, 
ManyToManyField
 Stage:  Unreviewed| Has_patch:  0  

Needs_docs:  0 |   Needs_tests:  0  

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

 * cc: dja...@farialima.net (added)
  * needs_better_patch:  => 0
  * needs_tests:  => 0
  * needs_docs:  => 0

Comment:

 Same problem here - an easy way to reproduce:

 {{{
 bash-3.2$ ./manage.py shell
 Python 2.5.4 (r254:67917, Dec 23 2008, 14:57:27)
 [GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin
 Type "help", "copyright", "credits" or "license" for more information.
 (InteractiveConsole)
 >>> from django.contrib.auth.models import User
 >>> user = User()
 >>> user.username = "testuser"
 >>> user.save()
 >>> user.delete()
 Traceback (most recent call last):
   File "", line 1, in 
   File "/path/to//django/db/models/base.py", line 660, in delete
 self._collect_sub_objects(seen_objs)
   File "/path/to//django/db/models/base.py", line 625, in
 _collect_sub_objects
 db = router.db_for_write(f.rel.through.__class__, instance=self)
   File "/path/to//django/db/utils.py", line 134, in _route_db
 chosen_db = method(model, **hints)
   File "/path/to/my/app/routers.py", line 35, in db_for_write
 object_name = model._meta.object_name
 AttributeError: type object 'ModelBase' has no attribute '_meta'
 >>>
 }}}

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

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

[Django] #14972: AdminEmailHandler breaks when logger is missing stack trace information

[Django]

#14972: AdminEmailHandler breaks when logger is missing stack trace information
+---
 Reporter:  jamstooks   |   Owner:  nobody
   Status:  new |   Milestone:
Component:  Core framework  | Version:  1.3-alpha 
 Keywords:  |   Stage:  Unreviewed
Has_patch:  0   |  
+---
 If a log message doesn't have stack trace info then record.exc_info is ()
 and ExceptionReporter !__init!__() breaks. I assume this is because
 *exc_info should contain the keyword arguments, but is assigned to ():

 {{{
 # django/utils/log.py line # 89
 exc_info = ()
 ...
 reporter = ExceptionReporter(request, is_email=True, *exc_info)
 # ERROR: __init__() takes at least 5 non-keyword arguments (2 given)
 }}}

 I'd be happy to build a patch for this in some way (if this is indeed a
 bug), but I'm not sure if the fix belongs in AdminEmailHandler or
 ExceptionReporter.

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

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

Re: [Django] #11206: The floatformat template tag doesn't work with a value of 0 and a precision of 7 or higher.

[Django]

#11206: The floatformat template tag doesn't work with a value of 0 and a 
precision
of 7 or higher.
--+-
  Reporter:  mrmachine| Owner:  nobody  
 
Status:  new  | Milestone:  1.3 
 
 Component:  Template system  |   Version:  SVN 
 
Resolution:   |  Keywords:  floatformat precision 7 
decimal sprintdec2010
 Stage:  Accepted | Has_patch:  1   
 
Needs_docs:  0|   Needs_tests:  0   
 
Needs_better_patch:  0|  
--+-
Comment (by adamnelson):

 It seems like the simpler solution is to use
 [http://docs.python.org/library/decimal.html#decimal.Decimal.normalize
 .normalize()].  I could be wrong though - I haven't gone through all the
 possible decimal/float issues


 {{{
 >>> Decimal('0.0').quantize(Decimal('1.0'))
 Decimal('0E-9')
 >>> Decimal('0.0').quantize(Decimal('1.0')).normalize()
 Decimal('0')
 }}}

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

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

[Django] #14971: Exclude by annotation works as OR rather than AND

[Django]

#14971: Exclude by annotation works as OR rather than AND
--+-
 Reporter:  orblivion |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Database layer (models, ORM)  | Version:  1.2   
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 I'm using sqlite3. I believe that this is all the relevant code; I'd
 rather not share everything I'm doing so I changed names and redacted
 irrelevant identifying characteristics to protect the innocent.

 Here's the model code:

 {{{

 class ObjGroup(models.Model):
 pass

 class Revision(models.Model):
 obj_group = models.ForeignKey(ObjGroup)

 class Obj(models.Model):
 created_obj_revision = models.ForeignKey(Revision, related_name =
 "new_objects")
 rejected_obj_revision = models.ForeignKey(Revision, related_name =
 "rejected_objects", null = True, blank = True)

 }}}

 Now I'm trying, in the shell at the moment, to query all Revisions in an
 Obj_Group where there's at least one object in revision.new_objects or
 revision.rejected_objects. So I figure what I should do is annotate the
 Count of new_objects and the Count of rejected_objects, and then exclude
 where
 both are zero. Exclude is supposed to work as NOT ( condition AND
 condition ), which I tested works properly on other attributes. But on
 these annotations, it seems to work as NOT( condition OR condition ).


 First list the count for all revisions in the group

 {{{

  In : qs = obj_group.revision_set.annotate(
   num_rejected_objects = Count("rejected_objects"), num_new_objects =
 Count("new_objects")).all()

  In : [(q.num_new_objects, q.num_rejected_objects) for q in qs]

  Out : [(2, 0),
   (0, 1),
   (1, 0),
   (0, 1),
   (1, 1),
   (0, 0),
   (1, 0),
   (0, 1),
   (1, 0),
   (2, 2),
   (0, 0),
   (1, 1),
   (0, 0),
   (1, 0),
   (0, 0)]

 }}}

 Now let's exclude them

 {{{

  In : qs = dg.revision_set.annotate(
   num_rejected_objects = Count("rejected_objects"), num_new_objects =
 Count("new_objects")).exclude(
   num_rejected_objects = 0, num_new_objects=0)

  In : [(q.num_new_objects, q.num_rejected_objects) for q in qs]

  Out: [(1, 1), (2, 2), (1, 1)]

 }}}
 It's eliminated all zeroes, rather than just the cases where both are zero

 Now just for fun let's filter them instead

 {{{
  In : qs = dg.revision_set.annotate(
   num_rejected_objects = Count("rejected_objects"), num_new_objects =
 Count("new_objects")).filter(
   num_rejected_objects = 0, num_new_objects=0)

  In : [(q.num_new_objects, q.num_rejected_objects) for q in qs]

  Out: [(0, 0), (0, 0), (0, 0), (0, 0)]

 }}}

 It properly selected only the ones where both are zero.

 Let me know if you need any more details about my setup. Thanks.

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

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

Re: [Django] #14579: Use built-in sessions middleware for entirely cookie-based sessions

[Django]

#14579: Use built-in sessions middleware for entirely cookie-based sessions
--+-
  Reporter:  oran | Owner:  nobody
Status:  new  | Milestone:
 Component:  django.contrib.sessions  |   Version:  1.2   
Resolution:   |  Keywords:
 Stage:  Accepted | Has_patch:  0 
Needs_docs:  0|   Needs_tests:  0 
Needs_better_patch:  0|  
--+-
Changes (by adamnelson):

  * component:  Uncategorized => django.contrib.sessions
  * summary:  built-in sessions middleware can't be used for entirely
  cookie-based sessions => Use built-in sessions
  middleware for entirely cookie-based sessions

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

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

Re: [Django] #14618: unable to "inspectdb" on mysql4 database

[Django]

#14618: unable to "inspectdb" on mysql4 database
+---
  Reporter:  pyrou  | Owner:  nobody
Status:  new| Milestone:  1.3   
 Component:  django-admin.py inspectdb  |   Version:  SVN   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Comment (by adamnelson):

 The patch looks fine and simple.  Can you confirm that you're on MySQL 4.1
 vs 4.0?  I think this would be a problem on 4.1 (because there's no
 information_schema), but I want to confirm exactly what version you're on.

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

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

Re: [Django] #14266: Audit database backend support claims, particularly for MySQL

[Django]

#14266: Audit database backend support claims, particularly for MySQL
+---
  Reporter:  carljm | Owner:  nobody
Status:  new| Milestone:  1.3   
 Component:  Documentation  |   Version:  SVN   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Comment (by adamnelson):

 I've looked through the django-users group and the RHEL 4 docs and I think
 you'll be hard pressed to find even one user who will be trying to upgrade
 to Django 1.3 with anything less than MySQL 4.1.  I couldn't find any
 references to v4.0 or v3.23 in the last 3 years on the group.

 In addition, I don't know of anybody who uses or tests on MySQL 4.0 or
 lower.  I think we should just leave out 3.23 and 4.0 from the notes and
 if those versions continue to work, great.

 Here are the release notes for [http://dev.mysql.com/doc/refman/5.1/en
 /mysql-nutshell.html version 5.1] and
 [http://dev.mysql.com/doc/refman/5.5/en/mysql-nutshell.html version 5.5]
 which should be distilled into two new sections under MySQL.

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

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

Re: [Django] #2495: db.models.TextField cannot be marked unique when using mysql backend

[Django]

#2495: db.models.TextField cannot be marked unique when using mysql backend
---+
  Reporter:  anonymous | Owner:  Honza_Kral 

Status:  new   | Milestone:  1.3

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

Resolution:|  Keywords:  mysql 
TextField
 Stage:  Accepted  | Has_patch:  1  

Needs_docs:  0 |   Needs_tests:  0  

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

 We up the patch from making the index on the first 255 bytes to 767 bytes
 if we marked this ticket as an enhancement for MySQL systems from 4.1.2
 and up and left behind MySQL 4.0 (version 4.1 came out 6 years ago).  IMHO
 this wouldn't break backwards compatibility since this never worked for
 anybody anyway and this code is only run when creating or altering the
 models.

 [http://dev.mysql.com/doc/refman/4.1/en/column-indexes.html MySQL 4.1
 Documentation]

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

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

[Django] #14970: Inconsistency in handling of managed/unmanaged transactions

[Django]

#14970: Inconsistency in handling of managed/unmanaged transactions
--+-
 Reporter:  mwrobel   |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Database layer (models, ORM)  | Version:  1.2   
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 I think that there are some bugs in the way the 'managed' flag is handled
 in enter_transaction_management() and leave_transaction_management() in
 django/db/transaction.py.

 1. enter_transaction_management() has a 'managed' parameter. I guess it
 should set the new transaction in managed mode depending on the value of
 this parameter, but it takes the mode from the surrounding transaction or
 from the settings (as stated in a comment). Surprisingly,
 connection._enter_transaction_management() is called with the value of the
 'managed' parameter instead of the mode that is set for the new
 transaction.

 2. leave_transaction_management() calls
 connection._leave_transaction_management() passing the mode of the current
 transaction (the transaction that is being left) as a parameter. From what
 I can see in django/db/backends/postgresql_psycopg2/base.py, it expects to
 get the mode of the transaction that will be active after
 leave_transaction_management() finishes.

 Now I will describe the use case in which I encountered the problems: I
 use the psycopg2 backend and I want to have the connection in database-
 level autocommit mode by default. Sometimes I want to begin a managed
 transaction and after some operations commit or rollback it and return to
 the database-level autocommit mode.

 Currently I have to enter the transaction as follows:
 {{{
 enter_transaction_management(managed=True)
 managed(True)
 }}}
 and leave:
 {{{
 managed(False)
 leave_transaction_management()
 }}}

 I think that the managed() calls should be redundant, but the first/second
 one is needed to circumvent the first/second problem I mentioned.

 My proposal is to:

 1. change enter_transaction_management() to set mode depending on the
 parameter (and when parameter is not given, take the mode from the
 surrounding transaction or the settings).

 2. change leave_transaction_management() to pass the mode of the
 transaction that becomes active to
 connection._leave_transaction_management() (I don't know what was the
 intended semantics, but it is what pycopg2 backend seems to expect, and
 other backends don't override _leave_transaction_management()).

 I see that the proposed changes can break backward compatibility, but I
 think that they don't change any documented behavior.

 I can create patches that fix the problem, but I would like to hear from
 Django developers if the fix is acceptable before I write the patches.

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

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

Re: [Django] #13161: Ticked 2514 and 5171, solution for using Django with other psycopg2 applications.

[Django]

#13161: Ticked 2514 and 5171, solution for using Django with other psycopg2
applications.
---+
  Reporter:  spoksss   | Owner:  nobody 
  
Status:  new   | Milestone: 
  
 Component:  Database layer (models, ORM)  |   Version:  1.2-beta   
  
Resolution:|  Keywords:  psycopg2, 
unicode
 Stage:  Accepted  | Has_patch:  1  
  
Needs_docs:  0 |   Needs_tests:  1  
  
Needs_better_patch:  0 |  
---+
Comment (by spoksss):

 Hi,

 I created some project just to show what is a problem, I attached it in
 this comment.

 Set settings, syncdb and then try to run below test:

 python manage.py test myapp.MyModelTestCase

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

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

Re: [Django] #14957: doc nit: slug_field not required

[Django]

#14957: doc nit: slug_field not required
+---
  Reporter:  CarlFK | Owner:  nobody
Status:  closed | Milestone:
 Component:  Documentation  |   Version:  1.2   
Resolution:  wontfix|  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by timo):

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

Comment:

 The current wording makes sense to me -- it shows that slug and slug_field
 are used together if object_id isn't specified.  Thanks for the suggestion
 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-upda...@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

[Changeset] r15067 - django/branches/releases/1.2.X/docs/ref/contrib/admin

[noreply]

Author: timo
Date: 2010-12-27 07:41:57 -0600 (Mon, 27 Dec 2010)
New Revision: 15067

Modified:
   django/branches/releases/1.2.X/docs/ref/contrib/admin/index.txt
Log:
[1.2.X] Fixed #12642 - Add docs for has_[add|change|delete]_permission 
ModelAdmin methods. Thanks to MadeR for the report and for the wiki 
contributors from which I took language for this patch.

Backport of r15066 from trunk.

Modified: django/branches/releases/1.2.X/docs/ref/contrib/admin/index.txt
===
--- django/branches/releases/1.2.X/docs/ref/contrib/admin/index.txt 
2010-12-27 13:41:19 UTC (rev 15066)
+++ django/branches/releases/1.2.X/docs/ref/contrib/admin/index.txt 
2010-12-27 13:41:57 UTC (rev 15067)
@@ -887,6 +887,27 @@
 kwargs["queryset"] = Car.objects.filter(owner=request.user)
 return super(MyModelAdmin, 
self).formfield_for_manytomany(db_field, request, **kwargs)
 
+.. method:: ModelAdmin.has_add_permission(self, request)
+
+Should return ``True`` if adding an object is permitted, ``False``
+otherwise.
+
+.. method:: ModelAdmin.has_change_permission(self, request, obj=None)
+
+Should return ``True`` if editing obj is permitted, ``False`` otherwise.
+If obj is ``None``, should return ``True`` or ``False`` to indicate whether
+editing of objects of this type is permitted in general (e.g., ``False``
+will be interpreted as meaning that the current user is not permitted to
+edit any object of this type).
+
+.. method:: ModelAdmin.has_delete_permission(self, request, obj=None)
+
+Should return ``True`` if deleting obj is permitted, ``False`` otherwise.
+If obj is ``None``, should return ``True`` or ``False`` to indicate whether
+deleting objects of this type is permitted in general (e.g., ``False`` will
+be interpreted as meaning that the current user is not permitted to delete
+any object of this type).
+
 .. method:: ModelAdmin.queryset(self, request)
 
 The ``queryset`` method on a ``ModelAdmin`` returns a

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

[Changeset] r15066 - django/trunk/docs/ref/contrib/admin

[noreply]

Author: timo
Date: 2010-12-27 07:41:19 -0600 (Mon, 27 Dec 2010)
New Revision: 15066

Modified:
   django/trunk/docs/ref/contrib/admin/index.txt
Log:
Fixed #12642 - Add docs for has_[add|change|delete]_permission ModelAdmin 
methods. Thanks to MadeR for the report and for the wiki contributors from 
which I took language for this patch.

Modified: django/trunk/docs/ref/contrib/admin/index.txt
===
--- django/trunk/docs/ref/contrib/admin/index.txt   2010-12-27 13:28:04 UTC 
(rev 15065)
+++ django/trunk/docs/ref/contrib/admin/index.txt   2010-12-27 13:41:19 UTC 
(rev 15066)
@@ -921,6 +921,27 @@
 kwargs["queryset"] = Car.objects.filter(owner=request.user)
 return super(MyModelAdmin, 
self).formfield_for_manytomany(db_field, request, **kwargs)
 
+.. method:: ModelAdmin.has_add_permission(self, request)
+
+Should return ``True`` if adding an object is permitted, ``False``
+otherwise.
+
+.. method:: ModelAdmin.has_change_permission(self, request, obj=None)
+
+Should return ``True`` if editing obj is permitted, ``False`` otherwise.
+If obj is ``None``, should return ``True`` or ``False`` to indicate whether
+editing of objects of this type is permitted in general (e.g., ``False``
+will be interpreted as meaning that the current user is not permitted to
+edit any object of this type).
+
+.. method:: ModelAdmin.has_delete_permission(self, request, obj=None)
+
+Should return ``True`` if deleting obj is permitted, ``False`` otherwise.
+If obj is ``None``, should return ``True`` or ``False`` to indicate whether
+deleting objects of this type is permitted in general (e.g., ``False`` will
+be interpreted as meaning that the current user is not permitted to delete
+any object of this type).
+
 .. method:: ModelAdmin.queryset(self, request)
 
 The ``queryset`` method on a ``ModelAdmin`` returns a

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

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

[noreply]

Author: timo
Date: 2010-12-27 07:28:04 -0600 (Mon, 27 Dec 2010)
New Revision: 15065

Added:
   django/branches/releases/1.2.X/docs/topics/http/decorators.txt
Modified:
   django/branches/releases/1.2.X/docs/index.txt
   django/branches/releases/1.2.X/docs/ref/middleware.txt
   django/branches/releases/1.2.X/docs/topics/cache.txt
   django/branches/releases/1.2.X/docs/topics/http/index.txt
Log:
[1.2.X] Fixed #6181 - Document `django.views.decorators.http` - thanks adamv 
for the patch.

Backport of r15064 from trunk.

Modified: django/branches/releases/1.2.X/docs/index.txt
===
--- django/branches/releases/1.2.X/docs/index.txt   2010-12-27 13:27:26 UTC 
(rev 15064)
+++ django/branches/releases/1.2.X/docs/index.txt   2010-12-27 13:28:04 UTC 
(rev 15065)
@@ -91,7 +91,8 @@
 * **The basics:**
   :doc:`URLconfs ` |
   :doc:`View functions ` |
-  :doc:`Shortcuts `
+  :doc:`Shortcuts ` |
+  :doc:`Decorators `
 
 * **Reference:**  :doc:`Request/response objects `
 

Modified: django/branches/releases/1.2.X/docs/ref/middleware.txt
===
--- django/branches/releases/1.2.X/docs/ref/middleware.txt  2010-12-27 
13:27:26 UTC (rev 15064)
+++ django/branches/releases/1.2.X/docs/ref/middleware.txt  2010-12-27 
13:28:04 UTC (rev 15065)
@@ -98,6 +98,9 @@
 something other than 200, JavaScript files (for IE compatibility), or
 responses that have the ``Content-Encoding`` header already specified.
 
+GZip compression can be applied to individual views using the
+:func:`~django.views.decorators.http.gzip_page()` decorator.
+
 Conditional GET middleware
 --
 

Modified: django/branches/releases/1.2.X/docs/topics/cache.txt
===
--- django/branches/releases/1.2.X/docs/topics/cache.txt2010-12-27 
13:27:26 UTC (rev 15064)
+++ django/branches/releases/1.2.X/docs/topics/cache.txt2010-12-27 
13:28:04 UTC (rev 15065)
@@ -710,6 +710,8 @@
 designated variables, and to tell caching mechanisms not to cache particular
 pages. We'll look at some of these headers in the sections that follow.
 
+.. _using-vary-headers:
+
 Using Vary headers
 ==
 

Added: django/branches/releases/1.2.X/docs/topics/http/decorators.txt
===
--- django/branches/releases/1.2.X/docs/topics/http/decorators.txt  
(rev 0)
+++ django/branches/releases/1.2.X/docs/topics/http/decorators.txt  
2010-12-27 13:28:04 UTC (rev 15065)
@@ -0,0 +1,71 @@
+===
+View Decorators
+===
+
+.. currentmodule:: django.views.decorators.http
+
+Django provides several decorators that can be applied to views to support
+various HTTP features.
+
+Allowed HTTP Methods
+
+
+.. function:: require_http_methods(request_method_list)
+
+This decorator is used to make a view only accept particular request methods.
+Usage::
+
+from django.views.decorators.http import require_http_methods
+@require_http_methods(["GET", "POST"])
+def my_view(request):
+# I can assume now that only GET or POST requests make it this far
+# ...
+pass
+
+Note that request methods should be in uppercase.
+
+.. function:: require_GET()
+
+Decorator to require that a view only accept the GET method.
+
+.. function:: require_POST()
+
+Decorator to require that a view only accept the POST method.
+
+Conditional view processing
+===
+
+.. function:: condition(etag_func=None, last_modified_func=None)
+
+.. function:: etag(etag_func)
+
+.. function:: last_modified(last_modified_func)
+
+These decorators can be used to generate ``ETag`` and ``Last-Modified``
+headers; see
+:doc:`conditional view processing `.
+
+.. currentmodule:: django.views.decorators.http
+
+GZip Compression
+
+
+.. function:: gzip_page()
+
+This decorator compresses content if the browser allows gzip compression.
+It sets the ``Vary`` header accordingly, so that caches will base their
+storage on the ``Accept-Encoding`` header.
+
+.. currentmodule:: django.views.decorators.vary
+
+Vary Headers
+
+
+The ``Vary`` header defines which request headers a cache mechanism should take
+into account when building its cache key.
+
+.. function:: vary_on_cookie(func)
+
+.. function:: vary_on_headers(*headers)
+
+See :ref:`using vary headers `.

Modified: django/branches/releases/1.2.X/docs/topics/http/index.txt
===
--- django/branches/releases/1.2.X/docs/topics/http/index.txt   2010-12-27 
13:27:26 UTC (rev 15064)
+++ django/branches/releases/1.2.X/docs/topics/http/index.txt   2010-12-27 
13:28:04 UTC (rev 15065)
@@ -8,6 +8,7 @@

urls
views
+   decorators
file-uploads
shortcuts

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

[noreply]

Author: timo
Date: 2010-12-27 07:27:26 -0600 (Mon, 27 Dec 2010)
New Revision: 15064

Added:
   django/trunk/docs/topics/http/decorators.txt
Modified:
   django/trunk/docs/index.txt
   django/trunk/docs/ref/middleware.txt
   django/trunk/docs/topics/cache.txt
   django/trunk/docs/topics/http/index.txt
Log:
Fixed #6181 - Document `django.views.decorators.http` - thanks adamv for the 
patch.

Modified: django/trunk/docs/index.txt
===
--- django/trunk/docs/index.txt 2010-12-27 07:47:25 UTC (rev 15063)
+++ django/trunk/docs/index.txt 2010-12-27 13:27:26 UTC (rev 15064)
@@ -91,7 +91,8 @@
 * **The basics:**
   :doc:`URLconfs ` |
   :doc:`View functions ` |
-  :doc:`Shortcuts `
+  :doc:`Shortcuts ` |
+  :doc:`Decorators `
 
 * **Reference:**
   :doc:`Request/response objects ` |

Modified: django/trunk/docs/ref/middleware.txt
===
--- django/trunk/docs/ref/middleware.txt2010-12-27 07:47:25 UTC (rev 
15063)
+++ django/trunk/docs/ref/middleware.txt2010-12-27 13:27:26 UTC (rev 
15064)
@@ -98,6 +98,9 @@
 something other than 200, JavaScript files (for IE compatibility), or
 responses that have the ``Content-Encoding`` header already specified.
 
+GZip compression can be applied to individual views using the
+:func:`~django.views.decorators.http.gzip_page()` decorator.
+
 Conditional GET middleware
 --
 

Modified: django/trunk/docs/topics/cache.txt
===
--- django/trunk/docs/topics/cache.txt  2010-12-27 07:47:25 UTC (rev 15063)
+++ django/trunk/docs/topics/cache.txt  2010-12-27 13:27:26 UTC (rev 15064)
@@ -950,6 +950,8 @@
 designated variables, and to tell caching mechanisms not to cache particular
 pages. We'll look at some of these headers in the sections that follow.
 
+.. _using-vary-headers:
+
 Using Vary headers
 ==
 

Added: django/trunk/docs/topics/http/decorators.txt
===
--- django/trunk/docs/topics/http/decorators.txt
(rev 0)
+++ django/trunk/docs/topics/http/decorators.txt2010-12-27 13:27:26 UTC 
(rev 15064)
@@ -0,0 +1,71 @@
+===
+View Decorators
+===
+
+.. currentmodule:: django.views.decorators.http
+
+Django provides several decorators that can be applied to views to support
+various HTTP features.
+
+Allowed HTTP Methods
+
+
+.. function:: require_http_methods(request_method_list)
+
+This decorator is used to make a view only accept particular request methods.
+Usage::
+
+from django.views.decorators.http import require_http_methods
+@require_http_methods(["GET", "POST"])
+def my_view(request):
+# I can assume now that only GET or POST requests make it this far
+# ...
+pass
+
+Note that request methods should be in uppercase.
+
+.. function:: require_GET()
+
+Decorator to require that a view only accept the GET method.
+
+.. function:: require_POST()
+
+Decorator to require that a view only accept the POST method.
+
+Conditional view processing
+===
+
+.. function:: condition(etag_func=None, last_modified_func=None)
+
+.. function:: etag(etag_func)
+
+.. function:: last_modified(last_modified_func)
+
+These decorators can be used to generate ``ETag`` and ``Last-Modified``
+headers; see
+:doc:`conditional view processing `.
+
+.. currentmodule:: django.views.decorators.http
+
+GZip Compression
+
+
+.. function:: gzip_page()
+
+This decorator compresses content if the browser allows gzip compression.
+It sets the ``Vary`` header accordingly, so that caches will base their
+storage on the ``Accept-Encoding`` header.
+
+.. currentmodule:: django.views.decorators.vary
+
+Vary Headers
+
+
+The ``Vary`` header defines which request headers a cache mechanism should take
+into account when building its cache key.
+
+.. function:: vary_on_cookie(func)
+
+.. function:: vary_on_headers(*headers)
+
+See :ref:`using vary headers `.

Modified: django/trunk/docs/topics/http/index.txt
===
--- django/trunk/docs/topics/http/index.txt 2010-12-27 07:47:25 UTC (rev 
15063)
+++ django/trunk/docs/topics/http/index.txt 2010-12-27 13:27:26 UTC (rev 
15064)
@@ -8,6 +8,7 @@

urls
views
+   decorators
file-uploads
shortcuts
generic-views

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

Re: [Django] #14969: To have a way to modify third part model classes

[Django]

#14969: To have a way to modify third part model classes
---+
  Reporter:  marinho   | Owner:  nobody
Status:  new   | Milestone:
 Component:  Database layer (models, ORM)  |   Version:  SVN   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by marinho):

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

Comment:

 Fixing example code:

 {{{
 from django.db import models
 from django.contrib.auth.models import User

 from modify_models import ModifiedModel

 class ModifyingUser(ModifiedModel):
 class Meta:
 model = User
 exclude = ('first_name','last_name',)

 website = models.URLField(blank=True, verify_exists=False)

 def __unicode__(self):
 return '%s - %s'%(self.pk, self.name)
 }}}

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

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

[Django] #14969: To have a way to modify third part model classes

[Django]

#14969: To have a way to modify third part model classes
--+-
 Reporter:  marinho   |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Database layer (models, ORM)  | Version:  SVN   
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 Sometimes we need to modify a model class from a third part application or
 a Django's contrib, just for a specific project. The most common
 situations are related to the User, Group and Permission classes, like add
 new fields, or change __unicode__, etc.

 So I wrote this metaclass to allow us to modify a model class from another
 place of code without really change the original code.

 Basically you just inherit '''ModifiedModel''', set a '''Meta''' inner
 class with '''model = 'application.Model and set attributes with model
 fields, like below:

 """
 from django.db import models
 from django.contrib.auth.models import User

 from modify_models import ModifiedModel

 class ModifyingUser(ModifiedModel):
 class Meta:
 model = User
 exclude = ('first_name','last_name',)

 website = models.URLField(blank=True, verify_exists=False)

 def __unicode__(self):
 return '%s - %s'%(self.pk, self.name)
 """

 The code above adds a new field "website", excludes "first_name" and
 "last_name" and replaces the descriptor __unicode__ in the User model.

 In my projects and some of my clients sometimes we need this, so I thought
 it can be useful for other people and could be part of Django.

 I'm attaching a simple Python file to this ticket.

 If/when the ticket be approved I can work on documentations and tests and
 maybe improve the code to be part of the framework (i.e. re-think names).

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

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

Re: [Django] #14967: django.contrib.auth.admin.UserAdmin.response_add changed in 1.2.4

[Django]

#14967: django.contrib.auth.admin.UserAdmin.response_add changed in 1.2.4
+---
  Reporter:  jonas.obr...@divio.ch  | Owner:  nobody
Status:  new| Milestone:
 Component:  Documentation  |   Version:  1.2   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Comment (by jonas.obr...@divio.ch):

 Thank you very much for the clarification.

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

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

[Django] #14968: handle BaseExceptions with middleware, or at least KeyboardInterrupt

[Django]

#14968: handle BaseExceptions with middleware, or at least KeyboardInterrupt
+---
 Reporter:  Suor|   Owner:  Suor  
   Status:  new |   Milestone:
Component:  Core framework  | Version:  1.2   
 Keywords:  |   Stage:  Unreviewed
Has_patch:  1   |  
+---
 I was trying to write a middleware which shows a 503 page on
 KeyboardInterrupt (which happens on django restart) and run into this.
 If it is not handled some unlucky users get 500 error page and search bots
 go away for a while.

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

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