Re: [Django] #16895: documentation should warn of cost of ordering

[Django]

#16895: documentation should warn of cost of ordering
-+-
   Reporter: |  Owner:  nobody
  outofculture@… | Status:  new
   Type: |  Component:  Documentation
  Cleanup/optimization   |   Severity:  Normal
  Milestone: |   Keywords:
Version: |  Has patch:  0
 Resolution: |Needs tests:  0
   Triage Stage:  Accepted   |  Easy pickings:  0
Needs documentation:  1  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by ptone):

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


Comment:

 I think the mention in the optimization docs has priority - but there
 should be some caution about the risk of having too many performance
 warnings in the API docs

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

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

[Changeset] r16882 - django/trunk/tests/modeltests/fixtures/fixtures

[noreply]

Author: PaulM
Date: 2011-09-21 22:56:47 -0700 (Wed, 21 Sep 2011)
New Revision: 16882

Added:
   django/trunk/tests/modeltests/fixtures/fixtures/invalid.json
Log:
Refs r16873 and #16026 -- Missed adding the fixture.


Added: django/trunk/tests/modeltests/fixtures/fixtures/invalid.json
===
--- django/trunk/tests/modeltests/fixtures/fixtures/invalid.json
(rev 0)
+++ django/trunk/tests/modeltests/fixtures/fixtures/invalid.json
2011-09-22 05:56:47 UTC (rev 16882)
@@ -0,0 +1,10 @@
+[
+{
+"pk": "1",
+"model": "fixtures.article",
+"fields": {
+"headline": null,
+"pub_date": "2006-06-16 13:00:00"
+}
+}
+]

-- 
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] #16877: documentation code blocks cropped on mobile browsers (was: documentation code blocks cropped on nook color)

[Django]

#16877: documentation code blocks cropped on mobile browsers
-+-
   Reporter:  dardub@…   |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Djangoproject.com
Version:  1.3|  Web site
 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
-+-

-- 
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] #16877: documentation code blocks cropped on nook color

[Django]

#16877: documentation code blocks cropped on nook color
-+-
   Reporter:  dardub@…   |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Djangoproject.com
Version:  1.3|  Web site
 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 ptone):

 * needs_better_patch:   => 0
 * component:  Documentation => Djangoproject.com Web site
 * needs_tests:   => 0
 * needs_docs:   => 0
 * ui_ux:  1 => 0
 * stage:  Unreviewed => Accepted


Comment:

 This has been a long standing problem for mobile browsers, and I assumed
 it was already in trac - but can not find anything that would justify this
 being marked as duplicate.

 For a rough, old, and inadequate solution - see an old blog post of mine:
 http://ptone.com/dablog/2009/02/reading-djangos-docs-on-iphone/

 Since this would probably need to be solved in the specific serving
 context of djangoproject.com - I'm changing the component.

-- 
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] r16881 - django/branches/releases/1.3.X/docs/topics/forms

[noreply]

Author: PaulM
Date: 2011-09-21 22:48:42 -0700 (Wed, 21 Sep 2011)
New Revision: 16881

Modified:
   django/branches/releases/1.3.X/docs/topics/forms/modelforms.txt
Log:
[1.3.X] Fixed #11674 -- Clarified docs on excluded fields of ModelForms. Thanks 
PieterSwinkels for the patch.


Modified: django/branches/releases/1.3.X/docs/topics/forms/modelforms.txt
===
--- django/branches/releases/1.3.X/docs/topics/forms/modelforms.txt 
2011-09-22 05:40:54 UTC (rev 16880)
+++ django/branches/releases/1.3.X/docs/topics/forms/modelforms.txt 
2011-09-22 05:48:42 UTC (rev 16881)
@@ -332,14 +332,18 @@
 .. note::
 
 If you specify ``fields`` or ``exclude`` when creating a form with
-``ModelForm``, then the fields that are not in the resulting form will not
-be set by the form's ``save()`` method. Django will prevent any attempt to
-save an incomplete model, so if the model does not allow the missing fields
-to be empty, and does not provide a default value for the missing fields,
-any attempt to ``save()`` a ``ModelForm`` with missing fields will fail.
-To avoid this failure, you must instantiate your model with initial values
-for the missing, but required fields::
+``ModelForm``, then the fields that are not in the resulting form
+will not be set by the form's ``save()`` method. Also, if you
+manually add the excluded fields back to the form, they will not
+be initialized from the model instance.
 
+Django will prevent any attempt to save an incomplete model, so if
+the model does not allow the missing fields to be empty, and does
+not provide a default value for the missing fields, any attempt to
+``save()`` a ``ModelForm`` with missing fields will fail.  To
+avoid this failure, you must instantiate your model with initial
+values for the missing, but required fields::
+
 author = Author(title='Mr')
 form = PartialAuthorForm(request.POST, instance=author)
 form.save()
@@ -633,6 +637,12 @@
 instance won't be saved to the database and won't be included in the return
 value (``instances``, in the above example).
 
+When fields are missing from the form (for example because they have
+been excluded), these fields will not be set by the ``save()``
+method. You can find more information about this restriction, which
+also holds for regular ``ModelForms``, in `Using a subset of fields on
+the form`_.
+
 Pass ``commit=False`` to return the unsaved model instances::
 
 # don't save to the database

-- 
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] #11674: documentation clarifications on ModelForms & ModelFormsets Meta fields

[Django]

#11674: documentation clarifications on ModelForms & ModelFormsets Meta fields
-+-
   Reporter: |  Owner:  raulcd
  david.h.haas@… | Status:  closed
   Type: |  Component:  Documentation
  Cleanup/optimization   |   Severity:  Normal
  Milestone: |   Keywords:  ModelForm, Meta
Version:  SVN|  class, easy-pickings
 Resolution:  fixed  |  Has patch:  1
   Triage Stage:  Ready for  |Needs tests:  0
  checkin|  Easy pickings:  1
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-

Comment (by PaulM):

 In [16881]:
 {{{
 #!CommitTicketReference repository="" revision="16881"
 [1.3.X] Fixed #11674 -- Clarified docs on excluded fields of ModelForms.
 Thanks PieterSwinkels for the patch.
 }}}

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

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

[Changeset] r16880 - django/branches/releases/1.3.X/docs/ref

[noreply]

Author: PaulM
Date: 2011-09-21 22:40:54 -0700 (Wed, 21 Sep 2011)
New Revision: 16880

Modified:
   django/branches/releases/1.3.X/docs/ref/signals.txt
Log:
[1.3.X] Spelling fix for r16879.


Modified: django/branches/releases/1.3.X/docs/ref/signals.txt
===
--- django/branches/releases/1.3.X/docs/ref/signals.txt 2011-09-22 05:39:07 UTC 
(rev 16879)
+++ django/branches/releases/1.3.X/docs/ref/signals.txt 2011-09-22 05:40:54 UTC 
(rev 16880)
@@ -359,7 +359,7 @@
 place: a ``management`` module in one of your :setting:`INSTALLED_APPS`. If
 handlers are registered anywhere else they may not be loaded by
 :djadmin:`syncdb`. It is important that handlers of this signal perform
-idempodent changes (e.g. no database alterations) as this may cause the
+idempotent changes (e.g. no database alterations) as this may cause the
 :djadmin:`flush` management command to fail if it also ran during the
 :djadmin:`syncdb` command.
 

-- 
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] #15633: Bad documentation of post_syncdb signal

[Django]

#15633: Bad documentation of post_syncdb signal
-+-
   Reporter:  vzima  |  Owner:  justinlilly
   Type:  Bug| Status:  closed
  Milestone: |  Component:  Documentation
Version:  SVN|   Severity:  Normal
 Resolution:  fixed  |   Keywords:
   Triage Stage:  Ready for  |  Has patch:  1
  checkin|Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-

Comment (by PaulM):

 In [16879]:
 {{{
 #!CommitTicketReference repository="" revision="16879"
 [1.3.X] Fixed #15633 -- Improved docs for post_syncdb signal. Thanks
 Justin Lilly for the patch.
 }}}

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

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

[Changeset] r16879 - django/branches/releases/1.3.X/docs/ref

[noreply]

Author: PaulM
Date: 2011-09-21 22:39:07 -0700 (Wed, 21 Sep 2011)
New Revision: 16879

Modified:
   django/branches/releases/1.3.X/docs/ref/signals.txt
Log:
[1.3.X] Fixed #15633 -- Improved docs for post_syncdb signal. Thanks Justin 
Lilly for the patch.


Modified: django/branches/releases/1.3.X/docs/ref/signals.txt
===
--- django/branches/releases/1.3.X/docs/ref/signals.txt 2011-09-22 05:36:57 UTC 
(rev 16878)
+++ django/branches/releases/1.3.X/docs/ref/signals.txt 2011-09-22 05:39:07 UTC 
(rev 16879)
@@ -352,12 +352,16 @@
 .. data:: django.db.models.signals.post_syncdb
:module:
 
-Sent by :djadmin:`syncdb` after it installs an application.
+Sent by :djadmin:`syncdb` command after it installs an application, and
+:djadmin:`flush` command.
 
 Any handlers that listen to this signal need to be written in a particular
 place: a ``management`` module in one of your :setting:`INSTALLED_APPS`. If
 handlers are registered anywhere else they may not be loaded by
-:djadmin:`syncdb`.
+:djadmin:`syncdb`. It is important that handlers of this signal perform
+idempodent changes (e.g. no database alterations) as this may cause the
+:djadmin:`flush` management command to fail if it also ran during the
+:djadmin:`syncdb` command.
 
 Arguments sent with this signal:
 

-- 
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] r16878 - in django/branches/releases/1.3.X: django/contrib/admin tests/regressiontests/admin_views

[noreply]

Author: PaulM
Date: 2011-09-21 22:36:57 -0700 (Wed, 21 Sep 2011)
New Revision: 16878

Modified:
   django/branches/releases/1.3.X/django/contrib/admin/forms.py
   django/branches/releases/1.3.X/tests/regressiontests/admin_views/tests.py
Log:
[1.3.X] Fixed #16837 -- Improved error messages for admin login. Thanks Wim 
Feijen for the patch.


Modified: django/branches/releases/1.3.X/django/contrib/admin/forms.py
===
--- django/branches/releases/1.3.X/django/contrib/admin/forms.py
2011-09-22 05:21:51 UTC (rev 16877)
+++ django/branches/releases/1.3.X/django/contrib/admin/forms.py
2011-09-22 05:36:57 UTC (rev 16878)
@@ -6,8 +6,8 @@
 
 from django.utils.translation import ugettext_lazy, ugettext as _
 
-ERROR_MESSAGE = ugettext_lazy("Please enter a correct username and password. "
-  "Note that both fields are case-sensitive.")
+ERROR_MESSAGE = ugettext_lazy("Please enter the correct username and password "
+"for a staff account. Note that both fields are case-sensitive.")
 
 class AdminAuthenticationForm(AuthenticationForm):
 """

Modified: 
django/branches/releases/1.3.X/tests/regressiontests/admin_views/tests.py
===
--- django/branches/releases/1.3.X/tests/regressiontests/admin_views/tests.py   
2011-09-22 05:21:51 UTC (rev 16877)
+++ django/branches/releases/1.3.X/tests/regressiontests/admin_views/tests.py   
2011-09-22 05:36:57 UTC (rev 16878)
@@ -38,7 +38,10 @@
 Question, Answer, Inquisition, Actor, FoodDelivery,
 RowLevelChangePermissionModel, Paper, CoverLetter, Story, OtherStory)
 
+ERROR_MESSAGE = "Please enter the correct username and password \
+for a staff account. Note that both fields are case-sensitive."
 
+
 class AdminViewBasicTest(TestCase):
 fixtures = ['admin-views-users.xml', 'admin-views-colors.xml',
 'admin-views-fabrics.xml', 'admin-views-books.xml']
@@ -638,12 +641,12 @@
 self.assertContains(login, "Your e-mail address is not your username")
 # only correct passwords get a username hint
 login = self.client.post('/test_admin/admin/', 
self.super_email_bad_login)
-self.assertContains(login, "Please enter a correct username and 
password.")
+self.assertContains(login, ERROR_MESSAGE)
 new_user = User(username='jondoe', password='secret', 
email='su...@example.com')
 new_user.save()
 # check to ensure if there are multiple e-mail addresses a user 
doesn't get a 500
 login = self.client.post('/test_admin/admin/', self.super_email_login)
-self.assertContains(login, "Please enter a correct username and 
password.")
+self.assertContains(login, ERROR_MESSAGE)
 
 # Add User
 request = self.client.get('/test_admin/admin/')
@@ -674,7 +677,7 @@
 self.assertEqual(request.status_code, 200)
 login = self.client.post('/test_admin/admin/', self.joepublic_login)
 self.assertEqual(login.status_code, 200)
-self.assertContains(login, "Please enter a correct username and 
password.")
+self.assertContains(login, ERROR_MESSAGE)
 
 # Requests without username should not return 500 errors.
 request = self.client.get('/test_admin/admin/')
@@ -1234,12 +1237,12 @@
 self.assertContains(login, "Your e-mail address is not your username")
 # only correct passwords get a username hint
 login = self.client.post('/test_admin/admin/secure-view/', 
self.super_email_bad_login)
-self.assertContains(login, "Please enter a correct username and 
password.")
+self.assertContains(login, ERROR_MESSAGE)
 new_user = User(username='jondoe', password='secret', 
email='su...@example.com')
 new_user.save()
 # check to ensure if there are multiple e-mail addresses a user 
doesn't get a 500
 login = self.client.post('/test_admin/admin/secure-view/', 
self.super_email_login)
-self.assertContains(login, "Please enter a correct username and 
password.")
+self.assertContains(login, ERROR_MESSAGE)
 
 # Add User
 request = self.client.get('/test_admin/admin/secure-view/')
@@ -1271,7 +1274,7 @@
 login = self.client.post('/test_admin/admin/secure-view/', 
self.joepublic_login)
 self.assertEqual(login.status_code, 200)
 # Login.context is a list of context dicts we just need to check the 
first one.
-self.assertContains(login, "Please enter a correct username and 
password.")
+self.assertContains(login, ERROR_MESSAGE)
 
 # 8509 - if a normal user is already logged in, it is possible
 # to change user into the superuser without error

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

Re: [Django] #16837: updated error message when logging in into the admin fails because is_staff is False

[Django]

#16837: updated error message when logging in into the admin fails because 
is_staff
is False
-+-
   Reporter:  Wim|  Owner:  wimfeijen
  Feijen  | Status:  closed
   Type:  Bug|  Component:  contrib.admin
  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:  0  |
  UI/UX:  0  |
-+-

Comment (by PaulM):

 In [16878]:
 {{{
 #!CommitTicketReference repository="" revision="16878"
 [1.3.X] Fixed #16837 -- Improved error messages for admin login. Thanks
 Wim Feijen for the patch.
 }}}

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

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

Re: [Django] #5968: Registering/Unregistering multiple models fails

[Django]

#5968: Registering/Unregistering multiple models fails
-+-
   Reporter:  anderso|  Owner:  nobody
   Type:  New| Status:  new
  feature|  Component:  contrib.databrowse
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  1
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-

Comment (by ptone):

 Databrowse is now deprecated, see #16907

 however this has a recent, solid patch, and should still be considered for
 inclusion while databrowse remains

-- 
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] #16565: An issue in databrowse's template object_detail.html

[Django]

#16565: An issue in databrowse's template object_detail.html
-+-
   Reporter:  leopku |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  contrib.databrowse
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:  databrowse,
   Triage Stage:  Ready for  |  template
  checkin|  Has patch:  1
Needs documentation:  0  |Needs tests:  1
Patch needs improvement:  1  |  Easy pickings:  0
  UI/UX:  0  |
-+-
Changes (by ptone):

 * stage:  Accepted => Ready for checkin


Comment:

 I'm wontfixing a bunch of databrowse tickets since it is now deprecated.
 However since this has a patch, and since databrowse doesn't have tests
 and is unlikely to get them, I'd propose that some simple fixes like this
 are allowed in without tests to improve databrowse during its twilight.

-- 
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] #16274: Databrowse doesn't support GeometryCollection field

[Django]

#16274: Databrowse doesn't support GeometryCollection field
-+-
   Reporter:  anonymous  |  Owner:  Satyajit
   Type:  New| Status:  closed
  feature|  Component:  contrib.databrowse
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution:  wontfix|  Has patch:  0
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by ptone):

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


Comment:

 Databrowse is now deprecated, see #16907

-- 
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] #15792: databrowse attempting to create urls out of non-models

[Django]

#15792: databrowse attempting to create urls out of non-models
-+-
   Reporter: |  Owner:  nobody
  mstefanro@…| Status:  closed
   Type:  Bug|  Component:  contrib.databrowse
  Milestone: |   Severity:  Normal
Version:  1.2|   Keywords:
 Resolution:  wontfix|  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  1
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by ptone):

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


Comment:

 Databrowse is now deprecated, see #16907

-- 
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] #15719: Write tests for databrowse

[Django]

#15719: Write tests for databrowse
-+-
   Reporter:  aaugustin  |  Owner:  nobody
   Type: | Status:  closed
  Cleanup/optimization   |  Component:  contrib.databrowse
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution:  wontfix|  Has patch:  0
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by ptone):

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


Comment:

 Databrowse is now deprecated, see #16907

-- 
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] #12188: Nullable numeric and date fields cause ValueError and ValidationError respectively in databrowse

[Django]

#12188: Nullable numeric and date fields cause ValueError and ValidationError
respectively in databrowse
-+-
   Reporter:  skyl   |  Owner:  nobody
   Type:  Bug| Status:  closed
  Milestone: |  Component:  contrib.databrowse
Version:  1.1|   Severity:  Normal
 Resolution:  wontfix|   Keywords:  databrowse null
   Triage Stage:  Accepted   |  ValueError ValidationError
Needs documentation:  0  |  Has patch:  0
Patch needs improvement:  0  |Needs tests:  0
  UI/UX:  0  |  Easy pickings:  0
-+-
Changes (by ptone):

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


Comment:

 Databrowse is now deprecated, see #16907

-- 
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] #6011: manage.py flush command not working as advertised

[Django]

#6011: manage.py flush command not working as advertised
-+-
   Reporter:  Collin |  Owner:  nobody
  Grady    | Status:  closed
   Type:  Bug|  Component:  Core (Management
  Milestone: |  commands)
Version:  SVN|   Severity:  Normal
 Resolution:  fixed  |   Keywords:
   Triage Stage:  Ready for  |  Has patch:  1
  checkin|Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by PaulM):

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


Comment:

 In [16877]:
 {{{
 #!CommitTicketReference repository="" revision="16877"
 Fixed #6011 -- Improved help text for flush command. Thanks Julien for the
 patch.
 }}}

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

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

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

[noreply]

Author: PaulM
Date: 2011-09-21 22:21:51 -0700 (Wed, 21 Sep 2011)
New Revision: 16877

Modified:
   django/trunk/django/core/management/commands/flush.py
Log:
Fixed #6011 -- Improved help text for flush command. Thanks Julien for the 
patch.


Modified: django/trunk/django/core/management/commands/flush.py
===
--- django/trunk/django/core/management/commands/flush.py   2011-09-22 
05:10:52 UTC (rev 16876)
+++ django/trunk/django/core/management/commands/flush.py   2011-09-22 
05:21:51 UTC (rev 16877)
@@ -17,7 +17,10 @@
 default=DEFAULT_DB_ALIAS, help='Nominates a database to flush. '
 'Defaults to the "default" database.'),
 )
-help = "Executes ``sqlflush`` on the current database."
+help = ('Returns the database to the state it was in immediately after '
+   'syncdb was executed. This means that all data will be removed '
+   'from the database, any post-synchronization handlers will be '
+   're-executed, and the initial_data fixture will be re-installed.')
 
 def handle_noargs(self, **options):
 db = options.get('database', DEFAULT_DB_ALIAS)

-- 
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] #9316: databrowse does not filter URL fields properly

[Django]

#9316: databrowse does not filter URL fields properly
+
   Reporter:  ishirav   |  Owner:  nobody
   Type:  Bug   | Status:  closed
  Milestone:|  Component:  contrib.databrowse
Version:  SVN   |   Severity:  Normal
 Resolution:  wontfix   |   Keywords:
   Triage Stage:  Accepted  |  Has patch:  1
Needs documentation:  0 |Needs tests:  1
Patch needs improvement:  1 |  Easy pickings:  0
  UI/UX:  0 |
+
Changes (by ptone):

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


Comment:

 Databrowse is now deprecated, see #16907

-- 
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] #8936: add databrowse-like functionality to the admin (was: Integrate databrowse functionality in to the admin)

[Django]

#8936: add databrowse-like functionality to the admin
-+---
   Reporter:  simon  |  Owner:  nobody
   Type:  New feature| Status:  new
  Milestone: |  Component:  contrib.admin
Version:  1.0|   Severity:  Normal
 Resolution: |   Keywords:  django pony
   Triage Stage:  Someday/Maybe  |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+---
Changes (by ptone):

 * component:  contrib.databrowse => contrib.admin


Comment:

 Since Databrowse is now deprecated, this should be considered as a
 proposed enhancement to the admin

 Databrowse is now deprecated, see #16907

-- 
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] #7388: Databrowse - text overlapping

[Django]

#7388: Databrowse - text overlapping
-+-
   Reporter:  Kless  |  Owner:  nobody
    | Status:  closed
   Type:  Bug|  Component:  contrib.databrowse
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:  databrowse view
 Resolution:  wontfix|  overlap
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  1  |  Easy pickings:  0
  UI/UX:  0  |
-+-
Changes (by ptone):

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


Comment:

 Databrowse is now deprecated, see #16907

-- 
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] #7135: Databrowse doesn't handle model inheritance

[Django]

#7135: Databrowse doesn't handle model inheritance
+
   Reporter:  admackin  |  Owner:  nobody
   Type:  Bug   | Status:  closed
  Milestone:|  Component:  contrib.databrowse
Version:  1.0   |   Severity:  Normal
 Resolution:  wontfix   |   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 ptone):

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


Comment:

 Databrowse is now deprecated, see #16907

-- 
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] #6946: Alphabetize DatabrowseSite index view

[Django]

#6946: Alphabetize DatabrowseSite index view
-+-
   Reporter:  anonymous  |  Owner:  nobody
   Type:  New| Status:  closed
  feature|  Component:  contrib.databrowse
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:  alphabetize, index
 Resolution:  wontfix|  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  1
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  1  |
  UI/UX:  0  |
-+-
Changes (by ptone):

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


Comment:

 Databrowse is now deprecated, see #16907

-- 
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] #6418: Databrowse not allowing download of FieldType: FileField

[Django]

#6418: Databrowse not allowing download of FieldType: FileField
-+-
   Reporter:  Manish |  Owner:  nobody
  Singh   | Status:  closed
   Type:  New|  Component:  contrib.databrowse
  feature|   Severity:  Normal
  Milestone: |   Keywords:  databrowse
Version:  SVN|  Has patch:  1
 Resolution:  wontfix|Needs tests:  1
   Triage Stage: |  Easy pickings:  0
  Someday/Maybe  |
Needs documentation:  1  |
Patch needs improvement:  1  |
  UI/UX:  0  |
-+-
Changes (by ptone):

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


Comment:

 Databrowse is now deprecated, see #16907

-- 
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] #6037: View on years-months-days in databrowse's calendar plugin

[Django]

#6037: View on years-months-days in databrowse's calendar plugin
-+-
   Reporter:  jan2ary|  Owner:  jan2ary
   Type:  New| Status:  closed
  feature|  Component:  contrib.databrowse
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:
 Resolution:  wontfix|  Has patch:  1
   Triage Stage: |Needs tests:  0
  Someday/Maybe  |  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by ptone):

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


Comment:

 Databrowse is now deprecated, see #16907

-- 
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] #4481: Databrowse should use pagination

[Django]

#4481: Databrowse should use pagination
-+-
   Reporter:  anonymous  |  Owner:  nobody
   Type: | Status:  closed
  Cleanup/optimization   |  Component:  contrib.databrowse
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:
 Resolution:  wontfix|  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  1
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by ptone):

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


Comment:

 Databrowse is now deprecated, see #16907

-- 
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] #4094: databrowse calendars do not translate the month back to english resulting in an error

[Django]

#4094: databrowse calendars do not translate the month back to english resulting
in an error
-+-
   Reporter:  lawgon |  Owner:  burzak
   | Status:  closed
   Type:  Bug|  Component:  contrib.databrowse
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:  sprintsept14
 Resolution:  wontfix|  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  1  |
  UI/UX:  0  |
-+-
Changes (by ptone):

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


Comment:

 Databrowse is now deprecated, see #16907

-- 
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] #7198: improved error message on apps without models.py files

[Django]

#7198: improved error message on apps without models.py files
-+-
   Reporter:  gav|  Owner:  justinlilly
   Type:  Bug| Status:  closed
  Milestone: |  Component:  Core (Other)
Version:  SVN|   Severity:  Normal
 Resolution:  fixed  |   Keywords:  management command
   Triage Stage:  Ready for  |  sql sqlall
  checkin|  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+-
Changes (by PaulM):

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


Comment:

 In [16876]:
 {{{
 #!CommitTicketReference repository="" revision="16876"
 Fixed #7198 -- Improved error message when missing models.py. Thanks
 Silver_Ghost and for the patch.
 }}}

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

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

[Changeset] r16876 - django/trunk/django/db/models

[noreply]

Author: PaulM
Date: 2011-09-21 22:10:52 -0700 (Wed, 21 Sep 2011)
New Revision: 16876

Modified:
   django/trunk/django/db/models/loading.py
Log:
Fixed #7198 -- Improved error message when missing models.py. Thanks 
Silver_Ghost and for the patch.


Modified: django/trunk/django/db/models/loading.py
===
--- django/trunk/django/db/models/loading.py2011-09-22 04:52:43 UTC (rev 
16875)
+++ django/trunk/django/db/models/loading.py2011-09-22 05:10:52 UTC (rev 
16876)
@@ -146,6 +146,7 @@
 if mod is None:
 if emptyOK:
 return None
+raise ImproperlyConfigured("App with label %s is 
missing a models.py module.")
 else:
 return mod
 raise ImproperlyConfigured("App with label %s could not be found" 
% app_label)

-- 
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] #11674: documentation clarifications on ModelForms & ModelFormsets Meta fields

[Django]

#11674: documentation clarifications on ModelForms & ModelFormsets Meta fields
-+-
   Reporter: |  Owner:  raulcd
  david.h.haas@… | Status:  closed
   Type: |  Component:  Documentation
  Cleanup/optimization   |   Severity:  Normal
  Milestone: |   Keywords:  ModelForm, Meta
Version:  SVN|  class, easy-pickings
 Resolution:  fixed  |  Has patch:  1
   Triage Stage:  Ready for  |Needs tests:  0
  checkin|  Easy pickings:  1
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by PaulM):

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


Comment:

 Fixed this in r16875. Thanks for the patch!

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

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

[Changeset] r16875 - django/trunk/docs/topics/forms

[noreply]

Author: PaulM
Date: 2011-09-21 21:52:43 -0700 (Wed, 21 Sep 2011)
New Revision: 16875

Modified:
   django/trunk/docs/topics/forms/modelforms.txt
Log:
Fixed 11674 -- Clarified docs on excluded fields of ModelForms.


Modified: django/trunk/docs/topics/forms/modelforms.txt
===
--- django/trunk/docs/topics/forms/modelforms.txt   2011-09-22 04:36:15 UTC 
(rev 16874)
+++ django/trunk/docs/topics/forms/modelforms.txt   2011-09-22 04:52:43 UTC 
(rev 16875)
@@ -331,14 +331,18 @@
 .. note::
 
 If you specify ``fields`` or ``exclude`` when creating a form with
-``ModelForm``, then the fields that are not in the resulting form will not
-be set by the form's ``save()`` method. Django will prevent any attempt to
-save an incomplete model, so if the model does not allow the missing fields
-to be empty, and does not provide a default value for the missing fields,
-any attempt to ``save()`` a ``ModelForm`` with missing fields will fail.
-To avoid this failure, you must instantiate your model with initial values
-for the missing, but required fields::
+``ModelForm``, then the fields that are not in the resulting form
+will not be set by the form's ``save()`` method. Also, if you
+manually add the excluded fields back to the form, they will not
+be initialized from the model instance.
 
+Django will prevent any attempt to save an incomplete model, so if
+the model does not allow the missing fields to be empty, and does
+not provide a default value for the missing fields, any attempt to
+``save()`` a ``ModelForm`` with missing fields will fail.  To
+avoid this failure, you must instantiate your model with initial
+values for the missing, but required fields::
+
 author = Author(title='Mr')
 form = PartialAuthorForm(request.POST, instance=author)
 form.save()
@@ -632,6 +636,12 @@
 instance won't be saved to the database and won't be included in the return
 value (``instances``, in the above example).
 
+When fields are missing from the form (for example because they have
+been excluded), these fields will not be set by the ``save()``
+method. You can find more information about this restriction, which
+also holds for regular ``ModelForms``, in `Using a subset of fields on
+the form`_.
+
 Pass ``commit=False`` to return the unsaved model instances::
 
 # don't save to the database

-- 
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] #15633: Bad documentation of post_syncdb signal

[Django]

#15633: Bad documentation of post_syncdb signal
-+-
   Reporter:  vzima  |  Owner:  justinlilly
   Type:  Bug| Status:  closed
  Milestone: |  Component:  Documentation
Version:  SVN|   Severity:  Normal
 Resolution:  fixed  |   Keywords:
   Triage Stage:  Ready for  |  Has patch:  1
  checkin|Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by PaulM):

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


Comment:

 In [16874]:
 {{{
 #!CommitTicketReference repository="" revision="16874"
 Fixed #15633 -- Improved docs for post_syncdb signal.
 }}}

-- 
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] r16874 - django/trunk/docs/ref

[noreply]

Author: PaulM
Date: 2011-09-21 21:36:15 -0700 (Wed, 21 Sep 2011)
New Revision: 16874

Modified:
   django/trunk/docs/ref/signals.txt
Log:
Fixed #15633 -- Improved docs for post_syncdb signal.


Modified: django/trunk/docs/ref/signals.txt
===
--- django/trunk/docs/ref/signals.txt   2011-09-22 04:30:20 UTC (rev 16873)
+++ django/trunk/docs/ref/signals.txt   2011-09-22 04:36:15 UTC (rev 16874)
@@ -365,12 +365,16 @@
 .. data:: django.db.models.signals.post_syncdb
:module:
 
-Sent by :djadmin:`syncdb` after it installs an application.
+Sent by :djadmin:`syncdb` command after it installs an application, and
+:djadmin:`flush` command.
 
 Any handlers that listen to this signal need to be written in a particular
 place: a ``management`` module in one of your :setting:`INSTALLED_APPS`. If
 handlers are registered anywhere else they may not be loaded by
-:djadmin:`syncdb`.
+:djadmin:`syncdb`. It is important that handlers of this signal perform
+idempotent changes (e.g. no database alterations) as this may cause the
+:djadmin:`flush` management command to fail if it also ran during the
+:djadmin:`syncdb` command.
 
 Arguments sent with this signal:
 

-- 
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] r16873 - in django/trunk: django/core/management/commands tests/modeltests/fixtures

[noreply]

Author: PaulM
Date: 2011-09-21 21:30:20 -0700 (Wed, 21 Sep 2011)
New Revision: 16873

Modified:
   django/trunk/django/core/management/commands/loaddata.py
   django/trunk/tests/modeltests/fixtures/tests.py
Log:
Fixed #16026 -- loaddata now identifies which object triggered an error.


Modified: django/trunk/django/core/management/commands/loaddata.py
===
--- django/trunk/django/core/management/commands/loaddata.py2011-09-22 
04:16:21 UTC (rev 16872)
+++ django/trunk/django/core/management/commands/loaddata.py2011-09-22 
04:30:20 UTC (rev 16873)
@@ -12,7 +12,8 @@
 from django.core import serializers
 from django.core.management.base import BaseCommand
 from django.core.management.color import no_style
-from django.db import connections, router, transaction, DEFAULT_DB_ALIAS
+from django.db import (connections, router, transaction, DEFAULT_DB_ALIAS,
+  IntegrityError, DatabaseError)
 from django.db.models import get_apps
 from django.utils.itercompat import product
 
@@ -177,7 +178,16 @@
 if router.allow_syncdb(using, 
obj.object.__class__):
 loaded_objects_in_fixture += 1
 models.add(obj.object.__class__)
-obj.save(using=using)
+try:
+obj.save(using=using)
+except (DatabaseError, 
IntegrityError), e:
+msg = "Could not load 
%(app_label)s.%(object_name)s(pk=%(pk)s): %(error_msg)s" % {
+'app_label': 
obj.object._meta.app_label,
+'object_name': 
obj.object._meta.object_name,
+'pk': obj.object.pk,
+'error_msg': e
+}
+raise e.__class__, 
e.__class__(msg), sys.exc_info()[2]
 
 # Since we disabled constraint checks, we must 
manually check for
 # any invalid keys that might have been added

Modified: django/trunk/tests/modeltests/fixtures/tests.py
===
--- django/trunk/tests/modeltests/fixtures/tests.py 2011-09-22 04:16:21 UTC 
(rev 16872)
+++ django/trunk/tests/modeltests/fixtures/tests.py 2011-09-22 04:30:20 UTC 
(rev 16873)
@@ -252,6 +252,17 @@
 ''
 ])
 
+def test_loaddata_error_message(self):
+"""
+Verifies that loading a fixture which contains an invalid object
+outputs an error message which contains the pk of the object
+that triggered the error.
+"""
+new_io = StringIO.StringIO()
+management.call_command('loaddata', 'invalid.json', verbosity=0, 
stderr=new_io, commit=False)
+output = new_io.getvalue().strip().split('\n')
+self.assertRegexpMatches(output[-1], "IntegrityError: Could not load 
fixtures.Article\(pk=1\): .*$")
+
 def test_loading_using(self):
 # Load db fixtures 1 and 2. These will load using the 'default' 
database identifier explicitly
 management.call_command('loaddata', 'db_fixture_1', verbosity=0, 
using='default', commit=False)

-- 
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] #16026: Inform user which object triggered error in loaddata

[Django]

#16026: Inform user which object triggered error in loaddata
-+-
   Reporter: |  Owner:  gabrielhurley
  gabrielhurley  | Status:  closed
   Type:  New|  Component:  Core (Management
  feature|  commands)
  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:  0  |
  UI/UX:  0  |
-+-
Changes (by PaulM):

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


Comment:

 In [16873]:
 {{{
 #!CommitTicketReference repository="" revision="16873"
 Fixed #16026 -- loaddata now identifies which object triggered an error.
 }}}

-- 
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] #15894: SITE_CACHE does not invalidate in multiprocess environments

[Django]

#15894: SITE_CACHE does not invalidate in multiprocess environments
+
   Reporter:  Kronuz|  Owner:  fcurella
   Type:  Bug   | Status:  new
  Milestone:|  Component:  contrib.sites
Version:  1.3   |   Severity:  Normal
 Resolution:|   Keywords:  cache invalidation
   Triage Stage:  Accepted  |  Has patch:  1
Needs documentation:  1 |Needs tests:  0
Patch needs improvement:  1 |  Easy pickings:  0
  UI/UX:  0 |
+
Changes (by PaulM):

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


Comment:

 The docs are a start, but I think we probably need a bit more than that,
 as well as an entry in the changelog. Using `sleep()` in the tests is
 probably not the best way to do it... no matter how fast everything else
 runs, that test will take at least as long as your sleep statement. Can
 you use a `yield` instead to get the same effect?

-- 
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] #16892: Allow class based view 'cache_timeout' to control middleware.

[Django]

#16892: Allow class based view 'cache_timeout' to control middleware.
---+---
   Reporter:  rob@…|  Owner:  nobody
   Type:  New feature  | Status:  closed
  Milestone:   |  Component:  Generic views
Version:  1.3  |   Severity:  Normal
 Resolution:  duplicate|   Keywords:  CBV Cache
   Triage Stage:  Unreviewed   |  Has patch:  1
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+---
Changes (by ptone):

 * status:  new => closed
 * cc: preston@… (added)
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0
 * resolution:   => duplicate


Comment:

 This is really a specific case of #14512, in particular, the issue of
 representing decorator parameters as inheritable class attribute

-- 
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] r16872 - in django/trunk: django/contrib/admin tests/regressiontests/admin_views

[noreply]

Author: PaulM
Date: 2011-09-21 21:16:21 -0700 (Wed, 21 Sep 2011)
New Revision: 16872

Modified:
   django/trunk/django/contrib/admin/forms.py
   django/trunk/tests/regressiontests/admin_views/tests.py
Log:
Fixed #16837 -- Improved error message for admin login.


Modified: django/trunk/django/contrib/admin/forms.py
===
--- django/trunk/django/contrib/admin/forms.py  2011-09-22 04:10:02 UTC (rev 
16871)
+++ django/trunk/django/contrib/admin/forms.py  2011-09-22 04:16:21 UTC (rev 
16872)
@@ -6,8 +6,8 @@
 
 from django.utils.translation import ugettext_lazy, ugettext as _
 
-ERROR_MESSAGE = ugettext_lazy("Please enter a correct username and password. "
-  "Note that both fields are case-sensitive.")
+ERROR_MESSAGE = ugettext_lazy("Please enter the correct username and password "
+"for a staff account. Note that both fields are case-sensitive.")
 
 class AdminAuthenticationForm(AuthenticationForm):
 """

Modified: django/trunk/tests/regressiontests/admin_views/tests.py
===
--- django/trunk/tests/regressiontests/admin_views/tests.py 2011-09-22 
04:10:02 UTC (rev 16871)
+++ django/trunk/tests/regressiontests/admin_views/tests.py 2011-09-22 
04:16:21 UTC (rev 16872)
@@ -40,7 +40,10 @@
 RowLevelChangePermissionModel, Paper, CoverLetter, Story, OtherStory,
 ComplexSortedPerson, Parent, Child)
 
+ERROR_MESSAGE = "Please enter the correct username and password \
+for a staff account. Note that both fields are case-sensitive."
 
+
 class AdminViewBasicTest(TestCase):
 fixtures = ['admin-views-users.xml', 'admin-views-colors.xml',
 'admin-views-fabrics.xml', 'admin-views-books.xml']
@@ -761,12 +764,12 @@
 self.assertContains(login, "Your e-mail address is not your username")
 # only correct passwords get a username hint
 login = self.client.post('/test_admin/admin/', 
self.super_email_bad_login)
-self.assertContains(login, "Please enter a correct username and 
password.")
+self.assertContains(login, ERROR_MESSAGE)
 new_user = User(username='jondoe', password='secret', 
email='su...@example.com')
 new_user.save()
 # check to ensure if there are multiple e-mail addresses a user 
doesn't get a 500
 login = self.client.post('/test_admin/admin/', self.super_email_login)
-self.assertContains(login, "Please enter a correct username and 
password.")
+self.assertContains(login, ERROR_MESSAGE)
 
 # Add User
 request = self.client.get('/test_admin/admin/')
@@ -797,7 +800,7 @@
 self.assertEqual(request.status_code, 200)
 login = self.client.post('/test_admin/admin/', self.joepublic_login)
 self.assertEqual(login.status_code, 200)
-self.assertContains(login, "Please enter a correct username and 
password.")
+self.assertContains(login, ERROR_MESSAGE)
 
 # Requests without username should not return 500 errors.
 request = self.client.get('/test_admin/admin/')
@@ -1360,12 +1363,12 @@
 self.assertContains(login, "Your e-mail address is not your username")
 # only correct passwords get a username hint
 login = self.client.post('/test_admin/admin/secure-view/', 
self.super_email_bad_login)
-self.assertContains(login, "Please enter a correct username and 
password.")
+self.assertContains(login, ERROR_MESSAGE)
 new_user = User(username='jondoe', password='secret', 
email='su...@example.com')
 new_user.save()
 # check to ensure if there are multiple e-mail addresses a user 
doesn't get a 500
 login = self.client.post('/test_admin/admin/secure-view/', 
self.super_email_login)
-self.assertContains(login, "Please enter a correct username and 
password.")
+self.assertContains(login, ERROR_MESSAGE)
 
 # Add User
 request = self.client.get('/test_admin/admin/secure-view/')
@@ -1397,7 +1400,7 @@
 login = self.client.post('/test_admin/admin/secure-view/', 
self.joepublic_login)
 self.assertEqual(login.status_code, 200)
 # Login.context is a list of context dicts we just need to check the 
first one.
-self.assertContains(login, "Please enter a correct username and 
password.")
+self.assertContains(login, ERROR_MESSAGE)
 
 # 8509 - if a normal user is already logged in, it is possible
 # to change user into the superuser without error

-- 
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] #16837: updated error message when logging in into the admin fails because is_staff is False

[Django]

#16837: updated error message when logging in into the admin fails because 
is_staff
is False
-+-
   Reporter:  Wim|  Owner:  wimfeijen
  Feijen  | Status:  closed
   Type:  Bug|  Component:  contrib.admin
  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:  0  |
  UI/UX:  0  |
-+-
Changes (by PaulM):

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


Comment:

 In [16872]:
 {{{
 #!CommitTicketReference repository="" revision="16872"
 Fixed #16837 -- Improved error message for admin login.
 }}}

-- 
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] #16907: Deprecate databrowse

[Django]

#16907: Deprecate databrowse
-+-
   Reporter:  ptone  |  Owner:  nobody
   Type: | Status:  closed
  Cleanup/optimization   |  Component:  contrib.databrowse
  Milestone:  1.4|   Severity:  Normal
Version:  SVN|   Keywords:
 Resolution:  fixed  |  Has patch:  1
   Triage Stage:  Ready for  |Needs tests:  0
  checkin|  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  1  |
  UI/UX:  0  |
-+-
Changes (by PaulM):

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


Comment:

 In [16871]:
 {{{
 #!CommitTicketReference repository="" revision="16871"
 Fixed #16907 -- Deprecate databrowse.
 }}}

-- 
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] r16871 - in django/trunk: django/contrib/databrowse docs/ref/contrib docs/releases

[noreply]

Author: PaulM
Date: 2011-09-21 21:10:02 -0700 (Wed, 21 Sep 2011)
New Revision: 16871

Modified:
   django/trunk/django/contrib/databrowse/__init__.py
   django/trunk/docs/ref/contrib/databrowse.txt
   django/trunk/docs/releases/1.4.txt
Log:
Fixed #16907 -- Deprecate databrowse.


Modified: django/trunk/django/contrib/databrowse/__init__.py
===
--- django/trunk/django/contrib/databrowse/__init__.py  2011-09-22 00:58:42 UTC 
(rev 16870)
+++ django/trunk/django/contrib/databrowse/__init__.py  2011-09-22 04:10:02 UTC 
(rev 16871)
@@ -1 +1,6 @@
+import warnings
 from django.contrib.databrowse.sites import DatabrowsePlugin, ModelDatabrowse, 
DatabrowseSite, site
+
+
+warnings.warn("The Databrowse contrib app is deprecated",
+PendingDeprecationWarning)

Modified: django/trunk/docs/ref/contrib/databrowse.txt
===
--- django/trunk/docs/ref/contrib/databrowse.txt2011-09-22 00:58:42 UTC 
(rev 16870)
+++ django/trunk/docs/ref/contrib/databrowse.txt2011-09-22 04:10:02 UTC 
(rev 16871)
@@ -5,21 +5,15 @@
 .. module:: django.contrib.databrowse
:synopsis: Databrowse is a Django application that lets you browse your 
data.
 
+.. deprecated:: 1.4
+This module has been deprecated.
+
 Databrowse is a Django application that lets you browse your data.
 
 As the Django admin dynamically creates an admin interface by introspecting
 your models, Databrowse dynamically creates a rich, browsable Web site by
 introspecting your models.
 
-.. admonition:: Note
-
-Databrowse is **very** new and is currently under active development. It
-may change substantially before the next Django release.
-
-With that said, it's easy to use, and it doesn't require writing any
-code. So you can play around with it today, with very little investment in
-time or coding.
-
 How to use Databrowse
 =
 

Modified: django/trunk/docs/releases/1.4.txt
===
--- django/trunk/docs/releases/1.4.txt  2011-09-22 00:58:42 UTC (rev 16870)
+++ django/trunk/docs/releases/1.4.txt  2011-09-22 04:10:02 UTC (rev 16871)
@@ -640,3 +640,19 @@
 were located in a ``django.conf.urls.defaults`` module.
 
 Starting with Django 1.4 they are now available in :mod:`django.conf.urls`.
+
+``django.contrib.databrowse``
+~
+
+Databrowse has not seen active development for some time, and this does not
+show any sign of changing. There had been a suggestion for a GSOC project to
+integrate the functionality of databrowse into the admin, but no progress was
+made. While Databrowse has been deprecated, an enhancement of
+django.contrib.admin providing a similar feature set is still possible.
+
+.. _GSOC Proposal: 
https://code.djangoproject.com/wiki/SummerOfCode2011#Integratedatabrowseintotheadmin
+
+The code that powers Databrowse is licensed under the same terms as Django
+itself, and so is available to be adopted by an individual or group as
+a third-party project.
+

-- 
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] #14678: Users are able to add more than one page to the same url

[Django]

#14678: Users are able to add more than one page to the same url
-+-
   Reporter:  seler  |  Owner:  j4nu5
   Type:  Bug| Status:  assigned
  Milestone: |  Component:  contrib.flatpages
Version:  SVN|   Severity:  Normal
 Resolution: |   Keywords:  flatpages, unique,
   Triage Stage:  Accepted   |  sites
Needs documentation:  1  |  Has patch:  1
Patch needs improvement:  1  |Needs tests:  0
  UI/UX:  0  |  Easy pickings:  1
-+-
Changes (by ptone):

 * needs_better_patch:  0 => 1
 * stage:  Design decision needed => Accepted
 * milestone:  1.4 =>


Comment:

 While unique together may not currently work with M2M - it could be said
 that this ticket is just a specific case of #702

 Either way a signal is the wrong way to handle this, this should be done
 by overriding validate_unique in the FlatPage model, which could be done
 in this case because we do not need to solve unique_together for all cases
 of M2M.  comment 9 in incorrect in that unique_together is not enforced at
 the database level (that is unique), and so the model validation code path
 is the only way to handle this.

 A procedural note, the issue is a real issue, as such it is accepted.
 Design Decision Needed should, to quote the documentation: 'This stage is
 for issues which may be contentious, may be backwards incompatible, or
 otherwise involve high-level design decisions.'  There is some nuance on
 when that test is met, but there is some push to reserve DDN only for
 those issues which truly need significant core braintrust to be involved.

-- 
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] #16907: Deprecate databrowse

[Django]

#16907: Deprecate databrowse
-+-
   Reporter:  ptone  |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |  Component:  contrib.databrowse
  Milestone:  1.4|   Severity:  Normal
Version:  SVN|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage:  Ready for  |Needs tests:  0
  checkin|  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  1  |
  UI/UX:  0  |
-+-
Changes (by ptone):

 * stage:  Accepted => Ready for checkin


Comment:

 tweaks made - self marking RFC per suggestion from SmileyChris - committer
 may choose to further refine release note if desired.

-- 
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] #16212: Improve multiple sort UX

[Django]

#16212: Improve multiple sort UX
---+---
   Reporter:  idangazit|  Owner:  nobody
   Type:  New feature  | Status:  new
  Milestone:   |  Component:  contrib.admin
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:  1|
---+---

Comment (by julien):

 Glad you like it! I've just posted the last patch. I'll do a bit more
 testing in different browsers and will commit it when I get round to it
 within a couple of days. Feel free to run it through some testing too if
 you'd like.

-- 
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] #16907: Deprecate databrowse

[Django]

#16907: Deprecate databrowse
-+-
   Reporter:  ptone  |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |  Component:  contrib.databrowse
  Milestone:  1.4|   Severity:  Normal
Version:  SVN|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  1  |
  UI/UX:  0  |
-+-
Changes (by SmileyChris):

 * needs_better_patch:  0 => 1
 * milestone:   => 1.4
 * stage:  Unreviewed => Accepted


Comment:

 Minor tweaks to docs still required, but after those, feel free to promote
 to Ready for Checkin yourself.

-- 
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] r16870 - django/branches/releases/1.3.X/docs/ref/contrib/gis

[noreply]

Author: PaulM
Date: 2011-09-21 17:58:42 -0700 (Wed, 21 Sep 2011)
New Revision: 16870

Modified:
   django/branches/releases/1.3.X/docs/ref/contrib/gis/geoip.txt
Log:
[1.3.X] backport minor docs fix for GeoIP


Modified: django/branches/releases/1.3.X/docs/ref/contrib/gis/geoip.txt
===
--- django/branches/releases/1.3.X/docs/ref/contrib/gis/geoip.txt   
2011-09-21 22:58:15 UTC (rev 16869)
+++ django/branches/releases/1.3.X/docs/ref/contrib/gis/geoip.txt   
2011-09-22 00:58:42 UTC (rev 16870)
@@ -144,7 +144,7 @@
 Returns a dictionary of city information for the given query.  Some
 of the values in the dictionary may be undefined (``None``).
 
-.. method:: GeoIPcountry(query)
+.. method:: GeoIP.country(query)
 
 Returns a dictionary with the country code and country for the given 
 query.

-- 
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] #16908: Broken image url

[Django]

#16908: Broken image url
--+---
   Reporter:  sony.fermino@…  |  Owner:  nobody
   Type:  Bug | Status:  closed
  Milestone:  |  Component:  Documentation
Version:  1.3 |   Severity:  Normal
 Resolution:  invalid |   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 anonymous):

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


Comment:

 The Djangobook is not an official resource, nor does this ticket tracker
 cover it.  Please use the contact links provided on its 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.

[Django] #16908: Broken image url

[Django]

#16908: Broken image url
+---
 Reporter:  sony.fermino@…  |  Owner:  nobody
 Type:  Bug | Status:  new
Milestone:  |  Component:  Documentation
  Version:  1.3 |   Severity:  Normal
 Keywords:  |   Triage Stage:  Unreviewed
Has patch:  0   |  Easy pickings:  0
UI/UX:  0   |
+---
 The broken url is:
 http://media.djangobook.com/content/chapter21/scaling-1.jpg
 (among other images).

 It's referred to in:
 http://www.djangobook.com/en/beta/chapter21/

 Please, make me know when ready; I'm curious to see that image. :)

 Best regards,
 Sony Santos

-- 
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] r16869 - in django/branches/releases/1.3.X/django: contrib/gis/db/backends/spatialite contrib/sites db/backends

[noreply]

Author: carljm
Date: 2011-09-21 15:58:15 -0700 (Wed, 21 Sep 2011)
New Revision: 16869

Modified:
   
django/branches/releases/1.3.X/django/contrib/gis/db/backends/spatialite/creation.py
   django/branches/releases/1.3.X/django/contrib/sites/management.py
   django/branches/releases/1.3.X/django/db/backends/creation.py
Log:
[1.3.X] Fixed #16353 -- don't try to create Site objects on all databases. Refs 
#15573, #15346. Thanks Aymeric Augustin for the report and the patch.

Backport of r16868 in trunk.

Modified: 
django/branches/releases/1.3.X/django/contrib/gis/db/backends/spatialite/creation.py
===
--- 
django/branches/releases/1.3.X/django/contrib/gis/db/backends/spatialite/creation.py
2011-09-21 22:46:48 UTC (rev 16868)
+++ 
django/branches/releases/1.3.X/django/contrib/gis/db/backends/spatialite/creation.py
2011-09-21 22:58:15 UTC (rev 16869)
@@ -56,14 +56,6 @@
 interactive=False,
 database=self.connection.alias)
 
-# One effect of calling syncdb followed by flush is that the id of the
-# default site may or may not be 1, depending on how the sequence was
-# reset.  If the sites app is loaded, then we coerce it.
-from django.db.models import get_model
-Site = get_model('sites', 'Site')
-if Site is not None and 
Site.objects.using(self.connection.alias).count() == 1:
-
Site.objects.using(self.connection.alias).update(id=settings.SITE_ID)
-
 from django.core.cache import get_cache
 from django.core.cache.backends.db import BaseDatabaseCache
 for cache_alias in settings.CACHES:

Modified: django/branches/releases/1.3.X/django/contrib/sites/management.py
===
--- django/branches/releases/1.3.X/django/contrib/sites/management.py   
2011-09-21 22:46:48 UTC (rev 16868)
+++ django/branches/releases/1.3.X/django/contrib/sites/management.py   
2011-09-21 22:58:15 UTC (rev 16869)
@@ -3,14 +3,21 @@
 """
 
 from django.db.models import signals
+from django.db import router
 from django.contrib.sites.models import Site
 from django.contrib.sites import models as site_app
 
 def create_default_site(app, created_models, verbosity, db, **kwargs):
-if Site in created_models:
+# Only create the default sites in databases where Django created the table
+if Site in created_models and router.allow_syncdb(db, Site) :
 if verbosity >= 2:
 print "Creating example.com Site object"
-s = Site(domain="example.com", name="example.com")
+# The default settings set SITE_ID = 1, and some tests in Django's test
+# suite rely on this value. However, if database sequences are reused
+# (e.g. in the test suite after flush/syncdb), it isn't guaranteed that
+# the next id will be 1, so we coerce it. See #15573 and #16353. This
+# can also crop up outside of tests - see #15346.
+s = Site(pk=1, domain="example.com", name="example.com")
 s.save(using=db)
 Site.objects.clear_cache()
 

Modified: django/branches/releases/1.3.X/django/db/backends/creation.py
===
--- django/branches/releases/1.3.X/django/db/backends/creation.py   
2011-09-21 22:46:48 UTC (rev 16868)
+++ django/branches/releases/1.3.X/django/db/backends/creation.py   
2011-09-21 22:58:15 UTC (rev 16869)
@@ -374,15 +374,6 @@
 verbosity=max(verbosity - 1, 0),
 interactive=False,
 database=self.connection.alias)
-
-# One effect of calling syncdb followed by flush is that the id of the
-# default site may or may not be 1, depending on how the sequence was
-# reset.  If the sites app is loaded, then we coerce it.
-from django.db.models import get_model
-if 'django.contrib.sites' in settings.INSTALLED_APPS:
-Site = get_model('sites', 'Site')
-if Site is not None and 
Site.objects.using(self.connection.alias).count() == 1:
-
Site.objects.using(self.connection.alias).update(id=settings.SITE_ID)
 
 from django.core.cache import get_cache
 from django.core.cache.backends.db import BaseDatabaseCache

-- 
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] #16353: With multi-databases, if django.contrib.sites.models.Site is not synchronized on all databases, Django's tests fail

[Django]

#16353: With multi-databases, if django.contrib.sites.models.Site is not
synchronized on all databases, Django's tests fail
-+---
   Reporter:  aaugustin  |  Owner:  nobody
   Type:  Bug| Status:  closed
  Milestone: |  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 carljm):

 In [16869]:
 {{{
 #!CommitTicketReference repository="" revision="16869"
 [1.3.X] Fixed #16353 -- don't try to create Site objects on all databases.
 Refs #15573, #15346. Thanks Aymeric Augustin for the report and the patch.

 Backport of r16868 in trunk.
 }}}

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

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

Re: [Django] #15573: runtests.py sets incorrect SITE_ID when using Oracle

[Django]

#15573: runtests.py sets incorrect SITE_ID when using Oracle
+---
   Reporter:  ikelly|  Owner:  nobody
   Type:  Bug   | Status:  closed
  Milestone:|  Component:  Testing framework
Version:  SVN   |   Severity:  Normal
 Resolution:  fixed |   Keywords:  oracle site_id
   Triage Stage:  Accepted  |  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
+---

Comment (by carljm):

 In [16869]:
 {{{
 #!CommitTicketReference repository="" revision="16869"
 [1.3.X] Fixed #16353 -- don't try to create Site objects on all databases.
 Refs #15573, #15346. Thanks Aymeric Augustin for the report and the patch.

 Backport of r16868 in trunk.
 }}}

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

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

Re: [Django] #15346: SITE_ID default value is wrong

[Django]

#15346: SITE_ID default value is wrong
--+
   Reporter:  depaolim|Owner:  nobody
   Type:  |   Status:  closed
  Milestone:  |Component:  Contrib apps
Version:  1.2 | Severity:
 Resolution:  worksforme  | Keywords:  SITE_ID
   Triage Stage:  Unreviewed  |Has patch:  0
Needs documentation:  0   |  Needs tests:  0
Patch needs improvement:  0   |
--+

Comment (by carljm):

 In [16869]:
 {{{
 #!CommitTicketReference repository="" revision="16869"
 [1.3.X] Fixed #16353 -- don't try to create Site objects on all databases.
 Refs #15573, #15346. Thanks Aymeric Augustin for the report and the patch.

 Backport of r16868 in trunk.
 }}}

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

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

Re: [Django] #15346: SITE_ID default value is wrong

[Django]

#15346: SITE_ID default value is wrong
--+
   Reporter:  depaolim|Owner:  nobody
   Type:  |   Status:  closed
  Milestone:  |Component:  Contrib apps
Version:  1.2 | Severity:
 Resolution:  worksforme  | Keywords:  SITE_ID
   Triage Stage:  Unreviewed  |Has patch:  0
Needs documentation:  0   |  Needs tests:  0
Patch needs improvement:  0   |
--+

Comment (by carljm):

 In [16868]:
 {{{
 #!CommitTicketReference repository="" revision="16868"
 Fixed #16353 -- don't try to create Site objects on all databases. Refs
 #15573, #15346. Thanks Aymeric Augustin for the report and the patch.
 }}}

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

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

Re: [Django] #16353: With multi-databases, if django.contrib.sites.models.Site is not synchronized on all databases, Django's tests fail

[Django]

#16353: With multi-databases, if django.contrib.sites.models.Site is not
synchronized on all databases, Django's tests fail
-+---
   Reporter:  aaugustin  |  Owner:  nobody
   Type:  Bug| Status:  closed
  Milestone: |  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  |
-+---
Changes (by carljm):

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


Comment:

 In [16868]:
 {{{
 #!CommitTicketReference repository="" revision="16868"
 Fixed #16353 -- don't try to create Site objects on all databases. Refs
 #15573, #15346. Thanks Aymeric Augustin for the report and the patch.
 }}}

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

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

Re: [Django] #15573: runtests.py sets incorrect SITE_ID when using Oracle

[Django]

#15573: runtests.py sets incorrect SITE_ID when using Oracle
+---
   Reporter:  ikelly|  Owner:  nobody
   Type:  Bug   | Status:  closed
  Milestone:|  Component:  Testing framework
Version:  SVN   |   Severity:  Normal
 Resolution:  fixed |   Keywords:  oracle site_id
   Triage Stage:  Accepted  |  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
+---

Comment (by carljm):

 In [16868]:
 {{{
 #!CommitTicketReference repository="" revision="16868"
 Fixed #16353 -- don't try to create Site objects on all databases. Refs
 #15573, #15346. Thanks Aymeric Augustin for the report and the patch.
 }}}

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

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

[Changeset] r16868 - in django/trunk/django: contrib/gis/db/backends/spatialite contrib/sites db/backends

[noreply]

Author: carljm
Date: 2011-09-21 15:46:48 -0700 (Wed, 21 Sep 2011)
New Revision: 16868

Modified:
   django/trunk/django/contrib/gis/db/backends/spatialite/creation.py
   django/trunk/django/contrib/sites/management.py
   django/trunk/django/db/backends/creation.py
Log:
Fixed #16353 -- don't try to create Site objects on all databases. Refs #15573, 
#15346. Thanks Aymeric Augustin for the report and the patch.

Modified: django/trunk/django/contrib/gis/db/backends/spatialite/creation.py
===
--- django/trunk/django/contrib/gis/db/backends/spatialite/creation.py  
2011-09-21 22:45:25 UTC (rev 16867)
+++ django/trunk/django/contrib/gis/db/backends/spatialite/creation.py  
2011-09-21 22:46:48 UTC (rev 16868)
@@ -56,14 +56,6 @@
 interactive=False,
 database=self.connection.alias)
 
-# One effect of calling syncdb followed by flush is that the id of the
-# default site may or may not be 1, depending on how the sequence was
-# reset.  If the sites app is loaded, then we coerce it.
-from django.db.models import get_model
-Site = get_model('sites', 'Site')
-if Site is not None and 
Site.objects.using(self.connection.alias).count() == 1:
-
Site.objects.using(self.connection.alias).update(id=settings.SITE_ID)
-
 from django.core.cache import get_cache
 from django.core.cache.backends.db import BaseDatabaseCache
 for cache_alias in settings.CACHES:

Modified: django/trunk/django/contrib/sites/management.py
===
--- django/trunk/django/contrib/sites/management.py 2011-09-21 22:45:25 UTC 
(rev 16867)
+++ django/trunk/django/contrib/sites/management.py 2011-09-21 22:46:48 UTC 
(rev 16868)
@@ -3,14 +3,21 @@
 """
 
 from django.db.models import signals
+from django.db import router
 from django.contrib.sites.models import Site
 from django.contrib.sites import models as site_app
 
 def create_default_site(app, created_models, verbosity, db, **kwargs):
-if Site in created_models:
+# Only create the default sites in databases where Django created the table
+if Site in created_models and router.allow_syncdb(db, Site) :
 if verbosity >= 2:
 print "Creating example.com Site object"
-s = Site(domain="example.com", name="example.com")
+# The default settings set SITE_ID = 1, and some tests in Django's test
+# suite rely on this value. However, if database sequences are reused
+# (e.g. in the test suite after flush/syncdb), it isn't guaranteed that
+# the next id will be 1, so we coerce it. See #15573 and #16353. This
+# can also crop up outside of tests - see #15346.
+s = Site(pk=1, domain="example.com", name="example.com")
 s.save(using=db)
 Site.objects.clear_cache()
 

Modified: django/trunk/django/db/backends/creation.py
===
--- django/trunk/django/db/backends/creation.py 2011-09-21 22:45:25 UTC (rev 
16867)
+++ django/trunk/django/db/backends/creation.py 2011-09-21 22:46:48 UTC (rev 
16868)
@@ -248,14 +248,6 @@
 interactive=False,
 database=self.connection.alias)
 
-# One effect of calling syncdb followed by flush is that the id of the
-# default site may or may not be 1, depending on how the sequence was
-# reset.  If the sites app is loaded, then we coerce it.
-from django.db.models import get_model
-Site = get_model('sites', 'Site')
-if Site is not None and 
Site.objects.using(self.connection.alias).count() == 1:
-
Site.objects.using(self.connection.alias).update(id=settings.SITE_ID)
-
 from django.core.cache import get_cache
 from django.core.cache.backends.db import BaseDatabaseCache
 for cache_alias in settings.CACHES:

-- 
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] r16867 - django/branches/releases/1.3.X/docs/ref/contrib

[noreply]

Author: DrMeers
Date: 2011-09-21 15:45:25 -0700 (Wed, 21 Sep 2011)
New Revision: 16867

Modified:
   django/branches/releases/1.3.X/docs/ref/contrib/messages.txt
Log:
[1.3.X] Fixed #16904 -- Additional clarification regarding contrib.messages 
iteration. Thanks murphyke for the report and patch.

Backport of [16866] from trunk.

Modified: django/branches/releases/1.3.X/docs/ref/contrib/messages.txt
===
--- django/branches/releases/1.3.X/docs/ref/contrib/messages.txt
2011-09-21 22:43:41 UTC (rev 16866)
+++ django/branches/releases/1.3.X/docs/ref/contrib/messages.txt
2011-09-21 22:45:25 UTC (rev 16867)
@@ -210,6 +210,10 @@
 ``RequestContext``. Otherwise, ensure ``messages`` is available to
 the template context.
 
+Even if you know there is only just one message, you should still iterate over
+the ``messages`` sequence, because otherwise the message storage will not be 
cleared
+for the next request.
+
 Creating custom message levels
 --
 

-- 
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] #16904: django.contrib.messages minor note

[Django]

#16904: django.contrib.messages minor note
-+-
   Reporter:  murphyke   |  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:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-

Comment (by DrMeers):

 In [16867]:
 {{{
 #!CommitTicketReference repository="" revision="16867"
 [1.3.X] Fixed #16904 -- Additional clarification regarding
 contrib.messages iteration. Thanks murphyke for the report and patch.

 Backport of [16866] from trunk.
 }}}

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

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

Re: [Django] #16904: django.contrib.messages minor note

[Django]

#16904: django.contrib.messages minor note
-+-
   Reporter:  murphyke   |  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:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by DrMeers):

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


Comment:

 In [16866]:
 {{{
 #!CommitTicketReference repository="" revision="16866"
 Fixed #16904 -- Additional clarification regarding contrib.messages
 iteration. Thanks murphyke for the report and 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] r16866 - django/trunk/docs/ref/contrib

[noreply]

Author: DrMeers
Date: 2011-09-21 15:43:41 -0700 (Wed, 21 Sep 2011)
New Revision: 16866

Modified:
   django/trunk/docs/ref/contrib/messages.txt
Log:
Fixed #16904 -- Additional clarification regarding contrib.messages iteration. 
Thanks murphyke for the report and patch.

Modified: django/trunk/docs/ref/contrib/messages.txt
===
--- django/trunk/docs/ref/contrib/messages.txt  2011-09-21 21:19:18 UTC (rev 
16865)
+++ django/trunk/docs/ref/contrib/messages.txt  2011-09-21 22:43:41 UTC (rev 
16866)
@@ -183,6 +183,10 @@
 ``RequestContext``. Otherwise, ensure ``messages`` is available to
 the template context.
 
+Even if you know there is only just one message, you should still iterate over
+the ``messages`` sequence, because otherwise the message storage will not be 
cleared
+for the next request.
+
 Creating custom message levels
 --
 

-- 
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] #16907: Deprecate databrowse

[Django]

#16907: Deprecate databrowse
-+-
   Reporter:  ptone  |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |  Component:  contrib.databrowse
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage: |Needs tests:  0
  Unreviewed |  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by ptone):

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


Comment:

 Here is a pull that implements the initiation of deprecation:

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

-- 
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] #16907: Deprecate databrowse

[Django]

#16907: Deprecate databrowse
--+
 Reporter:  ptone |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Milestone:|  Component:  contrib.databrowse
  Version:  SVN   |   Severity:  Normal
 Keywords:|   Triage Stage:  Unreviewed
Has patch:  1 |  Easy pickings:  0
UI/UX:  0 |
--+
 Several times it has come up that databrowse is a good candidate for
 removal from Django.

 
https://code.djangoproject.com/wiki/SummerOfCode2011#Integratedatabrowseintotheadmin

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

 are just two

-- 
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] #14678: Users are able to add more than one page to the same url

[Django]

#14678: Users are able to add more than one page to the same url
-+-
   Reporter:  seler  |  Owner:  j4nu5
   Type:  Bug| Status:  assigned
  Milestone:  1.4|  Component:  contrib.flatpages
Version:  SVN|   Severity:  Normal
 Resolution: |   Keywords:  flatpages, unique,
   Triage Stage:  Design |  sites
  decision needed|  Has patch:  1
Needs documentation:  1  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+-
Changes (by ptone):

 * cc: preston@… (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] #16483: manage.py shell does not work with the latest IPython release (0.11.rc2)

[Django]

#16483: manage.py shell does not work with the latest IPython release (0.11.rc2)
-+-
   Reporter:  croach |  Owner:  croach
   Type:  Bug| Status:  reopened
  Milestone: |  Component:  Core (Management
Version:  SVN|  commands)
 Resolution: |   Severity:  Normal
   Triage Stage: |   Keywords:
  Unreviewed |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-

Comment (by aaugustin):

 If I understand correctly, you're saying that we should switch from
 `InteractiveShellEmbed.mainloop` to `embed` so that the user's IPython
 configuration gets loaded? Or that we should keep
 `InteractiveShellEmbed.mainloop`?

 From my (external) point of view, the best information on this ticket is
 provided by comment #3 (whose author seems to be an IPython developer),
 and it doesn't recommend switching to `embed`.

 Any evidence in favor of one or the other will be appreciated — not
 everyone is very familiar with IPython. Thanks!

-- 
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] #16483: manage.py shell does not work with the latest IPython release (0.11.rc2)

[Django]

#16483: manage.py shell does not work with the latest IPython release (0.11.rc2)
-+-
   Reporter:  croach |  Owner:  croach
   Type:  Bug| Status:  reopened
  Milestone: |  Component:  Core (Management
Version:  SVN|  commands)
 Resolution: |   Severity:  Normal
   Triage Stage: |   Keywords:
  Unreviewed |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
Changes (by fdintino):

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


Comment:

 I'm not sure whether this comment should go here, or if I should open a
 new ticket.

 I'm doubtful that the ipython interactive shell was ever completely
 broken... however, the ipython shell as it is currently implemented
 doesn't import the user's iPython configuration, which changed in 0.11. In
 fact, as far as I can tell, that is the only difference between
 `IPython.frontend.terminal.embed.InteractiveShellEmbed.mainloop()` (what
 django currently calls) and `IPython.frontend.terminal.embed.embed()`.

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

[noreply]

Author: Alex
Date: 2011-09-21 14:19:18 -0700 (Wed, 21 Sep 2011)
New Revision: 16865

Modified:
   django/trunk/docs/topics/auth.txt
Log:
Switch a few examples in the docs to use newstyle classes.

Modified: django/trunk/docs/topics/auth.txt
===
--- django/trunk/docs/topics/auth.txt   2011-09-21 17:25:13 UTC (rev 16864)
+++ django/trunk/docs/topics/auth.txt   2011-09-21 21:19:18 UTC (rev 16865)
@@ -1637,13 +1637,13 @@
 The ``authenticate`` method takes credentials as keyword arguments. Most of
 the time, it'll just look like this::
 
-class MyBackend:
+class MyBackend(object):
 def authenticate(self, username=None, password=None):
 # Check the username/password and return a User.
 
 But it could also authenticate a token, like so::
 
-class MyBackend:
+class MyBackend(object):
 def authenticate(self, token=None):
 # Check the token and return a User.
 
@@ -1665,7 +1665,7 @@
 from django.conf import settings
 from django.contrib.auth.models import User, check_password
 
-class SettingsBackend:
+class SettingsBackend(object):
 """
 Authenticate against the settings ADMIN_LOGIN and ADMIN_PASSWORD.
 
@@ -1719,7 +1719,7 @@
 The simple backend above could implement permissions for the magic admin
 fairly simply::
 
-class SettingsBackend:
+class SettingsBackend(object):
 
 # ...
 

-- 
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] #16212: Improve multiple sort UX

[Django]

#16212: Improve multiple sort UX
---+---
   Reporter:  idangazit|  Owner:  nobody
   Type:  New feature  | Status:  new
  Milestone:   |  Component:  contrib.admin
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:  1|
---+---

Comment (by jezdez):

 <3

-- 
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] #16212: Improve multiple sort UX

[Django]

#16212: Improve multiple sort UX
---+---
   Reporter:  idangazit|  Owner:  nobody
   Type:  New feature  | Status:  new
  Milestone:   |  Component:  contrib.admin
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:  1|
---+---
Changes (by idangazit):

 * stage:  Design decision needed => Accepted


Comment:

 This is pretty winful, and has that fully-baked feel. +1 from 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] #16212: Improve multiple sort UX

[Django]

#16212: Improve multiple sort UX
-+-
   Reporter:  idangazit  |  Owner:  nobody
   Type:  New| Status:  new
  feature|  Component:  contrib.admin
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:
 Resolution: |  Has patch:  0
   Triage Stage:  Design |Needs tests:  0
  decision needed|  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  1  |
-+-

Comment (by julien):

 I've discussed this on IRC with Idan. We've especially tried to find a
 better icon. Our latest suggestion is a more explicit icon combining the
 sort triangles and a cross (see latest attached 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.

Re: [Django] #16905: Custom fields and apps should have a way to hook into BaseCommand.validate (was: Custom fields should be included in BaseCommand.validate)

[Django]

#16905: Custom fields and apps should have a way to hook into 
BaseCommand.validate
-+-
   Reporter:  jdunck |  Owner:  nobody
   Type:  New| Status:  new
  feature|  Component:  Core (Management
  Milestone: |  commands)
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  |
-+-

Comment (by carljm):

 Not only custom fields, but also things that aren't fields at all - e.g.
 #8579.

-- 
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] #16904: django.contrib.messages minor note

[Django]

#16904: django.contrib.messages minor note
-+-
   Reporter:  murphyke   |  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:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by aaugustin):

 * needs_better_patch:   => 0
 * stage:  Unreviewed => Ready for checkin
 * type:  Uncategorized => Cleanup/optimization
 * 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] #16900: utils.dictconfig doesn't work with python 3

[Django]

#16900: utils.dictconfig doesn't work with python 3
-+-
   Reporter:  adsworth   |  Owner:  adsworth
   Type:  Bug| Status:  new
  Milestone: |  Component:  Python 3
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Design |  Has patch:  0
  decision needed|Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by aaugustin):

 * stage:  Unreviewed => Design decision needed


Comment:

 This is a problem only on python 3.0 and 3.1, because since 3.2 dictconfig
 is part of the standard library.

 To the best of my knowledge, nobody has decided which versions of python 3
 would be supported by Django. It would be reasonable to start support at
 Python 3.2 (by the time the py3k branch is merged in trunk). In this case,
 this ticket wouldn't be necessary.

 Marking as DDN, the decision to take is "which versions of Python are
 targeted by the py3k branch?"

-- 
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] #16905: Custom fields should be included in BaseCommand.validate

[Django]

#16905: Custom fields should be included in BaseCommand.validate
-+-
   Reporter:  jdunck |  Owner:  nobody
   Type:  New| Status:  new
  feature|  Component:  Core (Management
  Milestone: |  commands)
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 carljm):

 * version:  1.3 => SVN
 * stage:  Unreviewed => Accepted


Comment:

 Definitely. Both #3055 and #8579 are waiting on 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] #3055: GenericRelation should squawk if pointed to a model that doesn't have a GenericForeignKey on it

[Django]

#3055: GenericRelation should squawk if pointed to a model that doesn't have a
GenericForeignKey on it
-+-
   Reporter:  panta@…|  Owner:  marcosmoyano
   Type:  defect | Status:  reopened
  Milestone: |  Component:  Database layer
Version:  SVN|  (models, ORM)
 Resolution: |   Severity:  major
   Triage Stage:  Accepted   |   Keywords:
Needs documentation:  0  |  Has patch:  1
Patch needs improvement:  0  |Needs tests:  0
  UI/UX:  0  |  Easy pickings:  0
-+-

Comment (by carljm):

 This blocks on #16905 (extensible validation).

-- 
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] #8579: Move admin validation to only run as part of "validate" management command

[Django]

#8579: Move admin validation to only run as part of "validate" management 
command
---+---
   Reporter:  mtredinnick  |  Owner:  nobody
   Type:  New feature  | Status:  new
  Milestone:   |  Component:  contrib.admin
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 carljm):

 * ui_ux:   => 0
 * easy:   => 0


Comment:

 This ticket has been referenced (e.g.
 https://code.djangoproject.com/ticket/16283#comment:7) as the ticket for
 making validation extensible, but really its a more specific thing that
 blocks on extensible validation. I could edit the title and description to
 broaden this ticket, but I don't want to lose the specific piece of moving
 admin validation, which can be done in a separate commit after we have
 extensible validation.

 So I'm going to leave #16905 open as the ticket for extensible validation,
 and just note here that this (as well as #3055) blocks on #16905.

-- 
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] #16906: Avoid strftime when isoformat can do the job

[Django]

#16906: Avoid strftime when isoformat can do the job
-+-
   Reporter:  aaugustin  |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |  Component:  Core (Other)
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution: |  Has patch:  0
   Triage Stage: |Needs tests:  0
  Unreviewed |  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Description changed by aaugustin:

Old description:

> r7946 introduced a `datetime_safe` module that provides a Python
> implementation of `datetime.[date|datetime].strftime` for dates before
> 1900.
>
> However, this is overkill for the purpose of just showing a `date` or
> `datetime` in ISO format (`%Y-%m-%d` and `%Y-%m-%d %H:%M:%S`). It makes
> the code needlessly complicated, sometimes inconistent, and inefficient.
> The `isoformat` method achieves the same result, works for any date, and
> is implemented in C.
>
> Also, some code still uses the `strftime` function from the standard
> library. Using `isoformat` is better because it isn't subject to the 1900
> limit.
>
> See attached patch.
>
> 
>
> For more background, see `isoformat_date` in
> http://svn.python.org/view/python/tags/r271/Modules/datetimemodule.c?view=markup.
> Note that `date` objects have no `__unicode__` and their `__str__` just
> call `isoformat`, so `str(date)` or `unicode(date)` is the same as
> `datetime_safe.date(date.year, date.month,
> date.day).strftime('%Y-%m-%d')`. It's pretty much the same for `datetime`
> objects, except that `isoformat` uses `T` as a separator, while `str` and
> `unicode` use a space.
>
> Changing `date.format('%Y-%m-%d')` to `date.isoformat()` is safe.
> Changing `datetime.format('%Y-%m-%d %H:%M:%S')` to `datetime.isoformat()`
> requires removing the microseconds and the timezone first, if there is
> one, so the correct pattern is `datetime.replace(microsecond=0,
> tzinfo=None)`. This also applies for time objects.

New description:

 While working on timezone support in Django, the inconsistency in these
 three functions surprised me:
 
https://code.djangoproject.com/browser/django/trunk/django/db/backends/__init__.py#L714

 

 In fact, r7946 introduced a `datetime_safe` module that provides a Python
 implementation of `datetime.[date|datetime].strftime` for dates before
 1900.

 However, this is overkill for the purpose of just showing a `date` or
 `datetime` in ISO format (`%Y-%m-%d` and `%Y-%m-%d %H:%M:%S`). It makes
 the code needlessly complicated, sometimes inconistent, and inefficient.
 The `isoformat` method achieves the same result, works for any date, and
 is implemented in C.

 Also, some code still uses the `strftime` function from the standard
 library. Using `isoformat` is better because it isn't subject to the 1900
 limit.

 See attached patch.

 

 For more background, see `isoformat_date` in
 
http://svn.python.org/view/python/tags/r271/Modules/datetimemodule.c?view=markup.
 Note that `date` objects have no `__unicode__` and their `__str__` just
 call `isoformat`, so `str(date)` or `unicode(date)` is the same as
 `datetime_safe.date(date.year, date.month,
 date.day).strftime('%Y-%m-%d')`. It's pretty much the same for `datetime`
 objects, except that `isoformat` uses `T` as a separator, while `str` and
 `unicode` use a space.

 Changing `date.format('%Y-%m-%d')` to `date.isoformat()` is safe. Changing
 `datetime.format('%Y-%m-%d %H:%M:%S')` to `datetime.isoformat()` requires
 removing the microseconds and the timezone first, if there is one, so the
 correct pattern is `datetime.replace(microsecond=0, tzinfo=None)`. This
 also applies for time objects.

--

-- 
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] #16906: Avoid strftime when isoformat can do the job

[Django]

#16906: Avoid strftime when isoformat can do the job
-+-
 Reporter:  aaugustin|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |Component:  Core
Milestone:   |  (Other)
  Version:  1.3  | Severity:  Normal
 Keywords:   | Triage Stage:
Has patch:  0|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
 r7946 introduced a `datetime_safe` module that provides a Python
 implementation of `datetime.[date|datetime].strftime` for dates before
 1900.

 However, this is overkill for the purpose of just showing a `date` or
 `datetime` in ISO format (`%Y-%m-%d` and `%Y-%m-%d %H:%M:%S`). It makes
 the code needlessly complicated, sometimes inconistent, and inefficient.
 The `isoformat` method achieves the same result, works for any date, and
 is implemented in C.

 Also, some code still uses the `strftime` function from the standard
 library. Using `isoformat` is better because it isn't subject to the 1900
 limit.

 See attached patch.

 

 For more background, see `isoformat_date` in
 
http://svn.python.org/view/python/tags/r271/Modules/datetimemodule.c?view=markup.
 Note that `date` objects have no `__unicode__` and their `__str__` just
 call `isoformat`, so `str(date)` or `unicode(date)` is the same as
 `datetime_safe.date(date.year, date.month,
 date.day).strftime('%Y-%m-%d')`. It's pretty much the same for `datetime`
 objects, except that `isoformat` uses `T` as a separator, while `str` and
 `unicode` use a space.

 Changing `date.format('%Y-%m-%d')` to `date.isoformat()` is safe. Changing
 `datetime.format('%Y-%m-%d %H:%M:%S')` to `datetime.isoformat()` requires
 removing the microseconds and the timezone first, if there is one, so the
 correct pattern is `datetime.replace(microsecond=0, tzinfo=None)`. This
 also applies for time objects.

-- 
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] #16905: Custom fields should be included in BaseCommand.validate

[Django]

#16905: Custom fields should be included in BaseCommand.validate
-+-
 Reporter:  jdunck   |Owner:  nobody
 Type:  New feature  |   Status:  new
Milestone:   |Component:  Core
  Version:  1.3  |  (Management commands)
 Keywords:   | Severity:  Normal
Has patch:  0| Triage Stage:
  Needs tests:  0|  Unreviewed
Easy pickings:  0|  Needs documentation:  0
 |  Patch needs improvement:  0
 |UI/UX:  0
-+-
 Right now, management.validation.get_validation_errors has a long chain of
 elif isinstance's for built-in fields.

 It should be possible for custom fields to participate in this model-
 declaration validation phase.

-- 
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] #702: make unique_together work with ManyToMany

[Django]

#702: make unique_together work with ManyToMany
-+-
   Reporter:  hugo   |  Owner:  nobody
   Type:  New| Status:  new
  feature|  Component:  Database layer
  Milestone: |  (models, ORM)
Version:  SVN|   Severity:  Normal
 Resolution: |   Keywords:  model-validation
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
Changes (by ptone):

 * status:  assigned => new
 * owner:  j4nu5 => nobody
 * version:   => SVN
 * component:  Validators => Database layer (models, ORM)


Comment:

 This should be in the db/orm component

 for reference an attempt at implementation would have to be made here:

 django.db.models.base.Model._perform_unique_checks

 If the implementation is not practical (this ticket closed as wontfix) a
 note of the limitation should be noted in the docs

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

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

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

[noreply]

Author: julien
Date: 2011-09-21 10:25:13 -0700 (Wed, 21 Sep 2011)
New Revision: 16864

Modified:
   django/trunk/django/core/management/commands/makemessages.py
Log:
Fixed #16897 -- Fixed some docstrings and help texts for the `makemessages` 
management command. Thanks, Simon Meers.

Modified: django/trunk/django/core/management/commands/makemessages.py
===
--- django/trunk/django/core/management/commands/makemessages.py
2011-09-21 15:58:32 UTC (rev 16863)
+++ django/trunk/django/core/management/commands/makemessages.py
2011-09-21 17:25:13 UTC (rev 16864)
@@ -15,16 +15,19 @@
 
 def handle_extensions(extensions=('html',)):
 """
-organizes multiple extensions that are separated with commas or passed by
-using --extension/-e multiple times.
+Organizes multiple extensions that are separated with commas or passed by
+using --extension/-e multiple times. Note that the .py extension is ignored
+here because of the way non-*.py files are handled in make_messages() (they
+are copied to file.ext.py files to trick xgettext to parse them as Python
+files).
 
-for example: running 'django-admin makemessages -e js,txt -e xhtml -a'
-would result in a extension list: ['.js', '.txt', '.xhtml']
+For example: running 'django-admin makemessages -e js,txt -e xhtml -a'
+would result in an extension list: ['.js', '.txt', '.xhtml']
 
 >>> handle_extensions(['.html', 'html,js,py,py,py,.py', 'py,.py'])
-['.html', '.js']
+set(['.html', '.js'])
 >>> handle_extensions(['.html, txt,.tpl'])
-['.html', '.tpl', '.txt']
+set(['.html', '.tpl', '.txt'])
 """
 ext_list = []
 for ext in extensions:
@@ -32,10 +35,6 @@
 for i, ext in enumerate(ext_list):
 if not ext.startswith('.'):
 ext_list[i] = '.%s' % ext_list[i]
-
-# we don't want *.py files here because of the way non-*.py files
-# are handled in make_messages() (they are copied to file.ext.py files to
-# trick xgettext to parse them as Python files)
 return set([x for x in ext_list if x != '.py'])
 
 def _popen(cmd):
@@ -318,7 +317,7 @@
 make_option('--all', '-a', action='store_true', dest='all',
 default=False, help='Updates the message files for all existing 
locales.'),
 make_option('--extension', '-e', dest='extensions',
-help='The file extension(s) to examine (default: ".html", separate 
multiple extensions with commas, or use -e multiple times)',
+help='The file extension(s) to examine (default: "html,txt", or 
"js" if the domain is "djangojs"). Separate multiple extensions with commas, or 
use -e multiple times.',
 action='append'),
 make_option('--symlinks', '-s', action='store_true', dest='symlinks',
 default=False, help='Follows symlinks to directories when 
examining source code and templates for translation strings.'),

-- 
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] #16897: makemessages option_list default value for "extensions" is missing .txt

[Django]

#16897: makemessages option_list default value for "extensions" is missing .txt
-+-
   Reporter:  DrMeers|  Owner:  nobody
   Type:  Bug| Status:  closed
  Milestone: |  Component:  Core (Management
Version:  1.3|  commands)
 Resolution:  fixed  |   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
-+-
Changes (by julien):

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


Comment:

 In [16864]:
 {{{
 #!CommitTicketReference repository="" revision="16864"
 Fixed #16897 -- Fixed some docstrings and help texts for the
 `makemessages` management command. Thanks, Simon Meers.
 }}}

-- 
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] #702: make unique_together work with ManyToMany

[Django]

#702: make unique_together work with ManyToMany
---+--
   Reporter:  hugo |  Owner:  j4nu5
   Type:  New feature  | Status:  assigned
  Milestone:   |  Component:  Validators
Version:   |   Severity:  Normal
 Resolution:   |   Keywords:  model-validation
   Triage Stage:  Accepted |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+--
Changes (by j4nu5):

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


-- 
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] #13614: Back button breaks many to many widget

[Django]

#13614: Back button breaks many to many widget
+---
   Reporter:  minarets  |  Owner:  nobody
   Type:  Bug   | Status:  reopened
  Milestone:|  Component:  contrib.admin
Version:  1.2   |   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 ptone):

 Just adding a datapoint, seems to be problem free for me with Safari 5.0.2
 os x 10.6.8

-- 
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] #16904: django.contrib.messages minor note

[Django]

#16904: django.contrib.messages minor note
---+---
 Reporter:  murphyke   |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Milestone: |  Component:  Documentation
  Version:  1.3|   Severity:  Normal
 Keywords: |   Triage Stage:  Unreviewed
Has patch:  1  |  Easy pickings:  0
UI/UX:  0  |
---+---
 In the "Displaying messages" section, it might be helpful to add the
 sentence: "Even when you know there is only just one message, you should
 still iterate over the messages sequence, because otherwise the message
 storage will not be cleared for the next request."

 The patch is 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] #16703: collectstatic management command looks in current working dir instead of project root

[Django]

#16703: collectstatic management command looks in current working dir instead of
project root
-+-
   Reporter: |  Owner:  nobody
  danielnaab | Status:  closed
   Type:  Bug|  Component:  contrib.staticfiles
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution:  fixed  |  Has patch:  0
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by jezdez):

 * component:  Core (Management commands) => contrib.staticfiles


-- 
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] r16863 - in django/trunk: django/contrib/staticfiles django/core/files tests/regressiontests/file_storage tests/regressiontests/staticfiles_tests

[noreply]

Author: jezdez
Date: 2011-09-21 08:58:32 -0700 (Wed, 21 Sep 2011)
New Revision: 16863

Modified:
   django/trunk/django/contrib/staticfiles/finders.py
   django/trunk/django/core/files/storage.py
   django/trunk/tests/regressiontests/file_storage/tests.py
   django/trunk/tests/regressiontests/staticfiles_tests/tests.py
Log:
Fixed #16703 -- Raise an exception if the storage location of the 
DefaultStorageFinder is empty.

Modified: django/trunk/django/contrib/staticfiles/finders.py
===
--- django/trunk/django/contrib/staticfiles/finders.py  2011-09-21 15:58:21 UTC 
(rev 16862)
+++ django/trunk/django/contrib/staticfiles/finders.py  2011-09-21 15:58:32 UTC 
(rev 16863)
@@ -3,7 +3,7 @@
 from django.core.exceptions import ImproperlyConfigured
 from django.core.files.storage import default_storage, Storage, 
FileSystemStorage
 from django.utils.datastructures import SortedDict
-from django.utils.functional import memoize, LazyObject
+from django.utils.functional import empty, memoize, LazyObject
 from django.utils.importlib import import_module
 from django.utils._os import safe_join
 
@@ -133,7 +133,7 @@
 List all files in all app storages.
 """
 for storage in self.storages.itervalues():
-if storage.exists(''): # check if storage location exists
+if storage.exists(''):  # check if storage location exists
 for path in utils.get_files(storage, ignore_patterns):
 yield path, storage
 
@@ -210,13 +210,22 @@
 for path in utils.get_files(self.storage, ignore_patterns):
 yield path, self.storage
 
+
 class DefaultStorageFinder(BaseStorageFinder):
 """
 A static files finder that uses the default storage backend.
 """
 storage = default_storage
 
+def __init__(self, *args, **kwargs):
+super(DefaultStorageFinder, self).__init__(*args, **kwargs)
+base_location = getattr(self.storage, 'base_location', empty)
+if not base_location:
+raise ImproperlyConfigured("The storage backend of the "
+   "staticfiles finder %r doesn't have "
+   "a valid location." % self.__class__)
 
+
 def find(path, all=False):
 """
 Find a static file with the given path using all enabled finders.
@@ -237,10 +246,12 @@
 # No match.
 return all and [] or None
 
+
 def get_finders():
 for finder_path in settings.STATICFILES_FINDERS:
 yield get_finder(finder_path)
 
+
 def _get_finder(import_path):
 """
 Imports the staticfiles finder class described by import_path, where

Modified: django/trunk/django/core/files/storage.py
===
--- django/trunk/django/core/files/storage.py   2011-09-21 15:58:21 UTC (rev 
16862)
+++ django/trunk/django/core/files/storage.py   2011-09-21 15:58:32 UTC (rev 
16863)
@@ -12,8 +12,9 @@
 from django.utils.functional import LazyObject
 from django.utils.importlib import import_module
 from django.utils.text import get_valid_filename
-from django.utils._os import safe_join
+from django.utils._os import safe_join, abspathu
 
+
 __all__ = ('Storage', 'FileSystemStorage', 'DefaultStorage', 'default_storage')
 
 class Storage(object):
@@ -145,9 +146,10 @@
 def __init__(self, location=None, base_url=None):
 if location is None:
 location = settings.MEDIA_ROOT
+self.base_location = location
+self.location = abspathu(self.base_location)
 if base_url is None:
 base_url = settings.MEDIA_URL
-self.location = os.path.abspath(location)
 self.base_url = base_url
 
 def _open(self, name, mode='rb'):

Modified: django/trunk/tests/regressiontests/file_storage/tests.py
===
--- django/trunk/tests/regressiontests/file_storage/tests.py2011-09-21 
15:58:21 UTC (rev 16862)
+++ django/trunk/tests/regressiontests/file_storage/tests.py2011-09-21 
15:58:32 UTC (rev 16863)
@@ -96,6 +96,14 @@
 shutil.rmtree(self.temp_dir)
 shutil.rmtree(self.temp_dir2)
 
+def test_emtpy_location(self):
+"""
+Makes sure an exception is raised if the location is empty
+"""
+storage = self.storage_class(location='')
+self.assertEqual(storage.base_location, '')
+self.assertEqual(storage.location, os.getcwd())
+
 def test_file_access_options(self):
 """
 Standard file access options are available, and work as expected.

Modified: django/trunk/tests/regressiontests/staticfiles_tests/tests.py
===
--- django/trunk/tests/regressiontests/staticfiles_tests/tests.py   
2011-09-21 15:58:21 UTC (rev 16862)
+++ django/trunk/tests/regressiontests/staticfiles_tests/tests.py   
2011-09-21 

Re: [Django] #16703: collectstatic management command looks in current working dir instead of project root

[Django]

#16703: collectstatic management command looks in current working dir instead of
project root
-+-
   Reporter: |  Owner:  nobody
  danielnaab | Status:  closed
   Type:  Bug|  Component:  Core (Management
  Milestone: |  commands)
Version:  1.3|   Severity:  Normal
 Resolution:  fixed  |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
Changes (by jezdez):

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


Comment:

 In [16863]:
 {{{
 #!CommitTicketReference repository="" revision="16863"
 Fixed #16703 -- Raise an exception if the storage location of the
 DefaultStorageFinder 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.

[Changeset] r16862 - in django/trunk: django/contrib/staticfiles tests/regressiontests/staticfiles_tests tests/regressiontests/staticfiles_tests/project/documents/cached tests/regressiontests/staticf

[noreply]

Author: jezdez
Date: 2011-09-21 08:58:21 -0700 (Wed, 21 Sep 2011)
New Revision: 16862

Added:
   
django/trunk/tests/regressiontests/staticfiles_tests/project/documents/cached/css/
   
django/trunk/tests/regressiontests/staticfiles_tests/project/documents/cached/css/img/
   
django/trunk/tests/regressiontests/staticfiles_tests/project/documents/cached/css/img/window.png
   
django/trunk/tests/regressiontests/staticfiles_tests/project/documents/cached/css/window.css
   
django/trunk/tests/regressiontests/staticfiles_tests/project/documents/cached/img/
   
django/trunk/tests/regressiontests/staticfiles_tests/project/documents/cached/img/relative.png
Modified:
   django/trunk/django/contrib/staticfiles/storage.py
   
django/trunk/tests/regressiontests/staticfiles_tests/project/documents/cached/relative.css
   
django/trunk/tests/regressiontests/staticfiles_tests/project/documents/cached/styles.css
   django/trunk/tests/regressiontests/staticfiles_tests/tests.py
Log:
Fixed the relative static file resolution of the CachedStaticFilesStorage 
backend and the post processing of deeply nested static files.

Modified: django/trunk/django/contrib/staticfiles/storage.py
===
--- django/trunk/django/contrib/staticfiles/storage.py  2011-09-21 14:20:18 UTC 
(rev 16861)
+++ django/trunk/django/contrib/staticfiles/storage.py  2011-09-21 15:58:21 UTC 
(rev 16862)
@@ -113,13 +113,22 @@
 return matched
 name_parts = name.split('/')
 # Using posix normpath here to remove duplicates
-result = url_parts = posixpath.normpath(url).split('/')
-level = url.count('..')
-if level:
-result = name_parts[:-level - 1] + url_parts[level:]
-elif name_parts[:-1]:
-result = name_parts[:-1] + url_parts[-1:]
-joined_result = '/'.join(result)
+url = posixpath.normpath(url)
+url_parts = url.split('/')
+parent_level, sub_level = url.count('..'), url.count('/')
+if url.startswith('/'):
+sub_level -= 1
+url_parts = url_parts[1:]
+if parent_level or not url.startswith('/'):
+start, end = parent_level + 1, parent_level
+else:
+if sub_level:
+if sub_level == 1:
+parent_level -= 1
+start, end = parent_level, sub_level - 1
+else:
+start, end = 1, sub_level - 1
+joined_result = '/'.join(name_parts[:-start] + url_parts[end:])
 hashed_url = self.url(joined_result, force=True)
 # Return the hashed and normalized version to the file
 return 'url("%s")' % hashed_url

Added: 
django/trunk/tests/regressiontests/staticfiles_tests/project/documents/cached/css/img/window.png
===
--- 
django/trunk/tests/regressiontests/staticfiles_tests/project/documents/cached/css/img/window.png
(rev 0)
+++ 
django/trunk/tests/regressiontests/staticfiles_tests/project/documents/cached/css/img/window.png
2011-09-21 15:58:21 UTC (rev 16862)
@@ -0,0 +1,4 @@
+‰PNG
+ 
+   
+IHDR © ¥–   –IDAT8ËÅÕm À  ОÀ NíT¸‰›t!i"¾Z4Y“eÁ¼0 ¤”Ð9‡! |  cµ  
4` Ë ¨ò nÁ Ð6ÞÀ=8 §ðœ¢ [k‡ %à å:íÚ¶èª3 ²h H@ J°1¦> ø ª>}õ…RßR’Ñ m~é   Ó 
P”PnÀmê{ §IZ  ® ï=æœQ+Šõ á 5Ý…¹¡LIEND®B`‚
\ No newline at end of file

Added: 
django/trunk/tests/regressiontests/staticfiles_tests/project/documents/cached/css/window.css
===
--- 
django/trunk/tests/regressiontests/staticfiles_tests/project/documents/cached/css/window.css
(rev 0)
+++ 
django/trunk/tests/regressiontests/staticfiles_tests/project/documents/cached/css/window.css
2011-09-21 15:58:21 UTC (rev 16862)
@@ -0,0 +1,3 @@
+body {
+background: #d3d6d8 url("img/window.png");
+}
\ No newline at end of file

Added: 
django/trunk/tests/regressiontests/staticfiles_tests/project/documents/cached/img/relative.png
===
--- 
django/trunk/tests/regressiontests/staticfiles_tests/project/documents/cached/img/relative.png
  (rev 0)
+++ 
django/trunk/tests/regressiontests/staticfiles_tests/project/documents/cached/img/relative.png
  2011-09-21 15:58:21 UTC (rev 16862)
@@ -0,0 +1,4 @@
+‰PNG
+ 
+   
+IHDR © ¥–   –IDAT8ËÅÕm À  ОÀ NíT¸‰›t!i"¾Z4Y“eÁ¼0 ¤”Ð9‡! |  cµ  
4` Ë ¨ò nÁ Ð6ÞÀ=8 §ðœ¢ [k‡ %à å:íÚ¶èª3 ²h H@ J°1¦> ø ª>}õ…RßR’Ñ m~é   Ó 
P”PnÀmê{ §IZ  ® ï=æœQ+Šõ á 5Ý…¹¡LIEND®B`‚
\ No newline at end of file

Modified: 
django/trunk/tests/regressiontests/staticfiles_tests/project/documents/cached/relative.css
===
--- 

[Django] #16903: Add '--no-location' option for 'makemessages' command

[Django]

#16903: Add '--no-location' option for 'makemessages' command
-+
 Reporter:  alpar|  Owner:  nobody
 Type:  New feature  | Status:  new
Milestone:   |  Component:  Core (Management commands)
  Version:  1.3  |   Severity:  Normal
 Keywords:   |   Triage Stage:  Unreviewed
Has patch:  1|  Easy pickings:  1
UI/UX:  0|
-+
 The attached patch adds a `--no-location` option for the `makemessages`
 management command. It is against svn trunk revision -r16861. Please
 consider adding it to the svn repo.

 Rational: Location comments in the `.po` files can are very annoying when
 they are version controlled, because changes in the source codes will
 trigger a lot of changes in the `.po` files, even when the strings to be
 translated are not affected. The obvious remedy for this is using `--no-
 location`.

-- 
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] #16900: utils.dictconfig doesn't work with python 3 (was: utls.dictconfig doesn't work with python 3)

[Django]

#16900: utils.dictconfig doesn't work with python 3
--+--
   Reporter:  adsworth|  Owner:  adsworth
   Type:  Bug | Status:  new
  Milestone:  |  Component:  Python 3
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 adsworth):

 * needs_better_patch:   => 0
 * needs_docs:   => 0
 * needs_tests:   => 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] #16822: HTTPRequest::raw_post_data broken for tests

[Django]

#16822: HTTPRequest::raw_post_data broken for tests
-+-
   Reporter:  Whitney|  Owner:  nobody
   Type: | Status:  new
  Uncategorized  |  Component:  Testing framework
  Milestone: |   Severity:  Normal
Version: |   Keywords:
 Resolution: |  Has patch:  0
   Triage Stage: |Needs tests:  0
  Unreviewed |  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by jaylett):

 * cc: james@… (added)
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 This was introduced in [15939] deliberately, to close #15679, but I'm not
 happy with the behaviour. There are utility reasons (in middleware, or
 error handling) why you might want to read the raw post data independent
 of what's happened before. This is particularly causing me problems with
 sentry.

 As I understand it, it's an assumed invariant that you won't access
 raw_post_data having read it once, but the problem is that there are two
 paths to reading it, one of which (non-multipart) populates the
 _raw_post_data memo (and hence you *can* access raw_post_data as many
 times subsequently as you like) and one of which (multipart) doesn't, the
 latter on the basis that multipart data can be "big" and it'd chew up
 memory.

 I don't think raising the (untyped) exception "You cannot access
 raw_post_data after reading from request's data stream" is helpful,
 because (a) it's not always true, (b) it can't easily be specifically
 caught as an expected failure in error handling code such as sentry.
 Perhaps an Exception subclass that can be explicitly caught would be a
 better choice?

 I'd suggest changing the component to HTTP handling because I've seen this
 in the wild, not just in tests.

-- 
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] #13614: Back button breaks many to many widget

[Django]

#13614: Back button breaks many to many widget
+---
   Reporter:  minarets  |  Owner:  nobody
   Type:  Bug   | Status:  reopened
  Milestone:|  Component:  contrib.admin
Version:  1.2   |   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 CollinAnderson):

 Yes, that patch seems to have fixed it for me on Chrome. Thanks! IE 7/8
 and Firefox appear to continue work fine.

-- 
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] #13614: Back button breaks many to many widget

[Django]

#13614: Back button breaks many to many widget
+---
   Reporter:  minarets  |  Owner:  nobody
   Type:  Bug   | Status:  reopened
  Milestone:|  Component:  contrib.admin
Version:  1.2   |   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 anonymous):

 Yes, that patch seems to have fixed it for me on Chrome. Thanks! IE 7/8
 and Firefox appear to continue work fine.

-- 
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] r16860 - in django/trunk: django/contrib/admin tests/regressiontests/admin_inlines

[noreply]

Author: carljm
Date: 2011-09-21 07:00:58 -0700 (Wed, 21 Sep 2011)
New Revision: 16860

Modified:
   django/trunk/django/contrib/admin/options.py
   django/trunk/tests/regressiontests/admin_inlines/admin.py
   django/trunk/tests/regressiontests/admin_inlines/models.py
   django/trunk/tests/regressiontests/admin_inlines/tests.py
Log:
Fixed #16838 -- Corrected broken add-another inline JS in admin with 
related_name="+". Thanks jamesp for report and patch.

Modified: django/trunk/django/contrib/admin/options.py
===
--- django/trunk/django/contrib/admin/options.py2011-09-21 01:37:17 UTC 
(rev 16859)
+++ django/trunk/django/contrib/admin/options.py2011-09-21 14:00:58 UTC 
(rev 16860)
@@ -926,7 +926,7 @@
 for FormSet, inline in zip(self.get_formsets(request), 
self.inline_instances):
 prefix = FormSet.get_default_prefix()
 prefixes[prefix] = prefixes.get(prefix, 0) + 1
-if prefixes[prefix] != 1:
+if prefixes[prefix] != 1 or not prefix:
 prefix = "%s-%s" % (prefix, prefixes[prefix])
 formset = FormSet(data=request.POST, files=request.FILES,
   instance=new_object,
@@ -955,7 +955,7 @@
self.inline_instances):
 prefix = FormSet.get_default_prefix()
 prefixes[prefix] = prefixes.get(prefix, 0) + 1
-if prefixes[prefix] != 1:
+if prefixes[prefix] != 1 or not prefix:
 prefix = "%s-%s" % (prefix, prefixes[prefix])
 formset = FormSet(instance=self.model(), prefix=prefix,
   queryset=inline.queryset(request))
@@ -1025,7 +1025,7 @@
self.inline_instances):
 prefix = FormSet.get_default_prefix()
 prefixes[prefix] = prefixes.get(prefix, 0) + 1
-if prefixes[prefix] != 1:
+if prefixes[prefix] != 1 or not prefix:
 prefix = "%s-%s" % (prefix, prefixes[prefix])
 formset = FormSet(request.POST, request.FILES,
   instance=new_object, prefix=prefix,
@@ -1046,7 +1046,7 @@
 for FormSet, inline in zip(self.get_formsets(request, obj), 
self.inline_instances):
 prefix = FormSet.get_default_prefix()
 prefixes[prefix] = prefixes.get(prefix, 0) + 1
-if prefixes[prefix] != 1:
+if prefixes[prefix] != 1 or not prefix:
 prefix = "%s-%s" % (prefix, prefixes[prefix])
 formset = FormSet(instance=obj, prefix=prefix,
   queryset=inline.queryset(request))

Modified: django/trunk/tests/regressiontests/admin_inlines/admin.py
===
--- django/trunk/tests/regressiontests/admin_inlines/admin.py   2011-09-21 
01:37:17 UTC (rev 16859)
+++ django/trunk/tests/regressiontests/admin_inlines/admin.py   2011-09-21 
14:00:58 UTC (rev 16860)
@@ -101,6 +101,14 @@
 inlines = [ChapterInline]
 
 
+class ConsigliereInline(admin.TabularInline):
+model = Consigliere
+
+
+class SottoCapoInline(admin.TabularInline):
+model = SottoCapo
+
+
 site.register(TitleCollection, inlines=[TitleInline])
 # Test bug #12561 and #12778
 # only ModelAdmin media
@@ -115,3 +123,4 @@
 site.register(Fashionista, inlines=[InlineWeakness])
 site.register(Holder4, Holder4Admin)
 site.register(Author, AuthorAdmin)
+site.register(CapoFamiglia, inlines=[ConsigliereInline, SottoCapoInline])

Modified: django/trunk/tests/regressiontests/admin_inlines/models.py
===
--- django/trunk/tests/regressiontests/admin_inlines/models.py  2011-09-21 
01:37:17 UTC (rev 16859)
+++ django/trunk/tests/regressiontests/admin_inlines/models.py  2011-09-21 
14:00:58 UTC (rev 16860)
@@ -122,3 +122,17 @@
 class Chapter(models.Model):
 novel = models.ForeignKey(Novel)
 
+
+# Models for #16838
+class CapoFamiglia(models.Model):
+name = models.CharField(max_length=100)
+
+
+class Consigliere(models.Model):
+name = models.CharField(max_length=100)
+capo_famiglia = models.ForeignKey(CapoFamiglia, related_name='+')
+
+
+class SottoCapo(models.Model):
+name = models.CharField(max_length=100)
+capo_famiglia = models.ForeignKey(CapoFamiglia, related_name='+')

Modified: django/trunk/tests/regressiontests/admin_inlines/tests.py
===
--- django/trunk/tests/regressiontests/admin_inlines/tests.py   2011-09-21 
01:37:17 UTC (rev 16859)
+++ django/trunk/tests/regressiontests/admin_inlines/tests.py   2011-09-21 
14:00:58 UTC (rev 16860)
@@ -4,7 +4,8 @@
 
 # local test models
 from models import (Holder, Inner, Holder2, 

Re: [Django] #16866: Handling empty list of candidates in select_template function

[Django]

#16866: Handling empty list of candidates in select_template function
+-
   Reporter:  Silver_Ghost  |  Owner:  Silver_Ghost
   Type:  Bug   | Status:  closed
  Milestone:|  Component:  Template system
Version:  SVN   |   Severity:  Normal
 Resolution:  fixed |   Keywords:  select_template
   Triage Stage:  Accepted  |  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
 * resolution:   => fixed


Comment:

 In [16861]:
 {{{
 #!CommitTicketReference repository="" revision="16861"
 Fixed #16866 -- Clearer error message if empty list is passed to
 select_template. Thanks Silver_Ghost for report and 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] r16861 - in django/trunk: django/template tests/regressiontests/templates

[noreply]

Author: carljm
Date: 2011-09-21 07:20:18 -0700 (Wed, 21 Sep 2011)
New Revision: 16861

Modified:
   django/trunk/django/template/loader.py
   django/trunk/tests/regressiontests/templates/loaders.py
Log:
Fixed #16866 -- Clearer error message if empty list is passed to 
select_template. Thanks Silver_Ghost for report and patch.

Modified: django/trunk/django/template/loader.py
===
--- django/trunk/django/template/loader.py  2011-09-21 14:00:58 UTC (rev 
16860)
+++ django/trunk/django/template/loader.py  2011-09-21 14:20:18 UTC (rev 
16861)
@@ -179,6 +179,8 @@
 
 def select_template(template_name_list):
 "Given a list of template names, returns the first that can be loaded."
+if not template_name_list:
+raise TemplateDoesNotExist("No template names provided")
 not_found = []
 for template_name in template_name_list:
 try:

Modified: django/trunk/tests/regressiontests/templates/loaders.py
===
--- django/trunk/tests/regressiontests/templates/loaders.py 2011-09-21 
14:00:58 UTC (rev 16860)
+++ django/trunk/tests/regressiontests/templates/loaders.py 2011-09-21 
14:20:18 UTC (rev 16861)
@@ -143,5 +143,16 @@
 self.assertEqual(output, 'obj:after')
 self.assertEqual(context['obj'], 'before')
 
+def test_empty_list(self):
+self.assertRaisesRegexp(TemplateDoesNotExist,
+'No template names provided$',
+loader.render_to_string, [])
+
+
+def test_select_templates_from_empty_list(self):
+self.assertRaisesRegexp(TemplateDoesNotExist,
+'No template names provided$',
+loader.select_template, [])
+
 if __name__ == "__main__":
 unittest.main()

-- 
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] #16902: select_related() results in a poor perfomance

[Django]

#16902: select_related() results in a poor perfomance
-+-
   Reporter: |  Owner:  nobody
  ivan_virabyan  | Status:  new
   Type: |  Component:  Database layer
  Cleanup/optimization   |  (models, ORM)
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:  select_related,
 Resolution: |  get_cached_row, perfomance
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
Changes (by carljm):

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


Comment:

 Accepting because I can duplicate the timing results and inspection of
 query.py confirms that there's a lot of work repeated unnecessarily for
 every result row. Don't have time at the moment to test or review the
 patch. Thanks for the report!

-- 
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] #16335: Cannot iterate defaultdict in template

[Django]

#16335: Cannot iterate defaultdict in template
-+-
   Reporter: |  Owner:  bluejeansummer
  jacob.ninja.dev@…  | Status:  assigned
   Type:  Bug|  Component:  Template system
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  1
Patch needs improvement:  1  |
  UI/UX:  0  |
-+-
Changes (by akvadrako):

 * cc: akvadrako (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] #16901: Admin: Post save redirect behaves differently since 1.3.1

[Django]

#16901: Admin: Post save redirect behaves differently since 1.3.1
-+-
   Reporter:  Lenz   |  Owner:  nobody
  Hirsch   | Status:  closed
   Type: |  Component:  Uncategorized
  Uncategorized  |   Severity:  Normal
  Milestone: |   Keywords:
Version:  1.3|  Has patch:  0
 Resolution:  wontfix|Needs tests:  0
   Triage Stage: |  Easy pickings:  0
  Unreviewed |
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-

Comment (by Lenz Hirsch ):

 Thanks a lot!

 {{{
 USE_X_FORWARDED_HOST = True
 }}}

 indeed fixes the problem.

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