Re: [Django] #17372: Sleep middleware

[Django]

#17372: Sleep middleware
--+--
 Reporter:  josharian |Owner:  nobody
 Type:  New feature   |   Status:  closed
Component:  Core (Other)  |  Version:  1.3
 Severity:  Normal|   Resolution:  wontfix
 Keywords:| Triage Stage:  Unreviewed
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--

Comment (by aaugustin):

 http://djangosnippets.org/ is also a good place to upload such utilities.

-- 
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] #17365: Extend test discovery to inlcude unittest2 test suite runner

[Django]

#17365: Extend test discovery to inlcude unittest2 test suite runner
---+
 Reporter:  jezdez |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Testing framework  |  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 russellm):

 +1 to everything Jacob said, with one caveat: There is a historical reason
 for looking for tests in models.py -- that's the way you could easily find
 doctests on any of your model methods.  I'm not arguing that this is a
 reason to include models.py, but given that there was method in the
 madness of including models.py in the search path in the first place, if
 we choose to remove models.py, we need to make sure the change is
 documented.

 I'm also interested to know how this would impact on any plans to
 introduce better support for "suites"; I've had a couple of discussions in
 recent times, as well as a long running desire to provide a way to
 separate true unit test (e.g., check that contrib.auth works) from
 integration tests (e.g., checking that contrib.auth is deployed correctly)
 from acceptance tests (e.g., testing that contrib.auth works in practice
 against a browser test suite). I haven't given any specific thought to how
 this would be implemented, but if we're going to make a change to test
 discovery, it would be good to know that the idea has been considered,
 even if we dont' deliver on the actual capability.

-- 
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] #17366: Deprecate loading tests from models.py

[Django]

#17366: Deprecate loading tests from models.py
--+
 Reporter:  Alex  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Testing framework |  Version:  SVN
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+

Comment (by russellm):

 There is a reason that models.py was searched for tests -- it's to catch
 any doctests that are defined on model methods.

 I'm not necessarily arguing against the decision to deprecate models.py as
 a source of tests, but given that it wasn't a completely arbitrary
 decision in the first place, it's worth documenting the specific
 consequences.

-- 
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] #17364: Minor typo and style changes for docs/topics/testing.txt

[Django]

#17364: Minor typo and style changes for docs/topics/testing.txt
-+-
 Reporter:  movielady|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.3
Component:  Documentation|   Resolution:
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by russellm):

 * stage:  Accepted => Ready for checkin


Comment:

 Looks good - thanks for the contribution!

-- 
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] #17373: TabularInline with extra = 0: "Add another" wraps in instead of inside of

[Django]

#17373: TabularInline with extra = 0: "Add another" wraps in  instead of 

inside of 
---+
 Reporter:  jpic   |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  contrib.admin  |Version:  1.3
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 To reproduce the bug, set extra = 0 in a TabularInline. Then open the
 admin page with the inline table, the "Add another" link is in a tr/td
 inside the table. Click "Add another" and it will add a row and wrap the
 "Add another" link inside a  instead of tr/td.

 It is semantically wrong (a  may not have  for parent) and
 displays wrong ("Add another X" shouldn't wordwrap).

 To fix the bug, change in
 
https://code.djangoproject.com/browser/django/trunk/django/contrib/admin/static/admin/js/inlines.js#L44:

{{{
 $(this).attr("tagName") == "TR"
}}}

 Into:

{{{
 $(this).is('tr')
}}}

 FTR is there a better way than this command to enable non-compressed admin
 js ?

 {{{
 ln -Lfn ../env/lib/python2.7/site-
 packages/django/contrib/admin/media/js/inlines.js
 static/admin/js/inlines.min.js
 }}}

-- 
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] #16845: Admin should hide password hash field by default

[Django]

#16845: Admin should hide password hash field by default
--+
 Reporter:  PaulM |Owner:  PaulM
 Type:  Cleanup/optimization  |   Status:  closed
Component:  contrib.auth  |  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 dstufft):

 Fwiw this is going to need to be updated once PaulM finishes the Password
 Hashing. I actually had talked to him on IRC (Suppose I should have
 mentioned it in here) and discussed and committed to updating the patch
 one the Password Hashing got merged into 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] #17365: Extend test discovery to inlcude unittest2 test suite runner

[Django]

#17365: Extend test discovery to inlcude unittest2 test suite runner
---+
 Reporter:  jezdez |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Testing framework  |  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 streeter):

 * cc: streeter (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] #16563: Error pickling request.user

[Django]

#16563: Error pickling request.user
-+
 Reporter:  zero.fuxor@… |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.auth |  Version:  1.3
 Severity:  Release blocker  |   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):

 Replying to [comment:14 poirier]:
 > Would it be possible to fix this instead by fixing the chain of events
 somewhere else?

 No, I don't think so.

 > e.g. should any access of request.session result in setting the Vary:
 Cookie header?

 Yes, it should. Any access of the session means the response you are
 generating is almost certainly dependent in some way on values in the
 session, which means serving that same response as a cached response to
 other users would be at best wrong, and at worst a security issue. This
 applies even more strongly, if anything, to accessing `request.user` in
 particular. So it's quite important that `request.user` remain lazy, and
 that accessing it trigger `Vary: Cookie` on the response.

-- 
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] r17189 - in django/trunk: django/db/models tests/regressiontests/transactions_regress

[noreply]

Author: adrian
Date: 2011-12-09 15:16:56 -0800 (Fri, 09 Dec 2011)
New Revision: 17189

Modified:
   django/trunk/django/db/models/query.py
   django/trunk/tests/regressiontests/transactions_regress/models.py
   django/trunk/tests/regressiontests/transactions_regress/tests.py
Log:
Fixed #16818 -- Fixed ORM bug with many-to-many add() method where it wasn't 
committing the change. Thanks, pressureman and kmtracey

Modified: django/trunk/django/db/models/query.py
===
--- django/trunk/django/db/models/query.py  2011-12-09 23:14:04 UTC (rev 
17188)
+++ django/trunk/django/db/models/query.py  2011-12-09 23:16:56 UTC (rev 
17189)
@@ -396,18 +396,29 @@
 self._for_write = True
 connection = connections[self.db]
 fields = self.model._meta.local_fields
-if 
(connection.features.can_combine_inserts_with_and_without_auto_increment_pk
-and self.model._meta.has_auto_field):
-self.model._base_manager._insert(objs, fields=fields, 
using=self.db)
+if not transaction.is_managed(using=self.db):
+transaction.enter_transaction_management(using=self.db)
+forced_managed = True
 else:
-objs_with_pk, objs_without_pk = partition(
-lambda o: o.pk is None,
-objs
-)
-if objs_with_pk:
-self.model._base_manager._insert(objs_with_pk, fields=fields, 
using=self.db)
-if objs_without_pk:
-self.model._base_manager._insert(objs_without_pk, fields=[f 
for f in fields if not isinstance(f, AutoField)], using=self.db)
+forced_managed = False
+try:
+if 
(connection.features.can_combine_inserts_with_and_without_auto_increment_pk
+and self.model._meta.has_auto_field):
+self.model._base_manager._insert(objs, fields=fields, 
using=self.db)
+else:
+objs_with_pk, objs_without_pk = partition(lambda o: o.pk is 
None, objs)
+if objs_with_pk:
+self.model._base_manager._insert(objs_with_pk, 
fields=fields, using=self.db)
+if objs_without_pk:
+self.model._base_manager._insert(objs_without_pk, 
fields=[f for f in fields if not isinstance(f, AutoField)], using=self.db)
+if forced_managed:
+transaction.commit(using=self.db)
+else:
+transaction.commit_unless_managed(using=self.db)
+finally:
+if forced_managed:
+transaction.leave_transaction_management(using=self.db)
+
 return objs
 
 def get_or_create(self, **kwargs):

Modified: django/trunk/tests/regressiontests/transactions_regress/models.py
===
--- django/trunk/tests/regressiontests/transactions_regress/models.py   
2011-12-09 23:14:04 UTC (rev 17188)
+++ django/trunk/tests/regressiontests/transactions_regress/models.py   
2011-12-09 23:16:56 UTC (rev 17189)
@@ -2,3 +2,9 @@
 
 class Mod(models.Model):
 fld = models.IntegerField()
+
+class M2mA(models.Model):
+others = models.ManyToManyField('M2mB')
+
+class M2mB(models.Model):
+fld = models.IntegerField()

Modified: django/trunk/tests/regressiontests/transactions_regress/tests.py
===
--- django/trunk/tests/regressiontests/transactions_regress/tests.py
2011-12-09 23:14:04 UTC (rev 17188)
+++ django/trunk/tests/regressiontests/transactions_regress/tests.py
2011-12-09 23:16:56 UTC (rev 17189)
@@ -5,7 +5,7 @@
 from django.db.transaction import commit_on_success, commit_manually, 
TransactionManagementError
 from django.test import TransactionTestCase, skipUnlessDBFeature
 
-from .models import Mod
+from .models import Mod, M2mA, M2mB
 
 
 class TestTransactionClosing(TransactionTestCase):
@@ -164,3 +164,17 @@
 _ = User.objects.all()[0]
 except:
 self.fail("A transaction consisting of a failed operation was not 
closed.")
+
+class TestManyToManyAddTransaction(TransactionTestCase):
+def test_manyrelated_add_commit(self):
+"Test for https://code.djangoproject.com/ticket/16818";
+a = M2mA.objects.create()
+b = M2mB.objects.create(fld=10)
+a.others.add(b)
+
+# We're in a TransactionTestCase and have not changed transaction
+# behavior from default of "autocommit", so this rollback should not
+# actually do anything. If it does in fact undo our add, that's a bug
+# that the bulk insert was not auto-committed.
+transaction.rollback()
+self.assertEqual(a.others.count(), 1)

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, s

Re: [Django] #16818: Regression introduced by r16739 -- `ManyRelatedManager.add()` doesn't commit to database

[Django]

#16818: Regression introduced by r16739 -- `ManyRelatedManager.add()` doesn't
commit to database
-+-
 Reporter:  pressureman  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:  fixed
 Severity:  Release blocker  | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by adrian):

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


Comment:

 In [17189]:
 {{{
 #!CommitTicketReference repository="" revision="17189"
 Fixed #16818 -- Fixed ORM bug with many-to-many add() method where it
 wasn't committing the change. Thanks, pressureman and kmtracey
 }}}

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

[noreply]

Author: adrian
Date: 2011-12-09 15:14:04 -0800 (Fri, 09 Dec 2011)
New Revision: 17188

Modified:
   django/trunk/docs/topics/db/optimization.txt
Log:
Fixed some comma splices in the 'Insert in bulk' section of db/optimization.txt

Modified: django/trunk/docs/topics/db/optimization.txt
===
--- django/trunk/docs/topics/db/optimization.txt2011-12-09 22:13:27 UTC 
(rev 17187)
+++ django/trunk/docs/topics/db/optimization.txt2011-12-09 23:14:04 UTC 
(rev 17188)
@@ -283,21 +283,23 @@
 Entry(headline="Python 3.1 Planned")
 ])
 
-Is preferable to::
+...is preferable to::
 
 Entry.objects.create(headline="Python 3.0 Released")
 Entry.objects.create(headline="Python 3.1 Planned")
 
 Note that there are a number of :meth:`caveats to this method
-`, make sure it is appropriate for
-your use case. This also applies to :class:`ManyToManyFields
-`, doing::
+`, so make sure it's appropriate
+for your use case.
 
+This also applies to :class:`ManyToManyFields
+`, so doing::
+
 my_band.members.add(me, my_friend)
 
-Is preferable to::
+...is preferable to::
 
 my_band.members.add(me)
 my_band.members.add(my_friend)
 
-Where ``Bands`` and ``Artists`` have a many-to-many relationship.
+...where ``Bands`` and ``Artists`` have a many-to-many relationship.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #17372: Sleep middleware

[Django]

#17372: Sleep middleware
--+--
 Reporter:  josharian |Owner:  nobody
 Type:  New feature   |   Status:  closed
Component:  Core (Other)  |  Version:  1.3
 Severity:  Normal|   Resolution:  wontfix
 Keywords:| Triage Stage:  Unreviewed
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
 * needs_better_patch:   => 0
 * resolution:   => wontfix
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 Hi, and thanks for the contribution.

 Generally, the leaning has been towards making contrib smaller, not
 larger, and the bar for adding something is quite high - it has to be the
 de facto standard implementation of a very common pattern. Although this
 middleware could be quite useful, I don't think it meets the bar for
 contrib. Fortunately, there's an active ecosystem of third-party reusable
 Django libraries, installable with [http://pip-installer.org pip] from
 [http://pypi.python.org/pypi/ the Python Package Index], and I think this
 would fit right in to that larger ecosystem. I'd encourage you to package
 it up, put it on PyPI, and see if it gains some traction.

 Thanks again!

-- 
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] #17372: Sleep middleware

[Django]

#17372: Sleep middleware
--+
 Reporter:  josharian |  Owner:  nobody
 Type:  New feature   | Status:  new
Component:  Core (Other)  |Version:  1.3
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  1
Easy pickings:  0 |  UI/UX:  0
--+
 It is useful to be able to simulate slow response times from a server --
 for example, to see what a mobile client ui will look like when the
 connection is poor.

 A sleep-every-request middleware makes that very easy. The middleware is
 easy to write, but given how common a task it is, it might be worth having
 packaged with Django contrib.

 To put code where my mouth is, a first cut implementation, which I happily
 place in the public domain, is at https://gist.github.com/1453629. I'm
 happy to iterate on it, given feedback.

-- 
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] #16845: Admin should hide password hash field by default

[Django]

#16845: Admin should hide password hash field by default
--+
 Reporter:  PaulM |Owner:  PaulM
 Type:  Cleanup/optimization  |   Status:  closed
Component:  contrib.auth  |  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 adrian):

 Thanks for the patch, dstufft. I made these changes before committing:

 * Made a {{{mask_password}}} function so as not to duplicate the logic.
 * Renamed {{{ReadOnlyHashedPassword*}}} to {{{ReadOnlyPasswordHash*}}}
 because I thought it was more readable/direct.
 * Removed the help_text from the User.password field now that we're not
 using that.
 * Moved the "if not value" check to be the first statement within
 {{{ReadOnlyPasswordHashWidget.render()}}} so as to fail faster, in that
 case.
 * Rewrote the {{{help_text}}} for {{{UserChangeForm.password}}} so that
 it's friendlier for people who are not sysadmin types.

-- 
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] #3100: Support for arguments on intermediate tag tokens (ex. {% if arg %}{% elif arg %}{% endif %})

[Django]

#3100: Support for arguments on intermediate tag tokens (ex. {% if arg %}{% elif
arg %}{% endif %})
-+-
 Reporter:  Eric Van Dewoestine  |Owner:  aaugustin
 |   Status:  closed
 Type:  New feature  |  Version:  SVN
Component:  Template system  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  1
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by aaugustin):

 In [17187]:
 {{{
 #!CommitTicketReference repository="" revision="17187"
 Fixed #17348 -- Implemented {% elif %}. Refs #3100.
 }}}

-- 
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] #17348: Implement {% elif %} in the template language

[Django]

#17348: Implement {% elif %} in the template language
-+-
 Reporter:  aaugustin|Owner:  aaugustin
 Type:  New feature  |   Status:  closed
Component:  Template system  |  Version:  SVN
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by aaugustin):

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


Comment:

 In [17187]:
 {{{
 #!CommitTicketReference repository="" revision="17187"
 Fixed #17348 -- Implemented {% elif %}. Refs #3100.
 }}}

-- 
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] r17187 - in django/trunk: django/template docs/ref/templates docs/releases tests/regressiontests/templates

[noreply]

Author: aaugustin
Date: 2011-12-09 14:13:27 -0800 (Fri, 09 Dec 2011)
New Revision: 17187

Modified:
   django/trunk/django/template/defaulttags.py
   django/trunk/docs/ref/templates/builtins.txt
   django/trunk/docs/releases/1.4.txt
   django/trunk/tests/regressiontests/templates/tests.py
Log:
Fixed #17348 -- Implemented {% elif %}. Refs #3100.


Modified: django/trunk/django/template/defaulttags.py
===
--- django/trunk/django/template/defaulttags.py 2011-12-09 22:10:52 UTC (rev 
17186)
+++ django/trunk/django/template/defaulttags.py 2011-12-09 22:13:27 UTC (rev 
17187)
@@ -250,32 +250,38 @@
 return self.nodelist_false.render(context)
 
 class IfNode(Node):
-child_nodelists = ('nodelist_true', 'nodelist_false')
 
-def __init__(self, var, nodelist_true, nodelist_false=None):
-self.nodelist_true, self.nodelist_false = nodelist_true, nodelist_false
-self.var = var
+def __init__(self, conditions_nodelists):
+self.conditions_nodelists = conditions_nodelists
 
 def __repr__(self):
-return ""
+return ""
 
 def __iter__(self):
-for node in self.nodelist_true:
-yield node
-for node in self.nodelist_false:
-yield node
+for _, nodelist in self.conditions_nodelists:
+for node in nodelist:
+yield node
 
+@property
+def nodelist(self):
+return NodeList(node for _, nodelist in self.conditions_nodelists for 
node in nodelist)
+
 def render(self, context):
-try:
-var = self.var.eval(context)
-except VariableDoesNotExist:
-var = None
+for condition, nodelist in self.conditions_nodelists:
 
-if var:
-return self.nodelist_true.render(context)
-else:
-return self.nodelist_false.render(context)
+if condition is not None:   # if / elif clause
+try:
+match = condition.eval(context)
+except VariableDoesNotExist:
+match = None
+else:   # else clause
+match = True
 
+if match:
+return nodelist.render(context)
+
+return ''
+
 class RegroupNode(Node):
 def __init__(self, target, expression, var_name):
 self.target, self.expression = target, expression
@@ -825,6 +831,8 @@
 
 {% if athlete_list %}
 Number of athletes: {{ athlete_list|count }}
+{% elif athlete_in_locker_room_list %}
+Athletes should be out of the locker room soon!
 {% else %}
 No athletes.
 {% endif %}
@@ -832,8 +840,9 @@
 In the above, if ``athlete_list`` is not empty, the number of athletes will
 be displayed by the ``{{ athlete_list|count }}`` variable.
 
-As you can see, the ``if`` tag can take an option ``{% else %}`` clause
-that will be displayed if the test fails.
+As you can see, the ``if`` tag may take one or several `` {% elif %}``
+clauses, as well as an ``{% else %}`` clause that will be displayed if all
+previous conditions fail. These clauses are optional.
 
 ``if`` tags may use ``or``, ``and`` or ``not`` to test a number of
 variables or to negate a given variable::
@@ -871,17 +880,33 @@
 
 Operator precedence follows Python.
 """
+# {% if ... %}
 bits = token.split_contents()[1:]
-var = TemplateIfParser(parser, bits).parse()
-nodelist_true = parser.parse(('else', 'endif'))
+condition = TemplateIfParser(parser, bits).parse()
+nodelist = parser.parse(('elif', 'else', 'endif'))
+conditions_nodelists = [(condition, nodelist)]
 token = parser.next_token()
+
+# {% elif ... %} (repeatable)
+while token.contents.startswith('elif'):
+bits = token.split_contents()[1:]
+condition = TemplateIfParser(parser, bits).parse()
+nodelist = parser.parse(('elif', 'else', 'endif'))
+conditions_nodelists.append((condition, nodelist))
+token = parser.next_token()
+
+# {% else %} (optional)
 if token.contents == 'else':
-nodelist_false = parser.parse(('endif',))
-parser.delete_first_token()
-else:
-nodelist_false = NodeList()
-return IfNode(var, nodelist_true, nodelist_false)
+nodelist = parser.parse(('endif',))
+conditions_nodelists.append((None, nodelist))
+token = parser.next_token()
 
+# {% endif %}
+assert token.contents == 'endif'
+
+return IfNode(conditions_nodelists)
+
+
 @register.tag
 def ifchanged(parser, token):
 """

Modified: django/trunk/docs/ref/templates/builtins.txt
===
--- django/trunk/docs/ref/templates/builtins.txt2011-12-09 22:10:52 UTC 
(rev 17186)
+++ django/trunk/docs/ref/templates/builtins.txt2011-12-09 22

Re: [Django] #3100: Support for arguments on intermediate tag tokens (ex. {% if arg %}{% elif arg %}{% endif %})

[Django]

#3100: Support for arguments on intermediate tag tokens (ex. {% if arg %}{% elif
arg %}{% endif %})
-+-
 Reporter:  Eric Van Dewoestine  |Owner:  aaugustin
 |   Status:  closed
 Type:  New feature  |  Version:  SVN
Component:  Template system  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  1
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by aaugustin):

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


Comment:

 In [17186]:
 {{{
 #!CommitTicketReference repository="" revision="17186"
 Fixed #3100 -- Added support for arguments on intermediate tag tokens.
 }}}

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

[noreply]

Author: aaugustin
Date: 2011-12-09 14:10:52 -0800 (Fri, 09 Dec 2011)
New Revision: 17186

Modified:
   django/trunk/django/template/base.py
   django/trunk/django/template/loader_tags.py
Log:
Fixed #3100 -- Added support for arguments on intermediate tag tokens.



Modified: django/trunk/django/template/base.py
===
--- django/trunk/django/template/base.py2011-12-09 22:10:03 UTC (rev 
17185)
+++ django/trunk/django/template/base.py2011-12-09 22:10:52 UTC (rev 
17186)
@@ -250,15 +250,15 @@
 var_node = self.create_variable_node(filter_expression)
 self.extend_nodelist(nodelist, var_node, token)
 elif token.token_type == TOKEN_BLOCK:
-if token.contents in parse_until:
+try:
+command = token.contents.split()[0]
+except IndexError:
+self.empty_block_tag(token)
+if command in parse_until:
 # put token back on token list so calling
 # code knows why it terminated
 self.prepend_token(token)
 return nodelist
-try:
-command = token.contents.split()[0]
-except IndexError:
-self.empty_block_tag(token)
 # execute callback function for this tag and append
 # resulting node
 self.enter_command(command, token)

Modified: django/trunk/django/template/loader_tags.py
===
--- django/trunk/django/template/loader_tags.py 2011-12-09 22:10:03 UTC (rev 
17185)
+++ django/trunk/django/template/loader_tags.py 2011-12-09 22:10:52 UTC (rev 
17186)
@@ -189,8 +189,14 @@
 parser.__loaded_blocks.append(block_name)
 except AttributeError: # parser.__loaded_blocks isn't a list yet
 parser.__loaded_blocks = [block_name]
-nodelist = parser.parse(('endblock', 'endblock %s' % block_name))
-parser.delete_first_token()
+nodelist = parser.parse(('endblock',))
+
+# This check is kept for backwards-compatibility. See #3100.
+endblock = parser.next_token()
+acceptable_endblocks = ('endblock', 'endblock %s' % block_name)
+if endblock.contents not in acceptable_endblocks:
+parser.invalid_block_tag(endblock, 'endblock', acceptable_endblocks)
+
 return BlockNode(block_name, nodelist)
 
 @register.tag('extends')

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] r17185 - django/trunk/django/contrib/auth

[noreply]

Author: adrian
Date: 2011-12-09 14:10:03 -0800 (Fri, 09 Dec 2011)
New Revision: 17185

Modified:
   django/trunk/django/contrib/auth/forms.py
   django/trunk/django/contrib/auth/models.py
Log:
Fixed #16845 -- Admin 'Change user' page no longer shows the password hash. 
Thanks, dstufft

Modified: django/trunk/django/contrib/auth/forms.py
===
--- django/trunk/django/contrib/auth/forms.py   2011-12-09 21:53:21 UTC (rev 
17184)
+++ django/trunk/django/contrib/auth/forms.py   2011-12-09 22:10:03 UTC (rev 
17185)
@@ -1,6 +1,8 @@
 from django import forms
+from django.forms.util import flatatt
 from django.template import loader
 from django.utils.http import int_to_base36
+from django.utils.safestring import mark_safe
 from django.utils.translation import ugettext_lazy as _
 
 from django.contrib.auth.models import User
@@ -9,7 +11,41 @@
 from django.contrib.auth.tokens import default_token_generator
 from django.contrib.sites.models import get_current_site
 
+UNMASKED_DIGITS_TO_SHOW = 6
 
+mask_password = lambda p: "%s%s" % (p[:UNMASKED_DIGITS_TO_SHOW], "*" * 
max(len(p) - UNMASKED_DIGITS_TO_SHOW, 0))
+
+class ReadOnlyPasswordHashWidget(forms.Widget):
+def render(self, name, value, attrs):
+if not value:
+return "None"
+final_attrs = self.build_attrs(attrs)
+parts = value.split("$")
+if len(parts) != 3:
+# Legacy passwords didn't specify a hash type and were md5.
+hash_type = "md5"
+masked = mask_password(value)
+else:
+hash_type = parts[0]
+masked = mask_password(parts[2])
+return mark_safe("""
+%(hash_type_label)s: %(hash_type)s
+%(masked_label)s: %(masked)s
+""" % {
+"attrs": flatatt(final_attrs),
+"hash_type_label": _("Hash type"),
+"hash_type": hash_type,
+"masked_label": _("Masked hash"),
+"masked": masked,
+})
+
+class ReadOnlyPasswordHashField(forms.Field):
+widget = ReadOnlyPasswordHashWidget
+
+def __init__(self, *args, **kwargs):
+kwargs.setdefault("required", False)
+super(ReadOnlyPasswordHashField, self).__init__(*args, **kwargs)
+
 class UserCreationForm(forms.ModelForm):
 """
 A form that creates a user, with no privileges, from the given username 
and password.
@@ -51,7 +87,11 @@
 username = forms.RegexField(label=_("Username"), max_length=30, 
regex=r'^[\w.@+-]+$',
 help_text = _("Required. 30 characters or fewer. Letters, digits and 
@/./+/-/_ only."),
 error_messages = {'invalid': _("This value may contain only letters, 
numbers and @/./+/-/_ characters.")})
+password = ReadOnlyPasswordHashField(label=_("Password"), help_text=_("We 
don't store raw passwords, so there's no way to see this user's password, but 
you can change the password using this form."))
 
+def clean_password(self):
+return self.initial["password"]
+
 class Meta:
 model = User
 

Modified: django/trunk/django/contrib/auth/models.py
===
--- django/trunk/django/contrib/auth/models.py  2011-12-09 21:53:21 UTC (rev 
17184)
+++ django/trunk/django/contrib/auth/models.py  2011-12-09 22:10:03 UTC (rev 
17185)
@@ -177,7 +177,7 @@
 first_name = models.CharField(_('first name'), max_length=30, blank=True)
 last_name = models.CharField(_('last name'), max_length=30, blank=True)
 email = models.EmailField(_('e-mail address'), blank=True)
-password = models.CharField(_('password'), max_length=128, 
help_text=_("Use '[algo]$[salt]$[hexdigest]' or use the change password form."))
+password = models.CharField(_('password'), max_length=128)
 is_staff = models.BooleanField(_('staff status'), default=False, 
help_text=_("Designates whether the user can log into this admin site."))
 is_active = models.BooleanField(_('active'), default=True, 
help_text=_("Designates whether this user should be treated as active. Unselect 
this instead of deleting accounts."))
 is_superuser = models.BooleanField(_('superuser status'), default=False, 
help_text=_("Designates that this user has all permissions without explicitly 
assigning them."))

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #16845: Admin should hide password hash field by default

[Django]

#16845: Admin should hide password hash field by default
--+
 Reporter:  PaulM |Owner:  PaulM
 Type:  Cleanup/optimization  |   Status:  closed
Component:  contrib.auth  |  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 adrian):

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


Comment:

 In [17185]:
 {{{
 #!CommitTicketReference repository="" revision="17185"
 Fixed #16845 -- Admin 'Change user' page no longer shows the password
 hash. Thanks, dstufft
 }}}

-- 
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] r17184 - django/trunk/tests/regressiontests/admin_scripts

[noreply]

Author: jezdez
Date: 2011-12-09 13:53:21 -0800 (Fri, 09 Dec 2011)
New Revision: 17184

Modified:
   django/trunk/tests/regressiontests/admin_scripts/tests.py
Log:
Fixed copy & paste mistake made in r17183.

Modified: django/trunk/tests/regressiontests/admin_scripts/tests.py
===
--- django/trunk/tests/regressiontests/admin_scripts/tests.py   2011-12-09 
21:50:28 UTC (rev 17183)
+++ django/trunk/tests/regressiontests/admin_scripts/tests.py   2011-12-09 
21:53:21 UTC (rev 17184)
@@ -1084,7 +1084,7 @@
 self.cmd.handle(addrport="7000")
 self.assertServerSettings('127.0.0.1', '7000')
 
-@unittest.skipUnless(socket.has_ipv6, 'markdown is installed')
+@unittest.skipUnless(socket.has_ipv6, "platform doesn't support IPv6")
 def test_runner_addrport_ipv6(self):
 self.cmd.handle(addrport="", use_ipv6=True)
 self.assertServerSettings('::1', '8000', ipv6=True, raw_ipv6=True)
@@ -1102,7 +1102,7 @@
 self.cmd.handle(addrport="test.domain.local:7000")
 self.assertServerSettings('test.domain.local', '7000')
 
-@unittest.skipUnless(socket.has_ipv6, 'markdown is installed')
+@unittest.skipUnless(socket.has_ipv6, "platform doesn't support IPv6")
 def test_runner_hostname_ipv6(self):
 self.cmd.handle(addrport="test.domain.local:7000", use_ipv6=True)
 self.assertServerSettings('test.domain.local', '7000', ipv6=True)

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] r17183 - django/trunk/tests/regressiontests/admin_scripts

[noreply]

Author: jezdez
Date: 2011-12-09 13:50:28 -0800 (Fri, 09 Dec 2011)
New Revision: 17183

Modified:
   django/trunk/tests/regressiontests/admin_scripts/tests.py
Log:
Fixed #16683 -- Skip the IPv6 runserver tests if the platform doesn't support 
it.

Modified: django/trunk/tests/regressiontests/admin_scripts/tests.py
===
--- django/trunk/tests/regressiontests/admin_scripts/tests.py   2011-12-09 
21:43:24 UTC (rev 17182)
+++ django/trunk/tests/regressiontests/admin_scripts/tests.py   2011-12-09 
21:50:28 UTC (rev 17183)
@@ -7,6 +7,7 @@
 
 import os
 import shutil
+import socket
 import sys
 import re
 
@@ -1056,11 +1057,14 @@
 self.assertNoOutput(err)
 self.assertOutput(out, '0 errors found')
 
+
 class ManageRunserver(AdminScriptTestCase):
 def setUp(self):
 from django.core.management.commands.runserver import 
BaseRunserverCommand
-def monkey_run(*args, **options): return
 
+def monkey_run(*args, **options):
+return
+
 self.cmd = BaseRunserverCommand()
 self.cmd.run = monkey_run
 
@@ -1080,7 +1084,8 @@
 self.cmd.handle(addrport="7000")
 self.assertServerSettings('127.0.0.1', '7000')
 
-# IPv6
+@unittest.skipUnless(socket.has_ipv6, 'markdown is installed')
+def test_runner_addrport_ipv6(self):
 self.cmd.handle(addrport="", use_ipv6=True)
 self.assertServerSettings('::1', '8000', ipv6=True, raw_ipv6=True)
 
@@ -1090,18 +1095,19 @@
 self.cmd.handle(addrport="[2001:0db8:1234:5678::9]:7000")
 self.assertServerSettings('2001:0db8:1234:5678::9', '7000', ipv6=True, 
raw_ipv6=True)
 
-# Hostname
+def test_runner_hostname(self):
 self.cmd.handle(addrport="localhost:8000")
 self.assertServerSettings('localhost', '8000')
 
 self.cmd.handle(addrport="test.domain.local:7000")
 self.assertServerSettings('test.domain.local', '7000')
 
+@unittest.skipUnless(socket.has_ipv6, 'markdown is installed')
+def test_runner_hostname_ipv6(self):
 self.cmd.handle(addrport="test.domain.local:7000", use_ipv6=True)
 self.assertServerSettings('test.domain.local', '7000', ipv6=True)
 
-# Potentially ambiguous
-
+def test_runner_ambiguous(self):
 # Only 4 characters, all of which could be in an ipv6 address
 self.cmd.handle(addrport="beef:7654")
 self.assertServerSettings('beef', '7654')

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #16683: Make ipv6 tests in regressiontests.admin_scripts.tests.ManageRunserver skippable if ipv6 support isn't present

[Django]

#16683: Make ipv6 tests in regressiontests.admin_scripts.tests.ManageRunserver
skippable if ipv6 support isn't present
---+
 Reporter:  bugs@… |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Testing framework  |  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:  new => closed
 * resolution:   => fixed


Comment:

 In [17183]:
 {{{
 #!CommitTicketReference repository="" revision="17183"
 Fixed #16683 -- Skip the IPv6 runserver tests if the platform doesn't
 support it.
 }}}

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

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

Re: [Django] #17093: Refactor django.template to quarantine global state

[Django]

#17093: Refactor django.template to quarantine global state
--+
 Reporter:  carljm|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Template system   |  Version:  SVN
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by anatoly techtonik ):

 * cc: techtonik@… (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] #17218: Select Filter (its "to" box) has 0 height if in a collapsed fieldset

[Django]

#17218: Select Filter (its "to" box) has 0 height if in a collapsed fieldset
---+-
 Reporter:  jimallman   |Owner:  jimallman
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  Version:  SVN
 Severity:  Release blocker|   Resolution:  fixed
 Keywords:  fieldset   | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  1  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  1
---+-

Comment (by adrian):

 Thanks for the patch, jimallman. I made a few changes before committing:

 * I used jQuery chaining so that we wouldn't have to look up
 {{{$(this).closest("fieldset")}}} twice.
 * I made a {{{resize_filters()}}} function so that we wouldn't have to
 define duplicate logic for the height normalization.
 * I used jQuery's {{{one()}}} method, which does the work of
 {{{unbind()}}}.

-- 
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] r17182 - django/trunk/django/contrib/admin/static/admin/js

[noreply]

Author: adrian
Date: 2011-12-09 13:43:24 -0800 (Fri, 09 Dec 2011)
New Revision: 17182

Modified:
   django/trunk/django/contrib/admin/static/admin/js/actions.min.js
   django/trunk/django/contrib/admin/static/admin/js/inlines.min.js
   django/trunk/django/contrib/admin/static/admin/js/prepopulate.min.js
Log:
Checking in latest results of running Google Closure Compiler on the admin JS. 
Looks like they changed the compiler output for 'false'

Modified: django/trunk/django/contrib/admin/static/admin/js/actions.min.js
===
--- django/trunk/django/contrib/admin/static/admin/js/actions.min.js
2011-12-09 21:41:20 UTC (rev 17181)
+++ django/trunk/django/contrib/admin/static/admin/js/actions.min.js
2011-12-09 21:43:24 UTC (rev 17182)
@@ -1,7 +1,7 @@
-(function(a){a.fn.actions=function(h){var 
b=a.extend({},a.fn.actions.defaults,h),e=a(this),f=false;checker=function(c){c?showQuestion():reset();a(e).attr("checked",c).parent().parent().toggleClass(b.selectedClass,c)};updateCounter=function(){var
 
c=a(e).filter(":checked").length;a(b.counterContainer).html(interpolate(ngettext("%(sel)s
 of %(cnt)s selected","%(sel)s of %(cnt)s 
selected",c),{sel:c,cnt:_actions_icnt},true));a(b.allToggle).attr("checked",function(){if(c==e.length){value=true;showQuestion()}else{value=
-false;clearAcross()}return 
value})};showQuestion=function(){a(b.acrossClears).hide();a(b.acrossQuestions).show();a(b.allContainer).hide()};showClear=function(){a(b.acrossClears).show();a(b.acrossQuestions).hide();a(b.actionContainer).toggleClass(b.selectedClass);a(b.allContainer).show();a(b.counterContainer).hide()};reset=function(){a(b.acrossClears).hide();a(b.acrossQuestions).hide();a(b.allContainer).hide();a(b.counterContainer).show()};clearAcross=function(){reset();a(b.acrossInput).val(0);a(b.actionContainer).removeClass(b.selectedClass)};
-a(b.counterContainer).show();a(this).filter(":checked").each(function(){a(this).parent().parent().toggleClass(b.selectedClass);updateCounter();a(b.acrossInput).val()==1&&showClear()});a(b.allToggle).show().click(function(){checker(a(this).attr("checked"));updateCounter()});a("div.actions
 span.question 
a").click(function(c){c.preventDefault();a(b.acrossInput).val(1);showClear()});a("div.actions
 span.clear 
a").click(function(c){c.preventDefault();a(b.allToggle).attr("checked",false);clearAcross();checker(0);
-updateCounter()});lastChecked=null;a(e).click(function(c){if(!c)c=window.event;var
 
d=c.target?c.target:c.srcElement;if(lastChecked&&a.data(lastChecked)!=a.data(d)&&c.shiftKey==true){var
 
g=false;a(lastChecked).attr("checked",d.checked).parent().parent().toggleClass(b.selectedClass,d.checked);a(e).each(function(){if(a.data(this)==a.data(lastChecked)||a.data(this)==a.data(d))g=g?false:true;g&&a(this).attr("checked",d.checked).parent().parent().toggleClass(b.selectedClass,d.checked)})}a(d).parent().parent().toggleClass(b.selectedClass,
-d.checked);lastChecked=d;updateCounter()});a("form#changelist-form 
table#result_list tr").find("td:gt(0) 
:input").change(function(){f=true});a('form#changelist-form 
button[name="index"]').click(function(){if(f)return confirm(gettext("You have 
unsaved changes on individual editable fields. If you run an action, your 
unsaved changes will be lost."))});a('form#changelist-form 
input[name="_save"]').click(function(){var c=false;a("div.actions select 
option:selected").each(function(){if(a(this).val())c=
-true});if(c)return f?confirm(gettext("You have selected an action, but you 
haven't saved your changes to individual fields yet. Please click OK to save. 
You'll need to re-run the action.")):confirm(gettext("You have selected an 
action, and you haven't made any changes on individual fields. You're probably 
looking for the Go button rather than the Save 
button."))})};a.fn.actions.defaults={actionContainer:"div.actions",counterContainer:"span.action-counter",allContainer:"div.actions
 span.all",acrossInput:"div.actions input.select-across",
+(function(a){a.fn.actions=function(g){var 
b=a.extend({},a.fn.actions.defaults,g),f=a(this),e=!1;checker=function(c){c?showQuestion():reset();a(f).attr("checked",c).parent().parent().toggleClass(b.selectedClass,c)};updateCounter=function(){var
 
c=a(f).filter(":checked").length;a(b.counterContainer).html(interpolate(ngettext("%(sel)s
 of %(cnt)s selected","%(sel)s of %(cnt)s 
selected",c),{sel:c,cnt:_actions_icnt},!0));a(b.allToggle).attr("checked",function(){c==f.length?(value=!0,showQuestion()):(value=
+!1,clearAcross());return 
value})};showQuestion=function(){a(b.acrossClears).hide();a(b.acrossQuestions).show();a(b.allContainer).hide()};showClear=function(){a(b.acrossClears).show();a(b.acrossQuestions).hide();a(b.actionContainer).toggleClass(b.selectedClass);a(b.allContainer).show();a(b.counterContainer).hide()};reset=function(){a(b.acrossClears).hide();a(b.acrossQuestions).hide();a(b.allContainer).hide();a(b.counterContainer).show()};clearAcross=function(){r

Re: [Django] #17218: Select Filter (its "to" box) has 0 height if in a collapsed fieldset

[Django]

#17218: Select Filter (its "to" box) has 0 height if in a collapsed fieldset
---+-
 Reporter:  jimallman   |Owner:  jimallman
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  Version:  SVN
 Severity:  Release blocker|   Resolution:  fixed
 Keywords:  fieldset   | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  1  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  1
---+-
Changes (by adrian):

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


Comment:

 In [17181]:
 {{{
 #!CommitTicketReference repository="" revision="17181"
 Fixed #17218 -- Fixed bug with SelectFilter where the 'to' box had a
 height=0 when it was within a collapsed fieldset. Thanks jimallman
 }}}

-- 
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] r17181 - django/trunk/django/contrib/admin/static/admin/js

[noreply]

Author: adrian
Date: 2011-12-09 13:41:20 -0800 (Fri, 09 Dec 2011)
New Revision: 17181

Modified:
   django/trunk/django/contrib/admin/static/admin/js/SelectFilter2.js
   django/trunk/django/contrib/admin/static/admin/js/collapse.js
   django/trunk/django/contrib/admin/static/admin/js/collapse.min.js
Log:
Fixed #17218 -- Fixed bug with SelectFilter where the 'to' box had a height=0 
when it was within a collapsed fieldset. Thanks jimallman

Modified: django/trunk/django/contrib/admin/static/admin/js/SelectFilter2.js
===
--- django/trunk/django/contrib/admin/static/admin/js/SelectFilter2.js  
2011-12-09 21:30:53 UTC (rev 17180)
+++ django/trunk/django/contrib/admin/static/admin/js/SelectFilter2.js  
2011-12-09 21:41:20 UTC (rev 17181)
@@ -97,7 +97,15 @@
 
 if (!is_stacked) {
 // In horizontal mode, give the same height to the two boxes.
-$(to_box).height($(filter_p).outerHeight() + 
$(from_box).outerHeight());
+var j_from_box = $(from_box);
+var j_to_box = $(to_box);
+var resize_filters = function() { 
j_to_box.height($(filter_p).outerHeight() + j_from_box.outerHeight()); }
+if (j_from_box.outerHeight() > 0) {
+resize_filters(); // This fieldset is already open. Resize now.
+} else {
+// This fieldset is probably collapsed. Wait for its 'show' 
event.
+j_to_box.closest('fieldset').one('show.fieldset', 
resize_filters);
+}
 }
 
 // Initial icon refresh

Modified: django/trunk/django/contrib/admin/static/admin/js/collapse.js
===
--- django/trunk/django/contrib/admin/static/admin/js/collapse.js   
2011-12-09 21:30:53 UTC (rev 17180)
+++ django/trunk/django/contrib/admin/static/admin/js/collapse.js   
2011-12-09 21:41:20 UTC (rev 17181)
@@ -12,11 +12,11 @@
// Add toggle to anchor tag
$("fieldset.collapse a.collapse-toggle").toggle(
function() { // Show
-   
$(this).text(gettext("Hide")).closest("fieldset").removeClass("collapsed");
+   
$(this).text(gettext("Hide")).closest("fieldset").removeClass("collapsed").trigger("show.fieldset",
 [$(this).attr("id")]);
return false;
},
function() { // Hide
-   
$(this).text(gettext("Show")).closest("fieldset").addClass("collapsed");
+   
$(this).text(gettext("Show")).closest("fieldset").addClass("collapsed").trigger("hide.fieldset",
 [$(this).attr("id")]);
return false;
}
);

Modified: django/trunk/django/contrib/admin/static/admin/js/collapse.min.js
===
--- django/trunk/django/contrib/admin/static/admin/js/collapse.min.js   
2011-12-09 21:30:53 UTC (rev 17180)
+++ django/trunk/django/contrib/admin/static/admin/js/collapse.min.js   
2011-12-09 21:41:20 UTC (rev 17181)
@@ -1,2 +1,2 @@
-(function(a){a(document).ready(function(){a("fieldset.collapse").each(function(c,b){if(a(b).find("div.errors").length==0){a(b).addClass("collapsed").find("h2").first().append('
 ('+gettext("Show")+")")}});a("fieldset.collapse 
a.collapse-toggle").toggle(function(){a(this).text(gettext("Hide")).closest("fieldset").removeClass("collapsed");return
 
false},function(){a(this).text(gettext("Show")).closest("fieldset").addClass("collapsed");
-return false})})})(django.jQuery);
+(function(a){a(document).ready(function(){a("fieldset.collapse").each(function(c,b){0==a(b).find("div.errors").length&&a(b).addClass("collapsed").find("h2").first().append('
 ('+gettext("Show")+")")});a("fieldset.collapse 
a.collapse-toggle").toggle(function(){a(this).text(gettext("Hide")).closest("fieldset").removeClass("collapsed").trigger("show.fieldset",[a(this).attr("id")]);return!1},function(){a(this).text(gettext("Show")).closest("fieldset").addClass("collapsed").trigger("hide.fieldset",
+[a(this).attr("id")]);return!1})})})(django.jQuery);

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] r17180 - django/trunk/django/contrib/admin/static/admin/js

[noreply]

Author: adrian
Date: 2011-12-09 13:30:53 -0800 (Fri, 09 Dec 2011)
New Revision: 17180

Modified:
   django/trunk/django/contrib/admin/static/admin/js/collapse.js
   django/trunk/django/contrib/admin/static/admin/js/collapse.min.js
Log:
Changed admin/js/collapse.js to take advantage of jQuery chaining in three 
places. Should make for a slight performance boost.

Modified: django/trunk/django/contrib/admin/static/admin/js/collapse.js
===
--- django/trunk/django/contrib/admin/static/admin/js/collapse.js   
2011-12-09 21:09:59 UTC (rev 17179)
+++ django/trunk/django/contrib/admin/static/admin/js/collapse.js   
2011-12-09 21:30:53 UTC (rev 17180)
@@ -3,9 +3,8 @@
// Add anchor tag for Show/Hide link
$("fieldset.collapse").each(function(i, elem) {
// Don't hide if fields in this fieldset have errors
-   if ( $(elem).find("div.errors").length == 0 ) {
-   $(elem).addClass("collapsed");
-   $(elem).find("h2").first().append(' (' + gettext("Show") +
')');
}
@@ -13,13 +12,11 @@
// Add toggle to anchor tag
$("fieldset.collapse a.collapse-toggle").toggle(
function() { // Show
-   $(this).text(gettext("Hide"));
-   
$(this).closest("fieldset").removeClass("collapsed");
+   
$(this).text(gettext("Hide")).closest("fieldset").removeClass("collapsed");
return false;
},
function() { // Hide
-   $(this).text(gettext("Show"));
-   
$(this).closest("fieldset").addClass("collapsed");
+   
$(this).text(gettext("Show")).closest("fieldset").addClass("collapsed");
return false;
}
);

Modified: django/trunk/django/contrib/admin/static/admin/js/collapse.min.js
===
--- django/trunk/django/contrib/admin/static/admin/js/collapse.min.js   
2011-12-09 21:09:59 UTC (rev 17179)
+++ django/trunk/django/contrib/admin/static/admin/js/collapse.min.js   
2011-12-09 21:30:53 UTC (rev 17180)
@@ -1,2 +1,2 @@
-(function(a){a(document).ready(function(){a("fieldset.collapse").each(function(c,b){if(a(b).find("div.errors").length==0){a(b).addClass("collapsed");a(b).find("h2").first().append('
 ('+gettext("Show")+")")}});a("fieldset.collapse 
a.collapse-toggle").toggle(function(){a(this).text(gettext("Hide"));a(this).closest("fieldset").removeClass("collapsed");return
 
false},function(){a(this).text(gettext("Show"));a(this).closest("fieldset").addClass("collapsed");
+(function(a){a(document).ready(function(){a("fieldset.collapse").each(function(c,b){if(a(b).find("div.errors").length==0){a(b).addClass("collapsed").find("h2").first().append('
 ('+gettext("Show")+")")}});a("fieldset.collapse 
a.collapse-toggle").toggle(function(){a(this).text(gettext("Hide")).closest("fieldset").removeClass("collapsed");return
 
false},function(){a(this).text(gettext("Show")).closest("fieldset").addClass("collapsed");
 return false})})})(django.jQuery);

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] r17179 - django/trunk/django/contrib/admin/static/admin/js

[noreply]

Author: adrian
Date: 2011-12-09 13:09:59 -0800 (Fri, 09 Dec 2011)
New Revision: 17179

Modified:
   django/trunk/django/contrib/admin/static/admin/js/SelectFilter2.js
Log:
Removed way-outdated comment in SelectFilter2.js admin JS file. And we should 
rename this to SelectFilter.js at some point

Modified: django/trunk/django/contrib/admin/static/admin/js/SelectFilter2.js
===
--- django/trunk/django/contrib/admin/static/admin/js/SelectFilter2.js  
2011-12-09 20:46:10 UTC (rev 17178)
+++ django/trunk/django/contrib/admin/static/admin/js/SelectFilter2.js  
2011-12-09 21:09:59 UTC (rev 17179)
@@ -1,8 +1,6 @@
 /*
 SelectFilter2 - Turns a multiple-select box into a filter interface.
 
-Different than SelectFilter because this is coupled to the admin framework.
-
 Requires core.js, SelectBox.js and addevent.js.
 */
 (function($) {

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #17348: Implement {% elif %} in the template language

[Django]

#17348: Implement {% elif %} in the template language
-+-
 Reporter:  aaugustin|Owner:  aaugustin
 Type:  New feature  |   Status:  new
Component:  Template system  |  Version:  SVN
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by aaugustin):

 Attached patch implements `{% elif %}`. It complements 3100-backwards-
 compatible.patch from #3100.

-- 
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] #10435: WSGI handler class cannot be overridden in runserver

[Django]

#10435: WSGI handler class cannot be overridden in runserver
-+-
 Reporter:  trevor   |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Core (Management |  Version:  SVN
  commands)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Design
 Keywords:   |  decision needed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by jezdez):

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


Comment:

 Huh, not sure why I haven't set this to fixed.

-- 
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] r17178 - django/trunk/docs/ref/contrib/admin

[noreply]

Author: adrian
Date: 2011-12-09 12:46:10 -0800 (Fri, 09 Dec 2011)
New Revision: 17178

Modified:
   django/trunk/docs/ref/contrib/admin/index.txt
Log:
Made some small clarifications to contrib/admin/index.txt

Modified: django/trunk/docs/ref/contrib/admin/index.txt
===
--- django/trunk/docs/ref/contrib/admin/index.txt   2011-12-09 19:53:06 UTC 
(rev 17177)
+++ django/trunk/docs/ref/contrib/admin/index.txt   2011-12-09 20:46:10 UTC 
(rev 17178)
@@ -28,7 +28,8 @@
 3. Add ``django.contrib.messages.context_processors.messages`` to
:setting:`TEMPLATE_CONTEXT_PROCESSORS` and
:class:`~django.contrib.messages.middleware.MessageMiddleware` to
-   :setting:`MIDDLEWARE_CLASSES`.
+   :setting:`MIDDLEWARE_CLASSES`. (These are both active by default, so
+   you only need to do this if you've manually tweaked the settings.)
 
 4. Determine which of your application's models should be editable in the
admin interface.
@@ -42,6 +43,9 @@
 
 7. Hook the ``AdminSite`` instance into your URLconf.
 
+After you've taken these steps, you'll be able to use your Django admin site
+by visiting the URL you hooked it into (``/admin/``, by default).
+
 Other topics
 
 

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #10868: _destroy_test_db exposes the production database to possibly destructive actions from the unit tests

[Django]

#10868: _destroy_test_db exposes the production database to possibly destructive
actions from the unit tests
-+-
 Reporter:  ovidiu   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Testing framework|  Version:
 Severity:  Release blocker  |   Resolution:
 Keywords:  django.test  | 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 adrian):

 * cc: adrian (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] #10868: _destroy_test_db exposes the production database to possibly destructive actions from the unit tests

[Django]

#10868: _destroy_test_db exposes the production database to possibly destructive
actions from the unit tests
-+-
 Reporter:  ovidiu   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Testing framework|  Version:
 Severity:  Release blocker  |   Resolution:
 Keywords:  django.test  | Triage Stage:  Design
Has patch:  0|  decision needed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by adrian):

 akaariai: Thanks for the detailed explanation. Even if we fixed line 323
 in backends/creation.py ({{{self.connection.settings_dict['NAME'] =
 old_database_name}}}), I think we'd still have a problem due to these
 lines (319-324) in {{{django/test/simple.py}}} --

 {{{#!python
 # Destroy all the non-mirror databases
 for connection, old_name, destroy in old_names:
 if destroy:
 connection.creation.destroy_test_db(old_name,
 self.verbosity)
 else:
 connection.settings_dict['NAME'] = old_name
 }}}

 I like your potential fix of making a copy of the settings dict to ensure
 it only affects the current thread -- so would we have to do the same
 thing in the {{{django/test/simple.py}}} lines above? Mind writing up a
 patch of this approach?

-- 
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] #10868: _destroy_test_db exposes the production database to possibly destructive actions from the unit tests

[Django]

#10868: _destroy_test_db exposes the production database to possibly destructive
actions from the unit tests
-+-
 Reporter:  ovidiu   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Testing framework|  Version:
 Severity:  Release blocker  |   Resolution:
 Keywords:  django.test  | Triage Stage:  Design
Has patch:  0|  decision needed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by adrian):

 Updated info: the code still lives in django/db/backends/creation.py but
 now it's lines 333-337, in the {{{_destroy_test_db()}}} method.

-- 
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] #10912: Autoescaping variable input in template tags

[Django]

#10912: Autoescaping variable input in template tags
-+-
 Reporter:  andrewbadr   |Owner:
 Type:  Bug  |   Status:  closed
Component:  Template system  |  Version:  1.0
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Design
Has patch:  1|  decision needed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  1
 |UI/UX:  0
-+-
Changes (by adrian):

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


Comment:

 OK, I'm marking this as fixed because the documentation is clear about the
 fact that firstof and cycle don't auto-escape. I also added a test for
 firstof (we already had one for cycle).

 Just for future reference, we added some original docs in [11163].

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

[noreply]

Author: adrian
Date: 2011-12-09 11:53:06 -0800 (Fri, 09 Dec 2011)
New Revision: 17177

Modified:
   django/trunk/docs/ref/templates/builtins.txt
Log:
Tweaked templates/builtins.txt to make it clearer that cycle and firstof 
filters don't auto-escape. Refs #10912

Modified: django/trunk/docs/ref/templates/builtins.txt
===
--- django/trunk/docs/ref/templates/builtins.txt2011-12-09 19:52:20 UTC 
(rev 17176)
+++ django/trunk/docs/ref/templates/builtins.txt2011-12-09 19:53:06 UTC 
(rev 17177)
@@ -88,9 +88,19 @@
 
 {% endfor %}
 
-Yes, you can mix variables and strings::
+Note that variable arguments (``rowvalue1`` and ``rowvalue2`` above) are NOT
+auto-escaped! So either make sure that you trust their values, or use explicit
+escaping, like this::
 
 {% for o in some_list %}
+
+...
+
+{% endfor %}
+
+You can mix variables and strings::
+
+{% for o in some_list %}
 
 ...
 
@@ -232,7 +242,8 @@
 firstof
 ^^^
 
-Outputs the first variable passed that is not False, without escaping.
+Outputs the first variable passed that is not False. Does NOT auto-escape
+variable values.
 
 Outputs nothing if all the passed variables are False.
 
@@ -258,9 +269,8 @@
 Note that the variables included in the firstof tag will not be
 escaped. This is because template tags do not escape their content.
 Any HTML or Javascript code contained in the printed variable will be
-rendered as-is, which could potentially lead to security issues.
-
-If you need to escape the variables in the firstof tag, you must do so
+rendered as-is, which could potentially lead to security issues. If you
+need to escape the variables in the firstof tag, you must do so
 explicitly::
 
 {% filter force_escape %}

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #10912: Autoescaping variable input in template tags

[Django]

#10912: Autoescaping variable input in template tags
-+-
 Reporter:  andrewbadr   |Owner:
 Type:  Bug  |   Status:  new
Component:  Template system  |  Version:  1.0
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Design
Has patch:  1|  decision needed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  1
 |UI/UX:  0
-+-

Comment (by adrian):

 In [17177]:
 {{{
 #!CommitTicketReference repository="" revision="17177"
 Tweaked templates/builtins.txt to make it clearer that cycle and firstof
 filters don't auto-escape. Refs #10912
 }}}

-- 
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] r17176 - django/trunk/tests/regressiontests/templates

[noreply]

Author: adrian
Date: 2011-12-09 11:52:20 -0800 (Fri, 09 Dec 2011)
New Revision: 17176

Modified:
   django/trunk/tests/regressiontests/templates/tests.py
Log:
Added a test that 'firstof' template filter doesn't auto-escape. cycle tag 
already has such a test (cycle20). Refs #10912

Modified: django/trunk/tests/regressiontests/templates/tests.py
===
--- django/trunk/tests/regressiontests/templates/tests.py   2011-12-07 
23:08:27 UTC (rev 17175)
+++ django/trunk/tests/regressiontests/templates/tests.py   2011-12-09 
19:52:20 UTC (rev 17176)
@@ -788,6 +788,7 @@
 'firstof07': ('{% firstof a b "c" %}', {'a':0}, 'c'),
 'firstof08': ('{% firstof a b "c and d" %}', {'a':0,'b':0}, 'c and 
d'),
 'firstof09': ('{% firstof %}', {}, template.TemplateSyntaxError),
+'firstof10': ('{% firstof a %}', {'a': '<'}, '<'), # Variables are 
NOT auto-escaped.
 
 ### FOR TAG 
###
 'for-tag01': ("{% for val in values %}{{ val }}{% endfor %}", 
{"values": [1, 2, 3]}, "123"),

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #10912: Autoescaping variable input in template tags

[Django]

#10912: Autoescaping variable input in template tags
-+-
 Reporter:  andrewbadr   |Owner:
 Type:  Bug  |   Status:  new
Component:  Template system  |  Version:  1.0
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Design
Has patch:  1|  decision needed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  1
 |UI/UX:  0
-+-

Comment (by adrian):

 In [17176]:
 {{{
 #!CommitTicketReference repository="" revision="17176"
 Added a test that 'firstof' template filter doesn't auto-escape. cycle tag
 already has such a test (cycle20). Refs #10912
 }}}

-- 
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] #3100: Support for arguments on intermediate tag tokens (ex. {% if arg %}{% elif arg %}{% endif %})

[Django]

#3100: Support for arguments on intermediate tag tokens (ex. {% if arg %}{% elif
arg %}{% endif %})
-+-
 Reporter:  Eric Van Dewoestine  |Owner:  aaugustin
 |   Status:  new
 Type:  New feature  |  Version:  SVN
Component:  Template system  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  1
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by aaugustin):

 Attached patch implement changes accept arguments on intermediary or final
 tags in a backwards compatible way.

 This is exercised by the new implementation of the `{% block %}` tag.
 Namely, template test `namedendblocks04` breaks if the changes in
 `django/template/loader_tags.py` are omitted.

-- 
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] #17365: Extend test discovery to inlcude unittest2 test suite runner (was: Add optional unittest2 discovery test suite runner)

[Django]

#17365: Extend test discovery to inlcude unittest2 test suite runner
---+
 Reporter:  jezdez |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Testing framework  |  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 jezdez):

 * stage:  Design decision needed => Accepted


Comment:

 Agreed, those points sound excellent. Marking as accepted and changing the
 subject to follow the direction of this ticket.

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

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

Re: [Django] #3100: Support for arguments on intermediate tag tokens (ex. {% if arg %}{% elif arg %}{% endif %})

[Django]

#3100: Support for arguments on intermediate tag tokens (ex. {% if arg %}{% elif
arg %}{% endif %})
-+-
 Reporter:  Eric Van Dewoestine  |Owner:  aaugustin
 |   Status:  new
 Type:  New feature  |  Version:  SVN
Component:  Template system  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  1
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by aaugustin):

 Here are some implementation details of the `Parser` class that I had to
 look up in the source in order to understand this ticket.

 An instance of `Parser` holds a list of tokens — the output of
 `Lexer.tokenize` — in its `tokens` instance variable. Its `parse` method
 builds a list of nodes (`nodelist`) by repeatedly popping the first token,
 compiling it, and appending to `nodelist` appropriate nodes.

 `parse` terminates:
   - when it reaches the end of the token stream;
   - when it receives a block token whose content is found in `parse_until`
 (when it was called with a `parse_until` argument).

 `parse_until` is used by tags that use final (or intermediary) tags, like
 `{% block ... %} {% endblock %}`, or `{% for ..%} {% empty %} {% endfor
 %}`. However, the current implementation requires that the exact content
 of the final (or intermediary) tag is known by the time the initial tag is
 compiled. This makes it impossible to have variable arguments on the
 intermediary tag.

 This feature is used to reject unmatched block/endblock tags: `{% block
 foo %}{% endblock bar %}`. I think this check should be delegated to the
 block tag itself. The alternative is to use Chris' technique — looking for
 an exact match by default, and for a prefix match for elements that end
 with a space — but it feels hackish.

-- 
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] #17365: Add optional unittest2 discovery test suite runner

[Django]

#17365: Add optional unittest2 discovery test suite runner
-+-
 Reporter:  jezdez   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Testing framework|  Version:  SVN
 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
-+-

Comment (by carljm):

 Summary of discussion with Jacob on IRC:

 - There's no reason for Django to ship two test runners, and test
 discovery doesn't bite in production, so the back-compat bar is lower. We
 should just do what we think is right and document the changes well.
 - Ignoring tests in `models.py` is fine, that's ugly and nobody should be
 doing it anyway (we do it 36 times in our own test suite, so we'd need to
 fix that).
 - There should be a way to a) discover tests in all `INSTALLED_APPS`, b)
 discover tests in a single app, c) discover tests under an arbitrary
 supplied root path, and d) discover tests rooted in the current directory.
 These could all be done with flags to `manage.py test`; e.g. `manage.py
 test` discovers based in `.`, `--installed` flag does all installed apps,
 `--app=app` for a single app, `--root=some/path`, etc. It would be ok to
 change the default from "all installed apps" to "discovery based in CWD",
 if it's easy for people to get back to "all installed apps" with a flag.

 Aymeric also suggested a `TEST_APPS` setting defaulting to
 `INSTALLED_APPS`, to set the default set of apps to discover tests in.
 This is something I've seen a lot of projects in the wild do.

-- 
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] #17368: Document django.template.add_to_builtins() or provide a standard way to add template tags from view code

[Django]

#17368: Document django.template.add_to_builtins() or provide a standard way to 
add
template tags from view code
-+-
 Reporter:  anatoly techtonik|Owner:  nobody
|   Status:  closed
 Type:  Uncategorized|  Version:  1.3
Component:  Template system  |   Resolution:  duplicate
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by ramiro):

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


Comment:

 Duplicate of #17085. Seem like it isn't worth pushing things in this path,
 but rather aim for the greater refactoring proposed in #17093.

-- 
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] #17370: https://docs.djangoproject.com/en/dev/howto/deployment/modwsgi/

[Django]

#17370: https://docs.djangoproject.com/en/dev/howto/deployment/modwsgi/
---+--
 Reporter:  anonymous  |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Uncategorized  |  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 carljm):

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


Comment:

 Please use words when filing bugs :-)

 The given URL is a 404, because the correct link in the current docs is
 https://docs.djangoproject.com/en/dev/howto/deployment/wsgi/modwsgi/

 If there are any incorrect links to the old URL within the docs, reopen
 with that information.

-- 
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] #17365: Add optional unittest2 discovery test suite runner

[Django]

#17365: Add optional unittest2 discovery test suite runner
-+-
 Reporter:  jezdez   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Testing framework|  Version:  SVN
 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
-+-

Comment (by carljm):

 #17366 is related.

-- 
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] #17365: Add optional unittest2 discovery test suite runner

[Django]

#17365: Add optional unittest2 discovery test suite runner
-+-
 Reporter:  jezdez   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Testing framework|  Version:  SVN
 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
-+-

Comment (by carljm):

 Replying to [comment:4 anonymous]:
 > IMO this should be the default, entirely replace django's manual test
 finding with discovery in both all applications as well as in a (setting?)
 defined list of extra places.

 Oh, somehow missed that comment. Yeah, that would be another option, to
 always do test discovery in all apps, and then have a setting that's a
 list of additional locations (`TEST_DIRS`?). The downside of that for me
 is that I would really like to have a way to disable running reusable app
 tests, and only run the tests internal to my project (whether they are
 kept in project-internal apps, or as I tend to prefer, in one tests
 directory for the whole project). So I'd like to have some (optional) way
 to say "please _don't_ do test discovery in all `INSTALLED_APPS`".

-- 
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] #17365: Add optional unittest2 discovery test suite runner

[Django]

#17365: Add optional unittest2 discovery test suite runner
-+-
 Reporter:  jezdez   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Testing framework|  Version:  SVN
 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
-+-

Comment (by carljm):

 Besides test discovery, the other thing this gives you is a more powerful
 way to specify which tests to run via commandline, by using real dotted
 path rather than the pseudo-dotted-path
 `applabel.TestCaseClass.testcasemethod`. Right now, if your tests within
 an app are split into submodules, there is no way to say "run just the
 tests in this module." You have to run either the entire app's tests, or a
 single `TestCase` subclass. With this runner, you can just give the real
 dotted path to the module.

 So we could make this the default for new `startproject`s without breaking
 back-compat. The biggest question is how to set `TEST_DISCOVERY_ROOT` by
 default. This is a bit of a puzzle, since we currently don't preset any
 settings with paths (e.g. users have to set `TEMPLATE_DIRS` and
 `STATICFILES_DIRS` themselves), and I'm not really interested in
 reintroducing any magic "find the project directory" code. I suppose one
 option would be to have `TEST_DISCOVERY_ROOT` default to empty, and if
 it's empty discover tests in all `INSTALLED_APPS` (but with robust
 discovery that includes all files matching the test* pattern, including
 sub-modules, not the "models.py and tests.py only" approach that we have
 now). Then if someone prefers keeping tests outside of apps, they could
 set `TEST_DISCOVERY_ROOT` to their preferred 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.

[Django] #17371: For DELETE requests TestClient encodes data as QUERY_STRING and forces an empty payload

[Django]

#17371: For DELETE requests TestClient encodes data as QUERY_STRING and forces 
an
empty payload
---+
 Reporter:  grzesiof@… |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  1.3
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 The Test Client's delete method is too limited.

 The http 1.1 rfc (http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html)
 doesn't specify that a request body is not allowed for DELETE requests. In
 fact the method is more similar to POST's and PUT's then it is to GET's.
 However when making a DELETE request with the test client the data is
 encoded as the query_string and no request-body-payload is provided
 
(https://code.djangoproject.com/browser/django/trunk/django/test/client.py#L313).

 I would personally make it behave the same way as POST's do, but I can
 imagine a lot of code may depend on the existing implementation.

-- 
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] #17370: https://docs.djangoproject.com/en/dev/howto/deployment/modwsgi/

[Django]

#17370: https://docs.djangoproject.com/en/dev/howto/deployment/modwsgi/
---+
 Reporter:  anonymous  |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  1.3
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+


-- 
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] #17144: Excessive GROUP BY clauses during aggregations.

[Django]

#17144: Excessive GROUP BY clauses during aggregations.
--+
 Reporter:  christian_oudard  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  ORM aggregation   |  Version:  1.3
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by sbussetti):

 This is a larger issue that merely the double inclusion of the pk.  For
 any query using annotation, ALL fields from query.select are listed in the
 groupby clause, even when it would only be appropriate for the grouping to
 only occur on the primary key.  For mysql this basically guarantees that
 all annotated queries will use the worst possible "Using temporary; Using
 filesort" method to evaluate the sql.

-- 
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] #17369: Useless error messages in management command execution

[Django]

#17369: Useless error messages in management command execution
+
 Reporter:  valexeev|  Owner:  nobody
 Type:  Bug | Status:  new
Component:  Core (Management commands)  |Version:  SVN
 Severity:  Normal  |   Keywords:
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  1
+
 Right now
 
[https://code.djangoproject.com/browser/django/trunk/django/core/management/base.py#L208
 BaseCommand.execute catches errors] and outputs quite useless portions of
 them.

 For example, I'm trying to move quite large (and, unfortunately,
 underdocumented) project from server to server. I know that I need to
 install a few components, but I do not precisely know which. So I just try
 running "runserver" command and fixing any errors occuring.

 But soon an error like this appears:
  Error: No module named exceptions

 Ok, how can this error message help me to learn what's the problem? In my
 opinion, it can't.

 But when I remove the try-catch from aforementioned method, I get a
 helpful traceback:
 {{{
 Traceback (most recent call last):
   File "manage.py", line 13, in 
 execute_manager(settings)
 [...]
   File "/[...]/utils.py", line 2, in 
 from sqlalchemy.exceptions import OperationalError
 ImportError: No module named exceptions
 }}}

 Oh, now I see that I obviously have problems with sqlalchemy installation.
 The source of the problem is pinned down and quickly fixed.

 The question is: what's the reason of having this try-catch in the first
 place, if it serves only to turn a helpful traceback into a useless 1-line
 error message? In my opinion, it should be removed altogether.

-- 
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] #17368: Document django.template.add_to_builtins() or provide a standard way to add template tags from view code

[Django]

#17368: Document django.template.add_to_builtins() or provide a standard way to 
add
template tags from view code
-+
 Reporter:  anatoly techtonik   |  Owner:  nobody
 Type:  Uncategorized| Status:  new
Component:  Template system  |Version:  1.3
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 https://docs.djangoproject.com/en/dev/howto/custom-template-tags/

 Currently, you need an obligatory `{% load %}` tag in all you templates if
 you want to use custom application tags. That's inconvenient. There is a
 `django.template.add_to_builtins()` function that accepts a string
 argument - a module name, which solves the problem. But this function is:

   1. Undocumented
   2. Module name is not convenient

 I propose the following mechanism:

 {{{
 from codereview import customtags

 django.template.add_library(customtags, default=True)
 }}}

-- 
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] #11154: Inconsistency with permissions for proxy models

[Django]

#11154: Inconsistency with permissions for proxy models
--+
 Reporter:  etianen   |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.auth  |  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 Kronuz):

 * cc: Kronuz (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] #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
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 Kronuz):

 * cc: Kronuz (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] #16111: Invalid SQL string representation from some queries

[Django]

#16111: Invalid SQL string representation from some queries
-+-
 Reporter:  Kronuz   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.3
  (models, ORM)  |   Resolution:  invalid
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Kronuz):

 * cc: Kronuz (added)
 * ui_ux:   => 0


Comment:

 Nope, my backend is PostgreSQL, the values are unescaped (by the
 stringification of the query)

-- 
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] #17367: PREPEND_WWW should warn on POSTs too

[Django]

#17367: PREPEND_WWW should warn on POSTs too
---+
 Reporter:  Tuttle |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Core (URLs)|Version:  SVN
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  1  |  UI/UX:  0
---+
 There is a nice on-DEBUG RuntimeError warning in the
 
[https://code.djangoproject.com/browser/django/tags/releases/1.3.1/django/middleware/common.py
 CommonMiddleware] saying that Django can't maintain POST data and redirect
 for APPENT_SLASH at the same time.

 There is also another redirect nearby that can be enabled by PREPEND_WWW.
 I think having similar POST warning would be handy for developers.

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

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

Re: [Django] #2879: Add live test server support to test framework

[Django]

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

 * stage:  Accepted => Ready for checkin


Comment:

 Replying to [comment:83 julien]:
 > Replying to [comment:76 jezdez]:
 > > - The new `LIVE_TEST_SERVER_HOST` and `LIVE_TEST_SERVER_PORT` settings
 are much too specific for Selenium (including the fact that "http" is
 hardcoded in `LiveServerTestCase`). I suggest introducing justa
 `LIVE_TEST_SERVER` setting instead and ask the users to give it a full
 URL, e.g. 'http://localhost/8081/'). Even though we have separate settings
 for email servers (`EMAIL_HOST` and `EMAIL_PORT`) the live test server has
 a lax API and shouldn't be hardwired to require protocol, host and port.
 >
 > Internally the `WSGIServer` opens a socket and binds it to a server
 address that has to be a pair (host, port), so we might have to keep that
 API too. What do you think?

 Ah, yeah, I misinterpreted the use. Looks good to me now.

 > > - The docs don't mention how to run the Selenium based tests except
 installing the selenium Python library. I suggest to add a small section
 about how to get Selenium to run in the first place (basically only where
 to download and how to run, like mentioned on
 http://pypi.python.org/pypi/selenium).
 >
 > As discussed on IRC, it is really as simple as installing the selenium
 package. The documentation could perhaps be improved, but it already
 contains all you need to get started.

 Yeah, I think this is fine for committing.

 > Finally, in the latest patch I've moved the live server tests to the
 already existing 'servers' app, and made a few small tweaks to the admin
 selenium tests.

 Woo!

-- 
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] #17337: [nonrel] Support for non-integer automatic primary keys (was: [nonrel] Support for non-integer primary keys)

[Django]

#17337: [nonrel] Support for non-integer automatic primary keys
-+-
 Reporter:  jonash   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  nonrel   |  Needs documentation:  0
Has patch:  1|  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] #17337: [nonrel] Support for non-integer primary keys

[Django]

#17337: [nonrel] Support for non-integer primary keys
-+-
 Reporter:  jonash   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  SVN
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  nonrel   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by aaugustin):

 * type:  Uncategorized => Bug


Comment:

 Two tickets (#17214, #17122)  were recently reported about problems in the
 admin with models using non-integer primary keys. A quick
 [https://code.djangoproject.com/search?q=primary_key&noquickjump=1&ticket=on
 search for "primary_key"] turns up lots of other problems with non-integer
 primary keys. Clearly people are trying to use them, and as far as I can
 see, [https://docs.djangoproject.com/en/dev/ref/models/fields/#primary-key
 the docs] don't forbid it.

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

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

[Django] #17366: Deprecate loading tests from models.py

[Django]

#17366: Deprecate loading tests from models.py
+
   Reporter:  Alex  |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Testing framework |Version:  SVN
   Severity:  Normal|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  1
  UI/UX:  0 |
+
 This is inconsistent with pretty much every other test tool, and really
 doesn't make a whole lot of sense.

-- 
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] #17365: Add optional unittest2 discovery test suite runner

[Django]

#17365: Add optional unittest2 discovery test suite runner
-+-
 Reporter:  jezdez   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Testing framework|  Version:  SVN
 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
-+-

Comment (by Alex):

 That was 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] #17365: Add optional unittest2 discovery test suite runner

[Django]

#17365: Add optional unittest2 discovery test suite runner
-+-
 Reporter:  jezdez   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Testing framework|  Version:  SVN
 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
-+-

Comment (by anonymous):

 IMO this should be the default, entirely replace django's manual test
 finding with discovery in both all applications as well as in a (setting?)
 defined list of extra places.

-- 
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] #17365: Add optional unittest2 discovery test suite runner

[Django]

#17365: Add optional unittest2 discovery test suite runner
-+-
 Reporter:  jezdez   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Testing framework|  Version:  SVN
 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 oinopion):

 * cc: tomek@… (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] #17365: Add optional unittest2 discovery test suite runner

[Django]

#17365: Add optional unittest2 discovery test suite runner
-+-
 Reporter:  jezdez   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Testing framework|  Version:  SVN
 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
-+-

Comment (by oinopion):

 It's backwards compatible and for me a clear win: it will be possible to
 find tests outside of installed apps.

-- 
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] #17365: Add optional unittest2 discovery test suite runner (was: Add discovery test suite runner)

[Django]

#17365: Add optional unittest2 discovery test suite runner
-+-
 Reporter:  jezdez   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Testing framework|  Version:  SVN
 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
-+-

-- 
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] #17365: Add discovery test suite runner

[Django]

#17365: Add discovery test suite runner
--+
   Reporter:  jezdez  |  Owner:  nobody
   Type:  New feature | Status:  new
  Component:  Testing framework   |Version:  SVN
   Severity:  Normal  |   Keywords:
   Triage Stage:  Design decision needed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+
 For projects wanting to support a more traditional approach to test suite
 discovery I'd like to propose to ship an optional subclass of the
 `DjangoTestSuiteRuner` class as described in @carljm's gist:
 https://gist.github.com/1450104

 It uses unittest2's test discovery feature behind the scenes as described
 in http://docs.python.org/dev/library/unittest.html#unittest-test-
 discovery

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