date:20110501

Re: [Django] #15943: 'raw' kwarg sent with pre_save and post_save signals is undocumented

2011-05-01 Thread Django

#15943: 'raw' kwarg sent with pre_save and post_save signals is undocumented
-+-
   Reporter: |  Owner:  nobody
  gabrielhurley  | Status:  new
   Type: |  Component:  Documentation
  Cleanup/optimization   |   Severity:  Normal
  Milestone: |   Keywords:
Version:  1.3|  Has patch:  0
 Resolution: |Needs tests:  0
   Triage Stage:  Accepted   |  Easy pickings:  1
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by aaugustin):

 * stage:  Unreviewed => Accepted


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #15900: reverse() does not properly escape namespaced views

2011-05-01 Thread Django

#15900: reverse() does not properly escape namespaced views
+--
   Reporter:  teolicy   |  Owner:  dmclain
   Type:  Bug   | Status:  assigned
  Milestone:|  Component:  Core (Other)
Version:  1.3   |   Severity:  Normal
 Resolution:|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  1
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  1 |  Easy pickings:  0
+--
Changes (by julien):

 * needs_better_patch:  0 => 1


Comment:

 I've had a quick look at this and I'm not sure if this patch addresses the
 core issue. dmclain, you mention that the resolver did not normalise
 prefixes, yet I see there already are passing tests for the following
 pattern at
 
source:django/trunk/tests/regressiontests/urlpatterns_reverse/extra_urls.py#L12:

 {{{
 #!python
 url(r'^prefix/(?P\w+)/',
 include('regressiontests.urlpatterns_reverse.included_urls2')),
 }}}

 As mentioned by the reporter, the bug only occurs when a namespace is
 used, yet I fail to see how your patch specifically addresses that. Could
 you elaborate on your approach?

 Also, looking at your tests, the following passes:

 {{{
 #!python
 (r'^other[246]/', include(otherobj2.urls)),
 }}}

 ... yet the tests unexpectedly fail if I swap the digits:

 {{{
 #!python
 (r'^other[426]/', include(otherobj2.urls)),
 }}}

 Finally, for completeness, it'd be good to test what is supposed to
 happen, for example, with "/other9/inner/".

-- 
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] #15849: {% ifchanged %} not thread-safe

2011-05-01 Thread Django

#15849: {% ifchanged %} not thread-safe
+-
   Reporter:  akaihola  |  Owner:  nobody
   Type:  Bug   | Status:  new
  Milestone:|  Component:  Template system
Version:  SVN   |   Severity:  Normal
 Resolution:|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  1
Needs documentation:  0 |Needs tests:  1
Patch needs improvement:  0 |  Easy pickings:  0
+-

Comment (by akaihola):

 Replying to [comment:4 carljm]:
 > I could see an argument that automated tests for template tag thread-
 safety or more difficult than they are worth, but I think we should at
 least have the argument ;-)

 I found an existing [http://code.djangoproject.com/changeset/8306#file3
 thread-safety test case] in the Django test suite. It's for bug #4948
 ("Saving !FileField files is not thread-safe"). Martin von Löwis also
 [http://code.djangoproject.com/ticket/4948#comment:14 described in a
 comment] how his
 [http://code.djangoproject.com/attachment/ticket/4948/t.py example script]
 demonstrated the bug.

 Do you think a similar approach could be used for testing template tags?

-- 
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] #15588: "FileField no longer deletes files" unclear

2011-05-01 Thread Django

#15588: "FileField no longer deletes files" unclear
-+-
   Reporter:  philipn|  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Documentation
Version:  1.3-beta   |   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Ready for  |  Has patch:  1
  checkin|Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
-+-
Changes (by dmclain):

 * easy:   => 0
 * stage:  Accepted => Ready for checkin


Comment:

 The release notes are already out, as is 1.3, but this language does seem
 better and it applies cleanly. If updating the release notes is allowed,
 this patch is worth applying.

-- 
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] #15827: the OneToOneField in Profile should be named 'user'

2011-05-01 Thread Django

#15827: the OneToOneField in Profile should be named 'user'
-+-
   Reporter:  lawgon |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Documentation
Version:  SVN|   Severity:  Normal
 Resolution: |   Keywords:  Auth Profile
   Triage Stage:  Ready for  |  Has patch:  1
  checkin|Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
-+-
Changes (by dmclain):

 * stage:  Accepted => Ready for checkin


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

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

Re: [Django] #15944: Cross-reference contrib.auth.models.check_password and contrib.auth.models.User.check_password

2011-05-01 Thread Django

#15944: Cross-reference contrib.auth.models.check_password and
contrib.auth.models.User.check_password
-+-
   Reporter:  airstrike  |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |  Component:  Documentation
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:  docs auth User
 Resolution: |  check_password
   Triage Stage: |  Has patch:  1
  Unreviewed |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
-+-
Changes (by airstrike):

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


Comment:

 I also apologize in advance if i happened to be too verbose in my 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.

[Django] #15944: Cross-reference contrib.auth.models.check_password and contrib.auth.models.User.check_password

2011-05-01 Thread Django

#15944: Cross-reference contrib.auth.models.check_password and
contrib.auth.models.User.check_password
---+---
Reporter: airstrike | Owner: nobody
Type: Cleanup/optimization | Status: new
Milestone: | Component: Documentation
Version: 1.3| Severity: Normal
Keywords: docs auth User check_password | Triage Stage: Unreviewed
Has patch: 1 | Easy pickings: 0
---+---

http://docs.djangoproject.com/en/1.3/topics/auth/#django.contrib.auth.models.check_password

http://docs.djangoproject.com/en/1.3/topics/auth.html#django.contrib.auth.models.User.check_password

I believe these two sections should be cross-referenced, so I'm attaching
a patch with my proposal changes for this section of the docs. I was also
getting a warning with sphinx when trying to build auth.txt from trunk
that read
{{{
docs/topics/auth.txt:3: (SEVERE/4) Duplicate ID: "module-
django.contrib.auth.views".
}}}

I'm attaching a second patch which aims to solve that issue as well. I'm
not sure if the solution is correct, but it "worksforme" on a new sphinx
build attempt.

This is my first patch ever, so proceed with caution!

--
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] #15943: 'raw' kwarg sent with pre_save and post_save signals is undocumented

2011-05-01 Thread Django

#15943: 'raw' kwarg sent with pre_save and post_save signals is undocumented
-+-
 Reporter:  gabrielhurley|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |Component:
Milestone:   |  Documentation
  Version:  1.3  | Severity:  Normal
 Keywords:   | Triage Stage:
Has patch:  0|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  1|  Patch needs improvement:  0
-+-
 The `raw` kwargs was added to `pre_save` and `post_save` in #5422, but (as
 far as I can tell) was never documented. It's a pretty handy parameter to
 know about so it should probably be documented along with the other
 parameters in `/ref/signals`.

-- 
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

2011-05-01 Thread Django

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

 * cc: kevin1024 (added)
 * has_patch:  0 => 1
 * easy:   => 0


Comment:

 OK, I spent some time hacking on this today.  Here is a patch.  Be gentle;
 it's my first contribution to Django. :)

-- 
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] #15936: Syndication: Turning off autoescape (content:encoded)

2011-05-01 Thread Django

#15936: Syndication: Turning off autoescape (content:encoded)
-+-
   Reporter:  Brant  |  Owner:  nobody
  Steen   | Status:  closed
   Type:  New|  Component:  contrib.syndication
  feature|   Severity:  Normal
  Milestone: |   Keywords:  syndication,
Version:  1.3|  content:encoded
 Resolution:  invalid|  Has patch:  1
   Triage Stage: |Needs tests:  1
  Unreviewed |  Easy pickings:  0
Needs documentation:  1  |
Patch needs improvement:  0  |
-+-

Comment (by Brant Steen ):

 Interesting... hence why it's always needed to be wrapped in CDATA.

 Thanks for clearing that up... I guess it can work either way but leaving
 it the way it is keeps it more generalized.

 Whenever I've looked at RSS feeds, they always do the CDATA inside
 content:encoded elements... so I figured they were always just a hand-in-
 hand kind of thing. Which is why I was so surprised when I couldn't figure
 out how to turn off auto escaping using the feedgenerator.

 Thanks again, that makes a lot of sense now.

-- 
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] #15929: test.client.RequestFactory keeps state

2011-05-01 Thread Django

#15929: test.client.RequestFactory keeps state
-+-
   Reporter: |  Owner:  nobody
  m.vantellingen@…   | Status:  new
   Type:  Bug|  Component:  Testing framework
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  1
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
-+-

Comment (by lukeplant):

 The authentication does indeed patch the request class for a reason, but
 there is way to avoid it, which is in the patch I just attached. I haven't
 actually checked that my patch fixes the issue, but I'm pretty sure it
 does, and all the other tests pass.

 I'm happy with this approach, but not with just fixing the symptoms as in
 the alternative approach. If someone integrates the regression tests for
 this into a full patch, I'll mark it as RFC.

-- 
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] #13729: UK localflavor mis-named/documentation bug.

2011-05-01 Thread Django

#13729: UK localflavor mis-named/documentation bug.
-+-
   Reporter:  schinckel  |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  contrib.localflavor
Version:  1.2|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Ready for  |  Has patch:  1
  checkin|Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
-+-

Comment (by claudep):

 Thanks for the correction, I mixed up '''uk''' ISO 639-1 for Ukrainian
 language and '''UA''' the ISO 3166 country code for Ukraine. It is not
 referenced in the patch, though.

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

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

Re: [Django] #15900: reverse() does not properly escape namespaced views

2011-05-01 Thread Django

#15900: reverse() does not properly escape namespaced views
+--
   Reporter:  teolicy   |  Owner:  dmclain
   Type:  Bug   | Status:  assigned
  Milestone:|  Component:  Core (Other)
Version:  1.3   |   Severity:  Normal
 Resolution:|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  1
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
+--

Comment (by tiliv):

 When I have a variable capture in the URL prefix responsible for declaring
 a namespace, I get a KeyError on the patched version of line 321 of the
 urlresolver.py file, which claims it's missing "username" (in my 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] #15940: Patch database documentation to explain why using sql_mode=strict is important

2011-05-01 Thread Django

#15940: Patch database documentation to explain why using sql_mode=strict is
important
---+---
   Reporter:  foxwhisper   |  Owner:  nobody
   Type:  New feature  | Status:  new
  Milestone:   |  Component:  Documentation
Version:  1.3  |   Severity:  Normal
 Resolution:   |   Keywords:
   Triage Stage:  Accepted |  Has patch:  0
Needs documentation:  1|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
---+---
Changes (by kmtracey):

 * needs_docs:  0 => 1
 * stage:  Design decision needed => Accepted


Comment:

 I'd say the existence of SQL modes in MySQL is worth a paragraph here:
 http://docs.djangoproject.com/en/1.3/ref/databases/#mysql-notes, after the
 section on storage engines and before the discussion of MySQLdb. A lot of
 people seem to not even know these modes exist. I think it is worth
 pointing them out (referencing the MySQL doc
 http://dev.mysql.com/doc/refman/5.6/en/server-sql-mode.html), mentioning
 that many default MySQL configurations treat what most people would
 consider to be error conditions (note this affects more than just integer
 range handling) rather more cavalierly than may be expected, and that
 choosing and configuring an appropriate mode for your server is something
 that should be done as part of initial setup. I don't believe we should
 recommend any particular mode, and we should be careful about stating
 anything about what is the default, because that does in fact differ
 depending on what distribution is in use.

-- 
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] #15887: Improve django.views.decorators.http docs

2011-05-01 Thread Django

#15887: Improve  django.views.decorators.http docs
-+-
   Reporter:  RoySmith   |  Owner:  nobody
   Type: | Status:  closed
  Cleanup/optimization   |  Component:  Documentation
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution:  fixed  |  Has patch:  1
   Triage Stage:  Ready for  |Needs tests:  0
  checkin|  Easy pickings:  1
Needs documentation:  0  |
Patch needs improvement:  1  |
-+-

Comment (by timo):

 In [16140]:
 {{{
 #!CommitTicketReference repository="" revision="16140"
 [1.3.X] Fixed #15887 - Added clarification for required_*() decorators;
 thanks RoySmith for the sugggestion.

 Backport of r16139 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.

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

2011-05-01 Thread noreply

Author: timo
Date: 2011-05-01 13:11:04 -0700 (Sun, 01 May 2011)
New Revision: 16140

Modified:
   django/branches/releases/1.3.X/docs/topics/http/decorators.txt
Log:
[1.3.X] Fixed #15887 - Added clarification for required_*() decorators; thanks 
RoySmith for the sugggestion.

Backport of r16139 from trunk.

Modified: django/branches/releases/1.3.X/docs/topics/http/decorators.txt
===
--- django/branches/releases/1.3.X/docs/topics/http/decorators.txt  
2011-05-01 20:08:55 UTC (rev 16139)
+++ django/branches/releases/1.3.X/docs/topics/http/decorators.txt  
2011-05-01 20:11:04 UTC (rev 16140)
@@ -10,8 +10,9 @@
 Allowed HTTP methods
 
 
-The following decorators in :mod:`django.views.decorators.http` can be used to
-restrict access to views based on the request method.
+The decorators in :mod:`django.views.decorators.http` can be used to restrict
+access to views based on the request method. These decorators will return
+a :class:`django.http.HttpResponseNotAllowed` if the conditions are not met.
 
 .. function:: require_http_methods(request_method_list)
 

-- 
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] #15887: Improve django.views.decorators.http docs

2011-05-01 Thread Django

#15887: Improve  django.views.decorators.http docs
-+-
   Reporter:  RoySmith   |  Owner:  nobody
   Type: | Status:  closed
  Cleanup/optimization   |  Component:  Documentation
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution:  fixed  |  Has patch:  1
   Triage Stage:  Ready for  |Needs tests:  0
  checkin|  Easy pickings:  1
Needs documentation:  0  |
Patch needs improvement:  1  |
-+-
Changes (by timo):

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


Comment:

 In [16139]:
 {{{
 #!CommitTicketReference repository="" revision="16139"
 Fixed #15887 - Added clarification for required_*() decorators; thanks
 RoySmith for the sugggestion.
 }}}

-- 
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] r16139 - django/trunk/docs/topics/http

2011-05-01 Thread noreply

Author: timo
Date: 2011-05-01 13:08:55 -0700 (Sun, 01 May 2011)
New Revision: 16139

Modified:
   django/trunk/docs/topics/http/decorators.txt
Log:
Fixed #15887 - Added clarification for required_*() decorators; thanks RoySmith 
for the sugggestion.

Modified: django/trunk/docs/topics/http/decorators.txt
===
--- django/trunk/docs/topics/http/decorators.txt2011-05-01 16:46:02 UTC 
(rev 16138)
+++ django/trunk/docs/topics/http/decorators.txt2011-05-01 20:08:55 UTC 
(rev 16139)
@@ -11,7 +11,8 @@
 
 
 The decorators in :mod:`django.views.decorators.http` can be used to restrict
-access to views based on the request method.
+access to views based on the request method. These decorators will return
+a :class:`django.http.HttpResponseNotAllowed` if the conditions are not met.
 
 .. function:: require_http_methods(request_method_list)
 

-- 
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] #15304: `Model.objects.create()` returns `long` instead of `int`.

2011-05-01 Thread Django

#15304: `Model.objects.create()` returns `long` instead of `int`.
-+-
   Reporter:  mrmachine  |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Database layer
Version:  SVN|  (models, ORM)
 Resolution: |   Severity:  Normal
   Triage Stage:  Ready for  |   Keywords:  int long primary
  checkin|  key create get
Needs documentation:  0  |  Has patch:  1
Patch needs improvement:  0  |Needs tests:  0
 |  Easy pickings:  0
-+-
Changes (by dmclain):

 * easy:   => 0
 * stage:  Accepted => Ready for checkin


Comment:

 It looks good to me on sqlite and postgres, I don't have a test setup for
 other DBs, but given that it's just running the PK through the same output
 function that is being called on all other fields, it seems unlikely to
 cause issues.

-- 
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] #8913: Make the "must be unique" error messages in ModelForms customizable

2011-05-01 Thread Django

#8913: Make the "must be unique" error messages in ModelForms customizable
-+-
   Reporter: |  Owner:  nobody
  Alexander_Nesterov | Status:  new
   Type:  New|  Component:  Forms
  feature|   Severity:  Normal
  Milestone: |   Keywords:  forms, unique,
Version:  1.0|  validation
 Resolution: |  Has patch:  0
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
-+-
Changes (by schickm):

 * cc: schickm (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] #15939: SignedIntegerField / UnsignedIntegerField as part of the core fields.py

2011-05-01 Thread Django

#15939: SignedIntegerField / UnsignedIntegerField as part of the core fields.py
-+-
   Reporter: |  Owner:  nobody
  foxwhisper | Status:  new
   Type:  New|  Component:  Database layer
  feature|  (models, ORM)
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution: |  Has patch:  0
   Triage Stage:  Design |Needs tests:  0
  decision needed|  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by aaugustin):

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


Comment:

 I am not sure the 32 bit limit is really relevant: it does not exist in
 Python and 64 bit machines are the common case today.

 !SignedIntegerField and !UnsignedIntegerField could cause confusion with
 !PositiveIntegerField and !IntegerField. Maybe adding optional min_value
 and max_value parameters to the existing fields would be more appropriate.

 #56 tackles a similar problem, the solutions proposed over there could be
 interesting here.

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

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

Re: [Django] #15940: Patch database documentation to explain why using sql_mode=strict is important

2011-05-01 Thread Django

#15940: Patch database documentation to explain why using sql_mode=strict is
important
-+-
   Reporter: |  Owner:  nobody
  foxwhisper | Status:  new
   Type:  New|  Component:  Documentation
  feature|   Severity:  Normal
  Milestone: |   Keywords:
Version:  1.3|  Has patch:  0
 Resolution: |Needs tests:  0
   Triage Stage:  Design |  Easy pickings:  0
  decision needed|
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by aaugustin):

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


Comment:

 I'll mark this as DDN, following Alex's judgement here:
 http://code.djangoproject.com/ticket/15923#comment:7

 In my opinion, documenting MySQL's features/bugs belongs to MySQL's docs,
 not to Django's.

 The docs generally assume that you are familiar with a) Python b) HTTP c)
 your database engine d) your web server e) your caching engine, if you use
 one, etc.

-- 
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] #15938: USE_THOUSAND_SEPARATOR breaks prepopulated_fields functionality

2011-05-01 Thread Django

#15938: USE_THOUSAND_SEPARATOR breaks prepopulated_fields functionality
-+-
   Reporter: |  Owner:  nobody
  lev.maximov@…  | Status:  new
   Type:  Bug|  Component:  contrib.admin
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution: |  USE_THOUSAND_SEPARATOR
   Triage Stage:  Accepted   |  prepopulated_fields
Needs documentation:  0  |  Has patch:  1
Patch needs improvement:  0  |Needs tests:  1
 |  Easy pickings:  1
-+-
Changes (by magopian):

 * needs_better_patch:  1 => 0
 * needs_tests:  0 => 1


Comment:

 Thanks lev for the update of the patch, looks good now. Sorry for that,
 but i missed the "needs tests" flag in my previous comment

-- 
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] #5931: repr for db Fields

2011-05-01 Thread Django

#5931: __repr__ for db Fields
-+-
   Reporter:  Thomas |  Owner:  nobody
  Güttler  | Status:  new
   Type: |  Component:  Database layer
  Cleanup/optimization   |  (models, ORM)
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage:  Ready for  |Needs tests:  0
  checkin|  Easy pickings:  1
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by aaugustin):

 * stage:  Accepted => Ready for checkin


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

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

Re: [Django] #15942: duplicate id "module-django.contrib.auth.views" in the topics/auth.txt doc

2011-05-01 Thread Django

#15942: duplicate id "module-django.contrib.auth.views" in the topics/auth.txt 
doc
-+-
   Reporter:  magopian   |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Documentation
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Ready for  |  Has patch:  1
  checkin|Needs tests:  0
Needs documentation:  0  |  Easy pickings:  1
Patch needs improvement:  0  |
-+-
Changes (by jezdez):

 * stage:  Unreviewed => Ready for checkin


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

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

Re: [Django] #15942: duplicate id "module-django.contrib.auth.views" in the topics/auth.txt doc

2011-05-01 Thread Django

#15942: duplicate id "module-django.contrib.auth.views" in the topics/auth.txt 
doc
--+---
   Reporter:  magopian|  Owner:  nobody
   Type:  Bug | Status:  new
  Milestone:  |  Component:  Documentation
Version:  1.3 |   Severity:  Normal
 Resolution:  |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  1
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  1
--+---
Changes (by magopian):

 * cc: mathieu.agopian@… (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.

[Django] #15942: duplicate id "module-django.contrib.auth.views" in the topics/auth.txt doc

2011-05-01 Thread Django

#15942: duplicate id "module-django.contrib.auth.views" in the topics/auth.txt 
doc
--+---
 Reporter:  magopian  |  Owner:  nobody
 Type:  Bug   | Status:  new
Milestone:|  Component:  Documentation
  Version:  1.3   |   Severity:  Normal
 Keywords:|   Triage Stage:  Unreviewed
Has patch:  1 |  Easy pickings:  1
--+---
 The documentation patch applied to fix #6581 ([16130] on trunk and [16131]
 on 1.3.X, git commit f3163a64b3940e3145090f6493849222ec052d0e) introduced
 a sphinx warning about a duplicate id {{{module-
 django.contrib.auth.views}}}.

 Indeed, the {{{.. module:: django.contrib.auth.views}}} id is present
 twice in the same file (line 879 and 1026 in {{{docs/topics/auth.txt}}}).

 I believe the second occurrence of the id should be replaced by {{{..
 currentmodule:: django.contrib.auth.views}}}, and i added a patch that
 does just 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] #15887: Improve django.views.decorators.http docs

2011-05-01 Thread Django

#15887: Improve  django.views.decorators.http docs
-+-
   Reporter:  RoySmith   |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |  Component:  Documentation
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage:  Ready for  |Needs tests:  0
  checkin|  Easy pickings:  1
Needs documentation:  0  |
Patch needs improvement:  1  |
-+-

Comment (by cg@…):

 Replying to [comment:5 Mathieu Agopian ]:
 > I've attached a the documentation patch with the typo fixed. Could some
 please check this and remove the "patch needs improvement" if the fixed
 patch is ok?

 Thanks for fixing the typo ;)

-- 
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] #13770: form BooleanField should clean the string u'false' as False.

2011-05-01 Thread Django

#13770: form BooleanField should clean the string u'false' as False.
-+
   Reporter:  jordanb|  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Forms
Version:  1.1|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Ready for checkin  |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+
Changes (by dmclain):

 * stage:  Accepted => Ready for checkin


Comment:

 Looks good to me

-- 
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] #13579: None gets ignored by __in filter

2011-05-01 Thread Django

#13579: None gets ignored by __in filter
-+-
   Reporter: |  Owner:  gruszczy
  outofculture   | Status:  new
   Type:  Bug|  Component:  Database layer
  Milestone: |  (models, ORM)
Version:  1.2|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  1  |  Easy pickings:  0
-+-
Changes (by dmclain):

 * needs_better_patch:  0 => 1
 * easy:   => 0


Comment:

 Looks like the implementation for `__in` has changed since the patch was
 made. This is more than just the patch not applying cleanly, there are
 more code paths that need to be considered now.

-- 
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] #15887: Improve django.views.decorators.http docs

2011-05-01 Thread Django

#15887: Improve  django.views.decorators.http docs
-+-
   Reporter:  RoySmith   |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |  Component:  Documentation
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage:  Ready for  |Needs tests:  0
  checkin|  Easy pickings:  1
Needs documentation:  0  |
Patch needs improvement:  1  |
-+-
Changes (by aaugustin):

 * stage:  Accepted => Ready for checkin


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

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

Re: [Django] #15941: Admin calendar week start day doc error

2011-05-01 Thread Django

#15941: Admin calendar week start day doc error
-+-
   Reporter:  r4mses@…   |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |  Component:  Documentation
  Milestone: |   Severity:  Normal
Version: |   Keywords:  calendar week start
 Resolution: |  day
   Triage Stage:  Ready for  |  Has patch:  1
  checkin|Needs tests:  0
Needs documentation:  0  |  Easy pickings:  1
Patch needs improvement:  0  |
-+-
Changes (by magopian):

 * stage:  Accepted => Ready for checkin


Comment:

 Well, that was a very quick patch indeed, thanks aaugustin!

 Patch looks good, passing this ticket as "ready for checkin"

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

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

Re: [Django] #15941: Admin calendar week start day doc error

2011-05-01 Thread Django

#15941: Admin calendar week start day doc error
-+-
   Reporter:  r4mses@…   |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |  Component:  Documentation
  Milestone: |   Severity:  Normal
Version: |   Keywords:  calendar week start
 Resolution: |  day
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
-+-
Changes (by aaugustin):

 * 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.

Re: [Django] #15941: Admin calendar week start day doc error

2011-05-01 Thread Django

#15941: Admin calendar week start day doc error
-+-
   Reporter:  r4mses@…   |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |  Component:  Documentation
  Milestone: |   Severity:  Normal
Version: |   Keywords:  calendar week start
 Resolution: |  day
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
-+-

Comment (by aaugustin):

 Trivial patch attached.

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

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

Re: [Django] #15941: Admin calendar week start day doc error

2011-05-01 Thread Django

#15941: Admin calendar week start day doc error
-+-
   Reporter:  r4mses@…   |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |  Component:  Documentation
  Milestone: |   Severity:  Normal
Version: |   Keywords:  calendar week start
 Resolution: |  day
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
-+-
Changes (by magopian):

 * cc: mathieu.agopian@… (added)
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * easy:  0 => 1
 * needs_docs:   => 0
 * type:  Bug => Cleanup/optimization
 * stage:  Unreviewed => Accepted


Comment:

 It seems that FIRST_DAY_OF_WEEK was added in 1.2 (according to
 http://docs.djangoproject.com/en/1.3/ref/settings/#first-day-of-week), but
 i can't find any info about that in the release notes of 1.2.

 Anyway, i could reproduce the "issue", and indeed this piece of
 documentation should be updated.

-- 
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] #15937: Deprecate AUTH_PROFILE_MODULE and get_profile

2011-05-01 Thread Django

#15937: Deprecate AUTH_PROFILE_MODULE and get_profile
-+-
   Reporter:  kmike  |  Owner:  nobody
   Type: | Status:  reopened
  Cleanup/optimization   |  Component:  contrib.auth
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution: |  Has patch:  0
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
-+-

Comment (by aaugustin):

 kmike, thanks for the additional context.

 I didn't remember that discussion from March on django-developers and your
 initial report was pretty vague.

 The ticket makes much more sense with your new comment.

-- 
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] #15937: Deprecate AUTH_PROFILE_MODULE and get_profile

2011-05-01 Thread Django

#15937: Deprecate AUTH_PROFILE_MODULE and get_profile
-+-
   Reporter:  kmike  |  Owner:  nobody
   Type: | Status:  reopened
  Cleanup/optimization   |  Component:  contrib.auth
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution: |  Has patch:  0
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
-+-
Changes (by jezdez):

 * status:  closed => reopened
 * resolution:  invalid =>
 * stage:  Unreviewed => Accepted


Comment:

 I definitely believe the get_profile hook serves a good purpose (get the
 profile for a user in a single profile scenario). The use of
 OneToOneFields are equally powerful and only needs some sensible
 documentation to become a good replacement. So I'm +1 on changing the docs
 to have a "advanced" or "multiple profiles" section.

-- 
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] r16138 - in django/trunk: django/contrib/admin/templatetags django/contrib/admin/views django/contrib/admindocs django/contrib/comments/templatetags django/contrib/contenttypes django/con

2011-05-01 Thread noreply

Author: jezdez
Date: 2011-05-01 09:46:02 -0700 (Sun, 01 May 2011)
New Revision: 16138

Modified:
   django/trunk/django/contrib/admin/templatetags/admin_list.py
   django/trunk/django/contrib/admin/templatetags/admin_modify.py
   django/trunk/django/contrib/admin/templatetags/log.py
   django/trunk/django/contrib/admin/views/decorators.py
   django/trunk/django/contrib/admindocs/views.py
   django/trunk/django/contrib/comments/templatetags/comments.py
   django/trunk/django/contrib/contenttypes/generic.py
   django/trunk/django/contrib/flatpages/templatetags/flatpages.py
   django/trunk/django/contrib/humanize/templatetags/humanize.py
   django/trunk/django/contrib/webdesign/templatetags/webdesign.py
   django/trunk/django/forms/formsets.py
   django/trunk/django/forms/models.py
   django/trunk/django/template/base.py
   django/trunk/django/template/defaulttags.py
   django/trunk/django/template/loader_tags.py
   django/trunk/django/templatetags/cache.py
   django/trunk/django/templatetags/i18n.py
   django/trunk/django/utils/decorators.py
   django/trunk/django/utils/functional.py
   django/trunk/django/views/decorators/cache.py
   django/trunk/django/views/decorators/http.py
   django/trunk/django/views/decorators/vary.py
   django/trunk/tests/modeltests/select_for_update/tests.py
   django/trunk/tests/regressiontests/admin_views/views.py
Log:
Replaced old-style with new-style decorator syntax.

Modified: django/trunk/django/contrib/admin/templatetags/admin_list.py
===
--- django/trunk/django/contrib/admin/templatetags/admin_list.py
2011-05-01 16:14:57 UTC (rev 16137)
+++ django/trunk/django/contrib/admin/templatetags/admin_list.py
2011-05-01 16:46:02 UTC (rev 16138)
@@ -19,6 +19,7 @@
 
 DOT = '.'
 
+@register.simple_tag
 def paginator_number(cl,i):
 """
 Generates an individual page index link in a paginated list.
@@ -29,8 +30,8 @@
 return mark_safe(u'%d ' % (i+1))
 else:
 return mark_safe(u'%d ' % 
(escape(cl.get_query_string({PAGE_VAR: i})), (i == cl.paginator.num_pages-1 and 
' class="end"' or ''), i+1))
-paginator_number = register.simple_tag(paginator_number)
 
+@register.inclusion_tag('admin/pagination.html')
 def pagination(cl):
 """
 Generates the series of links to the pages in a paginated list.
@@ -75,7 +76,6 @@
 'ALL_VAR': ALL_VAR,
 '1': 1,
 }
-pagination = register.inclusion_tag('admin/pagination.html')(pagination)
 
 def result_headers(cl):
 """
@@ -123,7 +123,8 @@
 
 def _boolean_icon(field_val):
 BOOLEAN_MAPPING = {True: 'yes', False: 'no', None: 'unknown'}
-return mark_safe(u'' % 
(settings.ADMIN_MEDIA_PREFIX, BOOLEAN_MAPPING[field_val], field_val))
+return mark_safe(u'' %
+(settings.ADMIN_MEDIA_PREFIX, BOOLEAN_MAPPING[field_val], field_val))
 
 def items_for_result(cl, result, form):
 """
@@ -222,6 +223,7 @@
 if form[cl.model._meta.pk.name].is_hidden:
 yield mark_safe(force_unicode(form[cl.model._meta.pk.name]))
 
+@register.inclusion_tag("admin/change_list_results.html")
 def result_list(cl):
 """
 Displays the headers and data list together
@@ -230,8 +232,8 @@
 'result_hidden_fields': list(result_hidden_fields(cl)),
 'result_headers': list(result_headers(cl)),
 'results': list(results(cl))}
-result_list = 
register.inclusion_tag("admin/change_list_results.html")(result_list)
 
+@register.inclusion_tag('admin/date_hierarchy.html')
 def date_hierarchy(cl):
 """
 Displays the date hierarchy for date drill-down functionality.
@@ -303,8 +305,8 @@
 'title': str(year.year),
 } for year in years]
 }
-date_hierarchy = 
register.inclusion_tag('admin/date_hierarchy.html')(date_hierarchy)
 
+@register.inclusion_tag('admin/search_form.html')
 def search_form(cl):
 """
 Displays a search form for searching the list.
@@ -314,12 +316,12 @@
 'show_result_count': cl.result_count != cl.full_result_count,
 'search_var': SEARCH_VAR
 }
-search_form = register.inclusion_tag('admin/search_form.html')(search_form)
 
+@register.inclusion_tag('admin/filter.html')
 def admin_list_filter(cl, spec):
 return {'title': spec.title(), 'choices' : list(spec.choices(cl))}
-admin_list_filter = 
register.inclusion_tag('admin/filter.html')(admin_list_filter)
 
+@register.inclusion_tag('admin/actions.html', takes_context=True)
 def admin_actions(context):
 """
 Track the number of times the action field has been rendered on the page,
@@ -327,4 +329,3 @@
 """
 context['action_index'] = context.get('action_index', -1) + 1
 return context
-admin_actions = register.inclusion_tag("admin/actions.html", 
takes_context=True)(admin_actions)

Modified: django/trunk/django/contrib/admin/templatetags/admin_modify.py
===
--- django/trun

[Django] #15941: Admin calendar week start day doc error

2011-05-01 Thread Django

#15941: Admin calendar week start day doc error
-+---
 Reporter:  r4mses@… |  Owner:  nobody
 Type:  Bug  | Status:  new
Milestone:   |  Component:  Documentation
  Version:   |   Severity:  Normal
 Keywords:  calendar week start day  |   Triage Stage:  Unreviewed
Has patch:  0|  Easy pickings:  0
-+---
 http://docs.djangoproject.com/en/dev/ref/models/fields/#datefield says:
  The JavaScript calendar will always start the week on a Sunday.

 This is not true since it can be changed using the FIRST_DAY_OF_WEEK
 setting and maybe also more l10n I don't know about.

 The text is in all the documentations from 1.0 to dev say this, but I
 don't know which version of Django that introduced FIRST_DAY_OF_WEEK (or
 other l10n that invalidates that sentence), but maybe it was #1061.

-- 
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] #15937: Deprecate AUTH_PROFILE_MODULE and get_profile

2011-05-01 Thread Django

#15937: Deprecate AUTH_PROFILE_MODULE and get_profile
-+-
   Reporter:  kmike  |  Owner:  nobody
   Type: | Status:  closed
  Cleanup/optimization   |  Component:  contrib.auth
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution:  invalid|  Has patch:  0
   Triage Stage: |Needs tests:  0
  Unreviewed |  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-

Comment (by kmike):

 Documentation change is totally backwards compatible and get_profile is
 not a *feature* in my opinion - it does almost nothing. How is
 user.get_profile() better than user.profile? It is just more verbose and
 less explicit. It was introduced to provide a standardised way to handle
 user profiles while ago but I haven't seen a lot of django apps using this
 feature (except for some profile-editing apps - but I don't see how would
 they suffer from documentation change and even from deprecating the
 option).

 There is at least one +0/+1 voice from a django core developer in recent
 discussions at django-developers mailing list (see
 https://groups.google.com/d/msg/django-developers/1Xj8Zzdokrw/d3TaHQMBHmcJ
 ).

 Anyway, the new thread: https://groups.google.com/d/topic/django-
 developers/Xd7_PhJhRUg/discussion.

-- 
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] #15936: Syndication: Turning off autoescape (content:encoded)

2011-05-01 Thread Django

#15936: Syndication: Turning off autoescape (content:encoded)
-+-
   Reporter:  Brant  |  Owner:  nobody
  Steen   | Status:  closed
   Type:  New|  Component:  contrib.syndication
  feature|   Severity:  Normal
  Milestone: |   Keywords:  syndication,
Version:  1.3|  content:encoded
 Resolution:  invalid|  Has patch:  1
   Triage Stage: |Needs tests:  1
  Unreviewed |  Easy pickings:  0
Needs documentation:  1  |
Patch needs improvement:  0  |
-+-
Changes (by aaugustin):

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


Comment:

 As far as I can tell, everything is working properly.

 In HTML, " 1 < 2 " is invalid, the correct version is " 1 < 2
 ". In Atom, it is the same, " foobar
 " is invalid, the correct version "
 foo
bar ".

 Your screenshot in Firefox shows correct escaping in the raw, unparsed
 source of your feed. Your screenshot in Safari shows that Safari has
 parsed the source, properly extracted the contents of the
  tag, and has inserted it in an HTML structure for
 display.

 The name of the tag "content:encoded" itself makes it fairly explicit that
 its content be encoded, and so does the spec (see my first comment). If
 you could insert arbitrary unescaped HTML inside "content:encoded", your
 RSS feed would no longer be valid XML, something RSS parsers clearly do
 not handle!

-- 
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] #5714: Date/Time fields' clean methods need strip()

2011-05-01 Thread Django

#5714: Date/Time fields' clean methods need strip()
-+-
   Reporter:  Simon  |Owner:  nobody
  Litchfield|   Status:  closed
   Type: |Component:  Forms
  Cleanup/optimization   | Severity:  Normal
  Milestone: | Keywords:
Version:  SVN|Has patch:  1
 Resolution:  fixed  |  Needs tests:  0
   Triage Stage:  Accepted   |
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by jezdez):

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


Comment:

 In [16137]:
 {{{
 #!CommitTicketReference repository="" revision="16137"
 Fixed #5714 -- Strip whitespaces around date and time form field values
 before converting it to a native type. Thanks to SmileyChris for the
 initial 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] r16137 - in django/trunk: django/forms django/utils tests/regressiontests/forms/tests

2011-05-01 Thread noreply

Author: jezdez
Date: 2011-05-01 09:14:57 -0700 (Sun, 01 May 2011)
New Revision: 16137

Modified:
   django/trunk/django/forms/fields.py
   django/trunk/django/utils/formats.py
   django/trunk/tests/regressiontests/forms/tests/fields.py
Log:
Fixed #5714 -- Strip whitespaces around date and time form field values before 
converting it to a native type. Thanks to SmileyChris for the initial patch.

Modified: django/trunk/django/forms/fields.py
===
--- django/trunk/django/forms/fields.py 2011-05-01 03:06:03 UTC (rev 16136)
+++ django/trunk/django/forms/fields.py 2011-05-01 16:14:57 UTC (rev 16137)
@@ -19,7 +19,7 @@
 from django.core import validators
 from django.utils import formats
 from django.utils.translation import ugettext_lazy as _
-from django.utils.encoding import smart_unicode, smart_str
+from django.utils.encoding import smart_unicode, smart_str, force_unicode
 from django.utils.functional import lazy
 
 # Provide this import for backwards compatibility.
@@ -320,16 +320,37 @@
 raise ValidationError(self.error_messages['max_whole_digits'] % 
(self.max_digits - self.decimal_places))
 return value
 
-class DateField(Field):
+class BaseTemporalField(Field):
+
+def __init__(self, input_formats=None, *args, **kwargs):
+super(BaseTemporalField, self).__init__(*args, **kwargs)
+if input_formats is not None:
+self.input_formats = input_formats
+
+def to_python(self, value):
+# Try to coerce the value to unicode.
+unicode_value = force_unicode(value, strings_only=True)
+if isinstance(unicode_value, unicode):
+value = unicode_value.strip()
+# If unicode, try to strptime against each input format.
+if isinstance(value, unicode):
+for format in self.input_formats:
+try:
+return self.strptime(value, format)
+except ValueError:
+continue
+raise ValidationError(self.error_messages['invalid'])
+
+def strptime(self, value, format):
+raise NotImplementedError('Subclasses must define this method.')
+
+class DateField(BaseTemporalField):
 widget = DateInput
+input_formats = formats.get_format_lazy('DATE_INPUT_FORMATS')
 default_error_messages = {
 'invalid': _(u'Enter a valid date.'),
 }
 
-def __init__(self, input_formats=None, *args, **kwargs):
-super(DateField, self).__init__(*args, **kwargs)
-self.input_formats = input_formats
-
 def to_python(self, value):
 """
 Validates that the input can be converted to a date. Returns a Python
@@ -341,23 +362,18 @@
 return value.date()
 if isinstance(value, datetime.date):
 return value
-for format in self.input_formats or 
formats.get_format('DATE_INPUT_FORMATS'):
-try:
-return datetime.date(*time.strptime(value, format)[:3])
-except ValueError:
-continue
-raise ValidationError(self.error_messages['invalid'])
+return super(DateField, self).to_python(value)
 
-class TimeField(Field):
+def strptime(self, value, format):
+return datetime.date(*time.strptime(value, format)[:3])
+
+class TimeField(BaseTemporalField):
 widget = TimeInput
+input_formats = formats.get_format_lazy('TIME_INPUT_FORMATS')
 default_error_messages = {
 'invalid': _(u'Enter a valid time.')
 }
 
-def __init__(self, input_formats=None, *args, **kwargs):
-super(TimeField, self).__init__(*args, **kwargs)
-self.input_formats = input_formats
-
 def to_python(self, value):
 """
 Validates that the input can be converted to a time. Returns a Python
@@ -367,23 +383,18 @@
 return None
 if isinstance(value, datetime.time):
 return value
-for format in self.input_formats or 
formats.get_format('TIME_INPUT_FORMATS'):
-try:
-return datetime.time(*time.strptime(value, format)[3:6])
-except ValueError:
-continue
-raise ValidationError(self.error_messages['invalid'])
+return super(TimeField, self).to_python(value)
 
-class DateTimeField(Field):
+def strptime(self, value, format):
+return datetime.time(*time.strptime(value, format)[3:6])
+
+class DateTimeField(BaseTemporalField):
 widget = DateTimeInput
+input_formats = formats.get_format_lazy('DATETIME_INPUT_FORMATS')
 default_error_messages = {
 'invalid': _(u'Enter a valid date/time.'),
 }
 
-def __init__(self, input_formats=None, *args, **kwargs):
-super(DateTimeField, self).__init__(*args, **kwargs)
-self.input_formats = input_formats
-
 def to_python(self, value):
 """
 Validates that the input can be converted to a datetime. Returns a
@@ -403,13 +414,11 @@

Re: [Django] #15837: Consolidate localflavor tests

2011-05-01 Thread Django

#15837: Consolidate localflavor tests
-+-
   Reporter:  julien |  Owner:  rodriguealcazar
   Type: | Status:  assigned
  Cleanup/optimization   |  Component:  contrib.localflavor
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution: |  Has patch:  0
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  1
Patch needs improvement:  0  |
-+-
Changes (by rodriguealcazar):

 * status:  new => assigned
 * owner:  nobody => rodriguealcazar


-- 
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] #15938: USE_THOUSAND_SEPARATOR breaks prepopulated_fields functionality

2011-05-01 Thread Django

#15938: USE_THOUSAND_SEPARATOR breaks prepopulated_fields functionality
-+-
   Reporter: |  Owner:  nobody
  lev.maximov@…  | Status:  new
   Type:  Bug|  Component:  contrib.admin
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution: |  USE_THOUSAND_SEPARATOR
   Triage Stage:  Accepted   |  prepopulated_fields
Needs documentation:  0  |  Has patch:  1
Patch needs improvement:  1  |Needs tests:  0
 |  Easy pickings:  1
-+-
Changes (by magopian):

 * cc: mathieu.agopian@… (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] #15938: USE_THOUSAND_SEPARATOR breaks prepopulated_fields functionality

2011-05-01 Thread Django

#15938: USE_THOUSAND_SEPARATOR breaks prepopulated_fields functionality
-+-
   Reporter: |  Owner:  nobody
  lev.maximov@…  | Status:  new
   Type:  Bug|  Component:  contrib.admin
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution: |  USE_THOUSAND_SEPARATOR
   Triage Stage:  Accepted   |  prepopulated_fields
Needs documentation:  0  |  Has patch:  1
Patch needs improvement:  1  |Needs tests:  0
 |  Easy pickings:  1
-+-
Changes (by magopian):

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


Comment:

 I've reproduced the issue, and can confirm everything stated in the ticket
 with one minor typo (it's {{{maxLength}}} in the javascript and not
 {{{max_length}}}).

 I'm marking this ticket as Accepted but the patch needs improvements:
 please remove the trailing comma, as it wasn't there in the first place,
 and it'll break in Internet Explorer.

-- 
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] #15936: Syndication: Turning off autoescape (content:encoded)

2011-05-01 Thread Django

#15936: Syndication: Turning off autoescape (content:encoded)
-+-
   Reporter:  Brant  |  Owner:  nobody
  Steen   | Status:  reopened
   Type:  New|  Component:  contrib.syndication
  feature|   Severity:  Normal
  Milestone: |   Keywords:  syndication,
Version:  1.3|  content:encoded
 Resolution: |  Has patch:  1
   Triage Stage: |Needs tests:  1
  Unreviewed |  Easy pickings:  0
Needs documentation:  1  |
Patch needs improvement:  0  |
-+-
Changes (by anonymous):

 * status:  closed => reopened
 * resolution:  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.

Re: [Django] #15936: Syndication: Turning off autoescape (content:encoded)

2011-05-01 Thread Django

#15936: Syndication: Turning off autoescape (content:encoded)
-+-
   Reporter:  Brant  |  Owner:  nobody
  Steen   | Status:  closed
   Type:  New|  Component:  contrib.syndication
  feature|   Severity:  Normal
  Milestone: |   Keywords:  syndication,
Version:  1.3|  content:encoded
 Resolution:  invalid|  Has patch:  1
   Triage Stage: |Needs tests:  1
  Unreviewed |  Easy pickings:  0
Needs documentation:  1  |
Patch needs improvement:  0  |
-+-

Comment (by brant):

 I believe that what is making your example work correctly is actually
 safari's parsing. Check it in FireFox (you'll need to view the source,
 firefox doesn't show the content:encoded portion on the screen).

 I modified my feed to reflect the example above. I'm attaching 2
 screenshots of the source (one from safari, one from firefox). You'll see
 that it's autoescaped in firefox. Also, if I check the same feed in
 Chrome, (which doesn't have a native RSS parser so it just shows you
 source) I see the same result as the firefox screenshot.

-- 
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] #15940: Patch database documentation to explain why using sql_mode=strict is important

2011-05-01 Thread Django

#15940: Patch database documentation to explain why using sql_mode=strict is
important
-+---
 Reporter:  foxwhisper   |  Owner:  nobody
 Type:  New feature  | Status:  new
Milestone:   |  Component:  Documentation
  Version:  1.3  |   Severity:  Normal
 Keywords:   |   Triage Stage:  Unreviewed
Has patch:  0|  Easy pickings:  0
-+---
 Currently, MySQL doesn't restrict you from entering an integer larger than
 the maximum allowed. It will raise a warning, but this warning isn't
 caught by Django anywhere. This is one of those gotcha's, which you only
 really notice after you've lost some data, and can't recover it (or unless
 you happened to come across similar threads like this).

 Although I'd love to see Django using sql_mode=strict by default, I doubt
 this will happen. So instead, can we add a section into the database
 documentation ( http://docs.djangoproject.com/en/dev/ref/databases/ )
 which explains why you should use sql_mode=strict, along with how to do it
 ( which is explained in
 (http://code.djangoproject.com/ticket/15923#comment:10 by kmtracey ).

 On a side note, there may also be other reasons why using sql_mode would
 be good or bad, so this would possibly have to be explored before this
 could be accepted?

 If this is accepted, I'd be happy to submit the documentation 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.

[Django] #15939: SignedIntegerField / UnsignedIntegerField as part of the core fields.py

2011-05-01 Thread Django

#15939: SignedIntegerField / UnsignedIntegerField as part of the core fields.py
-+--
 Reporter:  foxwhisper   |  Owner:  nobody
 Type:  New feature  | Status:  new
Milestone:   |  Component:  Database layer (models, ORM)
  Version:  1.3  |   Severity:  Normal
 Keywords:   |   Triage Stage:  Unreviewed
Has patch:  0|  Easy pickings:  0
-+--
 I'd like to place a feature request to see SignedIntegerField and
 UnsignedIntegerField included as part of the core fields.py ( which will
 adhere to the 32bit limits.h defaults -
 http://en.wikipedia.org/wiki/Limits.h )

 There has been some discussion so far in the following threads:

 http://code.djangoproject.com/ticket/15923

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

 http://groups.google.com/group/django-
 developers/browse_thread/thread/22dd636f421823fd/a058fd6c31ee09e3


 In terms of a use case scenario, I would imagine that most developers are
 used to working within the restrictions of a 32bit integer, and it would
 be nice to have this same ability for Django - out of the box.

 If this is accepted, I'd be more than willing to submit the code and
 documentation 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.

Re: [Django] #15923: Validate that IntegerField is a valid Signed value for databases that don't do it themselves.

2011-05-01 Thread Django

#15923: Validate that IntegerField is a valid Signed value for databases that 
don't
do it themselves.
-+-
   Reporter: |  Owner:  nobody
  foxwhisper | Status:  closed
   Type:  Bug|  Component:  Database layer
  Milestone: |  (models, ORM)
Version:  1.3|   Severity:  Normal
 Resolution:  wontfix|   Keywords:
   Triage Stage:  Design |  Has patch:  0
  decision needed|Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
-+-

Comment (by foxwhisper):

 Further discussion has taken place in these two threads:

 http://groups.google.com/group/django-
 developers/browse_thread/thread/f0b8ddbda03a2d8e
 http://groups.google.com/group/django-
 developers/browse_thread/thread/22dd636f421823fd/a058fd6c31ee09e3

 I'm going to submit two feature requests (one for
 SignedIntegerField/UnsignedIntegerField) and one for documentation on
 MySQL strict mode.

-- 
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] #5931: repr for db Fields

2011-05-01 Thread Django

#5931: __repr__ for db Fields
-+-
   Reporter:  Thomas |  Owner:  nobody
  Güttler  | Status:  new
   Type: |  Component:  Database layer
  Cleanup/optimization   |  (models, ORM)
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  1
Patch needs improvement:  0  |
-+-
Changes (by magopian):

 * needs_better_patch:  1 => 0


Comment:

 I understand now ;) thanks for the feedbacks and comments!

 I've attached an updated patch, with the additional test and the specific
 case for the Field instantiated without a name.

 Please let me know if this needs further improvements!

-- 
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] #15683: the force_escpe filter should not call mark_safe

2011-05-01 Thread Django

#15683: the force_escpe filter should not call mark_safe
-+-
   Reporter:  tyrion |  Owner:  marcosmoyano
   Type: | Status:  assigned
  Cleanup/optimization   |  Component:  Template system
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:  force_escape
 Resolution: |  mark_safe
   Triage Stage:  Ready for  |  Has patch:  1
  checkin|Needs tests:  1
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
-+-
Changes (by jezdez):

 * easy:   => 0
 * stage:  Accepted => Ready for checkin


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

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

[Django] #15938: USE_THOUSAND_SEPARATOR breaks prepopulated_fields functionality

2011-05-01 Thread Django

#15938: USE_THOUSAND_SEPARATOR breaks prepopulated_fields functionality
-+-
 Reporter:  lev.maximov@…|  Owner:  nobody
 Type:  Bug  | Status:  new
Milestone:   |  Component:
  Version:  1.3  |  contrib.admin
 Keywords:  USE_THOUSAND_SEPARATOR   |   Severity:  Normal
  prepopulated_fields|   Triage Stage:
Has patch:  1|  Unreviewed
 |  Easy pickings:  1
-+-
 {{{
 # models.py

 from django.db import models

 class Book(models.Model):
 slug = models.CharField(max_length=1000)
 name = models.CharField(max_length=1000)

 # admin.py

 from django.contrib import admin
 import models

 class BookAdmin(admin.ModelAdmin):
 prepopulated_fields = {
 'slug': ['name'],
 }

 admin.site.register(models.Book, BookAdmin)

 # settings.py

 USE_L10N = True
 USE_THOUSAND_SEPARATOR = True

 }}}

 This bug is present with most locales (including `en` and `en-gb`). Common
 values for `DECIMAL_SEPARATOR` are space, comma and dot. The former two
 generate a js error in django-generated js code, the latter one results in
 wrong `max_length` for slug field (1.000 = 1)

 Disclaimer:

 This example is somewhat artificial because `NUMBER_GROUPING` is usually 3
 and it doesn't make much sense to use slugs 1000 chars long.
 So the severity of the bug is not at all high. But the bug there is.

 The patch is against 1.3 but at the moment of writing the issue is present
 in trunk as well.

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

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

Re: [Django] #15937: Deprecate AUTH_PROFILE_MODULE and get_profile

2011-05-01 Thread Django

#15937: Deprecate AUTH_PROFILE_MODULE and get_profile
-+-
   Reporter:  kmike  |  Owner:  nobody
   Type: | Status:  closed
  Cleanup/optimization   |  Component:  contrib.auth
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution:  invalid|  Has patch:  0
   Triage Stage: |Needs tests:  0
  Unreviewed |  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by aaugustin):

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


Comment:

 The fact that you don't understand `get_profile` and `AUTH_PROFILE_MODULE`
 doesn't mean they are useless. They were introduced to provide a
 standardized way to extend a user's profile, after lots of discussion.

 Overall, this change is quite sensitive, backwards incompatible, and it
 removes a feature without a very good reason. You should review the
 discussions and tickets that have led to their introduction, propose
 something better on the mailing-list, and obtain consensus, and then you
 could reopen this ticket.

-- 
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] #15922: prepopulated_fields for DecimalField generates js error

2011-05-01 Thread Django

#15922: prepopulated_fields for DecimalField generates js error
-+-
   Reporter:  lev|  Owner:  nobody
   Type:  Bug| Status:  reopened
  Milestone: |  Component:  contrib.admin
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:  prepopulated_fields
   Triage Stage:  Accepted   |  Decimal default_if_none
Needs documentation:  0  |  Has patch:  0
Patch needs improvement:  0  |Needs tests:  0
 |  Easy pickings:  1
-+-

Comment (by lev):

 To be more explicit, the following works well:

 {{{
 # models.py

 from django.db import models

 class Book(models.Model):
 slug = models.CharField(max_length=100)
 starting_price = models.DecimalField(decimal_places=2, max_digits=10)

 # admin.py

 from django.contrib import admin
 import models

 class BookAdmin(admin.ModelAdmin):
 prepopulated_fields = {
 'slug': ['starting_price'],
 }

 admin.site.register(models.Book, BookAdmin)
 }}}

-- 
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] #15922: prepopulated_fields for DecimalField generates js error

2011-05-01 Thread Django

#15922: prepopulated_fields for DecimalField generates js error
-+-
   Reporter:  lev|  Owner:  nobody
   Type:  Bug| Status:  reopened
  Milestone: |  Component:  contrib.admin
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:  prepopulated_fields
   Triage Stage:  Accepted   |  Decimal default_if_none
Needs documentation:  0  |  Has patch:  0
Patch needs improvement:  0  |Needs tests:  0
 |  Easy pickings:  1
-+-

Comment (by lev):

 I found out that the bug does not occur if `DecimalField` is used only as
 a source field and not as a destination.

 So while changing the behaviour of `prepopulated_fields` so that it
 accepts `DecimalField` as destination field is somewhat dubious, here're
 some fixes that can be applied without such design decision:

 1) In documentation:
 {{{
 - prepopulated_fields doesn't accept DateTimeField, ForeignKey, nor
 ManyToManyField fields.
 + prepopulated_fields doesn't accept DateTimeField, ForeignKey, nor
 ManyToManyField fields as source fields.
 }}}

 2) Prohibit `DecimalField` to be used as a destination field in the code.

 3) Currently type control is applied to
 
[http://code.djangoproject.com/browser/django/tags/releases/1.3/django/contrib/admin/validation.py#L327
 destination field only].  Prohibiting `DateTimeField` as a source field
 could also make sense as it doesn't work either.

-- 
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] #13729: UK localflavor mis-named/documentation bug.

2011-05-01 Thread Django

#13729: UK localflavor mis-named/documentation bug.
-+-
   Reporter:  schinckel  |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  contrib.localflavor
Version:  1.2|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Ready for  |  Has patch:  1
  checkin|Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
-+-

Comment (by anonymous):

 Just to correct [comment:5 comment 5], '''UA''' is the code for Ukraine.
 '''UK''' is "exceptionally reserved" for the United Kingdom (see
 http://www.iso.org/iso/iso-3166-1_decoding_table#UK).

-- 
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] #15937: Deprecate AUTH_PROFILE_MODULE and get_profile

2011-05-01 Thread Django

#15937: Deprecate AUTH_PROFILE_MODULE and get_profile
--+--
 Reporter:  kmike |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Milestone:|  Component:  contrib.auth
  Version:  1.3   |   Severity:  Normal
 Keywords:|   Triage Stage:  Unreviewed
Has patch:  0 |  Easy pickings:  0
--+--
 Is it really necessary? I think it is confusing, especially for the
 newcomers.

 If deprecating is too much, maybe the docs
 (http://docs.djangoproject.com/en/1.3/topics/auth/#storing-additional-
 information-about-users) should be rewritten: new users should be advised
 to create a models with OneToOne field pointing to django.auth.models.User
 and to setup the signal for profile auto-creation (with copy-pastable
 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] #15929: test.client.RequestFactory keeps state

2011-05-01 Thread Django

#15929: test.client.RequestFactory keeps state
-+-
   Reporter: |  Owner:  nobody
  m.vantellingen@…   | Status:  new
   Type:  Bug|  Component:  Testing framework
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  1
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
-+-

Comment (by mvantellingen):

 Well the root cause is obviously that the AuthenticationMiddleware
 modifies the WSGIRequest class.
 The proper solution is to actually not do this, but there are probably
 reasons why this is done :-)

 I'm not sure if django should support custom middleware which modifies
 django internals.

-- 
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] #13648: '%s' escaping support for sqlite3

2011-05-01 Thread Django

#13648: '%s' escaping support for sqlite3
-+-
   Reporter:  master |  Owner:
   Type:  Bug| Status:  new
  Milestone: |  Component:  Database layer
Version:  SVN|  (models, ORM)
 Resolution: |   Severity:  Normal
   Triage Stage:  Ready for  |   Keywords:  sqlite escape
  checkin|  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+-
Changes (by aaugustin):

 * needs_better_patch:  1 => 0
 * stage:  Accepted => Ready for checkin


Comment:

 The "patch needs improvement" flag applied to the first proposals; the
 latest patch by salgado looks fine.

 I don't think it is useful to "join" this ticket with #12268, which would
 mean marking one as a duplicate of the other. Actually, it's rather
 necessary to fix this one before tackling #12268.

-- 
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] #15936: Syndication: Turning off autoescape (content:encoded)

2011-05-01 Thread Django

#15936: Syndication: Turning off autoescape (content:encoded)
-+-
   Reporter:  Brant  |  Owner:  nobody
  Steen   | Status:  closed
   Type:  New|  Component:  contrib.syndication
  feature|   Severity:  Normal
  Milestone: |   Keywords:  syndication,
Version:  1.3|  content:encoded
 Resolution:  invalid|  Has patch:  1
   Triage Stage: |Needs tests:  1
  Unreviewed |  Easy pickings:  0
Needs documentation:  1  |
Patch needs improvement:  0  |
-+-
Changes (by aaugustin):

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


Comment:

 Based on http://web.resource.org/rss/1.0/modules/content/
 `content:encoded` is:

 > An element whose contents are the entity-encoded or CDATA-escaped
 version of the content of the item.

 I see that you are trying to force CDATA-escaping:
 {{{
 def item_content_encoded(self, item):
 return "" % item.content
 }}}
 Why don't you just let Django perform the equivalent entity-encoding?

 As far as I can tell, the following solution works perfectly (see
 screenshot):
 {{{

 from django.contrib.syndication.views import feedgenerator, Feed

 ### not touched from your example

 class ExtendedRSSFeed(feedgenerator.Rss201rev2Feed):
 """
 Create a type of RSS feed that has content:encoded elements.
 """
 def root_attributes(self):
 attrs = super(ExtendedRSSFeed, self).root_attributes()
 attrs['xmlns:content'] =
 'http://purl.org/rss/1.0/modules/content/'
 return attrs

 def add_item_elements(self, handler, item):
 super(ExtendedRSSFeed, self).add_item_elements(handler, item)
 handler.addQuickElement(u'content:encoded',
 item['content_encoded'])

 ### customized

 class TestFeed(Feed):
 title = "test"
 link = "/"
 description = "test"
 feed_type = ExtendedRSSFeed

 def items(self):
 return range(3)

 def item_title(self, item):
 return "Title of item %d" % item

 def item_description(self, item):
 return "Description of item %d" % item

 def item_link(self, item):
 return "/%d/" % item

 def item_extra_kwargs(self, item):
 return {'content_encoded': 'Item %dlorem ipsum...'
 % item}
 }}}

-- 
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] #15929: test.client.RequestFactory keeps state

2011-05-01 Thread Django

#15929: test.client.RequestFactory keeps state
-+-
   Reporter: |  Owner:  nobody
  m.vantellingen@…   | Status:  new
   Type:  Bug|  Component:  Testing framework
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  1
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
-+-
Changes (by aaugustin):

 * needs_tests:  0 => 1


Comment:

 I haven't looked into the details, but this patch looks like it's fixing
 the symptoms and not addressing the root cause of the problem.

 For instance, what if someone has a custom middleware that adds another
 variable?

-- 
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.

63 matches

Mail list logo