date:20111217

Re: [Django] #17433: TestCase.assertFieldOutput documentation missing versionadded

2011-12-17 Thread Django

#17433: TestCase.assertFieldOutput documentation missing versionadded
---+
 Reporter:  dpifke |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Documentation  |  Version:  SVN
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  1  |UI/UX:  0
---+
Changes (by julien):

 * needs_better_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] #17433: TestCase.assertFieldOutput documentation missing versionadded

2011-12-17 Thread Django

#17433: TestCase.assertFieldOutput documentation missing versionadded
---+
 Reporter:  dpifke |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Documentation  |  Version:  SVN
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+
Changes (by julien):

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


Comment:

 Thanks for the report. Could you please re-post your patch generated from
 the root of the source tree? This makes it easier for others to apply it.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #16074: Class-based views clash get_context_data

2011-12-17 Thread Django

#16074: Class-based views clash get_context_data
---+
 Reporter:  emyller|Owner:  tobias
 Type:  Bug|   Status:  assigned
Component:  Generic views  |  Version:  SVN
 Severity:  Normal |   Resolution:
 Keywords:  cbv| Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by ptone):

 * has_patch:  0 => 1
 * version:  1.3 => SVN


Comment:

 https://github.com/django/django/pull/81

-- 
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] #17432: url(r'^admin/', include('admin.site.urls')),

2011-12-17 Thread Django

#17432: url(r'^admin/', include('admin.site.urls')),
---+--
 Reporter:  info@… |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  Version:  1.3
 Severity:  Normal |   Resolution:  needsinfo
 Keywords:  admin  | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--
Changes (by carljm):

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


Comment:

 Can you clarify where the first version of the line (the one marked "<---
 default") came from? I've checked both the startproject template and the
 docs for 1.3.1 and I can't find anywhere that line is found with the
 quotes.

-- 
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] #17430: Clearly document the permissions model for the Django admin interface

2011-12-17 Thread Django

#17430: Clearly document the permissions model for the Django admin interface
---+--
 Reporter:  ncoghlan@… |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  1.3
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by ncoghlan@…):

 The problem is that they're scattered, so it's hard to be sure you've
 covered everything. What happened to me was that I had a bug in my auth
 backend, such that "is_staff" and "is_superuser" weren't being set
 correctly (they were always False). Initially I assumed I had missed
 something, so I was scouring the docs trying to work out what I had
 missed. It was only after convincing myself that I had actually found all
 the relevant pieces that I took a closer look at my own code and uncovered
 the bug.

 A simple list of bullet points in the Custom Auth Backend section would
 have steered me in the right direction straight away (because I would have
 known I had covered everything, and hence I simply had a bug in the code I
 had already written rather than missing a step). With appropriate links to
 the specific sections, something like the following would make it crystal
 clear what you need to do to link the two together:

 "To use the Django admin system with a custom authentication backend, the
 custom backend must do at least the following:
 - create Django User objects for any users that need to access the Django
 admin system
 - ensure "is_active" is set for each of those users
 - ensure that either "is_superuser" (for full access) or "is_staff" and
 the appropriate permissions (for limited access) are set for each of those
 users"

 (That would probably replace the current sentence on the topic, since the
 two cover the same ground)

-- 
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] #17433: TestCase.assertFieldOutput documentation missing versionadded

2011-12-17 Thread Django

#17433: TestCase.assertFieldOutput documentation missing versionadded
---+
 Reporter:  dpifke |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Documentation  |Version:  SVN
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  1
Easy pickings:  1  |  UI/UX:  0
---+
 This function was added in [16653], but the documentation in
 docs/topics/testing.txt doesn't have a versionadded attribute indicating
 it's new.  Thus a visitor hitting the documentation via Google might be
 led to believe it's present in released versions.

 Attached is an extremely trivial patch against the current SVN trunk to
 fix this minor oversight.

-- 
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] #17432: url(r'^admin/', include('admin.site.urls')),

2011-12-17 Thread Django

#17432: url(r'^admin/', include('admin.site.urls')),
---+
 Reporter:  info@… |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  contrib.admin  |Version:  1.3
 Severity:  Normal |   Keywords:  admin
 Triage Stage:  Unreviewed |  Has patch:  1
Easy pickings:  1  |  UI/UX:  0
---+
 hello dear Developers.

 i found a bug.

 i'm using ubuntu 11.10 ubuntu and installded django this way


 {{{
 wget http://www.djangoproject.com/download/1.3.1/tarball/
 }}}



 {{{
 tar xzvf Django-1.3.1.tar.gz

 }}}


 {{{
 cd Django-1.3.1
 }}}



 {{{
 python setup.py install
 }}}



 but when i tried to activate the admin i found an error.

 the line

 {{{

 url(r'^admin/', include('admin.site.urls')), < default
 }}}


 have to look like

 {{{

 url(r'^admin/', include(admin.site.urls)),
 }}}

-- 
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] #16250: Error with new pyscopg2 2.4.2 release and tests

2011-12-17 Thread Django

#16250: Error with new pyscopg2 2.4.2 release and tests
---+
 Reporter:  anonymous  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Testing framework  |  Version:  1.3
 Severity:  Release blocker|   Resolution:  fixed
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by dpifke):

 Ubuntu users running the latest release (Oneiric) will encounter this
 issue, since Ubuntu ships Django 1.3.1 and Psycopg2 2.4.2.

 This has been reported to Ubuntu as issue 905837:

 https://bugs.launchpad.net/ubuntu/+source/python-django/+bug/905837

-- 
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] #17430: Clearly document the permissions model for the Django admin interface

2011-12-17 Thread Django

#17430: Clearly document the permissions model for the Django admin interface
---+--
 Reporter:  ncoghlan@… |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  1.3
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by kmtracey):

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


Comment:

 Could you say a bit more about where you looked and found docs lacking?

 This bit: https://docs.djangoproject.com/en/1.3/topics/auth/#writing-an-
 authentication-backend does mention that "The Django admin system is
 tightly coupled to the Django User object described at the beginning of
 this document. For now, the best way to deal with this is to create a
 Django User object for each user that exists for your backend (e.g., in
 your LDAP directory, your external SQL database, etc.)" implying to use
 admin with a custom auth backend you still do want to be using standard
 django.contrib.auth Usesr objects, with all their attributes.

 The descriptions for is_staff, is_active, is_superuser
 
(https://docs.djangoproject.com/en/1.3/topics/auth/#django.contrib.auth.models.User.is_staff)
 all mention how admin uses them.

 https://docs.djangoproject.com/en/1.3/topics/auth/#permissions describes
 how admin uses permissions to control how much access a user has to
 individual models in the admin 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.

Re: [Django] #5524: Cleaned form data should not be deleted if other data is invalid.

2011-12-17 Thread Django

#5524: Cleaned form data should not be deleted if other data is invalid.
-+-
 Reporter:  __hawkeye__  |Owner:  aaugustin
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by aaugustin):

 * owner:   => aaugustin


-- 
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] r17229 - django/trunk/django/core/serializers

2011-12-17 Thread noreply

Author: ramiro
Date: 2011-12-17 15:00:41 -0800 (Sat, 17 Dec 2011)
New Revision: 17229

Modified:
   django/trunk/django/core/serializers/json.py
Log:
Tweaked changes from r17228 to cater for older simplejson versions.

dump() started accepting the `use_decimal` argument in 2.1.3.

Refs #16850.

Modified: django/trunk/django/core/serializers/json.py
===
--- django/trunk/django/core/serializers/json.py2011-12-17 22:10:37 UTC 
(rev 17228)
+++ django/trunk/django/core/serializers/json.py2011-12-17 23:00:41 UTC 
(rev 17229)
@@ -18,7 +18,9 @@
 internal_use_only = False
 
 def end_serialization(self):
-self.options.update({'use_decimal': False}) # Use JS strings to 
represent Python Decimal instances (ticket #16850)
+if simplejson.__version__.split('.') >= ['2', '1', '3']:
+# Use JS strings to represent Python Decimal instances (ticket 
#16850)
+self.options.update({'use_decimal': False})
 simplejson.dump(self.objects, self.stream, cls=DjangoJSONEncoder, 
**self.options)
 
 def getvalue(self):

-- 
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] #16850: Testsuite failing on JSON serialization

2011-12-17 Thread Django

#16850: Testsuite failing on JSON serialization
-+-
 Reporter:  Raphael Hertzog  |Owner:  nobody
  |   Status:  closed
 Type:  Bug  |  Version:  1.3
Component:  Core |   Resolution:  fixed
  (Serialization)| Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by ramiro):

 In [17229]:
 {{{
 #!CommitTicketReference repository="" revision="17229"
 Tweaked changes from r17228 to cater for older simplejson versions.

 dump() started accepting the `use_decimal` argument in 2.1.3.

 Refs #16850.
 }}}

-- 
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] r17228 - django/trunk/django/core/serializers

2011-12-17 Thread noreply

Author: ramiro
Date: 2011-12-17 14:10:37 -0800 (Sat, 17 Dec 2011)
New Revision: 17228

Modified:
   django/trunk/django/core/serializers/json.py
Log:
Fixed #16850 -- Made sure we always represent Decimal instances with JS strings 
when serializing.

We force this when calling simplejson dump() to isolate us from changes of
default behavior to encode them with JavaScript numbers instead that could
introduce loss of precision when decoding back from JSON to Python.

Thanks Raphael Hertzog for the report and Bob Ippolito for his help.

Modified: django/trunk/django/core/serializers/json.py
===
--- django/trunk/django/core/serializers/json.py2011-12-17 17:38:08 UTC 
(rev 17227)
+++ django/trunk/django/core/serializers/json.py2011-12-17 22:10:37 UTC 
(rev 17228)
@@ -18,6 +18,7 @@
 internal_use_only = False
 
 def end_serialization(self):
+self.options.update({'use_decimal': False}) # Use JS strings to 
represent Python Decimal instances (ticket #16850)
 simplejson.dump(self.objects, self.stream, cls=DjangoJSONEncoder, 
**self.options)
 
 def getvalue(self):

-- 
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] #16850: Testsuite failing on JSON serialization

2011-12-17 Thread Django

#16850: Testsuite failing on JSON serialization
-+-
 Reporter:  Raphael Hertzog  |Owner:  nobody
  |   Status:  closed
 Type:  Bug  |  Version:  1.3
Component:  Core |   Resolution:  fixed
  (Serialization)| Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by ramiro):

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


Comment:

 In [17228]:
 {{{
 #!CommitTicketReference repository="" revision="17228"
 Fixed #16850 -- Made sure we always represent Decimal instances with JS
 strings when serializing.

 We force this when calling simplejson dump() to isolate us from changes of
 default behavior to encode them with JavaScript numbers instead that could
 introduce loss of precision when decoding back from JSON to Python.

 Thanks Raphael Hertzog for the report and Bob Ippolito for his help.
 }}}

-- 
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] #16919: Pass user to set_password_form in GET requests

2011-12-17 Thread Django

#16919: Pass user to set_password_form in GET requests
--+
 Reporter:  jaimeirurzun  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  contrib.auth  |  Version:  1.3
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  1 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by ejucovy):

 * cc: ethan.jucovy@… (added)


Comment:

 I have another use case for this: rendering the user's name in the
 `registration/password_reset_confirm.html` template.

 Currently the `password_reset_confirm` view does not provide "user" as a
 template context variable, nor even "uidb36" and "token".  Since the form
 also doesn't have the user object stored on a GET request, this means that
 there's no way for the template to say "{% if validlink %} Hello, {{
 user.username }} -- reset your password here {% endif %}" -- short of
 forking the view, or some pretty hacky middleware that re-parses the
 request URL and re-fetches the user from the given uid+token.

 I see that the "needs_tests" flag is set on this ticket .. what sort of
 test would be required for this patch to be merged?

-- 
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] #17431: Allow PasswordResetForm subclasses full control over email message to send

2011-12-17 Thread Django

#17431: Allow PasswordResetForm subclasses full control over email message to 
send
--+
 Reporter:  ejucovy   |  Owner:  nobody
 Type:  New feature   | Status:  new
Component:  contrib.auth  |Version:  SVN
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  1
Easy pickings:  0 |  UI/UX:  0
--+
 The `django.contrib.auth.forms.PasswordResetForm` has logic to:

 1. Validate that an active user exists with the email address provided
 1. Generate an unguessable URL for the given user to reset his password
 using a timestamped token
 1. Construct an email with a link to that URL
 1. Send that email to the given user's email address

 The `.save()` method of the form class is responsible for three of these
 four tasks.  The `.save()` method includes parameters for overriding the
 subject, body, and `From:` address of the email to be sent.  However, it's
 sometimes necessary to have more control over the email that will be sent.
 These use cases could include:

 1. BCC'ing a site administrator with a copy of the email sent
 1. Setting a custom `Reply-To` like "password-reset-h...@example.com" that
 is distinct from the message's `From:` address
 1. Setting a `text/html` MIME type for the message, or using an
 `EmailMultiAlternatives` object to attach both text and HTML versions of
 the message

 For all of these use cases, the knobs currently provided are insufficient,
 and require copying over all the logic in the `.save()` method.

 The attached patch satisfies these use cases by allowing the user to
 subclass PasswordResetForm and override a `.construct_email()` method,
 whose job is to construct and return an `EmailMessage` to be sent by the
 `.save()` method.  The changes are fully backwards-compatible, and a test
 demonstrating the subclassing approach is provided.

-- 
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] #2879: Add live test server support to test framework

2011-12-17 Thread Django

#2879: Add live test server support to test framework
-+-
 Reporter:  Mikeal Rogers|Owner:  devin
   |   Status:  new
 Type:  New feature  |  Version:
Component:  Testing framework|   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by akaariai):

 The live-server still requires STATIC_URL, it just doesn't get stuck if it
 is missing. So, it is fixed only in that sense.

 It would be nice if the stacktraces for missing 500.html would not get
 printed. But it isn't that important...

-- 
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] #17005: Adding django.contrib.site.middleware ?

2011-12-17 Thread Django

#17005: Adding django.contrib.site.middleware ?
---+--
 Reporter:  jordan@…   |Owner:  krzysiumed
 Type:  New feature|   Status:  assigned
Component:  contrib.sites  |  Version:
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by charettes):

 * 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] #2879: Add live test server support to test framework

2011-12-17 Thread Django

#2879: Add live test server support to test framework
-+-
 Reporter:  Mikeal Rogers|Owner:  devin
   |   Status:  new
 Type:  New feature  |  Version:
Component:  Testing framework|   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by julien):

 akaariai: Your suggestion for preventing dead locks when shutting down the
 live server makes sense. I've made the change in the latest patch,
 although I've borrowed some code from Python 2.7 to do the implementation
 (see the `_ImprovedEvent` class). I also agree about documenting the use
 of setUpClass/tearDownClass and including that change in the latest patch.

 However, I'm not sure how your suggestion addresses the `STATIC_URL`
 issue. Could you elaborate on that? I haven't had the time to investigate
 it fully myself yet. It seems at the very least there should be some
 documentation about it.

 From what I recall in the early days that I worked on this patch, I now
 remember having hit some issues if the tested site didn't include a
 favicon.ico, 404.html or 500.html files. Either the code should handle
 those cases or that should be documented.

-- 
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] #17005: Adding django.contrib.site.middleware ?

2011-12-17 Thread Django

#17005: Adding django.contrib.site.middleware ?
---+--
 Reporter:  jordan@…   |Owner:  krzysiumed
 Type:  New feature|   Status:  assigned
Component:  contrib.sites  |  Version:
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by krzysiumed):

 I'd written a patch. It contains docs and tests (I believe they are not
 necessary, because the middleware is very simple). Sorry for my poor
 English in docs.

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

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

Re: [Django] #11228: FieldFile with check if file exists.

2011-12-17 Thread Django

#11228: FieldFile with check if file exists.
-+-
 Reporter:  hersonls |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:  wontfix
 Severity:  Normal   | Triage Stage:  Design
 Keywords:   |  decision needed
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by aaugustin):

 * status:  new => closed
 * ui_ux:   => 0
 * resolution:   => wontfix
 * easy:   => 0


Comment:

 Like Chris, I doubt this would be generally useful. If you're losing
 files, you're got bigger problems than broken links in your templates!

 Furthermore, it's trivial to subclass !FileField to add this method if you
 need it.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #9057: allow override of contrib.auth auto creation of permissions and superuser

2011-12-17 Thread Django

#9057: allow override of contrib.auth auto creation of permissions and superuser
--+
 Reporter:  hvendelbo |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  contrib.auth  |  Version:  1.0
 Severity:  Normal|   Resolution:
 Keywords:  auth  | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  1
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by aaugustin):

 * stage:  Design decision needed => 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] #8886: loaddata deserializes BooleanFields wrong for inheriting model

2011-12-17 Thread Django

#8886: loaddata deserializes BooleanFields wrong for inheriting model
-+-
 Reporter:  erichs@… |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.0
  (models, ORM)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Design
 Keywords:  loaddata |  decision needed
  BooleanField   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by aaugustin):

 * status:  new => closed
 * ui_ux:   => 0
 * resolution:   => fixed
 * easy:   => 0


Comment:

 The example provided by the OP now properly raises a `ValidationError`:
 {{{
 Traceback (most recent call last):
   File "./manage.py", line 9, in 
 execute_from_command_line(sys.argv)
   File "/Users/myk/Documents/dev/django-
 trunk/django/core/management/__init__.py", line 422, in
 execute_from_command_line
 utility.execute()
   File "/Users/myk/Documents/dev/django-
 trunk/django/core/management/__init__.py", line 361, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "/Users/myk/Documents/dev/django-
 trunk/django/core/management/base.py", line 192, in run_from_argv
 self.execute(*args, **options.__dict__)
   File "/Users/myk/Documents/dev/django-
 trunk/django/core/management/base.py", line 228, in execute
 output = self.handle(*args, **options)
   File "/Users/myk/Documents/dev/django-
 trunk/django/core/management/base.py", line 364, in handle
 return self.handle_noargs(**options)
   File "/Users/myk/Documents/dev/django-
 trunk/django/core/management/commands/validate.py", line 9, in
 handle_noargs
 self.validate(display_num_errors=True)
   File "/Users/myk/Documents/dev/django-
 trunk/django/core/management/base.py", line 262, in validate
 num_errors = get_validation_errors(s, app)
   File "/Users/myk/Documents/dev/django-
 trunk/django/core/management/validation.py", line 30, in
 get_validation_errors
 for (app_name, error) in get_app_errors().items():
   File "/Users/myk/Documents/dev/django-
 trunk/django/db/models/loading.py", line 158, in get_app_errors
 self._populate()
   File "/Users/myk/Documents/dev/django-
 trunk/django/db/models/loading.py", line 64, in _populate
 self.load_app(app_name, True)
   File "/Users/myk/Documents/dev/django-
 trunk/django/db/models/loading.py", line 88, in load_app
 models = import_module('.models', app_name)
   File "/Users/myk/Documents/dev/django-trunk/django/utils/importlib.py",
 line 35, in import_module
 __import__(name)
   File "/Users/myk/Documents/dev/test_project/test_app/models.py", line
 22, in 
 class Employee(User):
   File "/Users/myk/Documents/dev/django-trunk/django/db/models/base.py",
 line 149, in __new__
 (field.name, name, base.__name__))
 django.core.exceptions.FieldError: Local field 'is_active' in class
 'Employee' clashes with field of similar name from base class 'User'
 }}}

-- 
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] #17005: Adding django.contrib.site.middleware ?

2011-12-17 Thread Django

#17005: Adding django.contrib.site.middleware ?
---+--
 Reporter:  jordan@…   |Owner:  krzysiumed
 Type:  New feature|   Status:  assigned
Component:  contrib.sites  |  Version:
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by krzysiumed):

 * status:  new => assigned


-- 
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] #17005: Adding django.contrib.site.middleware ?

2011-12-17 Thread Django

#17005: Adding django.contrib.site.middleware ?
---+--
 Reporter:  jordan@…   |Owner:  krzysiumed
 Type:  New feature|   Status:  new
Component:  contrib.sites  |  Version:
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by krzysiumed):

 * owner:  anonymous => krzysiumed
 * status:  assigned => new


-- 
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] #17005: Adding django.contrib.site.middleware ?

2011-12-17 Thread Django

#17005: Adding django.contrib.site.middleware ?
---+-
 Reporter:  jordan@…   |Owner:  anonymous
 Type:  New feature|   Status:  assigned
Component:  contrib.sites  |  Version:
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+-
Changes (by anonymous):

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


-- 
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] r17227 - django/trunk/tests/regressiontests/queries

2011-12-17 Thread noreply

Author: adrian
Date: 2011-12-17 09:38:08 -0800 (Sat, 17 Dec 2011)
New Revision: 17227

Modified:
   django/trunk/tests/regressiontests/queries/tests.py
Log:
Optimized an optimise

Modified: django/trunk/tests/regressiontests/queries/tests.py
===
--- django/trunk/tests/regressiontests/queries/tests.py 2011-12-17 17:37:24 UTC 
(rev 17226)
+++ django/trunk/tests/regressiontests/queries/tests.py 2011-12-17 17:38:08 UTC 
(rev 17227)
@@ -1430,7 +1430,7 @@
 
 # The annotation->tag link is single values and tag->children links is
 # multi-valued. So we have to split the exclude filter in the middle
-# and then optimise the inner query without losing results.
+# and then optimize the inner query without losing results.
 self.assertQuerysetEqual(
 Annotation.objects.exclude(tag__children__name="t2"),
 ['']

-- 
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] r17226 - in django/trunk: django/conf django/contrib/admin/static/admin/js/admin django/contrib/gis/geos/tests django/contrib/sessions django/core/management django/db/models/sql django/t

2011-12-17 Thread noreply

Author: adrian
Date: 2011-12-17 09:37:24 -0800 (Sat, 17 Dec 2011)
New Revision: 17226

Modified:
   django/trunk/django/conf/global_settings.py
   django/trunk/django/contrib/admin/static/admin/js/admin/ordering.js
   django/trunk/django/contrib/gis/geos/tests/test_geos.py
   django/trunk/django/contrib/sessions/tests.py
   django/trunk/django/core/management/__init__.py
   django/trunk/django/db/models/sql/query.py
   django/trunk/django/template/defaulttags.py
   django/trunk/django/views/debug.py
   django/trunk/tests/modeltests/force_insert_update/models.py
   django/trunk/tests/modeltests/prefetch_related/tests.py
   django/trunk/tests/regressiontests/defer_regress/tests.py
   django/trunk/tests/regressiontests/fixtures_regress/models.py
   django/trunk/tests/regressiontests/mail/tests.py
   django/trunk/tests/regressiontests/model_inheritance_regress/tests.py
   django/trunk/tests/regressiontests/multiple_database/tests.py
   django/trunk/tests/regressiontests/queries/tests.py
   django/trunk/tests/regressiontests/serializers_regress/tests.py
   django/trunk/tests/regressiontests/templates/filters.py
   django/trunk/tests/regressiontests/test_client_regress/models.py
Log:
Fixed various dodgy behaviours

Modified: django/trunk/django/conf/global_settings.py
===
--- django/trunk/django/conf/global_settings.py 2011-12-17 15:30:55 UTC (rev 
17225)
+++ django/trunk/django/conf/global_settings.py 2011-12-17 17:37:24 UTC (rev 
17226)
@@ -152,7 +152,7 @@
 },
 }
 
-# Classes used to implement db routing behaviour
+# Classes used to implement DB routing behavior.
 DATABASE_ROUTERS = []
 
 # The email backend to use. For possible shortcuts see django.core.mail.

Modified: django/trunk/django/contrib/admin/static/admin/js/admin/ordering.js
===
--- django/trunk/django/contrib/admin/static/admin/js/admin/ordering.js 
2011-12-17 15:30:55 UTC (rev 17225)
+++ django/trunk/django/contrib/admin/static/admin/js/admin/ordering.js 
2011-12-17 17:37:24 UTC (rev 17226)
@@ -11,7 +11,7 @@
 setOrder(input.value.split(','));
 input.disabled = true;
 draw();
-// Now initialise the dragging behaviour
+// Now initialize the dragging behavior
 var limit = (lis.length - 1) * height;
 for (var i = 0; i < lis.length; i++) {
 var li = lis[i];

Modified: django/trunk/django/contrib/gis/geos/tests/test_geos.py
===
--- django/trunk/django/contrib/gis/geos/tests/test_geos.py 2011-12-17 
15:30:55 UTC (rev 17225)
+++ django/trunk/django/contrib/gis/geos/tests/test_geos.py 2011-12-17 
17:37:24 UTC (rev 17226)
@@ -892,11 +892,11 @@
 
 def test23_transform_nosrid(self):
 """ Testing `transform` method (no SRID) """
-# raise a warning if SRID <0/None
+# Raise a warning if SRID <0/None.
 import warnings
 print "\nBEGIN - expecting Warnings; safe to ignore.\n"
 
-# test for do-nothing behaviour.
+# Test for do-nothing behavior.
 try:
 # Keeping line-noise down by only printing the relevant
 # warnings once.

Modified: django/trunk/django/contrib/sessions/tests.py
===
--- django/trunk/django/contrib/sessions/tests.py   2011-12-17 15:30:55 UTC 
(rev 17225)
+++ django/trunk/django/contrib/sessions/tests.py   2011-12-17 17:37:24 UTC 
(rev 17226)
@@ -410,6 +410,6 @@
 This test tested cycle_key() which would create a new session
 key for the same session data. But we can't invalidate previously
 signed cookies (other than letting them expire naturally) so
-testing for this behaviour is meaningless.
+testing for this behavior is meaningless.
 """
 pass

Modified: django/trunk/django/core/management/__init__.py
===
--- django/trunk/django/core/management/__init__.py 2011-12-17 15:30:55 UTC 
(rev 17225)
+++ django/trunk/django/core/management/__init__.py 2011-12-17 17:37:24 UTC 
(rev 17226)
@@ -168,7 +168,7 @@
 def print_lax_help(self):
 """Output the basic options available to every command.
 
-This just redirects to the default print_help() behaviour.
+This just redirects to the default print_help() behavior.
 """
 OptionParser.print_help(self)
 

Modified: django/trunk/django/db/models/sql/query.py
===
--- django/trunk/django/db/models/sql/query.py  2011-12-17 15:30:55 UTC (rev 
17225)
+++ django/trunk/django/db/models/sql/query.py  2011-12-17 17:37:24 UTC (rev 
17226)
@@ -1249,7 +1249,7 @@
 case). Finally, 'negate' is used in the same sense as for add_filter()
 -- it indicates an exclude() filter, or somethin

Re: [Django] #16850: Testsuite failing on JSON serialization

2011-12-17 Thread Django

#16850: Testsuite failing on JSON serialization
-+-
 Reporter:  Raphael Hertzog  |Owner:  nobody
  |   Status:  new
 Type:  Bug  |  Version:  1.3
Component:  Core |   Resolution:
  (Serialization)| Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by ramiro):

 Replying to [comment:4 ramiro]:
 > There is something strange in the fact that testing things with Python
 2.7 (I also use Debian unstable, Python 2.7 has recently entered Sid) and
 the same simplejson 2.2.0 version (provided by debian python-simplejson
 DEB package) doesn't show these failures.
 >
 > Just to be sure, I ran the serializers tests with Python 2.6 in the same
 system and I see the reported failures.
 >
 > Maybe Python 2.6 also has something to do with this?

 The reason for this is because additionally the version of Decimal shipped
 with Python 2.7 has a new `Decimal.from_float()` method that gets used
 during decoding from JSON operations instead or raising the error reported
 with Python 2.6 by the OP. This method can lose precision and neither we
 nor simplejson can control that.

 This seems to be an additional reason to keep using strings to encode
 Decimal's

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

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

Re: [Django] #16250: Error with new pyscopg2 2.4.2 release and tests

2011-12-17 Thread Django

#16250: Error with new pyscopg2 2.4.2 release and tests
---+
 Reporter:  anonymous  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Testing framework  |  Version:  1.3
 Severity:  Release blocker|   Resolution:  fixed
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by jakewan):

 Replying to [comment:30 yodiaditya]:
 > When it will included in django 1.3.1 ?
 See comment 26

-- 
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] #10244: FileFields can't be set to NULL in the db

2011-12-17 Thread Django

#10244: FileFields can't be set to NULL in the db
-+-
 Reporter:  oyvind   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.0
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  filefield NULL   |  Needs documentation:  0
  empty  |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by aaugustin):

 * ui_ux:   => 0
 * easy:   => 0
 * stage:  Design decision needed => Accepted


Comment:

 I see two possible solutions:
 - 1. document that `FileField` ignores the `null` keyword argument; this
 is the most backwards compatible solution;
 - 2. make `FileField` behave exactly like `CharField` wrt. `null`; this is
 the most consistent solution.

 Option 2. will be backwards incompatible only for people who set
 `null=True` on a `FileField`. The docs discourage that heavily, and it
 doesn't behave as expected, actually it doesn't even do anything, so there
 isn't much reason to have such code. That's why I think the change would
 be acceptable.

 I have a slight preference for option 2, which is better in the long term.

-- 
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] #17430: Clearly document the permissions model for the Django admin interface

2011-12-17 Thread Django

#17430: Clearly document the permissions model for the Django admin interface
---+
 Reporter:  ncoghlan@… |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  1.3
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 The current auth docs aren't particularly clear on *exactly* what is
 needed to support the Django admin with a custom backend. Specifically, I
 had to do a lot of digging and experimentation to work out adequate
 settings for a User to be able to:
 1. Access the admin pages at all (i.e. is_active + is_staff)
 2. Actually edit the model data (through trial and error, I know that
 is_active + is_staff + is_super works, but I don't know if there are any
 other ways to achieve the same thing).

-- 
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] #9104: FieldDoesNotExist is defined in "confusing" place.

2011-12-17 Thread Django

#9104: FieldDoesNotExist is defined in "confusing" place.
-+-
 Reporter:  telenieko|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  SVN
Component:  Core (Other) |   Resolution:  needsinfo
 Severity:  Normal   | Triage Stage:  Design
 Keywords:   |  decision needed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by aaugustin):

 * status:  new => closed
 * ui_ux:   => 0
 * resolution:   => needsinfo
 * easy:   => 0


Comment:

 Malcolm explained why the code is written in this way, and his question
 stays unanswered after years.

-- 
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] #13147: auth.UserCreationForm : unicity check on username not necessary

2011-12-17 Thread Django

#13147: auth.UserCreationForm : unicity check on username not necessary
-+-
 Reporter:  peyman   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  1.1
Component:  contrib.auth |   Resolution:  wontfix
 Severity:  Normal   | Triage Stage:  Design
 Keywords:   |  decision needed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by aaugustin):

 In [17225]:
 {{{
 #!CommitTicketReference repository="" revision="17225"
 Explained why UserCreationForm performs custom validation of usernames.
 Refs #13147.
 }}}

-- 
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] r17225 - django/trunk/django/contrib/auth

2011-12-17 Thread noreply

Author: aaugustin
Date: 2011-12-17 07:30:55 -0800 (Sat, 17 Dec 2011)
New Revision: 17225

Modified:
   django/trunk/django/contrib/auth/forms.py
Log:
Explained why UserCreationForm performs custom validation of usernames. Refs 
#13147.


Modified: django/trunk/django/contrib/auth/forms.py
===
--- django/trunk/django/contrib/auth/forms.py   2011-12-17 10:27:14 UTC (rev 
17224)
+++ django/trunk/django/contrib/auth/forms.py   2011-12-17 15:30:55 UTC (rev 
17225)
@@ -69,6 +69,8 @@
 fields = ("username",)
 
 def clean_username(self):
+# Since User.username is unique, this check is redundant,
+# but it sets a nicer error message than the ORM. See #13147.
 username = self.cleaned_data["username"]
 try:
 User.objects.get(username=username)

-- 
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] #13147: auth.UserCreationForm : unicity check on username not necessary

2011-12-17 Thread Django

#13147: auth.UserCreationForm : unicity check on username not necessary
-+-
 Reporter:  peyman   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  1.1
Component:  contrib.auth |   Resolution:  wontfix
 Severity:  Normal   | Triage Stage:  Design
 Keywords:   |  decision needed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by aaugustin):

 * status:  new => closed
 * ui_ux:   => 0
 * resolution:   => wontfix
 * easy:   => 0


Comment:

 I agree with Luke.

-- 
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] #12952: Models history doesn't use verbose names

2011-12-17 Thread Django

#12952: Models history doesn't use verbose names
---+
 Reporter:  acangiano  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  1.2-beta
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  1
---+

Comment (by aaugustin):

 #14358 is a duplicate and has patches too.

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

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

Re: [Django] #12952: Models history doesn't use verbose names

2011-12-17 Thread Django

#12952: Models history doesn't use verbose names
---+
 Reporter:  acangiano  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  1.2-beta
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  1
---+
Changes (by aaugustin):

 * stage:  Design decision needed => Accepted


Comment:

 The objection was "for debug purposes, it would be more useful to have the
 field names, as they are necessarily unique, untranslated, etc."

 In my opinion:
 - uniqueness is a weak argument: if you have two fields with the same
 name, you're just asking for trouble;
 - translation isn't an issue at all: in doubt, just switch the website to
 the default language of your codebase.

-- 
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] #12990: New Field Type: JSONField

2011-12-17 Thread Django

#12990: New Field Type: JSONField
-+-
 Reporter:  paltman  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  1.2-alpha
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Design
 Keywords:   |  decision needed
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by aaugustin):

 `django-extensions` is a fairly popular project that provides an
 [https://github.com/django-extensions/django-
 extensions/blob/master/django_extensions/db/fields/json.py implementation]
 of `JSONField`.

-- 
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] #12493: settings.configure silently allows TEMPLATE_DIRS configuration error

2011-12-17 Thread Django

#12493: settings.configure silently allows TEMPLATE_DIRS configuration error
--+
 Reporter:  mckoss|Owner:  gwilson
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Core (Other)  |  Version:  1.1
 Severity:  Normal|   Resolution:
 Keywords:  settings, templates   | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by aaugustin):

 * stage:  Design decision needed => Accepted


Comment:

 Accepting as explained by gwilson. We'll need a deprecation path for the
 switch from auto-correcting to raising an exception.

-- 
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] #12165: Ability to use SQL functions in queries

2011-12-17 Thread Django

#12165: Ability to use SQL functions in queries
-+-
 Reporter:  premalshah   |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  1.0
  (models, ORM)  |   Resolution:  invalid
 Severity:  Normal   | Triage Stage:  Design
 Keywords:  mysql functions  |  decision needed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by aaugustin):

 * status:  new => closed
 * ui_ux:   => 0
 * resolution:   => invalid
 * easy:   => 0


Comment:

 I'm not convinced by this argument:
 > Most people have powerful database servers and less powerful web
 servers.
 It's trivial to scale web servers: just put a load balancer and N web
 servers behind. It isn't as easy for database servers.

 On the other hand, compressing and decompressing directly the database is
 useful if you're doing anything else than storing and retrieving data:
 lookups, sorting, etc. This is a good reason to look into the second
 option.

 At first sight, it would require extensive changes to the ORM. Per the
 [https://docs.djangoproject.com/en/dev/internals/contributing/bugs-and-
 features/#requesting-features contributing guide], such feature requests
 should be sent to django-developers, preferably with a patch demonstrating
 the concept. For now, given the lack of interest for this ticket, I'm
 going to close it.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #17390: Describe how to do auth for Class Based Views in the main Auth docs

2011-12-17 Thread Django

#17390: Describe how to do auth for Class Based Views in the main Auth docs
--+
 Reporter:  ncoghlan@…|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  1.3
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by bpeschier):

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


Comment:

 Good catch, should describe the non-deprecated method of generic views.

-- 
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] #11372: Support setup.py develop

2011-12-17 Thread Django

#11372: Support setup.py develop
-+-
 Reporter:  kcarnold |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Core (Other) |  Version:  SVN
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:  Design
Has patch:  1|  decision needed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by aaugustin):

 * status:  new => closed
 * ui_ux:   => 0
 * resolution:   => wontfix
 * easy:   => 0


Comment:

 Developers may have `setuptools` installed because they need a package
 that requires it. That doesn't mean they prefer it over `distutils`.

 `distutils`, `pip` and `virtualenv` are currently the preferred solutions.
 See http://www.b-list.org/weblog/2008/dec/14/packaging/ for more
 background on this issue.

-- 
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] #11854: Add support of PostGIS's Azimuth function

2011-12-17 Thread Django

#11854: Add support of PostGIS's Azimuth function
--+
 Reporter:  ckarrie   |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  GIS   |  Version:  SVN
 Severity:  Normal|   Resolution:
 Keywords:  azimuth, postgis  | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  1
  Needs tests:  1 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+
Changes (by aaugustin):

 * stage:  Design decision needed => 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] #5524: Cleaned form data should not be deleted if other data is invalid.

2011-12-17 Thread Django

#5524: Cleaned form data should not be deleted if other data is invalid.
-+
 Reporter:  __hawkeye__  |Owner:
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+
Changes (by aaugustin):

 * needs_better_patch:  0 => 1


Comment:

 This change should be explained in the release notes. Besides this the
 patch looks pretty good.

-- 
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] #17427: DatabaseWrapper no longer hashable-> failure in test_connections_thread_local

2011-12-17 Thread Django

#17427: DatabaseWrapper no longer hashable-> failure in
test_connections_thread_local
-+-
 Reporter:  vsajip   |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by akaariai):

 I did a little investigation, and to me it seems the correct fix is to not
 define `__eq__` or `__hash__` at all, that is, they are inherited from
 object, and thus only same instance is equal.

 The current equality test using alias isn't a sane test anymore.
 Previously you had to try extra-hard to get two different instances in one
 thread to point to the same alias. Now this is much easier to do. So, if
 you have two DBWrappers pointing to the same alias but using different
 connections, I don't see a reason why they should be equal. Other
 possibility would be to base the the equality on the underlying connection
 equality, that is self.connection == other.connection.

 Previously if you transferred the DBWrapper in connections[some_alias]
 from thread 1 to thread 2, the transferred DBWrapper would have pointed to
 the same connection in thread 2 (because the DBWrapper instance was
 threading.local). So, if you tested self.alias == other.alias you would be
 testing that the connection is the same, too. This is no longer true.

 I hope the above explanation makes some sense. Making this change will
 require some minor changes to Django code. But the bigger deal is if this
 breaks user code in backwards incompatible way. User code relying on
 .alias equality is no longer correct, and instance equality will give the
 same result as long as you don't transfer connections between threads or
 anything like that. So, no problems should be caused to users by this.

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

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

Re: [Django] #11915: language range request should return sublanguage

2011-12-17 Thread Django

#11915: language range request should return sublanguage
--+
 Reporter:  galund|Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Internationalization  |  Version:  SVN
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by aaugustin):

 * ui_ux:   => 0
 * type:  New feature => Bug
 * easy:   => 0
 * stage:  Design decision needed => Accepted


Comment:

 ramiro: I propose to select whichever language comes first in
 `settings.LANGUAGES`.

-- 
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] #11903: WSGIRequest.path not quoted properly

2011-12-17 Thread Django

#11903: WSGIRequest.path not quoted properly
-+-
 Reporter:  ianb |Owner:  fgallina
 Type:  Bug  |   Status:  closed
Component:  HTTP handling|  Version:  1.1
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:  Design
Has patch:  1|  decision needed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by aaugustin):

 * status:  new => closed
 * ui_ux:   => 0
 * resolution:   => invalid
 * easy:   => 0


Comment:

 I believe the current behavior is correct. Django handles the encoding /
 decoding wherever necessary and provides `unicode` objects to the
 programmer.

 `request.path` is `unicode` and has no reason to be url-encoded. (In the
 code quoted in the original report, `path_info` is `unicode`, which
 guarantees that `self.path` is `unicode`.)

 This is a custom API of Django, which means we aren't bound by the WSGI or
 CGI spec there (while we are for `request.META['PATH_INFO']`).

 To sum up, if I'm typing "www.mysite.com/foo bar/" in my browser, the
 browser will issue a request for "/foo%20bar/", but Django will convert
 that back to `u"/foo bar/"`.

-- 
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] #2879: Add live test server support to test framework

2011-12-17 Thread Django

#2879: Add live test server support to test framework
-+-
 Reporter:  Mikeal Rogers|Owner:  devin
   |   Status:  new
 Type:  New feature  |  Version:
Component:  Testing framework|   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by akaariai):

 Ok, I did some investigation, and now STATIC_URL and quitting the tests
 when the server hits forever-loop should work.

 Attached is an incremental patch for the .10. patch. The stuff in my patch
 isn't polished at all, but it should show the problematic places, and at
 least some way to fix them.

 One thing about documentation: I wonder if it is a good advice to do
 selenium setup / quit in tearDown and setUp. This makes each test_method
 take about 7 seconds on my system (for each test method, start and stop
 Firefox).  Would it be better to advice the use of tearDownClass and
 setUpClass? This way Firefox is started only once per test class. On the
 other hand, this has a bit bigger chance of hitting cross-test
 dependencies. Maybe at least mention in the documentation that this is
 also possible? From my point of view, this documentation polishing can be
 done after initial commit.

-- 
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] #9015: Signal Connection Decorators

2011-12-17 Thread Django

#9015: Signal Connection Decorators
-+-
 Reporter:  zvoase   |Owner:  brosner
 Type:  New feature  |   Status:  closed
Component:  Core (Other) |  Version:  SVN
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  signals  | Triage Stage:  Design
Has patch:  1|  decision needed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  1
 |UI/UX:  0
-+-
Changes (by aaugustin):

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


-- 
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] #17429: if ordering = None incorrect result

2011-12-17 Thread Django

#17429: if ordering = None incorrect result
-+-
 Reporter:  self@…   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by bpeschier):

 * 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] #17426: Months in Spanish are written in lowercase

2011-12-17 Thread Django

#17426: Months in Spanish are written in lowercase
-+-
 Reporter:  opentia  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:   |  Version:  1.3
  Internationalization   |   Resolution:  needsinfo
 Severity:  Normal   | Triage Stage:
 Keywords:  months, Spanish  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by bpeschier):

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


Comment:

 According to the translations at
 [https://www.transifex.net/projects/p/django/resource/core/l/es/view/
 transifex], Django uses lowercase and python does the same. Can you give
 more info about the situation which uses uppercase month names?

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-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] #11131: Add watchlist to Trac

2011-12-17 Thread Django

#11131: Add watchlist to Trac
-+-
 Reporter:  sampablokuper|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Djangoproject.com|  Version:  1.0
  Web site   |   Resolution:
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by aaugustin):

 * stage:  Design decision needed => Ready for checkin


Comment:

 I'm going to move this ticket to RFC because it isn't of interest for the
 community, only for Trac admins. That's a procedural action, not a
 validation of the 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] #11816: defaults in genereated settings.py are absolute paths for template directories, media directories and media urls

2011-12-17 Thread Django

#11816: defaults in genereated settings.py are absolute paths for template
directories, media directories and media urls
-+-
 Reporter:  Jacques Mattheij |Owner:  nobody
|   Status:  closed
 Type:   |  Version:  1.1
  Cleanup/optimization   |   Resolution:  duplicate
Component:  Core (Management | Triage Stage:  Design
  commands)  |  decision needed
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by aaugustin):

 * status:  new => closed
 * ui_ux:   => 0
 * resolution:   => duplicate
 * easy:   => 0


Comment:

 This is a duplicate of #16504 which was closed as wontfix.

 I have mixed feelings about this idea.

 While it would make the initial setup of a new project slightly faster and
 more-beginner friendly, I really, really don't want people to store
 uploaded data (media files) next to code in production. This is prone to
 awful misconfigurations — from making the Python code writable by the
 webserver to serving uninterpreted Python files from the web root, and
 probably several others.

 Since we can't guess what a good location would be (maybe
 `/var/www/media`, `/var/www/{{ projectname }}/media`, `D:\\media`, ...),
 the default is empty.

-- 
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] #11797: Test Client Response content form value parsing

2011-12-17 Thread Django

#11797: Test Client Response content form value parsing
-+-
 Reporter:  Rupe |Owner:  Rupe
 Type:  New feature  |   Status:  closed
Component:  Testing framework|  Version:  SVN
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  test client content  | Triage Stage:  Design
  form post get  |  decision needed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by aaugustin):

 * status:  assigned => closed
 * ui_ux:   => 0
 * resolution:   => wontfix
 * easy:   => 0


Comment:

 As pointed out by Russell in the mailing list thread linked above, this is
 a significant increase of the scope of the test client, and it could be
 considered feature creep. Parsing HTML is not as trivial a task as it
 seems, even with Python's stdlib; browsers do incredible things to get it
 right in almost all cases.

 We're about to introduce support for live browser testing (for instance
 with Selenium) in #2879 and I think it's a better path forwards.

 It seems to me that the work on this ticket could live outside of trunk as
 a subclass of the test client, couldn't it? It would be a good candidate
 for djangosnippets.

-- 
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] #11569: django.core.cache.backends.db has bad transaction handling

2011-12-17 Thread Django

#11569: django.core.cache.backends.db has bad transaction handling
-+
 Reporter:  Glenn|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Cache system)  |  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by aaugustin):

 * component:  Database layer (models, ORM) => Core (Cache system)
 * stage:  Design decision needed => 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] #11166: {% widthratio 0 0 100 %} returns an empty string, rather than a 0

2011-12-17 Thread Django

#11166: {% widthratio 0 0 100 %} returns an empty string, rather than a 0
-+
 Reporter:  luddep   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Template system  |  Version:  SVN
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by aaugustin):

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


Comment:

 In [17224]:
 {{{
 #!CommitTicketReference repository="" revision="17224"
 Fixed #11166 -- {% widthratio %} should return 0 when the maximum is 0, no
 matter the value.
 }}}

-- 
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] r17224 - in django/trunk: django/template tests/regressiontests/templates

2011-12-17 Thread noreply

Author: aaugustin
Date: 2011-12-17 02:27:14 -0800 (Sat, 17 Dec 2011)
New Revision: 17224

Modified:
   django/trunk/django/template/defaulttags.py
   django/trunk/tests/regressiontests/templates/tests.py
Log:
Fixed #11166 -- {% widthratio %} should return 0 when the maximum is 0, no 
matter the value.


Modified: django/trunk/django/template/defaulttags.py
===
--- django/trunk/django/template/defaulttags.py 2011-12-17 03:53:25 UTC (rev 
17223)
+++ django/trunk/django/template/defaulttags.py 2011-12-17 10:27:14 UTC (rev 
17224)
@@ -435,7 +435,7 @@
 def render(self, context):
 try:
 value = self.val_expr.resolve(context)
-maxvalue = self.max_expr.resolve(context)
+max_value = self.max_expr.resolve(context)
 max_width = int(self.max_width.resolve(context))
 except VariableDoesNotExist:
 return ''
@@ -443,9 +443,11 @@
 raise TemplateSyntaxError("widthratio final argument must be an 
number")
 try:
 value = float(value)
-maxvalue = float(maxvalue)
-ratio = (value / maxvalue) * max_width
-except (ValueError, ZeroDivisionError):
+max_value = float(max_value)
+ratio = (value / max_value) * max_width
+except ZeroDivisionError:
+return '0'
+except ValueError:
 return ''
 return str(int(round(ratio)))
 

Modified: django/trunk/tests/regressiontests/templates/tests.py
===
--- django/trunk/tests/regressiontests/templates/tests.py   2011-12-17 
03:53:25 UTC (rev 17223)
+++ django/trunk/tests/regressiontests/templates/tests.py   2011-12-17 
10:27:14 UTC (rev 17224)
@@ -1429,7 +1429,7 @@
 
 ### WIDTHRATIO TAG 

 'widthratio01': ('{% widthratio a b 0 %}', {'a':50,'b':100}, '0'),
-'widthratio02': ('{% widthratio a b 100 %}', {'a':0,'b':0}, ''),
+'widthratio02': ('{% widthratio a b 100 %}', {'a':0,'b':0}, '0'),
 'widthratio03': ('{% widthratio a b 100 %}', {'a':0,'b':100}, '0'),
 'widthratio04': ('{% widthratio a b 100 %}', {'a':50,'b':100}, 
'50'),
 'widthratio05': ('{% widthratio a b 100 %}', {'a':100,'b':100}, 
'100'),

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

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

2011-12-17 Thread Django

#11166: {% widthratio 0 0 100 %} returns an empty string, rather than a 0
-+
 Reporter:  luddep   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Template system  |  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by aaugustin):

 * ui_ux:   => 0
 * easy:   => 0
 * stage:  Design decision needed => Accepted


Comment:

 I agree that the empty string is technically the "correct" output (the
 template engine returns nothing whenever an exception occurs), but that in
 this case "practicality beats purity".

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

59 matches

Mail list logo