Re: [Django] #11163: admin ForeignKeyRawIdWidget contains incorrect link when used in change list view

[Django]

#11163: admin ForeignKeyRawIdWidget contains incorrect link when used in change
list view
---+
  Reporter:  margierogin...@yahoo.com  | Owner:  nobody
Status:  reopened  | 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 margierogin...@yahoo.com):

 Oops.  That anonymous response above is from me, Margie ...

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

Re: [Django] #11163: admin ForeignKeyRawIdWidget contains incorrect link when used in change list view

[Django]

#11163: admin ForeignKeyRawIdWidget contains incorrect link when used in change
list view
---+
  Reporter:  margierogin...@yahoo.com  | Owner:  nobody
Status:  reopened  | 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 anonymous):

 I think this needs a similar fix to the one made for r10235 (but in
 ForeignKeyRawIdWidget).   I think a similar fix may also be needed in
 RelatedFieldWidgetWraper, where there is another hardcoded url
related_url = '../../../%s/%s/' % (rel_to._meta.app_label,
 rel_to._meta.object_name.lower())

 Sorry I can't jump in and fix it. I am overloaded with my own work right
 now, but as I get more familiar with the source and how to do patches, I
 will hopefully get to the point where I can.

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

Re: [Django] #11166: {% widthratio 0 0 100 %} returns an empty string, rather than a 0

[Django]

#11166: {% widthratio 0 0 100 %} returns an empty string, rather than a 0
--+-
  Reporter:  luddep   | Owner:  nobody
Status:  new  | Milestone:
 Component:  Template system  |   Version:  SVN   
Resolution:   |  Keywords:
 Stage:  Unreviewed   | Has_patch:  1 
Needs_docs:  0|   Needs_tests:  0 
Needs_better_patch:  0|  
--+-
Changes (by luddep):

  * needs_better_patch:  => 0
  * component:  Uncategorized => Template system
  * needs_tests:  => 0
  * version:  1.0 => SVN
  * needs_docs:  => 0
  * has_patch:  0 => 1

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

[Django] #11166: {% widthratio 0 0 100 %} returns an empty string, rather than a 0

[Django]

#11166: {% widthratio 0 0 100 %} returns an empty string, rather than a 0
---+
 Reporter:  luddep |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Uncategorized  | Version:  1.0   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 When supplying the {% widthratio %} template tag with both a value and max
 of 0 - you get an empty string returned (''), rather than a 0.
 Mathematically, this is correct - since typically division by zero results
 in undefined, but I wouldn't say this is the expected behaviour when using
 this to create charts, where a 0 rather than nothing, would be expected.

 Example:
 {{{
 
 
 }}}

 This would produce:
 {{{
 
 
 }}}

 Now, in the first example, the difference is only semantic - but the
 second one creates invalid css as well, not such a big of a deal, but,
 gets troublesome when you *need* a number returned, such as when using {%
 widthratio %} with the google charts api. (sparklines, for example,
 require a number between 0-100 - anything above 100, such as 550, is
 visually returned as 100 in the chart - so you can't have empty values.)

 But, when would anyone ever encounter this problem? I personally do when
 displaying data over a time period, where in some cases, nothing may have
 happened - leaving everything at 0, both the values and max values - which
 then results in everything showing up empty, rather than defaulting back
 to 0.

 I realize this is easy to work around, but I thought I would put it out
 there since at least I wasn't expecting this behavior and it seems a bit
 weird, especially when this is mainly used to create charts in templates.

 (Patch is for the latest svn checkout as of this writing, rev 10833)

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

Re: [Django] #11165: Data gets truncated when saved

[Django]

#11165: Data gets truncated when saved
+---
  Reporter:  neoel  | Owner:  nobody
Status:  closed | Milestone:
 Component:  Uncategorized  |   Version:  1.0   
Resolution:  invalid|  Keywords:
 Stage:  Unreviewed | Has_patch:  0 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by russellm):

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

Comment:

 Django uses the Python DBAPI interface to submit queries, and that API
 handles the quoting and argument substitution. You don't need to put the
 quotes into the template SQL itself.

 I'm going to guess this is a problem with usage, rather than a fundamental
 problem with Django DB interface. If you need help diagnosing your
 problem, I suggest asking on Django-users with a repeatable example.

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

[Django] #11165: Data gets truncated when saved

[Django]

#11165: Data gets truncated when saved
---+
 Reporter:  neoel  |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Uncategorized  | Version:  1.0   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 I am working on a system to index my music library, and I think I stumbled
 on a bug.
 When a query gets formed quote marks are not entered in the query. here is
 a piece of code where I believe the problem lies.
 Below is the complete code.

 The query is formed with this code:
INSERT INTO `shoutcast_song` (`path`, `title`) VALUES (%s, %s)
 the data is entered at the values but no quotation marks are found.
 I believe the code should be like this:
INSERT INTO `shoutcast_song` (`path`, `title`) VALUES ('%s', '%s')


 /var/lib/python-support/python2.5/django/db/models/sql/query.py in
 execute_sql

 1727. except EmptyResultSet:
 1728. if result_type == MULTI:
 1729. return empty_iter()
 1730. else:
 1731. return
 1732.
 1733. cursor = self.connection.cursor()

 1734. cursor.execute(sql, params) ...

 1735.
 1736. if not result_type:
 1737. return cursor
 1738. if result_type == SINGLE:
 1739. if self.ordering_aliases:
 1740. return cursor.fetchone()[:-len(results.ordering_aliases)]

 ▼ Local vars
 VariableValue
 cursor
 
 params
 ("/files/Music/Q/Queens of the Stone Age - Songs For The Deaf/Queens Of
 The Stone Age - Era Vulgaris/Queens of the Stone Age - Queens Of The Stone
 Age/Queens of the Stone Age - Lullabies To Paralyze/Queens Of The Stone
 Age/Queens Of The Stone Age - Rated R/Queens Of The Stone Age - Songs For
 The Deaf [Europe]Queens Of The Stone Age - 01 - You Think I Ain't Worth A
 Dollar, But I Feel Like A Millionaire.mp3", "Queens Of The Stone Age - 01
 - You Think I Ain't Worth A Dollar, But I Feel Like A Millionaire.mp3")
 result_type
 None
 self
 
 sql
 'INSERT INTO `shoutcast_song` (`path`, `title`) VALUES (%s, %s)'

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

Re: [Django] #11163: admin ForeignKeyRawIdWidget contains incorrect link when used in change list view

[Django]

#11163: admin ForeignKeyRawIdWidget contains incorrect link when used in change
list view
---+
  Reporter:  margierogin...@yahoo.com  | Owner:  nobody
Status:  reopened  | Milestone:
 Component:  Uncategorized |   Version:  1.0   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by Alex):

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

Comment:

 Reopening because I may have confused this with the bug fixed in r10235,
 I'll reclose if it turns out I was indeed correct.

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

Re: [Django] #10476: Fix(?) model insert handling when autcommit=True for PostgreSQL <= 8.1

[Django]

#10476: Fix(?) model insert handling when autcommit=True for PostgreSQL <= 8.1
---+
  Reporter:  mtredinnick   | Owner:  mtredinnick
Status:  new   | Milestone: 
 Component:  Database layer (models, ORM)  |   Version:  SVN
Resolution:|  Keywords: 
 Stage:  Accepted  | Has_patch:  1  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Changes (by russellm):

  * milestone:  1.1 =>

Comment:

 Like Malcolm said, this can wait until v1.2. We won't ever release v1.1 if
 we keep adding tickets that aren't essential.

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

Re: [Django] #11163: admin ForeignKeyRawIdWidget contains incorrect link when used in change list view

[Django]

#11163: admin ForeignKeyRawIdWidget contains incorrect link when used in change
list view
---+
  Reporter:  margierogin...@yahoo.com  | Owner:  nobody
Status:  closed| Milestone:
 Component:  Uncategorized |   Version:  1.0   
Resolution:  invalid   |  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Comment (by margierogin...@yahoo.com):

 I am including admin.site.urls.  My urls.py looks like this:

 from django.contrib import admin
 admin.autodiscover()

 import os
 urlpatterns = patterns('',
(r'^admin/', include(admin.site.urls)),

 )

 if settings.SERVE_MEDIA:
 urlpatterns += patterns('',
 (r'^site_media/(?P.*)$', 'django.views.static.serve',
 {'document_root': os.path.join(os.path.dirname(__file__),
 "site_media")}),
 )


 I don't know if this is useful, but here is the value that site.get_urls()
 returns (newlines added by me):

 (Pdb) from django.contrib.admin.sites import site
 (Pdb) site
 
 (Pdb) site.get_urls()
 [,
 ,
 ,
 ,
 ,
 \d+)/(?P.+)/$>,
 \w+)/$>,
 ,
 ,
 ,
 ,
 ] ^auth/group/>,
 ,
 ,
 ,
 ,
 ,
 ] ^auth/user/>,
 ,
 ,
 ,
 ,
 ] ^sites/site/>,
 ,
 ,
 ,
 ,
 ]
 ^taskmanager/task/>]
 (Pdb)

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

Re: [Django] #6183: [patch] Support help_text with ManyToMany field widgets

[Django]

#6183: [patch] Support help_text with ManyToMany field widgets
--+-
  Reporter:  Steven Armstrong   | Owner:  
nobody
Status:  new  | Milestone:  
  
 Component:  django.contrib.admin |   Version:  
newforms-admin
Resolution:   |  Keywords:  
  
 Stage:  Accepted | Has_patch:  1   
  
Needs_docs:  0|   Needs_tests:  0   
  
Needs_better_patch:  1|  
--+-
Comment (by lakinwecker):

 Yeah I'd be interested in getting this added to trunk too.

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

[Django] #11164: inconsistency in installation documentation, and a suggestion

[Django]

#11164: inconsistency in installation documentation, and a suggestion
---+
 Reporter:  fcady2007  |   Owner:  nobody
   Status:  new|   Milestone:
Component:  Uncategorized  | Version:  1.0   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 The online instructions say to run the command "sudo python setup.py
 install", but the INSTALL file in the tar package says to use the command
 "python setup.py install".

 Also, neither of these commands is working for me.  If I do not use sudo,
 I can only import django when I launch python from the Django directory.
 If I use sudo, I get the error message "error: could not create
 'build/lib': Permission denied".  I have little experience with Linux, so
 I have no idea what's going wrong.  It would be good to update
 documentation so that people like me can troubleshoot.

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

Re: [Django] #11163: admin ForeignKeyRawIdWidget contains incorrect link when used in change list view

[Django]

#11163: admin ForeignKeyRawIdWidget contains incorrect link when used in change
list view
---+
  Reporter:  margierogin...@yahoo.com  | Owner:  nobody
Status:  closed| Milestone:
 Component:  Uncategorized |   Version:  1.0   
Resolution:  invalid   |  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by Alex):

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

Comment:

 This is fixed as long as you use the include(admin.site.urls) method for
 setting up the admin.

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

Re: [Django] #11163: admin ForeignKeyRawIdWidget contains incorrect link when used in change list view

[Django]

#11163: admin ForeignKeyRawIdWidget contains incorrect link when used in change
list view
---+
  Reporter:  margierogin...@yahoo.com  | 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 |  
---+
Old description:

> When the user specifies in their admin.py that a field is both editable
> and a raw_id, like this:
>
> list_editable = ('owner',)
> raw_id_fields = ('owner',)
>
> the ForeignKeyRawIdWidget is used in the change list view for that field.
> However, the code in the ForeignKeyRawIdWidget's render() method is
> hardcoded to be called from the edit form, with the following code:
>
> related_url = '../../../%s/%s/' % (self.rel.to._meta.app_label,
> self.rel.to._meta.object_name.lower())
>
> When called from the change list, the url has one less entry than when
> called from the edit form.  As a result, the link is wrong when called
> from the change list.  For example, the url for the changelist is
> something like this:
>
>http://mysite.com/admin/taskmanager/task/
>
> while the url from the edit form is like this:
>
>http://mysite.com/admin/taskmanager/task/1
>
> So when used in the change list, the raw id widget's link ends up
> pointing to http://mysite.com/auth/user/?t=id rather than
> http://mysite.com/admin/auth/user/?t=id

New description:

 When the user specifies in their admin.py that a field is both editable
 and a raw_id, like this:

 {{{
 list_editable = ('owner',)
 raw_id_fields = ('owner',)
 }}}

 the ForeignKeyRawIdWidget is used in the change list view for that field.
 However, the code in the ForeignKeyRawIdWidget's render() method is
 hardcoded to be called from the edit form, with the following code:

 {{{
 related_url = '../../../%s/%s/' % (self.rel.to._meta.app_label,
 self.rel.to._meta.object_name.lower())
 }}}

 When called from the change list, the url has one less entry than when
 called from the edit form.  As a result, the link is wrong when called
 from the change list.  For example, the url for the changelist is
 something like this:

http://mysite.com/admin/taskmanager/task/

 while the url from the edit form is like this:

http://mysite.com/admin/taskmanager/task/1

 So when used in the change list, the raw id widget's link ends up pointing
 to http://mysite.com/auth/user/?t=id rather than
 http://mysite.com/admin/auth/user/?t=id

Comment (by ramiro):

 (reformatted description)

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

[Django] #11163: admin ForeignKeyRawIdWidget contains incorrect link when used in change list view

[Django]

#11163: admin ForeignKeyRawIdWidget contains incorrect link when used in change
list view
+---
   Reporter:  margierogin...@yahoo.com  |Owner:  nobody
 Status:  new   |Milestone:
  Component:  Uncategorized |  Version:  1.0   
   Keywords:|Stage:  Unreviewed
  Has_patch:  0 |   Needs_docs:  0 
Needs_tests:  0 |   Needs_better_patch:  0 
+---
 When the user specifies in their admin.py that a field is both editable
 and a raw_id, like this:

 list_editable = ('owner',)
 raw_id_fields = ('owner',)

 the ForeignKeyRawIdWidget is used in the change list view for that field.
 However, the code in the ForeignKeyRawIdWidget's render() method is
 hardcoded to be called from the edit form, with the following code:

 related_url = '../../../%s/%s/' % (self.rel.to._meta.app_label,
 self.rel.to._meta.object_name.lower())

 When called from the change list, the url has one less entry than when
 called from the edit form.  As a result, the link is wrong when called
 from the change list.  For example, the url for the changelist is
 something like this:

http://mysite.com/admin/taskmanager/task/

 while the url from the edit form is like this:

http://mysite.com/admin/taskmanager/task/1

 So when used in the change list, the raw id widget's link ends up pointing
 to http://mysite.com/auth/user/?t=id rather than
 http://mysite.com/admin/auth/user/?t=id

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

[Changeset] r10834 - django/branches/releases/1.0.X/django/core/management/commands

[noreply]

Author: jacob
Date: 2009-05-20 15:05:49 -0500 (Wed, 20 May 2009)
New Revision: 10834

Modified:
   
django/branches/releases/1.0.X/django/core/management/commands/makemessages.py
Log:
[1.0.X] Fixed #10867: make the makemessages command ignore files and only 
process directories. Thanks, diegobz. Backport of [10833] from trunk.

Modified: 
django/branches/releases/1.0.X/django/core/management/commands/makemessages.py
===
--- 
django/branches/releases/1.0.X/django/core/management/commands/makemessages.py  
2009-05-20 20:05:14 UTC (rev 10833)
+++ 
django/branches/releases/1.0.X/django/core/management/commands/makemessages.py  
2009-05-20 20:05:49 UTC (rev 10834)
@@ -1,6 +1,7 @@
 import re
 import os
 import sys
+import glob
 import warnings
 from itertools import dropwhile
 from optparse import make_option
@@ -95,8 +96,9 @@
 if locale is not None:
 languages.append(locale)
 elif all:
-languages = [el for el in os.listdir(localedir) if not 
el.startswith('.')]
-
+locale_dirs = filter(os.path.isdir, glob.glob('%s/*' % localedir)) 
+languages = [os.path.basename(l) for l in locale_dirs]
+
 for locale in languages:
 if verbosity > 0:
 print "processing language", locale


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

[Changeset] r10833 - django/trunk/django/core/management/commands

[noreply]

Author: jacob
Date: 2009-05-20 15:05:14 -0500 (Wed, 20 May 2009)
New Revision: 10833

Modified:
   django/trunk/django/core/management/commands/makemessages.py
Log:
Fixed #10867: make the makemessages command ignore files and only process 
directories. Thanks, diegobz.

Modified: django/trunk/django/core/management/commands/makemessages.py
===
--- django/trunk/django/core/management/commands/makemessages.py
2009-05-20 16:19:24 UTC (rev 10832)
+++ django/trunk/django/core/management/commands/makemessages.py
2009-05-20 20:05:14 UTC (rev 10833)
@@ -1,6 +1,7 @@
 import re
 import os
 import sys
+import glob
 import warnings
 from itertools import dropwhile
 from optparse import make_option
@@ -95,8 +96,9 @@
 if locale is not None:
 languages.append(locale)
 elif all:
-languages = [el for el in os.listdir(localedir) if not 
el.startswith('.')]
-
+locale_dirs = filter(os.path.isdir, glob.glob('%s/*' % localedir)) 
+languages = [os.path.basename(l) for l in locale_dirs]
+
 for locale in languages:
 if verbosity > 0:
 print "processing language", locale


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

[Django] #11162: No Mention of raise exceptions.ValidationError in custom model fields docs

[Django]

#11162: No Mention of   raise exceptions.ValidationError in custom model fields
docs
---+
 Reporter:  avikohn|   Owner:  nobody
   Status:  new|   Milestone:
Component:  Documentation  | Version:  1.0   
 Keywords: |   Stage:  Unreviewed
Has_patch:  0  |  
---+
 It would be useful to mention the use of Mention the use of
 ValidationError in custom model fields docs as a valid response for
 incorrectly formatted data

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

Re: [Django] #11161: Added plural rules for supported languages

[Django]

#11161: Added plural rules for supported languages
---+
  Reporter:  daniels   | Owner:  nobody
Status:  new   | Milestone:
 Component:  Translations  |   Version:  1.0   
Resolution:|  Keywords:  plural
 Stage:  Unreviewed| Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  1 
Needs_better_patch:  0 |  
---+
Changes (by daniels):

  * needs_tests:  0 => 1

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

Re: [Django] #11161: Added plural rules for supported languages

[Django]

#11161: Added plural rules for supported languages
---+
  Reporter:  daniels   | Owner:  nobody
Status:  new   | Milestone:
 Component:  Translations  |   Version:  1.0   
Resolution:|  Keywords:  plural
 Stage:  Unreviewed| Has_patch:  1 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by daniels):

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

Comment:

 This ticket is related to tickets #6505 and #9974.

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

[Django] #11161: Added plural rules for supported languages

[Django]

#11161: Added plural rules for supported languages
--+-
 Reporter:  daniels   |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Translations  | Version:  1.0   
 Keywords:  plural|   Stage:  Unreviewed
Has_patch:  1 |  
--+-
 Added gettext plural rules in global_settings.conf and code in trans_real
 to support them.
 Use gettext own c2py to translate the rules.

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

Re: [Django] #5612: [patch] Signals for login / logout

[Django]

#5612: [patch] Signals for login / logout
-+--
  Reporter:  pterk   | Owner:  nobody
Status:  reopened| Milestone:
 Component:  Core framework  |   Version:  SVN   
Resolution:  |  Keywords:
 Stage:  Design decision needed  | Has_patch:  1 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  1   |  
-+--
Comment (by JohnDoe):

 Updated patch to work with newer version, changed behavior to trigger
 login signal before updating last_login because i need to log time between
 logins.

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

[Django] #11160: Formset non_form_errors returns ErrorList() if is_valid is not called

[Django]

#11160: Formset non_form_errors returns ErrorList() if is_valid is not called
+---
 Reporter:  vbmendes|   Owner:  nobody
   Status:  new |   Milestone:
Component:  Forms   | Version:  SVN   
 Keywords:  formset non_form_errors validation  |   Stage:  Unreviewed
Has_patch:  1   |  
+---
 If Formset.non_form_errors() is called before Formset.is_valid(), it will
 return an empty ErrorList.
 Let's pretend we have two formsets in one view and we make this test: if
 formset1.is_valid() and formset2.is_valid(). If formset1 is not valid,
 formset2's is_valid() will not be called. It means that the user will have
 to fix all the formset1's validation erros before knowing that formset2
 also has errors. It's annoying for the user.

 I wrote a little patch to fix this issue. Just changing a little the
 Formset.non_form_errors() function.

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

Re: [Django] #11147: manage.py doesn't work with settings directory in pydev

[Django]

#11147: manage.py doesn't work with settings directory in pydev
--+-
  Reporter:  Leo  | Owner:  nobody
Status:  closed   | Milestone:  1.1   
 Component:  django-admin.py  |   Version:  SVN   
Resolution:  invalid  |  Keywords:
 Stage:  Unreviewed   | Has_patch:  0 
Needs_docs:  0|   Needs_tests:  0 
Needs_better_patch:  0|  
--+-
Comment (by Leo):

 Thanks for all of the feedback. The workaround suggested by kmtracey is
 fine for now. From an more theoretical standpoint, its just a bandaid,
 since 'src' is already on the pythonpath and is not an importable package
 (/lib/site-packages wouldn't have an `__init__.py` either) but that's just
 a handwavy argument.

 jacob: It doesn't actually go up two directories. It assumes 'src' is the
 project name and attempts to import it (which doesn't work in the existing
 case since its a root pythonpath and not a package).

 What ramiro says makes a lot of sense here, since I'm not using a project
 I shouldn't expect manage.py to work - although it would be nice if it did
 :-)

 The one small qualm I have here is that if we assume a project layout,
 manage.py will always be in the project directory and that directory is
 available on the pythonpath since its the cwd when manage.py is run.
 There's probably use cases that I'm totally not aware of but from the ones
 I understand there's no need to explicitly import the project package.

 Regardless, I'm fine with either abandoning manage.py going forward (since
 we're not using projects) or putting the `__init__.py` files in for now.

 Thanks again for the comments.

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

Re: [Django] #2131: [patch] HttpResponseSendFile for serving static files handler-specific sendfile mechanism

[Django]

#2131: [patch] HttpResponseSendFile for serving static files handler-specific
sendfile mechanism
---+
  Reporter:  ymasuda[at]ethercube.com  | Owner:  alsleme
Status:  new   | Milestone:  1.2
 Component:  Core framework|   Version:  SVN
Resolution:|  Keywords: 
 Stage:  Accepted  | Has_patch:  1  
Needs_docs:  1 |   Needs_tests:  1  
Needs_better_patch:  1 |  
---+
Changes (by hackeron):

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

Re: [Django] #10476: Fix(?) model insert handling when autcommit=True for PostgreSQL <= 8.1

[Django]

#10476: Fix(?) model insert handling when autcommit=True for PostgreSQL <= 8.1
---+
  Reporter:  mtredinnick   | Owner:  mtredinnick
Status:  new   | Milestone:  1.1
 Component:  Database layer (models, ORM)  |   Version:  SVN
Resolution:|  Keywords: 
 Stage:  Accepted  | Has_patch:  1  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Comment (by Richard Davies ):

 The last patch leaves the 'if version >= 8.2' rather awkwardly inside an
 'if uses_autocommit'.

 I don't think that outer 'if' statement is necessary, even in light of
 #10467 comment 4 and #10509, so here's a version which removes it, and
 hence allows the 'returning' syntax to be used whenever version >= 8.2,
 regardless of uses_autocommit.

 I think that [10065] was confused between two things:

 - setting 'can_return_id_from_insert=True' inside _cursor() rather than by
 default, which is necessary and the point of #10509

 - only doing this if uses_autocommit, which was overcautious and
 unnecessary

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

Re: [Django] #10476: Fix(?) model insert handling when autcommit=True for PostgreSQL <= 8.1

[Django]

#10476: Fix(?) model insert handling when autcommit=True for PostgreSQL <= 8.1
---+
  Reporter:  mtredinnick   | Owner:  mtredinnick
Status:  new   | Milestone:  1.1
 Component:  Database layer (models, ORM)  |   Version:  SVN
Resolution:|  Keywords: 
 Stage:  Accepted  | Has_patch:  1  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Changes (by Richard Davies ):

  * has_patch:  0 => 1
  * milestone:  => 1.1

Comment:

 It turns out that the current code already works on PostgreSQL <= 8.1. I'm
 attaching a patch which simply removes the check (and some documentation
 of the limitation). This means that we'll be able to get database-native
 autocommit into 1.1. for all versions of PostgreSQL - good!

 The secret is that django/db/backends/postgresql/operations.py already
 defines last_insert_id() in terms of 'select currval' which is defined to
 be a session-local value (see http://www.postgresql.org/docs/7.3/static
 /functions-sequence.html or any other version).

 When django/db/models/sql/subqueries.py defines InsertQuery.execute_sql(),
 the version which uses return last_insert_id() is already session-safe,
 even in database-native autocommit mode without a wrapping transaction.
 The version which uses the 'returning' syntax on Postgresql >= 8.2 is
 simply more efficient, not more session-safe.

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

Re: [Django] #11147: manage.py doesn't work with settings directory in pydev

[Django]

#11147: manage.py doesn't work with settings directory in pydev
--+-
  Reporter:  Leo  | Owner:  nobody
Status:  closed   | Milestone:  1.1   
 Component:  django-admin.py  |   Version:  SVN   
Resolution:  invalid  |  Keywords:
 Stage:  Unreviewed   | Has_patch:  0 
Needs_docs:  0|   Needs_tests:  0 
Needs_better_patch:  0|  
--+-
Comment (by kmtracey):

 Leo, I don't understand why you can't just put an `__init__.py` in the
 `src` directory?  Fine, so Pydev doesn't do it automagically but it's easy
 enough to add one.  Then everything works.  I also don't see that this
 structure is mandated by Pydev -- you do not have to use the Eclipse/Pydev
 default `src` directory structure, it's just the default.  You can easily
 override and use your own source tree structure.  But given that you want
 to use that structure, what's the problem with putting an `__init__.py`
 file in the root?

 `__init__.py` wasn't needed in the root when you used a settings directory
 prior to r10751 because the code was incorrectly figuring the 'project'
 dir WAS the settings dir.  And things like `startapp` would create
 subdirectories in the settings dir, instead of the root project dir.  Now
 the project dir is being figured out correctly, it needs an `__init__.py`
 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 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

[Changeset] r10832 - in django/branches/releases/1.0.X: django/dispatch tests/modeltests/signals

[noreply]

Author: jacob
Date: 2009-05-20 11:19:24 -0500 (Wed, 20 May 2009)
New Revision: 10832

Added:
   django/branches/releases/1.0.X/tests/modeltests/signals/tests.py
Modified:
   django/branches/releases/1.0.X/django/dispatch/dispatcher.py
Log:
[1.0.X] Fixed #11134: signals recievers that disconnect during their processing 
no longer mess things up for other handlers. Thanks, Honza Kral. Backport of 
[10831] from trunk.

Modified: django/branches/releases/1.0.X/django/dispatch/dispatcher.py
===
--- django/branches/releases/1.0.X/django/dispatch/dispatcher.py
2009-05-20 16:13:55 UTC (rev 10831)
+++ django/branches/releases/1.0.X/django/dispatch/dispatcher.py
2009-05-20 16:19:24 UTC (rev 10832)
@@ -14,52 +14,61 @@
 return id(target)
 
 class Signal(object):
-"""Base class for all signals
+"""
+Base class for all signals
 
 Internal attributes:
-receivers -- { receriverkey (id) : weakref(receiver) }
+
+receivers
+{ receriverkey (id) : weakref(receiver) }
 """
 
 def __init__(self, providing_args=None):
-"""providing_args -- A list of the arguments this signal can pass 
along in
-   a send() call.
 """
+Create a new signal.
+
+providing_args
+A list of the arguments this signal can pass along in a send() 
call.
+"""
 self.receivers = []
 if providing_args is None:
 providing_args = []
 self.providing_args = set(providing_args)
 
 def connect(self, receiver, sender=None, weak=True, dispatch_uid=None):
-"""Connect receiver to sender for signal
+"""
+Connect receiver to sender for signal.
 
-receiver -- a function or an instance method which is to
-receive signals.  Receivers must be
-hashable objects.
+Arguments:
+
+receiver
+A function or an instance method which is to receive signals.
+Receivers must be hashable objects.
 
-if weak is True, then receiver must be weak-referencable
-(more precisely saferef.safeRef() must be able to create
-a reference to the receiver).
+if weak is True, then receiver must be weak-referencable (more
+precisely saferef.safeRef() must be able to create a reference
+to the receiver).
 
-Receivers must be able to accept keyword arguments.
+Receivers must be able to accept keyword arguments.
 
-If receivers have a dispatch_uid attribute, the receiver will
-  not be added if another receiver already exists with that
-  dispatch_uid.
+If receivers have a dispatch_uid attribute, the receiver will
+not be added if another receiver already exists with that
+dispatch_uid.
 
-sender -- the sender to which the receiver should respond
-Must either be of type Signal, or None to receive events
-from any sender.
+sender
+The sender to which the receiver should respond Must either be
+of type Signal, or None to receive events from any sender.
 
-weak -- whether to use weak references to the receiver
-By default, the module will attempt to use weak
-references to the receiver objects.  If this parameter
-is false, then strong references will be used.
+weak
+Whether to use weak references to the receiver By default, the
+module will attempt to use weak references to the receiver
+objects. If this parameter is false, then strong references 
will
+be used.
 
-dispatch_uid -- an identifier used to uniquely identify a particular
-instance of a receiver. This will usually be a string, though it
-may be anything hashable.
-
-returns None
+dispatch_uid
+An identifier used to uniquely identify a particular instance 
of
+a receiver. This will usually be a string, though it may be
+anything hashable.
 """
 from django.conf import settings
 
@@ -99,22 +108,27 @@
 self.receivers.append((lookup_key, receiver))
 
 def disconnect(self, receiver=None, sender=None, weak=True, 
dispatch_uid=None):
-"""Disconnect receiver from sender for signal
+"""
+Disconnect receiver from sender for signal.
+
+If weak references are used, disconnect need not be called. The 
receiver
+will be remove from dispatch automatically.
 
-receiver -- the registered receiver to disconnect. May be none if
-dispatch_uid is specified.
-sender -- the 

Re: [Django] #11147: manage.py doesn't work with settings directory in pydev

[Django]

#11147: manage.py doesn't work with settings directory in pydev
--+-
  Reporter:  Leo  | Owner:  nobody
Status:  closed   | Milestone:  1.1   
 Component:  django-admin.py  |   Version:  SVN   
Resolution:  invalid  |  Keywords:
 Stage:  Unreviewed   | Has_patch:  0 
Needs_docs:  0|   Needs_tests:  0 
Needs_better_patch:  0|  
--+-
Changes (by jacob):

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

Comment:

 I'm fairly sure this is a PyDev bug because looking at the code there's no
 way it'll step up *two* directories (it just calls `os.path.dirname`).

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

Re: [Django] #11158: get_image_dimensions very slow after 1 call

[Django]

#11158: get_image_dimensions very slow after 1 call
-+--
  Reporter:  kua | Owner:  nobody   
  
Status:  new | Milestone:   
  
 Component:  Core framework  |   Version:  1.0  
  
Resolution:  |  Keywords:  get_image_dimensions, 
field, save, slow
 Stage:  Unreviewed  | Has_patch:  1
  
Needs_docs:  0   |   Needs_tests:  0
  
Needs_better_patch:  0   |  
-+--
Comment (by kua):

 Also, a work around for the 1.0x, current, code base: fd.seek(0) anytime
 before you save that model which has an ImageField

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

[Changeset] r10831 - in django/trunk: django/dispatch tests/modeltests/signals

[noreply]

Author: jacob
Date: 2009-05-20 11:13:55 -0500 (Wed, 20 May 2009)
New Revision: 10831

Added:
   django/trunk/tests/modeltests/signals/tests.py
Modified:
   django/trunk/django/dispatch/dispatcher.py
Log:
Fixed #11134: signals recievers that disconnect during their processing no 
longer mess things up for other handlers. Thanks, Honza Kral.

While I was at it I also cleaned up the formatting of the docstrings a bit.

Modified: django/trunk/django/dispatch/dispatcher.py
===
--- django/trunk/django/dispatch/dispatcher.py  2009-05-20 11:03:10 UTC (rev 
10830)
+++ django/trunk/django/dispatch/dispatcher.py  2009-05-20 16:13:55 UTC (rev 
10831)
@@ -14,52 +14,61 @@
 return id(target)
 
 class Signal(object):
-"""Base class for all signals
+"""
+Base class for all signals
 
 Internal attributes:
-receivers -- { receriverkey (id) : weakref(receiver) }
+
+receivers
+{ receriverkey (id) : weakref(receiver) }
 """
 
 def __init__(self, providing_args=None):
-"""providing_args -- A list of the arguments this signal can pass 
along in
-   a send() call.
 """
+Create a new signal.
+
+providing_args
+A list of the arguments this signal can pass along in a send() 
call.
+"""
 self.receivers = []
 if providing_args is None:
 providing_args = []
 self.providing_args = set(providing_args)
 
 def connect(self, receiver, sender=None, weak=True, dispatch_uid=None):
-"""Connect receiver to sender for signal
+"""
+Connect receiver to sender for signal.
 
-receiver -- a function or an instance method which is to
-receive signals.  Receivers must be
-hashable objects.
+Arguments:
+
+receiver
+A function or an instance method which is to receive signals.
+Receivers must be hashable objects.
 
-if weak is True, then receiver must be weak-referencable
-(more precisely saferef.safeRef() must be able to create
-a reference to the receiver).
+if weak is True, then receiver must be weak-referencable (more
+precisely saferef.safeRef() must be able to create a reference
+to the receiver).
 
-Receivers must be able to accept keyword arguments.
+Receivers must be able to accept keyword arguments.
 
-If receivers have a dispatch_uid attribute, the receiver will
-  not be added if another receiver already exists with that
-  dispatch_uid.
+If receivers have a dispatch_uid attribute, the receiver will
+not be added if another receiver already exists with that
+dispatch_uid.
 
-sender -- the sender to which the receiver should respond
-Must either be of type Signal, or None to receive events
-from any sender.
+sender
+The sender to which the receiver should respond Must either be
+of type Signal, or None to receive events from any sender.
 
-weak -- whether to use weak references to the receiver
-By default, the module will attempt to use weak
-references to the receiver objects.  If this parameter
-is false, then strong references will be used.
+weak
+Whether to use weak references to the receiver By default, the
+module will attempt to use weak references to the receiver
+objects. If this parameter is false, then strong references 
will
+be used.
 
-dispatch_uid -- an identifier used to uniquely identify a particular
-instance of a receiver. This will usually be a string, though it
-may be anything hashable.
-
-returns None
+dispatch_uid
+An identifier used to uniquely identify a particular instance 
of
+a receiver. This will usually be a string, though it may be
+anything hashable.
 """
 from django.conf import settings
 
@@ -99,22 +108,27 @@
 self.receivers.append((lookup_key, receiver))
 
 def disconnect(self, receiver=None, sender=None, weak=True, 
dispatch_uid=None):
-"""Disconnect receiver from sender for signal
+"""
+Disconnect receiver from sender for signal.
+
+If weak references are used, disconnect need not be called. The 
receiver
+will be remove from dispatch automatically.
 
-receiver -- the registered receiver to disconnect. May be none if
-dispatch_uid is specified.
-sender -- the registered sender to disconnect
-weak -- the weakref state to 

Re: [Django] #11156: Unnecessary savepoints with Oracle

[Django]

#11156: Unnecessary savepoints with Oracle
---+
  Reporter:  Richard Davies   |
 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 mboersma):

 * cc: mboersma, ikelly (added)
  * needs_better_patch:  => 0
  * needs_tests:  => 0
  * needs_docs:  => 0

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

Re: [Django] #11155: Buffer size in get_image_dimensions too small

[Django]

#11155: Buffer size in get_image_dimensions too small
-+--
  Reporter:  seph| Owner:  nobody   
   
Status:  new | Milestone:  1.2  
   
 Component:  File uploads/storage|   Version:  SVN  
   
Resolution:  |  Keywords:  ImageField, 
get_image_dimensions, buffer
 Stage:  Design decision needed  | Has_patch:  1
   
Needs_docs:  0   |   Needs_tests:  0
   
Needs_better_patch:  0   |  
-+--
Changes (by jacob):

  * needs_better_patch:  => 0
  * needs_docs:  => 0
  * stage:  Unreviewed => Design decision needed
  * needs_tests:  => 0
  * milestone:  1.1 => 1.2

Comment:

 Not a 1.1 issue.

 Plus: why should you need to read the whole TIFF to get its dimensions?
 What sort of messed-up format does that?

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

[Django] #11159: Test client encode_file doesn't set content-type properly

[Django]

#11159: Test client encode_file doesn't set content-type properly
--+-
 Reporter:  notanumber|   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Testing framework | Version:  1.0   
 Keywords:  encode_file content-type  |   Stage:  Unreviewed
Has_patch:  1 |  
--+-
 The test client doesn't properly set the content-type when uploading
 files.  It hard-codes the content-type value to to 'application/octet-
 stream'.  This makes it difficult to test that code that relies on a
 specific content-type being set.

 The encode_file method could be easily changed to make use of
 mimetypes.guess_type to make a best guess attempt to set a content-type,
 falling back to the default 'application/octet-stream'.

 I've attached a patch that does this.

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

Re: [Django] #11158: get_image_dimensions very slow after 1 call

[Django]

#11158: get_image_dimensions very slow after 1 call
-+--
  Reporter:  kua | Owner:  nobody   
  
Status:  new | Milestone:   
  
 Component:  Core framework  |   Version:  1.0  
  
Resolution:  |  Keywords:  get_image_dimensions, 
field, save, slow
 Stage:  Unreviewed  | Has_patch:  1
  
Needs_docs:  0   |   Needs_tests:  0
  
Needs_better_patch:  0   |  
-+--
Comment (by kua):

 In [110]: f.seek(0)

 In [111]: get_image_dimensions(f)
 #very quick/snappy
 Out[111]: (4000, 3000)

 In [112]: f.seek(1)

 In [113]: get_image_dimensions(f)
 #very slow ~30 seconds, and returns none
 In [114]:

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

Re: [Django] #11158: get_image_dimensions very slow after 1 call

[Django]

#11158: get_image_dimensions very slow after 1 call
-+--
  Reporter:  kua | Owner:  nobody   
  
Status:  new | Milestone:   
  
 Component:  Core framework  |   Version:  1.0  
  
Resolution:  |  Keywords:  get_image_dimensions, 
field, save, slow
 Stage:  Unreviewed  | Has_patch:  1
  
Needs_docs:  0   |   Needs_tests:  0
  
Needs_better_patch:  0   |  
-+--
Changes (by kua):

  * needs_better_patch:  => 0
  * component:  Uncategorized => Core framework
  * needs_tests:  => 0
  * needs_docs:  => 0

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

[Django] #11158: get_image_dimensions very slow after 1 call

[Django]

#11158: get_image_dimensions very slow after 1 call
-+--
 Reporter:  kua  |   Owner:  nobody
   Status:  new  |   Milestone:
Component:  Uncategorized| Version:  1.0   
 Keywords:  get_image_dimensions, field, save, slow  |   Stage:  Unreviewed
Has_patch:  1|  
-+--
 get_image_dimensions in django.core.files.images is very slow after 1 call

 This has the effect of slowing down calls to save on model image fields,
 the whole thing shudders to a halt while we spin around in PIL.Image.feed

 The issue is that the read pointer is not being reset after the call to
 get_image_dimensions. Subsequent calls to file.read

 To reproduce:


 from django.core.files.images import get_image_dimensions[[BR]]
 from django.core.files.uploadedfile import File[[BR]]

 f = File(open('/tmp/some_multi_megabyte_file.jpg')[[BR]]
 get_image_dimensions(f)[[BR]]
 get_image_dimensions(f)[[BR]]



 I suggest this function should save the read pointer pos, reset it to 0,
 then do all the PIL fancyness, then reset the pointer when finished. I've
 tried to attach a patch that reflects this

 Imagine this scenario: Someone mucks with the read pointer on a hundred
 meg image, say reads 2 kilobytes. Then this function is called and starts
 reading data in 1K chunks looking for a header (which has already been
 skipped).

 So 100 Megabytes - 2 kilobytes / 1024 bytes per read means this function
 will be called over 100,000 times

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

[Django] #11157: slugify and admin javascript URLify function produce different strings

[Django]

#11157: slugify and admin javascript URLify function produce different strings
--+-
 Reporter:  keeperofkeys  |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  django.contrib.admin  | Version:  1.1-beta-1
 Keywords:  slug  |   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 The javascript used by the admin to autogenerate slugs, URLify() in
 django.contrib.admin.media.js, removes certain words from the string
 before converting spaces to dashes. But
 django.template.defaultfilters.slugify leaves all words intact.

 eg 'Working at home' -> 'working-home' using the admin js and 'working-at-
 home' using slugify.

 Personally I prefer the latter but, whichever way round, the two filters
 ought to behave the same, as their functionality is meant to be
 interchangeable.

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

Re: [Django] #11149: error with def save_form_data --

[Django]

#11149: error with def save_form_data --
---+
  Reporter:  romankrv  | Owner:  kmtracey
Status:  closed| Milestone:  1.1 
 Component:  Database layer (models, ORM)  |   Version:  SVN 
Resolution:  fixed |  Keywords:  
 Stage:  Accepted  | Has_patch:  0   
Needs_docs:  0 |   Needs_tests:  0   
Needs_better_patch:  0 |  
---+
Comment (by romankrv):

 You are right. I haven't it but I reinstall it and it work. Bug is fixed.
 Good work cooparete.

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

Re: [Django] #11149: error with def save_form_data --

[Django]

#11149: error with def save_form_data --
---+
  Reporter:  romankrv  | Owner:  kmtracey
Status:  closed| Milestone:  1.1 
 Component:  Database layer (models, ORM)  |   Version:  SVN 
Resolution:  fixed |  Keywords:  
 Stage:  Accepted  | Has_patch:  0   
Needs_docs:  0 |   Needs_tests:  0   
Needs_better_patch:  0 |  
---+
Comment (by kmtracey):

 Replying to [comment:8 romankrv]:
 > After update it not import
 > "from django.core.files.utils import FileProxyMixin"

 That would seem to indicate your checkout is not complete.  Do you have
 the file django/core/files/utils.py?  It was added quite recently and the
 only thing in it is !FileProxyMixin:

 http://code.djangoproject.com/browser/django/trunk/django/core/files/utils.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 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---

Re: [Django] #11112: Formsets not supported as steps in FormWizard

[Django]

#2: Formsets not supported as steps in FormWizard
--+-
  Reporter:  hlecuanda   | Owner:  nobody  
  
Status:  new  | Milestone:  1.2 
  
 Component:  django.contrib.formtools |   Version:  SVN 
  
Resolution:   |  Keywords:  
FormWizard FormSet
 Stage:  Accepted | Has_patch:  1   
  
Needs_docs:  0|   Needs_tests:  0   
  
Needs_better_patch:  0|  
--+-
Changes (by anonymous):

 * cc: a...@andybak.net (added)

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

[Changeset] r10830 - django/trunk/django/conf/locale/pl/LC_MESSAGES

[noreply]

Author: zgoda
Date: 2009-05-20 06:03:10 -0500 (Wed, 20 May 2009)
New Revision: 10830

Modified:
   django/trunk/django/conf/locale/pl/LC_MESSAGES/django.mo
   django/trunk/django/conf/locale/pl/LC_MESSAGES/django.po
Log:
Polish translation updated.


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

Modified: django/trunk/django/conf/locale/pl/LC_MESSAGES/django.po
===
--- django/trunk/django/conf/locale/pl/LC_MESSAGES/django.po2009-05-20 
00:26:07 UTC (rev 10829)
+++ django/trunk/django/conf/locale/pl/LC_MESSAGES/django.po2009-05-20 
11:03:10 UTC (rev 10830)
@@ -5,7 +5,7 @@
 msgstr ""
 "Project-Id-Version: Django\n"
 "Report-Msgid-Bugs-To: \n"
-"POT-Creation-Date: 2009-05-06 09:30+0200\n"
+"POT-Creation-Date: 2009-05-20 12:58+0200\n"
 "PO-Revision-Date: 2008-02-25 15:53+0100\n"
 "Last-Translator: Jarek Zgoda \n"
 "MIME-Version: 1.0\n"
@@ -218,16 +218,16 @@
 msgid "Traditional Chinese"
 msgstr "chiński tradycyjny"
 
-#: contrib/admin/actions.py:56
+#: contrib/admin/actions.py:60
 #, python-format
 msgid "Successfully deleted %(count)d %(items)s."
 msgstr "Usunięto %(count)d %(items)s."
 
-#: contrib/admin/actions.py:63 contrib/admin/options.py:1025
+#: contrib/admin/actions.py:67 contrib/admin/options.py:1025
 msgid "Are you sure?"
 msgstr "Jesteś pewien?"
 
-#: contrib/admin/actions.py:81
+#: contrib/admin/actions.py:85
 #, python-format
 msgid "Delete selected %(verbose_name_plural)s"
 msgstr "Usuń wybrane %(verbose_name_plural)s"
@@ -320,7 +320,8 @@
 msgstr "Zmieniono %s"
 
 #: contrib/admin/options.py:519 contrib/admin/options.py:529
-#: contrib/comments/templates/comments/preview.html:16 forms/models.py:384
+#: contrib/comments/templates/comments/preview.html:16 forms/models.py:388
+#: forms/models.py:587
 msgid "and"
 msgstr "i"
 
@@ -4050,7 +4051,7 @@
 msgstr ""
 "Wybierz poprawną wartość. %(value)s nie jest jednym z dostępnych wyborów."
 
-#: forms/fields.py:704 forms/fields.py:765 forms/models.py:863
+#: forms/fields.py:704 forms/fields.py:765 forms/models.py:991
 msgid "Enter a list of values."
 msgstr "Podaj listę wartości."
 
@@ -4067,32 +4068,55 @@
 msgid "Order"
 msgstr "Porządek"
 
-#: forms/models.py:363
+#: forms/models.py:367
 #, python-format
 msgid "%(field_name)s must be unique for %(date_field)s %(lookup)s."
 msgstr ""
-"Wartości w %(field_name)s muszą być unikalne dla wyszukiwań %(lookup)s "
-"w %(date_field)s"
+"Wartości w %(field_name)s muszą być unikalne dla wyszukiwań %(lookup)s w %"
+"(date_field)s"
 
-#: forms/models.py:377 forms/models.py:385
+#: forms/models.py:381 forms/models.py:389
 #, python-format
 msgid "%(model_name)s with this %(field_label)s already exists."
 msgstr "%(field_label)s już istnieje w %(model_name)s."
 
-#: forms/models.py:738
+#: forms/models.py:581
+#, python-format
+msgid "Please correct the duplicate data for %(field)s."
+msgstr "Popraw zduplikowane dane w %(field)s."
+
+#: forms/models.py:585
+#, python-format
+msgid "Please correct the duplicate data for %(field)s, which must be unique."
+msgstr "Popraw zduplikowane dane w %(field)s, które wymaga unikalności."
+
+#: forms/models.py:591
+#, python-format
+msgid ""
+"Please correct the duplicate data for %(field_name)s which must be unique "
+"for the %(lookup)s in %(date_field)s."
+msgstr ""
+"Popraw zduplikowane dane w %(field_name)s, które wymaga unikalności dla "
+"%(lookup)s w polu %(date_field)s."
+
+#: forms/models.py:599
+msgid "Please correct the duplicate values below."
+msgstr "Popraw poniższe zduplikowane wartości."
+
+#: forms/models.py:855
 msgid "The inline foreign key did not match the parent instance primary key."
 msgstr "Osadzony klucz obcy nie pasuje do klucza głównego obiektu rodzica."
 
-#: forms/models.py:793
+#: forms/models.py:918
 msgid "Select a valid choice. That choice is not one of the available choices."
 msgstr "Wybierz poprawną wartość. Podana nie jest jednym z dostępnych wyborów."
 
-#: forms/models.py:864
+#: forms/models.py:992
 #, python-format
 msgid "Select a valid choice. %s is not one of the available choices."
 msgstr "Wybierz poprawną wartość. %s nie jest jednym z dostępnych wyborów."
 
-#: forms/models.py:866
+#: forms/models.py:994
 #, python-format
 msgid "\"%s\" is not a valid value for a primary key."
 msgstr "\"%s\" nie jest poprawną wartością klucza głównego."
@@ -4124,27 +4148,27 @@
 msgid "%.1f GB"
 msgstr "%.1f GB"
 
-#: utils/dateformat.py:41
+#: utils/dateformat.py:42
 msgid "p.m."
 msgstr "po południu"
 
-#: utils/dateformat.py:42
+#: utils/dateformat.py:43
 msgid "a.m."
 msgstr "rano"
 
-#: utils/dateformat.py:47
+#: utils/dateformat.py:48
 msgid "PM"
 msgstr "po południu"
 
-#: utils/dateformat.py:48
+#: utils/dateformat.py:49
 msgid "AM"
 msgstr "rano"
 
-#: utils/dateformat.py:97
+#: utils/dateformat.py:98
 msgid "midnight"
 msgstr "północ"

[Django] #11156: Unnecessary savepoints with Oracle

[Django]

#11156: Unnecessary savepoints with Oracle
--+-
 Reporter:  Richard Davies   |   Owner:  
nobody
   Status:  new   |   Milestone:

Component:  Database layer (models, ORM)  | Version:  
SVN   
 Keywords:|   Stage:  
Unreviewed
Has_patch:  0 |  
--+-
 Savepoints are implemented in the Postgresql and Oracle backends, and
 provide a useful features to users of both.

 In addition, the framework itself wraps various calls in savepoints (e.g.
 inside django/db/models/query.py:get_or_create). This is to work around a
 Postgresql-specific oddity that the open transaction needs to be rolled
 back to a prior savepoint if it experiences a database exception.

 This oddity is not present on Oracle, so the extra savepoints are not
 required. We probably need to split the current single backend flag
 uses_savepoints into two: can_savepoint and
 needs_savepoint_after_exception.

 See http://groups.google.com/group/django-
 developers/browse_thread/thread/bca33ecf27ff5d63

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

Re: [Django] #4339: Override an existing file, using Model.save_FIELD_file method,

[Django]

#4339: Override an existing file, using Model.save_FIELD_file method,
---+
  Reporter:  elaat...@gmail.com| Owner:  Gulopine   

Status:  new   | Milestone: 

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

Resolution:|  Keywords:  FileField 
db fs-rf-docs
 Stage:  Design decision needed| Has_patch:  1  

Needs_docs:  1 |   Needs_tests:  0  

Needs_better_patch:  1 |  
---+
Comment (by olau):

 rizumu: This bug is not particular to the admin. Also what you're talking
 about is the situation where the user is supposed to control the filename.
 This bug is about the case where the programmer is supposed to control the
 filename (where currently there's no simple knob in Django to say "this
 filename, and I mean it, no underscores").

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

Re: [Django] #11144: UnicodeEncodeError when unicode characters present in To/From/Cc and also a comma is present

[Django]

#11144: UnicodeEncodeError when unicode characters present in To/From/Cc and 
also a
comma is present
-+--
  Reporter:  anonymous   | Owner:  nobody   
 
Status:  new | Milestone:   
 
 Component:  django.core.mail|   Version:  1.0  
 
Resolution:  |  Keywords:  
UnicodeEncodeError
 Stage:  Design decision needed  | Has_patch:  1
 
Needs_docs:  0   |   Needs_tests:  0
 
Needs_better_patch:  0   |  
-+--
Changes (by rmt):

  * has_patch:  0 => 1

Comment:

 Patch attached.  Although handling header encoding in a function named
 forbid_multi_line_headers doesn't seem optimal.

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

Re: [Django] #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.1
 
 Component:  Database layer (models, ORM)  |   Version:  1.0-beta-1 
 
Resolution:|  Keywords:  
transactions
 Stage:  Accepted  | Has_patch:  1  
 
Needs_docs:  1 |   Needs_tests:  0  
 
Needs_better_patch:  0 |  
---+
Changes (by basti):

 * cc: basti (added)

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

Re: [Django] #11149: error with def save_form_data --

[Django]

#11149: error with def save_form_data --
---+
  Reporter:  romankrv  | Owner:  kmtracey
Status:  closed| Milestone:  1.1 
 Component:  Database layer (models, ORM)  |   Version:  SVN 
Resolution:  fixed |  Keywords:  
 Stage:  Accepted  | Has_patch:  0   
Needs_docs:  0 |   Needs_tests:  0   
Needs_better_patch:  0 |  
---+
Comment (by romankrv):

 After update it not import
 "from django.core.files.utils import FileProxyMixin"

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

Re: [Django] #4339: Override an existing file, using Model.save_FIELD_file method,

[Django]

#4339: Override an existing file, using Model.save_FIELD_file method,
---+
  Reporter:  elaat...@gmail.com| Owner:  Gulopine   

Status:  new   | Milestone: 

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

Resolution:|  Keywords:  FileField 
db fs-rf-docs
 Stage:  Design decision needed| Has_patch:  1  

Needs_docs:  1 |   Needs_tests:  0  

Needs_better_patch:  1 |  
---+
Comment (by rizumu):

 Just a quick thought from a UI standpoint in the Admin, it sure would be
 nice when you add an image for there to be a pop-up that showed you the
 image and proposed three options. A similar pop-up for an image could post
 some meta-data.

 Would you like to:
 Overwrite the existing image with the new one? (sitewide)
 Save the new image under a different name? (affects only this instance)
 Use the existing image? (No need to create a new one with an _ in the
 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-updates@googlegroups.com
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~--~~~~--~~--~--~---