Re: [Django] #7539: Add ON DELETE and ON UPDATE support to Django

[Django]

#7539: Add ON DELETE and ON UPDATE support to Django
---+
  Reporter:  glassfordm| Owner: 
Status:  new   | Milestone: 
 Component:  Database layer (models, ORM)  |   Version:  SVN
Resolution:|  Keywords:  feature
 Stage:  Design decision needed| Has_patch:  1  
Needs_docs:  1 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Changes (by jtiai):

 * cc: jtiai (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] #11993: ValueError: Cannot convert NaN to integer in regressiontests.defaultfilters.tests using Python 2.6.3

[Django]

#11993: ValueError: Cannot convert NaN to integer in
regressiontests.defaultfilters.tests using Python 2.6.3
+---
  Reporter:  kklimonda  | Owner:  nobody
Status:  closed | Milestone:
 Component:  Uncategorized  |   Version:  1.1   
Resolution:  fixed  |  Keywords:
 Stage:  Unreviewed | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by Alex):

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

Comment:

 Fixed in r11618.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
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] #10314: TestCase assert methods do not accept a msg parameter

[Django]

#10314: TestCase assert methods do not accept a msg parameter
+---
  Reporter:  wwinham| Owner:  nobody
Status:  reopened   | Milestone:  1.2   
 Component:  Testing framework  |   Version:  1.0   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  1 
Needs_docs:  1  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by russellm):

  * milestone:  => 1.2

Comment:

 Marking as v1.2 so I remember to check this in.

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

Re: [Django] #10314: TestCase assert methods do not accept a msg parameter

[Django]

#10314: TestCase assert methods do not accept a msg parameter
+---
  Reporter:  wwinham| Owner:  nobody
Status:  reopened   | Milestone:
 Component:  Testing framework  |   Version:  1.0   
Resolution: |  Keywords:
 Stage:  Accepted   | Has_patch:  1 
Needs_docs:  1  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by russellm):

  * status:  closed => reopened
  * needs_docs:  0 => 1
  * resolution:  wontfix =>

Comment:

 Reopening following discussion on django-dev that resolved to use the
 extra argument as a prefix to the internally generated error message of
 the assertions.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
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] #6148: Add generic support for database schemas

[Django]

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

Status:  assigned  | Milestone: 

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

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

Needs_docs:  0 |   Needs_tests:  0  

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

 Replying to [comment:32 hejsan]:
 > Is what I am describing what is being worked on, or are you only making
 it so that you have to specify for every single model or app that you want
 it to live in a schema?
 > -thanks

 The main purpose of this for me is to have the ''site'' living in the
 different namespace, but in the same database (PostgreSQL); not to have
 the models/apps in dedicated namespaces. In this way you can run
 completely different sites (users, models...) within the same database -
 useful if you do not have full control over the database (hosting for
 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
-~--~~~~--~~--~--~---

Re: [Django] #12020: Template tests fail if they take longer than 60 seconds

[Django]

#12020: Template tests fail if they take longer than 60 seconds
--+-
  Reporter:  jacob| Owner:  jacob
Status:  new  | Milestone:  1.2  
 Component:  Template system  |   Version:  1.1  
Resolution:   |  Keywords:   
 Stage:  Accepted | Has_patch:  0
Needs_docs:  0|   Needs_tests:  0
Needs_better_patch:  0|  
--+-
Changes (by jacob):

  * needs_better_patch:  => 0
  * stage:  Unreviewed => Accepted
  * 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] #12020: Template tests fail if they take longer than 60 seconds

[Django]

#12020: Template tests fail if they take longer than 60 seconds
-+--
 Reporter:  jacob|   Owner:  jacob 
   Status:  new  |   Milestone:  1.2   
Component:  Template system  | Version:  1.1   
 Keywords:   |   Stage:  Unreviewed
Has_patch:  0|  
-+--
 Many of the template tag/filter tests fail if the suite takes longer than
 60 seconds to execute. That's because they do some stuff using times (e.g.
 asserting that `{{ now }}` == `str(now)`) that fails if now slips into the
 past.

 This manifests itself as something like:

  {{{

 (django-trunk)ja...@dorkbook:~/Projects/Django/upstream/tests$
 ./runtests.py --settings=testsettings.sqlite templates
 ==
 FAIL: test_templates (regressiontests.templates.tests.Templates)
 --
 Traceback (most recent call last):
   File
 
"/Users/jacob/Projects/Django/upstream/tests/regressiontests/templates/tests.py",
 line 262, in test_templates
 ('-'*70, ("\n%s\n" % ('-'*70)).join(failures)))
 AssertionError: Tests failed:
 --
 Template test (TEMPLATE_STRING_IF_INVALID=''): cache07 -- FAILED. Expected
 'cache05', got u'cache07'
 --
 Template test (TEMPLATE_STRING_IF_INVALID='INVALID'): cache07 -- FAILED.
 Expected 'cache05', got u'cache07'
 --
 Template test (TEMPLATE_STRING_IF_INVALID=''): cache08 -- FAILED. Expected
 'cache06', got u'cache08'
 --
 Template test (TEMPLATE_STRING_IF_INVALID='INVALID'): cache08 -- FAILED.
 Expected 'cache06', got u'cache08'
 --
 Template test (TEMPLATE_STRING_IF_INVALID=''): filter-timesince01 --
 FAILED. Expected '1 minute', got u'2 minutes'
 --
 Template test (TEMPLATE_STRING_IF_INVALID='INVALID'): filter-timesince01
 -- FAILED. Expected '1 minute', got u'2 minutes'
 --
 Template test (TEMPLATE_STRING_IF_INVALID=''): filter-timesince03 --
 FAILED. Expected '1 hour, 25 minutes', got u'1 hour, 26 minutes'
 --
 Template test (TEMPLATE_STRING_IF_INVALID='INVALID'): filter-timesince03
 -- FAILED. Expected '1 hour, 25 minutes', got u'1 hour, 26 minutes'
 --
 Template test (TEMPLATE_STRING_IF_INVALID=''): filter-timesince11 --
 FAILED. Expected '0 minutes', got u'1 minute'
 --
 Template test (TEMPLATE_STRING_IF_INVALID='INVALID'): filter-timesince11
 -- FAILED. Expected '0 minutes', got u'1 minute'
 --
 Template test (TEMPLATE_STRING_IF_INVALID=''): filter-timesince12 --
 FAILED. Expected '0 minutes', got u'1 minute'
 --
 Template test (TEMPLATE_STRING_IF_INVALID='INVALID'): filter-timesince12
 -- FAILED. Expected '0 minutes', got u'1 minute'
 --
 Template test (TEMPLATE_STRING_IF_INVALID=''): filter-timesince13 --
 FAILED. Expected '0 minutes', got u'1 minute'
 --
 Template test (TEMPLATE_STRING_IF_INVALID='INVALID'): filter-timesince13
 -- FAILED. Expected '0 minutes', got u'1 minute'
 --
 Template test (TEMPLATE_STRING_IF_INVALID=''): filter-timeuntil01 --
 FAILED. Expected '2 minutes', got u'1 minute'
 --
 Template test (TEMPLATE_STRING_IF_INVALID='INVALID'): filter-timeuntil01
 -- FAILED. Expected '2 minutes', got u'1 minute'
 --
 Template test (TEMPLATE_STRING_IF_INVALID=''): filter-timeuntil02 --
 FAILED. Expected '1 day', got u'23 hours, 59 minutes'
 --
 Template test (TEMPLATE_STRING_IF_INVALID='INVALID'): filter-timeuntil02
 -- FAILED. Expected '1 day', got u'23 hours, 59 minutes'
 --
 Template test (TEMPLATE_STRING_IF_INVALID=''): filter-timeuntil03 --
 FAILED. Expected '8 hours, 10 minutes', got u'8 hours, 9 

Re: [Django] #12019: @cache_page with no args causes AttributeError with wsgi

[Django]

#12019: @cache_page with no args causes AttributeError with wsgi
---+
  Reporter:  rokclimb15| Owner:  nobody
Status:  new   | Milestone:
 Component:  Cache system  |   Version:  1.1   
Resolution:|  Keywords:
 Stage:  Unreviewed| Has_patch:  0 
Needs_docs:  0 |   Needs_tests:  0 
Needs_better_patch:  0 |  
---+
Changes (by Alex):

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

Old description:

> When calling @cache_page with no arguments I get the following exception
> while running mod_wsgi.  I'm not sure if that usage is valid.  I would
> assume it would use CACHE_MIDDLEWARE_SECONDS if nothing is provided, but
> I can't find anything about that in docs or see any evidence of that in
> the code.  If that argument is required, I think a clear exception should
> be thrown rather than this one when running under mod_wsgi.
>
> Traceback (most recent call last):
>
>  File "/usr/lib/python2.6/dist-packages/django/core/handlers/base.py",
> line 92, in get_response
>response = callback(request, *callback_args, **callback_kwargs)
>
>  File "/usr/lib/python2.6/dist-packages/django/utils/decorators.py", line
> 33, in adapt
>return MethodDecoratorAdaptor(decorator, func)
>
>  File "/usr/lib/python2.6/dist-packages/django/utils/decorators.py", line
> 15, in __init__
>update_wrapper(self, func)
>
>  File "/usr/lib/python2.6/functools.py", line 33, in update_wrapper
>setattr(wrapper, attr, getattr(wrapped, attr))
>
> AttributeError: 'WSGIRequest' object has no attribute '__name__'

New description:

 When calling @cache_page with no arguments I get the following exception
 while running mod_wsgi.  I'm not sure if that usage is valid.  I would
 assume it would use CACHE_MIDDLEWARE_SECONDS if nothing is provided, but I
 can't find anything about that in docs or see any evidence of that in the
 code.  If that argument is required, I think a clear exception should be
 thrown rather than this one when running under mod_wsgi.
 {{{
 Traceback (most recent call last):

  File "/usr/lib/python2.6/dist-packages/django/core/handlers/base.py",
 line 92, in get_response
response = callback(request, *callback_args, **callback_kwargs)

  File "/usr/lib/python2.6/dist-packages/django/utils/decorators.py", line
 33, in adapt
return MethodDecoratorAdaptor(decorator, func)

  File "/usr/lib/python2.6/dist-packages/django/utils/decorators.py", line
 15, in __init__
update_wrapper(self, func)

  File "/usr/lib/python2.6/functools.py", line 33, in update_wrapper
setattr(wrapper, attr, getattr(wrapped, attr))

 AttributeError: 'WSGIRequest' object has no attribute '__name__'
 }}}

Comment:

 Please use preview.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
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] #12019: @cache_page with no args causes AttributeError with wsgi

[Django]

#12019: @cache_page with no args causes AttributeError with wsgi
--+-
 Reporter:  rokclimb15|   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Cache system  | Version:  1.1   
 Keywords:|   Stage:  Unreviewed
Has_patch:  0 |  
--+-
 When calling @cache_page with no arguments I get the following exception
 while running mod_wsgi.  I'm not sure if that usage is valid.  I would
 assume it would use CACHE_MIDDLEWARE_SECONDS if nothing is provided, but I
 can't find anything about that in docs or see any evidence of that in the
 code.  If that argument is required, I think a clear exception should be
 thrown rather than this one when running under mod_wsgi.

 Traceback (most recent call last):

  File "/usr/lib/python2.6/dist-packages/django/core/handlers/base.py",
 line 92, in get_response
response = callback(request, *callback_args, **callback_kwargs)

  File "/usr/lib/python2.6/dist-packages/django/utils/decorators.py", line
 33, in adapt
return MethodDecoratorAdaptor(decorator, func)

  File "/usr/lib/python2.6/dist-packages/django/utils/decorators.py", line
 15, in __init__
update_wrapper(self, func)

  File "/usr/lib/python2.6/functools.py", line 33, in update_wrapper
setattr(wrapper, attr, getattr(wrapped, attr))

 AttributeError: 'WSGIRequest' object has no attribute '__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
-~--~~~~--~~--~--~---

Re: [Django] #11872: can't pass instance=None to inline formset

[Django]

#11872: can't pass instance=None to inline formset
---+
  Reporter:  tobias| Owner:  brosner
Status:  new   | Milestone:  1.2
 Component:  Forms |   Version:  1.1
Resolution:|  Keywords: 
 Stage:  Accepted  | Has_patch:  1  
Needs_docs:  0 |   Needs_tests:  0  
Needs_better_patch:  0 |  
---+
Changes (by brosner):

  * owner:  nobody => brosner
  * needs_better_patch:  => 0
  * stage:  Unreviewed => Accepted
  * 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] #12012: Integration with the Python standard library logging module

[Django]

#12012: Integration with the Python standard library logging module
-+--
  Reporter:  simon   | Owner:  nobody
Status:  new | Milestone:
 Component:  Core framework  |   Version:  SVN   
Resolution:  |  Keywords:
 Stage:  Unreviewed  | Has_patch:  1 
Needs_docs:  1   |   Needs_tests:  1 
Needs_better_patch:  1   |  
-+--
Comment (by vsajip):

 No, you're right about the best way to achieve what you want - i.e. by
 adding the {{{NullHandler}}} and setting propagate to False on the
 "django" logger, you will indeed ensure that any thing logged to
 "django.*" will disappear into the ether. That'll be fine from a backward
 compatibility point of view - users who have old settings files shouldn't
 see any unexpected logging messages.

 The other question is what different modes of initialisation of logging
 might be wanted by different users. If a user wants Django to
 automatically configure logging for them, they can define a dict bound to
 LOGGING in settings.py. This covers the simplest use case - users don't
 need to do anything else. About the schema for the dict, it would be nice
 if we could align the schema with what I'm proposing on python-dev,
 linked-to above (the schema ''is'' different to what Ivan Sagalaev
 suggested on the django-developers thread, but then it has to cover
 functionality of the logging module such as shared handlers, filters,
 formatters etc. which wasn't covered by Ivan's overview, but will be
 needed in certain cases).

 In a more complex use case, say the user wants to set up logging using
 their own code, but this needs to be done as early as possible and be
 called just once. For this, I suggested a callback mechanism
 [http://groups.google.com/group/django-
 
developers/tree/browse_frm/thread/43ad9bd9337cfb5c/56ae96ba80604e19#doc_c600420b7b093f51
 here] on your thread about "Best place for code that processes stuff from
 settings.py once". There, the user could define callbacks for logging or
 anything else which needs to be done just once. Their logging setup
 callback can use any mechanism to configure logging, e.g. programmatically
 using the logging getLogger/addHandler APIs or via loading a dict from
 YAML or JSON or just invoking the dict config mechanism using a dict
 obtained from some other source - including a literal dict in settings.py
 not called LOGGING ;-)

 One more point about handlers. Because propagate is set to False for the
 "django" logger, in order for users to see django events, they will
 explicitly have to add appropriate handlers to the "django" logger. These
 can be the same handlers as they e.g. attach to the root logger, or
 completely different handlers.

 A fairly common usage pattern is to attach console, file handlers to the
 root logger and nowhere else (but that wouldn't work for Django events, as
 I've explained above). Another common pattern is to attach console and
 file handlers to the root, and additional handlers (e.g. SMTP or file
 handlers pointing to files which just store errors) for particular
 severities (e.g. ERROR or CRITICAL) and/or particular areas of the
 application.

 Of course, knowledgeable users can, if they wish, set the "django"
 logger's propagate flag to True in their logging setup code, which means
 that they then don't need to attach handlers specifically to the "django"
 logger, as events will propagate up to the root logger.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
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] #7071: Allow to change form class for password change view

[Django]

#7071: Allow to change form class for password change view
-+--
  Reporter:  m.ga...@paranoja.pl | Owner:  nobody   
 
Status:  closed  | Milestone:   
 
 Component:  Contrib apps|   Version:  SVN  
 
Resolution:  duplicate   |  Keywords:  contrib auth 
password change form override
 Stage:  Design decision needed  | Has_patch:  1
 
Needs_docs:  0   |   Needs_tests:  0
 
Needs_better_patch:  0   |  
-+--
Changes (by lukeplant):

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

Comment:

 Duplicate of #8274

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
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] #12018: Use "RequestContext" instead of "Context" for comments moderation email

[Django]

#12018: Use "RequestContext" instead of "Context" for comments moderation email
-+--
 Reporter:  yourcelf |   Owner:  nobody
   Status:  new  |   Milestone:
Component:  django.contrib.comments  | Version:  1.1   
 Keywords:   |   Stage:  Unreviewed
Has_patch:  1|  
-+--
 The django.contrib.comments moderation framework allows users to send an
 email to site admins when a comment is posted.  The email is formatted
 using the template "comments/comment_notification_email.txt".  However,
 this template is rendered using a Context object, not RequestContext,
 making it impossible to add additional context parameters for the template
 renderer.

 An example of the type of additional context one might want in an email is
 a site url, allowing the template to provide a link to the comment or
 admin functions on the site.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
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] r11620 - django/branches/releases/1.1.X/django/template

[noreply]

Author: jacob
Date: 2009-10-12 11:57:01 -0500 (Mon, 12 Oct 2009)
New Revision: 11620

Modified:
   django/branches/releases/1.1.X/django/template/defaultfilters.py
Log:
[1.1.X] Fixed #11993: fixed the the floatformat filter on NaN values in Python 
2.6.3. Thanks, kklimonda. Backport if [11619] from trunk.


Modified: django/branches/releases/1.1.X/django/template/defaultfilters.py
===
--- django/branches/releases/1.1.X/django/template/defaultfilters.py
2009-10-12 16:53:23 UTC (rev 11619)
+++ django/branches/releases/1.1.X/django/template/defaultfilters.py
2009-10-12 16:57:01 UTC (rev 11620)
@@ -162,7 +162,7 @@
 
 try:
 m = int(d) - d
-except (OverflowError, InvalidOperation):
+except (ValueError, OverflowError, InvalidOperation):
 return input_val
 
 if not m and p < 0:


--~--~-~--~~~---~--~~
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] r11619 - django/trunk/django/template

[noreply]

Author: jacob
Date: 2009-10-12 11:53:23 -0500 (Mon, 12 Oct 2009)
New Revision: 11619

Modified:
   django/trunk/django/template/defaultfilters.py
Log:
Fixed #11993: fixed the the `floatformat` filter on `NaN` values in Python 
2.6.3. Thanks, kklimonda.

Modified: django/trunk/django/template/defaultfilters.py
===
--- django/trunk/django/template/defaultfilters.py  2009-10-12 15:32:24 UTC 
(rev 11618)
+++ django/trunk/django/template/defaultfilters.py  2009-10-12 16:53:23 UTC 
(rev 11619)
@@ -162,7 +162,7 @@
 
 try:
 m = int(d) - d
-except (OverflowError, InvalidOperation):
+except (ValueError, OverflowError, InvalidOperation):
 return input_val
 
 if not m and p < 0:


--~--~-~--~~~---~--~~
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] #12012: Integration with the Python standard library logging module

[Django]

#12012: Integration with the Python standard library logging module
-+--
  Reporter:  simon   | Owner:  nobody
Status:  new | Milestone:
 Component:  Core framework  |   Version:  SVN   
Resolution:  |  Keywords:
 Stage:  Unreviewed  | Has_patch:  1 
Needs_docs:  1   |   Needs_tests:  1 
Needs_better_patch:  1   |  
-+--
Comment (by simon):

 I might be going about the initialisation the wrong way then. Here's what
 I want to achieve: without the user needing to do anything at all
 (including modifying a settings.py created before logging was added to
 Django) I want ALL messages to any logger beneath "django" to be silently
 swallowed, no matter what the severity. My understanding is that the
 correct way to do this is to hook up a NullHandler and set "propogate =
 False" on the "django" logger as early as possible. Is there a better way
 of achieving that?

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

Re: [Django] #8274: Auth views should allow form customization

[Django]

#8274: Auth views should allow form customization
+---
  Reporter:  julien | Owner:  julien
Status:  closed | Milestone:
 Component:  Authentication |   Version:  SVN   
Resolution:  fixed  |  Keywords:
 Stage:  Ready for checkin  | Has_patch:  1 
Needs_docs:  0  |   Needs_tests:  0 
Needs_better_patch:  0  |  
+---
Changes (by lukeplant):

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

Comment:

 Implemented in r11618

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
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] r11618 - in django/trunk: django/contrib/auth docs/topics

[noreply]

Author: lukeplant
Date: 2009-10-12 10:32:24 -0500 (Mon, 12 Oct 2009)
New Revision: 11618

Modified:
   django/trunk/django/contrib/auth/views.py
   django/trunk/docs/topics/auth.txt
Log:
Fixed #8274 - allow custom forms for auth 'login' and 'password_change' views

Thanks to julien for the suggestion and patch, and SmileyChris for work on the 
patch.


Modified: django/trunk/django/contrib/auth/views.py
===
--- django/trunk/django/contrib/auth/views.py   2009-10-12 10:16:17 UTC (rev 
11617)
+++ django/trunk/django/contrib/auth/views.py   2009-10-12 15:32:24 UTC (rev 
11618)
@@ -14,11 +14,13 @@
 from django.contrib.auth.models import User
 from django.views.decorators.cache import never_cache
 
-def login(request, template_name='registration/login.html', 
redirect_field_name=REDIRECT_FIELD_NAME):
+def login(request, template_name='registration/login.html',
+  redirect_field_name=REDIRECT_FIELD_NAME,
+  authentication_form=AuthenticationForm):
 "Displays the login form and handles the login action."
 redirect_to = request.REQUEST.get(redirect_field_name, '')
 if request.method == "POST":
-form = AuthenticationForm(data=request.POST)
+form = authentication_form(data=request.POST)
 if form.is_valid():
 # Light security check -- make sure redirect_to isn't garbage.
 if not redirect_to or '//' in redirect_to or ' ' in redirect_to:
@@ -29,7 +31,7 @@
 request.session.delete_test_cookie()
 return HttpResponseRedirect(redirect_to)
 else:
-form = AuthenticationForm(request)
+form = authentication_form(request)
 request.session.set_test_cookie()
 if Site._meta.installed:
 current_site = Site.objects.get_current()
@@ -137,7 +139,7 @@
 else:
 context_instance['validlink'] = False
 form = None
-context_instance['form'] = form
+context_instance['form'] = form
 return render_to_response(template_name, context_instance=context_instance)
 
 def password_reset_complete(request, 
template_name='registration/password_reset_complete.html'):
@@ -145,16 +147,16 @@
  
{'login_url': settings.LOGIN_URL}))
 
 def password_change(request, 
template_name='registration/password_change_form.html',
-post_change_redirect=None):
+post_change_redirect=None, 
password_change_form=PasswordChangeForm):
 if post_change_redirect is None:
 post_change_redirect = 
reverse('django.contrib.auth.views.password_change_done')
 if request.method == "POST":
-form = PasswordChangeForm(request.user, request.POST)
+form = password_change_form(user=request.user, data=request.POST)
 if form.is_valid():
 form.save()
 return HttpResponseRedirect(post_change_redirect)
 else:
-form = PasswordChangeForm(request.user)
+form = password_change_form(user=request.user)
 return render_to_response(template_name, {
 'form': form,
 }, context_instance=RequestContext(request))

Modified: django/trunk/docs/topics/auth.txt
===
--- django/trunk/docs/topics/auth.txt   2009-10-12 10:16:17 UTC (rev 11617)
+++ django/trunk/docs/topics/auth.txt   2009-10-12 15:32:24 UTC (rev 11618)
@@ -262,8 +262,8 @@
 Creates, saves and returns a :class:`~django.contrib.auth.models.User`.
 The :attr:`~django.contrib.auth.models.User.username`,
 :attr:`~django.contrib.auth.models.User.email` and
-:attr:`~django.contrib.auth.models.User.password` are set as given, and
-the :class:`~django.contrib.auth.models.User` gets ``is_active=True``.
+:attr:`~django.contrib.auth.models.User.password` are set as given, 
and the
+:class:`~django.contrib.auth.models.User` gets ``is_active=True``.
 
 If no password is provided,
 :meth:`~django.contrib.auth.models.User.set_unusable_password()` will
@@ -705,7 +705,7 @@
 
 (r'^accounts/login/$', 'django.contrib.auth.views.login'),
 
-.. function:: views.login(request, [template_name, redirect_field_name])
+.. function:: views.login(request, [template_name, redirect_field_name, 
authentication_form])
 
 Here's what ``django.contrib.auth.views.login`` does:
 
@@ -785,6 +785,15 @@
 
 {% endblock %}
 
+.. versionadded:: 1.2
+
+If you are using alternate authentication (see
+:ref:`authentication-backends`) you can pass a custom authentication form
+to the login view via the ``authentication_form`` parameter. This form must
+accept a ``request`` keyword argument in its ``__init__`` method, and
+provide a ``get_user`` argument which returns the authenticated user object
+(this method is only ever called after successful form validation).
+
 .. 

Re: [Django] #9310: 404 debug pages should show the name of the tried urlpattern if one exists.

[Django]

#9310: 404 debug pages should show the name of the tried urlpattern if one 
exists.
-+--
  Reporter:  floguy  | Owner:  nobody
Status:  new | Milestone:  1.2   
 Component:  Core framework  |   Version:  1.0   
Resolution:  |  Keywords:
 Stage:  Accepted| Has_patch:  1 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  1   |  
-+--
Changes (by tobias):

 * cc: tobias (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
-~--~~~~--~~--~--~---

[Django] #12017: UKPostcodeField doesn't shows provided custom "error_messages"

[Django]

#12017: UKPostcodeField doesn't shows provided custom "error_messages"
+---
 Reporter:  vmagamedov  |   Owner:  jacob 
   Status:  new |   Milestone:
Component:  django.contrib.localflavor  | Version:  1.1   
 Keywords:  |   Stage:  Unreviewed
Has_patch:  1   |  
+---
 
[http://code.djangoproject.com/browser/django/trunk/django/contrib/localflavor/uk/forms.py#L35
 Here] we have:
 {{{
 if not self.postcode_regex.search(postcode):
 raise ValidationError(self.default_error_messages['invalid'])
 }}}

 But should be:

 {{{
 if not self.postcode_regex.search(postcode):
 raise ValidationError(self.error_messages['invalid'])
 }}}

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

[Django] #12016: timefield's are showing as "(None)" in the list_display of the admin interface

[Django]

#12016: timefield's are showing as "(None)" in the list_display of the admin
interface
-+--
 Reporter:  timkersten   |   Owner:  nobody
   Status:  new  |   Milestone:
Component:  django.contrib.admin | Version:  1.1   
 Keywords:  list_display, timefield  |   Stage:  Unreviewed
Has_patch:  1|  
-+--
 A timefield colume containing the time 00:00 would show up in the admin as
 "(None)" rather than "midnight" when displayed as part of the
 list_display.

 The cause is an if statement that should be checking for None, rather than
 evaluating to False.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
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] #7071: Allow to change form class for password change view

[Django]

#7071: Allow to change form class for password change view
-+--
  Reporter:  m.ga...@paranoja.pl | Owner:  nobody   
 
Status:  new | Milestone:   
 
 Component:  Contrib apps|   Version:  SVN  
 
Resolution:  |  Keywords:  contrib auth 
password change form override
 Stage:  Design decision needed  | Has_patch:  1
 
Needs_docs:  0   |   Needs_tests:  0
 
Needs_better_patch:  0   |  
-+--
Changes (by rvanlaar):

  * needs_better_patch:  1 => 0
  * needs_docs:  1 => 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] #12015: Czech fixes to js, has patch

[Django]

#12015: Czech fixes to js, has patch
--+-
 Reporter:  Vlada Macek   |   Owner:  nobody
   Status:  new   |   Milestone:
Component:  Translations  | Version:  SVN   
 Keywords:|   Stage:  Unreviewed
Has_patch:  1 |  
--+-
 Small, but glaring. Thanks for merging.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.
--~--~-~--~~~---~--~~
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] #12014: profile_class() method for User model

[Django]

#12014: profile_class() method for User model
-+--
  Reporter:  Suor| Owner:  nobody
Status:  closed  | Milestone:
 Component:  Authentication  |   Version:  1.1   
Resolution:  wontfix |  Keywords:
 Stage:  Unreviewed  | Has_patch:  0 
Needs_docs:  0   |   Needs_tests:  0 
Needs_better_patch:  0   |  
-+--
Changes (by ubernostrum):

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

Comment:

 If you need to know which class is providing user profiles, it's already
 easy to find out from inspecting the `AUTH_PROFILE_MODULE` setting. It's
 also easy to dynamically import based on the value of that setting (I've
 written applications which do 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
-~--~~~~--~~--~--~---

[Django] #12014: profile_class() method for User model

[Django]

#12014: profile_class() method for User model
+---
 Reporter:  Suor|   Owner:  nobody
   Status:  new |   Milestone:
Component:  Authentication  | Version:  1.1   
 Keywords:  |   Stage:  Unreviewed
Has_patch:  0   |  
+---
 In some cases it could help avoiding importing and naming profile model
 class.

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