Re: [Django] #16128: cascade delete does not work for proxy models

[Django]

#16128: cascade delete does not work for proxy models
-+-
 Reporter:  xkennyx@…|Owner:  nobody
 Type:  Bug  |   Status:  reopened
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  cascade delete   |  Needs documentation:  0
  proxy meta |  Patch needs improvement:  1
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by carljm):

 Replying to [comment:20 carljm]:
 > Replying to [comment:19 akaariai]:
 > >   - I hope the auto-created deferred model classes are not included in
 the proxy eq class. That could cause some problems...
 >
 > I'm not sure what you mean by "auto-created deferred model classes". The
 only auto-created model classes I'm aware of are those for many-to-many
 relations, and I don't see how those would cause a problem; they should
 never be nor have proxies.

 Whoops, sorry, charettes set me straight here on IRC. I'd forgotten that
 the `.defer()` implementation auto-creates proxy model classes
 automatically. On quick inspection I can't see why these wouldn't be
 included, but I'm also not clear what problem this would cause. You're
 right that it may need attention/tests, in any case.

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

-- 
You received this message because you are subscribed to the Google 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] #14087: django.core.management.get_commands only sees commands in the last package of a namespace package

[Django]

#14087: django.core.management.get_commands only sees commands in the last 
package
of a namespace package
--+
 Reporter:  KyleMac   |Owner:  nobody
 Type:  Bug   |   Status:  reopened
Component:  Core (Other)  |  Version:  1.2
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  1
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+

Comment (by bhuztez):

 update patch for revision 17517

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

-- 
You received this message because you are subscribed to the Google 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] #16502: CreateView useless error message when template_name is not specified

[Django]

#16502: CreateView useless error message when template_name is not specified
-+-
 Reporter:  silverghost3@…   |Owner:
 Type:  Bug  |  Silver_Ghost
Component:  Generic views|   Status:  assigned
 Severity:  Normal   |  Version:  SVN
 Keywords:  CreateView "generic  |   Resolution:
  view"  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by bhuztez):

 update Silver_Ghost's patch for revision 17517

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

-- 
You received this message because you are subscribed to the Google 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] #6498: Add case insensitive model ordering

[Django]

#6498: Add case insensitive model ordering
-+-
 Reporter:  Bastian Kleineidam   |Owner:  nobody
   |   Status:  new
 Type:  New feature  |  Version:  SVN
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  1
 Keywords:   |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by mitar):

 * cc: mmitar@… (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] #7580: Support ORDER BY BINARY in MySQL

[Django]

#7580: Support ORDER BY BINARY in MySQL
-+-
 Reporter:  Paul Kenjora |Owner:  anonymous
     |   Status:  closed
 Type:  New feature  |  Version:  SVN
Component:  Database layer   |   Resolution:  duplicate
  (models, ORM)  | Triage Stage:  Design
 Severity:  Normal   |  decision needed
 Keywords:  mysql, binary,   |  Needs documentation:  0
  order by   |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by mitar):

 * cc: mmitar@… (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] #16128: cascade delete does not work for proxy models

[Django]

#16128: cascade delete does not work for proxy models
-+-
 Reporter:  xkennyx@…|Owner:  nobody
 Type:  Bug  |   Status:  reopened
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  cascade delete   |  Needs documentation:  0
  proxy meta |  Patch needs improvement:  1
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by carljm):

 Replying to [comment:19 akaariai]:
 > I will not have time before Monday. I don't know if that is soon enough
 for 1.4.

 This is a bugfix, it can go in after the beta is released.

 >   - If a model has a large number of proxy models, does that cause
 performance problems?

 I'm not particularly concerned about that, as long as the patch doesn't do
 anything egregiously silly. If the proxy equivalence class is built up in
 Options at class-creation time, and we can move the get-relations-with-
 proxy-equivalence logic into Options so we aren't looking through the same
 relations over and over again, I think we should be fine.

 >   - The proxy_for_model is actually the same thing as concrete_model.
 proxy_for_model is supposed to build a chain of proxies to the concrete
 model, but that is not happening correctly. I don't think fixing this is
 this ticket's problem, but it is good to note this as this can cause
 problems when fixing this ticket.

 Is there a separate bug filed for that problem? If we fix that first,
 would it make the fix here clearer/simpler?

 >   - I hope the auto-created deferred model classes are not included in
 the proxy eq class. That could cause some problems...

 I'm not sure what you mean by "auto-created deferred model classes". The
 only auto-created model classes I'm aware of are those for many-to-many
 relations, and I don't see how those would cause a problem; they should
 never be nor have proxies.

 I think the whole concept of the "proxy equivalence class", if represented
 clearly in Options, will be useful in fixing other issues that make proxy
 models less useful than they could be. For instance, assigning any member
 of a proxy equivalence class to a ForeignKey ought to satisfy that FK's
 "is this object of the right type?" check. (Obviously that should be a
 separate ticket, just mentioning that I think this is adding something
 generally useful to Options).

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

-- 
You received this message because you are subscribed to the Google 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] #12460: inspectdb and field names ending with underscores

[Django]

#12460: inspectdb and field names ending with underscores
-+-
 Reporter:  3gun |Owner:  kgibula
     |   Status:  assigned
 Type:  Bug  |  Version:  SVN
Component:  Core (Management |   Resolution:
  commands)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:  inspectdb|  Patch needs improvement:  0
  underscore characters digits   |UI/UX:  0
Has patch:  1|
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by claudep):

 * needs_better_patch:  1 => 0
 * version:  1.1 => SVN
 * needs_tests:  1 => 0
 * ui_ux:   => 0


Comment:

 Here's an updated patch where I have slightly refactored things to isolate
 the normalization process of the field name. I purposely did not include
 the non-ascii characters issue which was also addressed by previous
 "inspectdb.diff" patch. If the committer finds it's better to also include
 it, I can complete the patch. Otherwise, I'll gladly add a specific patch
 for that issue in #16737 after this one is committed.

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

-- 
You received this message because you are subscribed to the Google 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] #13223: ValueError with inline and save as new

[Django]

#13223: ValueError with inline and save as new
+
 Reporter:  lucalenardi |Owner:  igors
 Type:  Bug |   Status:  assigned
Component:  contrib.admin   |  Version:  1.1
 Severity:  Normal  |   Resolution:
 Keywords:  admin, save-as-new  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  1
Easy pickings:  0   |UI/UX:  0
+
Changes (by igors):

 * cc: igor@… (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] #13223: ValueError with inline and save as new

[Django]

#13223: ValueError with inline and save as new
+
 Reporter:  lucalenardi |Owner:  igors
 Type:  Bug |   Status:  assigned
Component:  contrib.admin   |  Version:  1.1
 Severity:  Normal  |   Resolution:
 Keywords:  admin, save-as-new  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  1
Easy pickings:  0   |UI/UX:  0
+
Changes (by igors):

 * status:  new => assigned
 * owner:   => igors


Comment:

 I was wondering how this intermediate view could be implemented.

 The idea is to replace the "Save as New" button for a link to a clone/
 view. This view would present a pre-filled form with the data from the
 original object you'd like to clone. It's (very) similar to {{{ add_view
 }}}, but using {{{ initial }}} to fill the form based on the original
 object.
 The formsets are also pre-filled using {{{ initial }}}.

 All of this happens on GET. POSTing is the same as {{{ add_view}}}'s POST.

 This is the same to call {{{ add_view }}} passing initial values as GET
 parameters. But I think a clone/ url is much cleaner.

 Let me know if I'm on the right track so I can continue with the
 implementation. It's ugly with lot's of duplication and incomplete at this
 moment, the patch is just a prototype. But I need some feedback before
 moving 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-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] #17668: prefetch_related does not work in in_bulk

[Django]

#17668: prefetch_related does not work in in_bulk
-+-
 Reporter:  gurets@… |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Database layer   |  Version:
  (models, ORM)  |  1.4-alpha-1
 Severity:  Release blocker  |   Resolution:
 Keywords:  prefetch_related,| Triage Stage:  Accepted
  in_bulk|  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by akaariai):

 There are three possible choices for the iterator() + prefetch_related():
   1. Raise error.
   2. Favor prefetch: when iterator is used, fetch all the objects and
 related objects in one go, then yield them one at a time.
   3. Favor iterator: throw out the defined prefetch, and do the iterator
 properly. This is what is currently done.

 I suggested option 1 already, but that wasn't favored. From the rest
 option 2 is in my opinion better than the currently used option 3. Just
 because the potential performance loss is less in that case. You would get
 the reduced memory usage given by .iterator() when it is possible to do
 that. If there is prefetches, they are done correctly, but you lose the
 memory efficiency of iterator(). For example, in_bulk would have worked
 perfectly without any changes to it with option 2.

 Option 2 should be easy to implement, where the error is raised currently,
 do:
 {{{
 for obj in list(self):
 yield obj
 }}}
 I haven't actually tested this though...

 Anyways, which option is chosen isn't __that__ important. I could live
 with any of them.

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

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

[Changeset] r17518 - django/branches/releases/1.3.X/docs/topics/http

[noreply]

Author: timo
Date: 2012-02-12 09:16:37 -0800 (Sun, 12 Feb 2012)
New Revision: 17518

Modified:
   django/branches/releases/1.3.X/docs/topics/http/urls.txt
Log:
Fixed #16653 - Added example of kwargs support for resolve(); thanks krzysiumed 
for the patch.

Backport of r17517 from trunk.

Modified: django/branches/releases/1.3.X/docs/topics/http/urls.txt
===
--- django/branches/releases/1.3.X/docs/topics/http/urls.txt2012-02-12 
17:10:31 UTC (rev 17517)
+++ django/branches/releases/1.3.X/docs/topics/http/urls.txt2012-02-12 
17:16:37 UTC (rev 17518)
@@ -818,6 +818,13 @@
 namespaces into URLs on specific application instances, according to the
 :ref:`namespaced URL resolution strategy 
`.
 
+You can use ``kwargs`` instead of ``args``, for example::
+
+>>> reverse('admin:app_list', kwargs={'app_label': 'auth'})
+'/admin/auth/'
+
+``args`` and ``kwargs`` cannot be passed to ``reverse()`` at the same time.
+
 .. admonition:: Make sure your views are all correct.
 
 As part of working out which URL names map to which patterns, the

-- 
You received this message because you are subscribed to the Google 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] #16653: Document kwargs support for urlresolvers.resolve

[Django]

#16653: Document kwargs support for urlresolvers.resolve
-+-
 Reporter:  jedie|Owner:
 Type:   |  krzysiumed
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  1.3
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  1|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by timo):

 In [17518]:
 {{{
 #!CommitTicketReference repository="" revision="17518"
 Fixed #16653 - Added example of kwargs support for resolve(); thanks
 krzysiumed for the patch.

 Backport of r17517 from trunk.
 }}}

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

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

Re: [Django] #16653: Document kwargs support for urlresolvers.resolve

[Django]

#16653: Document kwargs support for urlresolvers.resolve
-+-
 Reporter:  jedie|Owner:
 Type:   |  krzysiumed
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  1.3
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  1|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by timo):

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


Comment:

 In [17517]:
 {{{
 #!CommitTicketReference repository="" revision="17517"
 Fixed #16653 - Added example of kwargs support for resolve(); thanks
 krzysiumed for the patch.
 }}}

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

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

[Changeset] r17517 - django/trunk/docs/topics/http

[noreply]

Author: timo
Date: 2012-02-12 09:10:31 -0800 (Sun, 12 Feb 2012)
New Revision: 17517

Modified:
   django/trunk/docs/topics/http/urls.txt
Log:
Fixed #16653 - Added example of kwargs support for resolve(); thanks krzysiumed 
for the patch.

Modified: django/trunk/docs/topics/http/urls.txt
===
--- django/trunk/docs/topics/http/urls.txt  2012-02-12 15:18:24 UTC (rev 
17516)
+++ django/trunk/docs/topics/http/urls.txt  2012-02-12 17:10:31 UTC (rev 
17517)
@@ -846,6 +846,11 @@
 namespaces into URLs on specific application instances, according to the
 :ref:`namespaced URL resolution strategy 
`.
 
+You can use ``kwargs`` instead of ``args``, for example::
+
+>>> reverse('admin:app_list', kwargs={'app_label': 'auth'})
+'/admin/auth/'
+
 ``args`` and ``kwargs`` cannot be passed to ``reverse()`` at the same time.
 
 .. admonition:: Make sure your views are all correct.

-- 
You received this message because you are subscribed to the Google 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] r17516 - django/trunk/docs/ref/contrib

[noreply]

Author: aaugustin
Date: 2012-02-12 07:18:24 -0800 (Sun, 12 Feb 2012)
New Revision: 17516

Modified:
   django/trunk/docs/ref/contrib/syndication.txt
Log:
Fixed #16150 -- Added 'feed_url' and clarified 'link' in the Feed reference 
docs.


Modified: django/trunk/docs/ref/contrib/syndication.txt
===
--- django/trunk/docs/ref/contrib/syndication.txt   2012-02-12 15:10:08 UTC 
(rev 17515)
+++ django/trunk/docs/ref/contrib/syndication.txt   2012-02-12 15:18:24 UTC 
(rev 17516)
@@ -388,17 +388,34 @@
 
 def link(self, obj):
 """
-# Takes the object returned by get_object() and returns the feed's
-# link as a normal Python string.
+# Takes the object returned by get_object() and returns the URL
+# of the HTML version of the feed as a normal Python string.
 """
 
 def link(self):
 """
-Returns the feed's link as a normal Python string.
+Returns the URL of the HTML version of the feed as a normal Python
+string.
 """
 
-link = '/foo/bar/' # Hard-coded link.
+link = '/blog/' # Hard-coded URL.
 
+# FEED_URL -- One of the following three is optional. The framework
+# looks for them in this order.
+
+def feed_url(self, obj):
+"""
+# Takes the object returned by get_object() and returns the feed's
+# own URL as a normal Python string.
+"""
+
+def feed_url(self):
+"""
+Returns the feed's own URL as a normal Python string.
+"""
+
+feed_url = '/blog/rss/' # Hard-coded URL.
+
 # GUID -- One of the following three is optional. The framework looks
 # for them in this order. This property is only used for Atom feeds
 # (where it is the feed-level ID element). If not provided, the feed

-- 
You received this message because you are subscribed to the Google 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] #16150: Syndication Feed docs incorrectly describe tag.

[Django]

#16150: Syndication Feed docs incorrectly describe  tag.
-+-
 Reporter:  melinath |Owner:  melinath
 Type:  Bug  |   Status:  closed
Component:  Documentation|  Version:  SVN
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  rss  | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  1|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by aaugustin):

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


Comment:

 In [17516]:
 {{{
 #!CommitTicketReference repository="" revision="17516"
 Fixed #16150 -- Added 'feed_url' and clarified 'link' in the Feed
 reference docs.
 }}}

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

-- 
You received this message because you are subscribed to the Google 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] r17515 - django/trunk/docs/releases

[noreply]

Author: aaugustin
Date: 2012-02-12 07:10:08 -0800 (Sun, 12 Feb 2012)
New Revision: 17515

Modified:
   django/trunk/docs/releases/1.4.txt
Log:
Fixed #17451 -- Mentioned the new JavaScript lexer in the release notes. Refs 
#7704.


Modified: django/trunk/docs/releases/1.4.txt
===
--- django/trunk/docs/releases/1.4.txt  2012-02-12 14:49:42 UTC (rev 17514)
+++ django/trunk/docs/releases/1.4.txt  2012-02-12 15:10:08 UTC (rev 17515)
@@ -524,6 +524,11 @@
   documentation about :ref:`the 403 (HTTP Forbidden) view`
   for more information.
 
+* The :djadmin:`makemessages` command uses a new and more accurate lexer,
+  `JsLex`_, for extracting translatable strings from JavaScript files.
+
+.. _JsLex: https://bitbucket.org/ned/jslex
+
 * The :ttag:`trans` template tag now takes an optional ``as`` argument to
   be able to retrieve a translation string without displaying it but setting
   a template context variable instead.

-- 
You received this message because you are subscribed to the Google 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] #7704: JS comments put after statements break make-messages.py output

[Django]

#7704: JS comments put after statements break make-messages.py output
-+-
 Reporter:  robbyd   |Owner:
 Type:  Bug  |  nedbatchelder
Component:   |   Status:  closed
  Internationalization   |  Version:  1.0
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  djangojs, make-  | Triage Stage:  Accepted
  messages   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|
Easy pickings:  1|
-+-

Comment (by aaugustin):

 In [17515]:
 {{{
 #!CommitTicketReference repository="" revision="17515"
 Fixed #17451 -- Mentioned the new JavaScript lexer in the release notes.
 Refs #7704.
 }}}

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

-- 
You received this message because you are subscribed to the Google 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] #17451: 1.4 release notes should mention new Javascript parsing for makemessages

[Django]

#17451: 1.4 release notes should mention new Javascript parsing for makemessages
-+-
 Reporter:  nedbatchelder|Owner:  zsiciarz
 Type:  Uncategorized|   Status:  closed
Component:  Documentation|  Version:
 Severity:  Normal   |  1.4-alpha-1
 Keywords:   |   Resolution:  fixed
Has patch:  1| Triage Stage:  Ready for
  Needs tests:  0|  checkin
Easy pickings:  0|  Needs documentation:  0
 |  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by aaugustin):

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


Comment:

 In [17515]:
 {{{
 #!CommitTicketReference repository="" revision="17515"
 Fixed #17451 -- Mentioned the new JavaScript lexer in the release notes.
 Refs #7704.
 }}}

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

-- 
You received this message because you are subscribed to the Google 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] r17514 - django/trunk/django/contrib/staticfiles/management/commands

[noreply]

Author: jezdez
Date: 2012-02-12 06:49:42 -0800 (Sun, 12 Feb 2012)
New Revision: 17514

Modified:
   django/trunk/django/contrib/staticfiles/management/commands/collectstatic.py
Log:
Fixed #17656 -- Stopped the collectstatic management command from running the 
database validation. Thanks, jcspray.

Modified: 
django/trunk/django/contrib/staticfiles/management/commands/collectstatic.py
===
--- 
django/trunk/django/contrib/staticfiles/management/commands/collectstatic.py
2012-02-12 14:29:30 UTC (rev 17513)
+++ 
django/trunk/django/contrib/staticfiles/management/commands/collectstatic.py
2012-02-12 14:49:42 UTC (rev 17514)
@@ -43,6 +43,7 @@
 "'.*' and '*~'."),
 )
 help = "Collect static files in a single location."
+requires_model_validation = False
 
 def __init__(self, *args, **kwargs):
 super(NoArgsCommand, self).__init__(*args, **kwargs)

-- 
You received this message because you are subscribed to the Google 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] #17656: collectstatic should not require a database

[Django]

#17656: collectstatic should not require a database
-+
 Reporter:  jcspray@…|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.staticfiles  |  Version:  SVN
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by jezdez):

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


Comment:

 In [17514]:
 {{{
 #!CommitTicketReference repository="" revision="17514"
 Fixed #17656 -- Stopped the collectstatic management command from running
 the database validation. Thanks, jcspray.
 }}}

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

-- 
You received this message because you are subscribed to the Google 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] #17481: leading zeros are missing from result of pbkdf2

[Django]

#17481: leading zeros are missing from result of pbkdf2
-+---
 Reporter:  bhuztez  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (Other) |  Version:  1.4-alpha-1
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+---

Comment (by aaugustin):

 In [17513]:
 {{{
 #!CommitTicketReference repository="" revision="17513"
 Added documentation for r17418. Refs #17481.
 }}}

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

-- 
You received this message because you are subscribed to the Google 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] r17513 - django/trunk/docs/releases

[noreply]

Author: aaugustin
Date: 2012-02-12 06:29:30 -0800 (Sun, 12 Feb 2012)
New Revision: 17513

Modified:
   django/trunk/docs/releases/1.4-beta-1.txt
Log:
Added documentation for r17418. Refs #17481.


Modified: django/trunk/docs/releases/1.4-beta-1.txt
===
--- django/trunk/docs/releases/1.4-beta-1.txt   2012-02-12 12:19:02 UTC (rev 
17512)
+++ django/trunk/docs/releases/1.4-beta-1.txt   2012-02-12 14:29:30 UTC (rev 
17513)
@@ -115,7 +115,22 @@
 .. _nist: http://csrc.nist.gov/publications/nistpubs/800-132/nist-sp800-132.pdf
 .. _bcrypt: http://en.wikipedia.org/wiki/Bcrypt
 
+.. warning::
 
+Django 1.4 alpha contained a bug that corrupted PBKDF2 hashes. To
+determine which accounts are affected, run :djadmin:`manage.py shell
+` and paste this snippet::
+
+from base64 import b64decode
+from django.contrib.auth.models import User
+hash_len = {'pbkdf2_sha1': 20, 'pbkdf2_sha256': 32}
+for user in User.objects.filter(password__startswith='pbkdf2_'):
+algo, _, _, hash = user.password.split('$')
+if len(b64decode(hash)) != hash_len[algo]:
+print user
+
+These users should reset their passwords.
+
 HTML5 Doctype
 ~
 
@@ -557,7 +572,7 @@
 
 * New phrases added to ``HIDDEN_SETTINGS`` regex in `django/views/debug.py`_.
 
-  ``'API'``, ``'TOKEN'``, ``'KEY'`` were added, ``'PASSWORD'`` was changed to 
+  ``'API'``, ``'TOKEN'``, ``'KEY'`` were added, ``'PASSWORD'`` was changed to
   ``'PASS'``.
 
 .. _django/views/debug.py: 
http://code.djangoproject.com/browser/django/trunk/django/views/debug.py

-- 
You received this message because you are subscribed to the Google 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] r17512 - in django/trunk: django/utils tests/regressiontests/logging_tests

[noreply]

Author: jezdez
Date: 2012-02-12 04:19:02 -0800 (Sun, 12 Feb 2012)
New Revision: 17512

Modified:
   django/trunk/django/utils/log.py
   django/trunk/tests/regressiontests/logging_tests/tests.py
Log:
Fixed AdminEmailHandler to format the subject message correctly when arguments 
are passed.

This bug was hidden before r17480 as it basically didn't take the arguments 
into account. Refs #14973.

Modified: django/trunk/django/utils/log.py
===
--- django/trunk/django/utils/log.py2012-02-11 22:17:02 UTC (rev 17511)
+++ django/trunk/django/utils/log.py2012-02-12 12:19:02 UTC (rev 17512)
@@ -49,7 +49,7 @@
 record.levelname,
 (request.META.get('REMOTE_ADDR') in settings.INTERNAL_IPS
  and 'internal' or 'EXTERNAL'),
-record.msg
+record.getMessage()
 )
 filter = get_exception_reporter_filter(request)
 request_repr = filter.get_request_repr(request)

Modified: django/trunk/tests/regressiontests/logging_tests/tests.py
===
--- django/trunk/tests/regressiontests/logging_tests/tests.py   2012-02-11 
22:17:02 UTC (rev 17511)
+++ django/trunk/tests/regressiontests/logging_tests/tests.py   2012-02-12 
12:19:02 UTC (rev 17512)
@@ -4,7 +4,7 @@
 
 from django.conf import compat_patch_logging_config
 from django.core import mail
-from django.test import TestCase
+from django.test import TestCase, RequestFactory
 from django.test.utils import override_settings
 from django.utils.log import CallbackFilter, RequireDebugFalse, getLogger
 
@@ -124,6 +124,16 @@
 
 class AdminEmailHandlerTest(TestCase):
 
+def get_admin_email_handler(self, logger):
+# Inspired from regressiontests/views/views.py: send_log()
+# ensuring the AdminEmailHandler does not get filtered out
+# even with DEBUG=True.
+admin_email_handler = [
+h for h in logger.handlers
+if h.__class__.__name__ == "AdminEmailHandler"
+][0]
+return admin_email_handler
+
 @override_settings(
 ADMINS=(('whatever admin', 'ad...@example.com'),),
 EMAIL_SUBJECT_PREFIX='-SuperAwesomeSubject-'
@@ -134,33 +144,63 @@
 setting are used to compose the email subject.
 Refs #16736.
 """
-
 message = "Custom message that says '%s' and '%s'"
 token1 = 'ping'
 token2 = 'pong'
 
 logger = getLogger('django.request')
-# Inspired from regressiontests/views/views.py: send_log()
-# ensuring the AdminEmailHandler does not get filtered out
-# even with DEBUG=True.
-admin_email_handler = [
-h for h in logger.handlers
-if h.__class__.__name__ == "AdminEmailHandler"
-][0]
+admin_email_handler = self.get_admin_email_handler(logger)
 # Backup then override original filters
 orig_filters = admin_email_handler.filters
-admin_email_handler.filters = []
+try:
+admin_email_handler.filters = []
 
-logger.error(message, token1, token2)
+logger.error(message, token1, token2)
 
-self.assertEqual(len(mail.outbox), 1)
-self.assertEqual(mail.outbox[0].to, ['ad...@example.com'])
-self.assertEqual(mail.outbox[0].subject,
- "-SuperAwesomeSubject-ERROR: Custom message that says 
'ping' and 'pong'")
+self.assertEqual(len(mail.outbox), 1)
+self.assertEqual(mail.outbox[0].to, ['ad...@example.com'])
+self.assertEqual(mail.outbox[0].subject,
+ "-SuperAwesomeSubject-ERROR: Custom message that 
says 'ping' and 'pong'")
+finally:
+# Restore original filters
+admin_email_handler.filters = orig_filters
 
-# Restore original filters
-admin_email_handler.filters = orig_filters
+@override_settings(
+ADMINS=(('whatever admin', 'ad...@example.com'),),
+EMAIL_SUBJECT_PREFIX='-SuperAwesomeSubject-',
+INTERNAL_IPS=('127.0.0.1',),
+)
+def test_accepts_args_and_request(self):
+"""
+Ensure that the subject is also handled if being
+passed a request object.
+"""
+message = "Custom message that says '%s' and '%s'"
+token1 = 'ping'
+token2 = 'pong'
 
+logger = getLogger('django.request')
+admin_email_handler = self.get_admin_email_handler(logger)
+# Backup then override original filters
+orig_filters = admin_email_handler.filters
+try:
+admin_email_handler.filters = []
+rf = RequestFactory()
+request = rf.get('/')
+logger.error(message, token1, token2,
+extra={
+'status_code': 403,
+'request': 

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

[Django]

#14973: AdminEmailHandler doesn't include report.message
+-
   Reporter:  jamstooks |Owner:  nobody
   Type:|   Status:  closed
  Component:  Core (Other)  |  Version:  1.3-alpha
   Severity:|   Resolution:  fixed
   Keywords:| Triage Stage:  Accepted
  Has patch:  0 |  Needs documentation:  0
Needs tests:  0 |  Patch needs improvement:  0
+-

Comment (by jezdez):

 In [17512]:
 {{{
 #!CommitTicketReference repository="" revision="17512"
 Fixed AdminEmailHandler to format the subject message correctly when
 arguments are passed.

 This bug was hidden before r17480 as it basically didn't take the
 arguments into account. Refs #14973.
 }}}

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

-- 
You received this message because you are subscribed to the Google 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] #10933: Avoid " TypeError: Cannot convert Decimal("0.0000") to Decimal " when the decimal module has been reloaded

[Django]

#10933: Avoid " TypeError: Cannot convert Decimal("0.") to Decimal  " when 
the
decimal module has been reloaded
-+-
 Reporter:  gagravarr|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  dceu2011 |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  1|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by anonymous):

 I can confirm this bug on Django 1.3 on Apache + mod_wsgi. I have tried
 applying adrian's patch. As I can't reproduce the error, I just get them
 emailed to me occasionally, I cannot yet confirm that it works.

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

-- 
You received this message because you are subscribed to the Google 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.