Re: [Django] #16285: Remove a misleading comment from the signing code

[Django]

#16285: Remove a misleading comment from the signing code
-+-
   Reporter:  PaulM  |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |  Component:  Core (Other)
  Milestone:  1.4|   Severity:  Normal
Version:  SVN|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  1  |
  UI/UX:  0  |
-+-
Changes (by aaugustin):

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


Comment:

 I think you can use salt for both puposes:

 - increasing security — then you need to store the salt somewhere and re-
 inject in when you verify the hash.
 - preventing injection of data from one part of an application into
 another — then the salt can be static.

 I accept the ticket because the second use-case sounds useful.

 I set "patch needs improvement" because I'd like to make sure we don't
 dismiss the first one too quickly.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #13956: Indefinite args for simpletags and inclusion tags

[Django]

#13956: Indefinite args for simpletags and inclusion tags
-+-
   Reporter:  melinath   |  Owner:  gregmuellegger
   Type:  New| Status:  assigned
  feature|  Component:  Template system
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:  simple_tag,
 Resolution: |  simpletag
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-

Comment (by melinath):

 Incidentally, passes with no unexpected failures.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #13956: Indefinite args for simpletags and inclusion tags

[Django]

#13956: Indefinite args for simpletags and inclusion tags
-+-
   Reporter:  melinath   |  Owner:  gregmuellegger
   Type:  New| Status:  assigned
  feature|  Component:  Template system
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:  simple_tag,
 Resolution: |  simpletag
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
Changes (by melinath):

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


Comment:

 This patch should address all concerns. Has docs and release notes. Has
 tests for everything - now modeled after and together with the other
 simple, inclusion, and assignment tests instead of elsewhere. Uses the
 backwards-compatible signature.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #16256: More class based views: formsets derived generic views

[Django]

#16256: More class based views: formsets derived generic views
---+---
   Reporter:  rasca|  Owner:  rasca
   Type:  New feature  | Status:  new
  Milestone:  1.4  |  Component:  Generic views
Version:  1.3  |   Severity:  Normal
 Resolution:   |   Keywords:
   Triage Stage:  Accepted |  Has patch:  1
Needs documentation:  1|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+---

Comment (by rasca):

 I do think the splitting of the view into a Create and a Update views is
 more like the other generic cbv views, although I end up joining them most
 of the times, but that's another issue.

 I still need a little more time to think about making views for 1 inline
 and for N inlines different. That way you end up having a formset_valid()
 in InlineFormSet which doesn't get used and might confuse people, for
 example.

 Anyone care to weight in on this?

 Being the logic the same in both implementations we might argue that the
 probability of it being correct is somewhat high =)

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #13956: Indefinite args for simpletags and inclusion tags

[Django]

#13956: Indefinite args for simpletags and inclusion tags
-+-
   Reporter:  melinath   |  Owner:  gregmuellegger
   Type:  New| Status:  assigned
  feature|  Component:  Template system
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:  simple_tag,
 Resolution: |  simpletag
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  1  |Needs tests:  1
Patch needs improvement:  1  |  Easy pickings:  0
  UI/UX:  0  |
-+-

Comment (by melinath):

 On the other hand, "beautiful is better than ugly". If I really want to
 maintain backwards-compatibility, I need to make the additional argument
 optional. Comparison:

 1. Original signature: `(params, defaults, name, node_class, parser,
 token)`
 2. New signature: `(parser, token, params, defaults, name, node_class,
 varargs)`
 3. Alternate: `(params, defaults, name, node_class, varargs, parser,
 token)`
 4. Backwards-compatible signature: `(params, defaults, name, node_class,
 parser, token, varargs=None)`

 4 is taking a turn down an inelegant path. I really would rather do 2 or
 3.

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

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

[Django] #16285: Remove a misleading comment from the signing code

[Django]

#16285: Remove a misleading comment from the signing code
--+--
 Reporter:  PaulM |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Milestone:  1.4   |  Component:  Core (Other)
  Version:  SVN   |   Severity:  Normal
 Keywords:|   Triage Stage:  Unreviewed
Has patch:  1 |  Easy pickings:  0
UI/UX:  0 |
--+--
 lines 99 and 100 of the signing module indicate that the provided salt is
 used to prevent brute forcing. This is misleading, it's actually necessary
 for namespacing signed strings, so that users can't take a signed string
 from one part of Django and put it into a different part which will trust
 it since it was properly signed.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #16199: Create a secure cookie-based session backend

[Django]

#16199: Create a secure cookie-based session backend
---+--
   Reporter:  floguy   |  Owner:  nobody
   Type:  New feature  | Status:  new
  Milestone:   |  Component:  contrib.sessions
Version:  SVN  |   Severity:  Normal
 Resolution:   |   Keywords:
   Triage Stage:  Accepted |  Has patch:  1
Needs documentation:  1|Needs tests:  0
Patch needs improvement:  1|  Easy pickings:  0
  UI/UX:  0|
---+--

Comment (by PaulM):

 Also Also (sorry for so many comments here), we're duplicating a lot of
 functionality. The string signer already does a bunch of the stuff that's
 in this module, albeit with JSON instead of pickle. Could we modify the
 signer to work with either JSON or pickle, and save ourselves a bunch of
 duplicated code? (e.g. the signer does a check to make sure the gzip is
 actually shorter, I don't see that here).

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

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

Re: [Django] #16199: Create a secure cookie-based session backend

[Django]

#16199: Create a secure cookie-based session backend
---+--
   Reporter:  floguy   |  Owner:  nobody
   Type:  New feature  | Status:  new
  Milestone:   |  Component:  contrib.sessions
Version:  SVN  |   Severity:  Normal
 Resolution:   |   Keywords:
   Triage Stage:  Accepted |  Has patch:  1
Needs documentation:  1|Needs tests:  0
Patch needs improvement:  1|  Easy pickings:  0
  UI/UX:  0|
---+--
Changes (by PaulM):

 * needs_better_patch:  0 => 1


Comment:

 I commented on #16182, but will go into more detail here. r16356 added 5
 digits of precision to the signed timestamp so that this cookie backend
 could pass the cookie rotation test. Adding these extra bits to our
 already limited cookie length isn't necessary, and the test should be
 modified to work with single-second precision for this backend.

 Unlike server-side session stores, when we rotate a cookie with this
 backend, we don't invalidate the previous one. In server side session
 stores, rotating a cookie should destroy access to the data server side,
 so we need to test that this rotation works immediately. In this backend,
 we can't invalidate previously signed cookies (other than letting them
 expire naturally). So requiring that setting a cookie then immediately
 rotating it produce a different cookie isn't meaningful.

 We can either skip the test entirely, wait for one second to pass before
 trying the rotate function, or do something excessively clever to modify
 the time in-place. I'm in favor of skipping the test and reverting r16356.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #16182: TimestampSigner should use a more precise timestamp

[Django]

#16182: TimestampSigner should use a more precise timestamp
-+-
   Reporter:  floguy |  Owner:  floguy
   Type:  Bug| Status:  reopened
  Milestone: |  Component:  Core (Other)
Version:  SVN|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Design |  Has patch:  1
  decision needed|Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by PaulM):

 * status:  closed => reopened
 * needs_better_patch:  1 => 0
 * resolution:  fixed =>
 * stage:  Ready for checkin => Design decision needed


Comment:

 I see this is already committed, but I'd like to raise an objection
 anyway. The timestamp signer was deliberately only using second-level
 precision. Multiplying by 10,000 significantly increases the length of our
 sig that we're storing in the already very limited 4095 bytes of the
 cookie space. We don't want to take up another couple of those when a user
 can be storing data there.

 I'll go into more detail in #16199, but signed cookies like this don't
 need this functionality for rotation. We're not invalidating any data on
 the backend, and a previously signed cookie is still technically valid
 until it expires even if we've rotated it on the users end.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #16199: Create a secure cookie-based session backend

[Django]

#16199: Create a secure cookie-based session backend
---+--
   Reporter:  floguy   |  Owner:  nobody
   Type:  New feature  | Status:  new
  Milestone:   |  Component:  contrib.sessions
Version:  SVN  |   Severity:  Normal
 Resolution:   |   Keywords:
   Triage Stage:  Accepted |  Has patch:  1
Needs documentation:  1|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+--

Comment (by PaulM):

 I see we have docs about max cookie length, but I'm concerned that's not
 going to be enough to help users who run into that issue debug it. Can we
 raise a warning (that could be caught and logged) when users are sending a
 cookie larger than the standard accepted size? It should trigger if the
 length of name + value + one for the equals sign is > 4095 (IE has the
 lowest limit).

 The warning might be best raised later on in the response. Since we're
 encouraging users to store lots of data in the cookie here, we should help
 them when they store too much.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #16256: More class based views: formsets derived generic views

[Django]

#16256: More class based views: formsets derived generic views
---+---
   Reporter:  rasca|  Owner:  rasca
   Type:  New feature  | Status:  new
  Milestone:  1.4  |  Component:  Generic views
Version:  1.3  |   Severity:  Normal
 Resolution:   |   Keywords:
   Triage Stage:  Accepted |  Has patch:  1
Needs documentation:  1|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+---

Comment (by AndrewIngram):

 I had a go at my own implementation of what you've done with regards to
 editing inline formsets alongside a model (but I didn't touch the admin
 itself), the logic is nearly identical to your solution (largely
 coincidence, but I did borrow ideas for naming conventions), but I've done
 my best to mimic the structure of Django's existing class-based views for
 editing objects. The two new concrete views are:

 - CreateWithInlinesView
 - UpdateWithInlinesView

 Each can take an inlines attribute which is a list of classes that extend
 InlineFormSet (which itself is just a bit of trickery around my
 InlineFormSetMixin which is used for the much simpler InlineFormSetView).

 Code is here: https://github.com/AndrewIngram/django-extra-
 views/blob/master/extra_views/advanced.py

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #13252: Use the natural key instead of the primary key when serializing

[Django]

#13252: Use the natural key instead of the primary key when serializing
-+-
   Reporter: |  Owner:  mtredinnick
  SmileyChris| Status:  reopened
   Type:  New|  Component:  Core
  feature|  (Serialization)
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  1  |
  UI/UX:  0  |
-+-
Changes (by SmileyChris):

 * needs_better_patch:  0 => 1


Comment:

 The new behaviour needs to be optional to be backwards compatible.

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

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

[Django]

#16282: CommentTemplateTagTests.testRenderCommentFormFromObjectWithQueryCount 
fails
on MySQL
+---
   Reporter:  ojii  |  Owner:  nobody
   Type:  Bug   | Status:  new
  Milestone:|  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 aaugustin):

 * stage:  Unreviewed => Accepted


Comment:

 The test doesn't fail in isolation:
 {{{
 tests % PYTHONPATH=.. ./runtests.py --settings=test_mysql comment_tests
 Creating test database for alias 'default'...
 
..
 --
 Ran 90 tests in 25.041s

 OK
 Destroying test database for alias 'default'...
 PYTHONPATH=.. ./runtests.py --settings=test_mysql comment_tests  13,78s
 user 1,53s system 55% cpu 27,642 total
 }}}

 It does in pair mode:
 {{{
 tests % PYTHONPATH=.. ./runtests.py --settings=test_mysql --pair
 text.TextTests.test_cookie_date

 (... snip ...)

 * 94 of 178: Check test pairing with comment_tests
 Creating test database for alias 'default'...
 
..F
 ==
 FAIL: testRenderCommentFormFromObjectWithQueryCount
 (regressiontests.comment_tests.tests.templatetag_tests.CommentTemplateTagTests)
 --
 Traceback (most recent call last):
   File "/Users/myk/Desktop/django-
 trunk/tests/regressiontests/comment_tests/tests/templatetag_tests.py",
 line 46, in testRenderCommentFormFromObjectWithQueryCount
 self.assertNumQueries(1, test)
   File "/Users/myk/Desktop/django-trunk/django/test/testcases.py", line
 549, in assertNumQueries
 func(*args, **kwargs)
   File "/Users/myk/Desktop/django-trunk/django/test/testcases.py", line
 234, in __exit__
 executed, self.num
 AssertionError: 2 != 1 : 2 queries executed, 1 expected

 (... snip ...)

 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #16284: djangojs uses en as fallback language rather than projects language code

[Django]

#16284: djangojs uses en as fallback language rather than projects language code
-+-
   Reporter:  anonymous  |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |  Component:
  Milestone: |  Internationalization
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Design |  Has patch:  0
  decision needed|Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by aaugustin):

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


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

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

Re: [Django] #16284: djangojs uses en as fallback language rather than projects language code

[Django]

#16284: djangojs uses en as fallback language rather than projects language code
-+-
   Reporter:  anonymous  |  Owner:  aaugustin
   Type: | Status:  assigned
  Cleanup/optimization   |  Component:
  Milestone: |  Internationalization
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Design |  Has patch:  0
  decision needed|Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by aaugustin):

 * status:  new => assigned
 * needs_better_patch:   => 0
 * component:  Uncategorized => Internationalization
 * needs_tests:   => 0
 * owner:  nobody => aaugustin
 * needs_docs:   => 0
 * type:  Uncategorized => Cleanup/optimization
 * stage:  Unreviewed => Design decision needed


Comment:

 Indeed, it's weird to have a special case for English.

 This dates back to r1560. Unfortunately, the commit message is not
 explicit, and it doesn't reference a ticket.

 That code was touched several times recently (r14901, r15404, r15441).
 #13726 is a good entry point, but I still don't understand very well
 what's going on there.

 I'll mark this ticket as DDN, because I think we need to check if the
 special case is useful, or if it's just an historic artifact.

 

 While investigating this ticket, I noticed there is another explicit
 reference to English as the "untranslated language" in
 `django.core.management.base.execute()`. The comment dates back to #5898,
 which was a refactoring, so it may be even older. It would be nice to
 check what's happening there too, and add an helpful comment for future
 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] #5831: Template Debug highlights wrong {% for %} tag

[Django]

#5831: Template Debug highlights wrong {% for %} tag
-+-
   Reporter:  Charmless  |  Owner:  vladmos
   | Status:  new
   Type:  Bug|  Component:  Template system
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:  debug for toplevel
 Resolution: |  nesting
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
Changes (by vladmos):

 * cc: m@… (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] #16283: manage.py depends on django.contrib.contenttypes et al. (was: my application project.auth takes models from django.contrib.auth)

[Django]

#16283: manage.py depends on django.contrib.contenttypes et al.
+--
   Reporter:  TheRoSS   |  Owner:  nobody
   Type:  Bug   | Status:  reopened
  Milestone:|  Component:  contrib.auth
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 |
+--
Changes (by aaugustin):

 * stage:  Unreviewed => Accepted


Comment:

 Your original report contained
 `django.contrib.auth.middleware.AuthenticationMiddleware`, and I missed
 the fact that the example you posted later on didn't — sorry about that.

 Thanks for your example. It really helped me reproduce the problem
 quickly. Indeed, I obtain this:
 {{{
 % ./manage.py sql --traceback all
 Error: One or more models did not validate:
 auth.permission: 'content_type' has a relation with model , which has either not
 been installed or is abstract.
 }}}

 And by raising an exception in `django.contrib.auth.models`, I reproduce
 your backtrace. It shows that `manage.py` depends on `contenttypes`,
 `admin` and `auth`, which is bad because django's core is supposed not to
 depend on contrib apps.

 The root cause of the problem is the fact that since r14563
 `django.core.management.validation` depends on
 `django.contrib.contenttypes`. I am going to update the summary to reflect
 this.

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

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

[Changeset] r16423 - in django/trunk: django/db/backends/postgresql_psycopg2 docs/ref docs/releases

[noreply]

Author: ramiro
Date: 2011-06-16 13:05:25 -0700 (Thu, 16 Jun 2011)
New Revision: 16423

Modified:
   django/trunk/django/db/backends/postgresql_psycopg2/base.py
   django/trunk/django/db/backends/postgresql_psycopg2/operations.py
   django/trunk/docs/ref/databases.txt
   django/trunk/docs/releases/1.4.txt
Log:
Fixed #16255 -- Raised minimum PostgreSQL version supported to 8.2.

Modified: django/trunk/django/db/backends/postgresql_psycopg2/base.py
===
--- django/trunk/django/db/backends/postgresql_psycopg2/base.py 2011-06-16 
19:56:22 UTC (rev 16422)
+++ django/trunk/django/db/backends/postgresql_psycopg2/base.py 2011-06-16 
20:05:25 UTC (rev 16423)
@@ -141,20 +141,11 @@
 cursor.execute("SET TIME ZONE %s", 
[settings_dict['TIME_ZONE']])
 if not hasattr(self, '_version'):
 self.__class__._version = get_version(cursor)
-if self._version[0:2] < (8, 0):
-# No savepoint support for earlier version of PostgreSQL.
-self.features.uses_savepoints = False
 if self.features.uses_autocommit:
-if self._version[0:2] < (8, 2):
-# FIXME: Needs extra code to do reliable model insert
-# handling, so we forbid it for now.
-from django.core.exceptions import ImproperlyConfigured
-raise ImproperlyConfigured("You cannot use autocommit=True 
with PostgreSQL prior to 8.2 at the moment.")
-else:
-# FIXME: Eventually we're enable this by default for
-# versions that support it, but, right now, that's hard to
-# do without breaking other things (#10509).
-self.features.can_return_id_from_insert = True
+# FIXME: Eventually we'll enable this by default for
+# versions that support it, but, right now, that's hard to
+# do without breaking other things (#10509).
+self.features.can_return_id_from_insert = True
 return CursorWrapper(cursor)
 
 def _enter_transaction_management(self, managed):

Modified: django/trunk/django/db/backends/postgresql_psycopg2/operations.py
===
--- django/trunk/django/db/backends/postgresql_psycopg2/operations.py   
2011-06-16 19:56:22 UTC (rev 16422)
+++ django/trunk/django/db/backends/postgresql_psycopg2/operations.py   
2011-06-16 20:05:25 UTC (rev 16423)
@@ -84,23 +84,13 @@
 
 def sql_flush(self, style, tables, sequences):
 if tables:
-if self.postgres_version[0:2] >= (8,1):
-# Postgres 8.1+ can do 'TRUNCATE x, y, z...;'. In fact, it 
*has to*
-# in order to be able to truncate tables referenced by a 
foreign
-# key in any other table. The result is a single SQL TRUNCATE
-# statement.
-sql = ['%s %s;' % \
-(style.SQL_KEYWORD('TRUNCATE'),
- style.SQL_FIELD(', '.join([self.quote_name(table) for 
table in tables]))
-)]
-else:
-# Older versions of Postgres can't do TRUNCATE in a single 
call, so
-# they must use a simple delete.
-sql = ['%s %s %s;' % \
-(style.SQL_KEYWORD('DELETE'),
- style.SQL_KEYWORD('FROM'),
- style.SQL_FIELD(self.quote_name(table))
- ) for table in tables]
+# Perform a single SQL 'TRUNCATE x, y, z...;' statement.  It allows
+# us to truncate tables referenced by a foreign key in any other
+# table.
+sql = ['%s %s;' % \
+(style.SQL_KEYWORD('TRUNCATE'),
+style.SQL_FIELD(', '.join([self.quote_name(table) for 
table in tables]))
+)]
 
 # 'ALTER SEQUENCE sequence_name RESTART WITH 1;'... style SQL 
statements
 # to reset sequence indices
@@ -171,17 +161,10 @@
 def check_aggregate_support(self, aggregate):
 """Check that the backend fully supports the provided aggregate.
 
-The population and sample statistics (STDDEV_POP, STDDEV_SAMP,
-VAR_POP, VAR_SAMP) were first implemented in Postgres 8.2.
-
 The implementation of population statistics (STDDEV_POP and VAR_POP)
 under Postgres 8.2 - 8.2.4 is known to be faulty. Raise
 NotImplementedError if this is the database in use.
 """
-if aggregate.sql_function in ('STDDEV_POP', 'STDDEV_SAMP', 'VAR_POP', 
'VAR_SAMP'):
-if self.postgres_version[0:2] < (8,2):
-raise NotImplementedError('PostgreSQL does not support %s 
prior to version 8.2. Please upgrade your version of PostgreSQL.' % 
aggregate.sql_function)
-
 if aggregate.sql_function in 

Re: [Django] #16255: Drop support for Posgres versions < 8.2 for Django 1.4

[Django]

#16255: Drop support for Posgres versions < 8.2 for Django 1.4
-+-
   Reporter:  ramiro |  Owner:  nobody
   Type: | Status:  closed
  Cleanup/optimization   |  Component:  Database layer
  Milestone:  1.4|  (models, ORM)
Version:  SVN|   Severity:  Normal
 Resolution:  fixed  |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
Changes (by ramiro):

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


Comment:

 In [16423]:
 {{{
 #!CommitTicketReference repository="" revision="16423"
 Fixed #16255 -- Raised minimum PostgreSQL version supported to 8.2.
 }}}

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

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

Re: [Django] #7198: manage.py sql/sqlall/test/etc. errors on apps without models.py files

[Django]

#7198: manage.py sql/sqlall/test/etc. errors on apps without models.py files
-+-
   Reporter:  gav|  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Core (Other)
Version:  SVN|   Severity:  Normal
 Resolution: |   Keywords:  management command
   Triage Stage:  Design |  sql sqlall
  decision needed|  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+-
Changes (by aaugustin):

 * easy:  0 => 1


Comment:

 Currently, the definition of a django application is: a package that
 contains a module named "models". For instance, see the note in
 https://docs.djangoproject.com/en/1.3/ref/settings/#installed-apps

 I suppose this hasn't gotten much attention because people consider it's
 part of the learning curve of Django.

 Gabriel Hurley, who is a core developer, proposed a solution in comment
 11. You're welcome to propose a patch implementing it, then ask for a
 review on the mailing list.

 However, if you want to lift the requirement that an app must contain a
 models.py file, you will have to check thoroughly the code and docs — the
 existence of this file is taken for granted in many 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] #8999: ModelAdmin.get_form and get_formset will overwrite self.exclude with a kwargs exclude

[Django]

#8999: ModelAdmin.get_form and get_formset will overwrite self.exclude with a
kwargs exclude
-+-
   Reporter:  seanl  |  Owner:  jkocherhans
   Type: | Status:  closed
  Cleanup/optimization   |  Component:  contrib.admin
  Milestone: |   Severity:  Normal
Version:  1.0|   Keywords:
 Resolution:  fixed  |  Has patch:  1
   Triage Stage:  Ready for  |Needs tests:  0
  checkin|  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by ramiro):

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


Comment:

 In [16422]:
 {{{
 #!CommitTicketReference repository="" revision="16422"
 Fixed #8999 -- Removed useless code in handling of `exclude` option in
 ModelAdmin and InlineModelAdmin custom form(set) hooks. Thanks goes to
 seanl for the report, patch and bkonkle and Julien for further work on
 final patch.
 }}}

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

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

[Changeset] r16422 - in django/trunk: django/contrib/admin tests/regressiontests/modeladmin

[noreply]

Author: ramiro
Date: 2011-06-16 12:56:22 -0700 (Thu, 16 Jun 2011)
New Revision: 16422

Modified:
   django/trunk/django/contrib/admin/options.py
   django/trunk/tests/regressiontests/modeladmin/tests.py
Log:
Fixed #8999 -- Removed useless code in handling of `exclude` option in 
ModelAdmin and InlineModelAdmin custom form(set) hooks. Thanks goes to seanl 
for the report, patch and bkonkle and Julien for further work on final patch.

Modified: django/trunk/django/contrib/admin/options.py
===
--- django/trunk/django/contrib/admin/options.py2011-06-16 16:42:54 UTC 
(rev 16421)
+++ django/trunk/django/contrib/admin/options.py2011-06-16 19:56:22 UTC 
(rev 16422)
@@ -433,7 +433,6 @@
 exclude = []
 else:
 exclude = list(self.exclude)
-exclude.extend(kwargs.get("exclude", []))
 exclude.extend(self.get_readonly_fields(request, obj))
 # if exclude is an empty list we pass None to be consistant with the
 # default on modelform_factory
@@ -1342,7 +1341,6 @@
 exclude = []
 else:
 exclude = list(self.exclude)
-exclude.extend(kwargs.get("exclude", []))
 exclude.extend(self.get_readonly_fields(request, obj))
 # if exclude is an empty list we use None, since that's the actual
 # default

Modified: django/trunk/tests/regressiontests/modeladmin/tests.py
===
--- django/trunk/tests/regressiontests/modeladmin/tests.py  2011-06-16 
16:42:54 UTC (rev 16421)
+++ django/trunk/tests/regressiontests/modeladmin/tests.py  2011-06-16 
19:56:22 UTC (rev 16422)
@@ -141,6 +141,63 @@
 type(ma.get_form(request).base_fields['sign_date'].widget),
 AdminDateWidget)
 
+def test_form_exclude_kwarg_override(self):
+"""
+Ensure that the `exclude` kwarg passed to `ModelAdmin.get_form()`
+overrides all other declarations. Refs #8999.
+"""
+
+class AdminBandForm(forms.ModelForm):
+
+class Meta:
+model = Band
+exclude = ['name']
+
+class BandAdmin(ModelAdmin):
+exclude = ['sign_date',]
+form = AdminBandForm
+
+def get_form(self, request, obj=None, **kwargs):
+kwargs['exclude'] = ['bio']
+return super(BandAdmin, self).get_form(request, obj, **kwargs)
+
+ma = BandAdmin(Band, self.site)
+self.assertEqual(ma.get_form(request).base_fields.keys(),
+['name', 'sign_date',])
+
+
+def test_formset_exclude_kwarg_override(self):
+"""
+Ensure that the `exclude` kwarg passed to 
`InlineModelAdmin.get_formset()`
+overrides all other declarations. Refs #8999.
+"""
+
+class AdminConcertForm(forms.ModelForm):
+
+class Meta:
+model = Concert
+exclude = ['day']
+
+class ConcertInline(TabularInline):
+exclude = ['transport']
+form = AdminConcertForm
+fk_name = 'main_band'
+model = Concert
+
+def get_formset(self, request, obj=None, **kwargs):
+kwargs['exclude'] = ['opening_band']
+return super(ConcertInline, self).get_formset(request, obj, 
**kwargs)
+
+class BandAdmin(ModelAdmin):
+inlines = [
+ConcertInline
+]
+
+ma = BandAdmin(Band, self.site)
+self.assertEqual(
+list(ma.get_formsets(request))[0]().forms[0].fields.keys(),
+['main_band', 'day', 'transport', 'id', 'DELETE',])
+
 def test_queryset_override(self):
 # If we need to override the queryset of a ModelChoiceField in our 
custom form
 # make sure that RelatedFieldWidgetWrapper doesn't mess that up.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #3104: 'float' object has no attribute 'split'

[Django]

#3104: 'float' object has no attribute 'split'
-+--
   Reporter:  anonymous  |  Owner:  nobody
   Type:  defect | Status:  closed
  Milestone: |  Component:  Core (Other)
Version: |   Severity:  normal
 Resolution:  invalid|   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:  reopened => closed
 * resolution:   => invalid


Comment:

 Your problem occurs inside `urllib.urlopen(someurl)` in your own code, so
 it's completely unrelated to Django, let alone to the ticket you reopened.

 This tracker is not the right place to discuss Python usage problems.
 Please ask such questions in a Python developers forum / chat instead.

 PS: my guess is that `someurl` is `None`.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #16283: my application project.auth takes models from django.contrib.auth

[Django]

#16283: my application project.auth takes models from django.contrib.auth
--+--
   Reporter:  TheRoSS |  Owner:  nobody
   Type:  Bug | Status:  reopened
  Milestone:  |  Component:  contrib.auth
Version:  1.3 |   Severity:  Normal
 Resolution:  |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+--
Changes (by TheRoSS):

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


Comment:

 I think there is a misunderstanding between us...
 I didn't used 'django.contrib.auth' at all, look at my second post,
 please.
 There is no 'django.contrib.auth.middleware.!AuthenticationMiddleware' in
 MIDDLEWARE_CLASSES

 I raised an exeption at the beginning of 'django.contrib.auth.models'.
 Look at the exception stack, please:

 {{{
 Traceback (most recent call last):
   File "C:\home\dev\seka\seka\manage.py", line 14, in 
 execute_manager(settings)
   File "C:\home\python\lib\site-
 packages\django\core\management\__init__.py", line 438, in execute_manager
 utility.execute()
   File "C:\home\python\lib\site-
 packages\django\core\management\__init__.py", line 379, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "C:\home\python\lib\site-packages\django\core\management\base.py",
 line 191, in run_from_argv
 self.execute(*args, **options.__dict__)
   File "C:\home\python\lib\site-packages\django\core\management\base.py",
 line 219, in execute
 self.validate()
   File "C:\home\python\lib\site-packages\django\core\management\base.py",
 line 243, in validate
 from django.core.management.validation import get_validation_errors
   File "C:\home\python\lib\site-
 packages\django\core\management\validation.py", line 3, in 
 from django.contrib.contenttypes.generic import GenericForeignKey,
 GenericRelation
   File "C:\home\python\lib\site-
 packages\django\contrib\contenttypes\generic.py", line 13, in 
 from django.contrib.admin.options import InlineModelAdmin,
 flatten_fieldsets
   File "C:\home\python\lib\site-
 packages\django\contrib\admin\__init__.py", line 6, in 
 from django.contrib.admin.sites import AdminSite, site
   File "C:\home\python\lib\site-packages\django\contrib\admin\sites.py",
 line 4, in 
 from django.contrib.admin.forms import AdminAuthenticationForm
   File "C:\home\python\lib\site-packages\django\contrib\admin\forms.py",
 line 4, in 
 from django.contrib.auth.forms import AuthenticationForm
   File "C:\home\python\lib\site-packages\django\contrib\auth\forms.py",
 line 1, in 
 from django.contrib.auth.models import User
   File "C:\home\python\lib\site-packages\django\contrib\auth\models.py",
 line 15, in 
 raise 'AUTH MODELS CALLED'
 }}}

 So 'auth' package was called from 'admin' package which was called from
 'contenttypes' which was called from django core.

 I didn't included those packages in my settings, but they were called
 anymore.
 Is this ok?
 Are the names 'auth', 'admin', 'contenttypes' magic and forbidden to use
 as an application names?

 I attach my zipped example project with this message, hope it will be
 helpful.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #13161: Ticked 2514 and 5171, solution for using Django with other psycopg2 applications.

[Django]

#13161: Ticked 2514 and 5171, solution for using Django with other psycopg2
applications.
-+-
   Reporter:  spoksss|  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Database layer
Version:  1.2-beta   |  (models, ORM)
 Resolution: |   Severity:  Normal
   Triage Stage:  Accepted   |   Keywords:  psycopg2, unicode
Needs documentation:  0  |  Has patch:  1
Patch needs improvement:  0  |Needs tests:  1
  UI/UX:  0  |  Easy pickings:  0
-+-
Changes (by spoksss):

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


Comment:

 Hi,
 what is status of this bug?
 It is possible that the patch will be applied to trunk?

 regards,

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #3104: 'float' object has no attribute 'split'

[Django]

#3104: 'float' object has no attribute 'split'
-+--
   Reporter:  anonymous  |  Owner:  nobody
   Type:  defect | Status:  reopened
  Milestone: |  Component:  Core (Other)
Version: |   Severity:  normal
 Resolution: |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+--
Changes (by anonymous):

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


Comment:

 Having AttributeError 'NoneType' object has no attribute 'strip' problem
 Environment:


 Request Method: GET
 Request URL: http://172.16.13.46:8080/addRecord/

 Django Version: 1.3
 Python Version: 2.6.6
 Installed Applications:
 ['django.contrib.auth',
  'django.contrib.contenttypes',
  'django.contrib.sessions',
  'django.contrib.sites',
  'django.contrib.messages',
  'django.contrib.staticfiles',
  'django.contrib.admin',
  'django.contrib.admindocs',
  'CI']
 Installed Middleware:
 ('django.middleware.common.CommonMiddleware',
  'django.contrib.sessions.middleware.SessionMiddleware',
  'django.middleware.csrf.CsrfViewMiddleware',
  'django.middleware.csrf.CsrfResponseMiddleware',
  'django.contrib.auth.middleware.AuthenticationMiddleware',
  'django.contrib.messages.middleware.MessageMiddleware')


 Traceback:
 File "/usr/local/lib/python2.6/dist-packages/django/core/handlers/base.py"
 in get_response
   111. response = callback(request,
 *callback_args, **callback_kwargs)
 File "/home/dbarker/cisite/CI/views.py" in addRecord
   73.   u_data = collectdata(u) #collect the url information
 File "/home/dbarker/cisite/CI/datagrab.py" in collectdata
   48. data = urllib.urlopen(someurl)
 File "/usr/lib/python2.6/urllib.py" in urlopen
   86. return opener.open(url)
 File "/usr/lib/python2.6/urllib.py" in open
   179. fullurl = unwrap(toBytes(fullurl))
 File "/usr/lib/python2.6/urllib.py" in unwrap
   1034. url = url.strip()

 Exception Type: AttributeError at /addRecord/
 Exception Value: 'NoneType' object has no attribute 'strip'

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

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

Re: [Django] #7198: manage.py sql/sqlall/test/etc. errors on apps without models.py files

[Django]

#7198: manage.py sql/sqlall/test/etc. errors on apps without models.py files
-+-
   Reporter:  gav|  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Core (Other)
Version:  SVN|   Severity:  Normal
 Resolution: |   Keywords:  management command
   Triage Stage:  Design |  sql sqlall
  decision needed|  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
Changes (by benedict.m.holland@…):

 * ui_ux:   => 0


Comment:

 I just recreated this bug. The fix of creating a blank models.py still
 works. This error is extremely misleading because the app is actually
 installed correctly in the settings.py and accessible. I couldn't believe
 that this is such an edge case to not get any attention over 4 years, but
 maybe this is just the case. BTW, I recreated this bug in 1.3.

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

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

Re: [Django] #16199: Create a secure cookie-based session backend

[Django]

#16199: Create a secure cookie-based session backend
---+--
   Reporter:  floguy   |  Owner:  nobody
   Type:  New feature  | Status:  new
  Milestone:   |  Component:  contrib.sessions
Version:  SVN  |   Severity:  Normal
 Resolution:   |   Keywords:
   Triage Stage:  Accepted |  Has patch:  1
Needs documentation:  1|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+--

Comment (by apollo13):

 Since we are 2.5+ we can replace ''session_key =
 property(_get_session_key, _set_session_key)'' with ''@property''. Aside
 from that ''contrib/session/tests.py'' need future imports for the with
 statement.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] r16421 - django/branches/releases/1.3.X/docs/ref/contrib/comments

[noreply]

Author: jezdez
Date: 2011-06-16 09:42:54 -0700 (Thu, 16 Jun 2011)
New Revision: 16421

Modified:
   django/branches/releases/1.3.X/docs/ref/contrib/comments/example.txt
   django/branches/releases/1.3.X/docs/ref/contrib/comments/index.txt
Log:
[1.3.X] Fixed #16031 -- Corrected comments template examples. Thanks, teraom.

Backport from trunk (r16412).

Modified: django/branches/releases/1.3.X/docs/ref/contrib/comments/example.txt
===
--- django/branches/releases/1.3.X/docs/ref/contrib/comments/example.txt
2011-06-16 16:41:14 UTC (rev 16420)
+++ django/branches/releases/1.3.X/docs/ref/contrib/comments/example.txt
2011-06-16 16:42:54 UTC (rev 16421)
@@ -103,13 +103,16 @@
   
   
-  
-{{ form }}
-
-  
-  
-
-  
+
+  {% csrf_token %}
+  {{ form }}
+  
+
+  
+  
+
+  
+
   
 
 Flagging

Modified: django/branches/releases/1.3.X/docs/ref/contrib/comments/index.txt
===
--- django/branches/releases/1.3.X/docs/ref/contrib/comments/index.txt  
2011-06-16 16:41:14 UTC (rev 16420)
+++ django/branches/releases/1.3.X/docs/ref/contrib/comments/index.txt  
2011-06-16 16:42:54 UTC (rev 16421)
@@ -218,13 +218,18 @@
 A complete form might look like::
 
 {% get_comment_form for event as form %}
-
-  {{ form }}
-  
-
-
-  
-
+
+  
+{% csrf_token %}
+{{ form }}
+
+  
+
+
+  
+
+  
+
 
 Be sure to read the `notes on the comment form`_, below, for some special
 considerations you'll need to make if you're using this approach.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #16031: Custom comment form is incomplete and wrong.

[Django]

#16031: Custom comment form is incomplete and wrong.
-+-
   Reporter:  ddshore@…  |  Owner:  teraom
   Type: | Status:  closed
  Cleanup/optimization   |  Component:  Documentation
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution:  fixed  |  Has patch:  1
   Triage Stage:  Ready for  |Needs tests:  0
  checkin|  Easy pickings:  1
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-

Comment (by jezdez):

 In [16421]:
 {{{
 #!CommitTicketReference repository="" revision="16421"
 [1.3.X] Fixed #16031 -- Corrected comments template examples. Thanks,
 teraom.

 Backport from trunk (r16412).
 }}}

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

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

[noreply]

Author: jezdez
Date: 2011-06-16 09:41:14 -0700 (Thu, 16 Jun 2011)
New Revision: 16420

Added:
   django/trunk/tests/regressiontests/urlpatterns_reverse/erroneous_urls.py
   
django/trunk/tests/regressiontests/urlpatterns_reverse/erroneous_views_module.py
Modified:
   django/trunk/django/core/urlresolvers.py
   django/trunk/tests/regressiontests/urlpatterns_reverse/tests.py
   django/trunk/tests/regressiontests/urlpatterns_reverse/views.py
Log:
Fixed #10802 -- Handle ImportErrors and AttributeErrors gracefully when raised 
by the URL resolver system during startup. Many thanks, IonelMaries and Bas 
Peschier.

Modified: django/trunk/django/core/urlresolvers.py
===
--- django/trunk/django/core/urlresolvers.py2011-06-16 16:35:04 UTC (rev 
16419)
+++ django/trunk/django/core/urlresolvers.py2011-06-16 16:41:14 UTC (rev 
16420)
@@ -16,6 +16,7 @@
 from django.utils.encoding import iri_to_uri, force_unicode, smart_str
 from django.utils.functional import memoize, lazy
 from django.utils.importlib import import_module
+from django.utils.module_loading import module_has_submodule
 from django.utils.regex_helper import normalize
 from django.utils.translation import get_language
 
@@ -84,19 +85,28 @@
 during the import fail and the string is returned.
 """
 if not callable(lookup_view):
+mod_name, func_name = get_mod_func(lookup_view)
 try:
-# Bail early for non-ASCII strings (they can't be functions).
-lookup_view = lookup_view.encode('ascii')
-mod_name, func_name = get_mod_func(lookup_view)
 if func_name != '':
 lookup_view = getattr(import_module(mod_name), func_name)
 if not callable(lookup_view):
-raise AttributeError("'%s.%s' is not a callable." % 
(mod_name, func_name))
-except (ImportError, AttributeError):
+raise ViewDoesNotExist(
+"Could not import %s.%s. View is not callable."
+% (mod_name, func_name))
+except AttributeError:
 if not can_fail:
+raise ViewDoesNotExist(
+"Could not import %s. View does not exist in module %s."
+% (lookup_view, mod_name))
+except ImportError:
+ownermod, submod = get_mod_func(mod_name)
+if (not can_fail and submod != '' and
+not module_has_submodule(import_module(ownermod), submod)):
+raise ViewDoesNotExist(
+"Could not import %s. Owning module %s does not exist."
+% (lookup_view, mod_name))
+if not can_fail:
 raise
-except UnicodeEncodeError:
-pass
 return lookup_view
 get_callable = memoize(get_callable, _callable_cache, 1)
 
@@ -192,14 +202,8 @@
 def callback(self):
 if self._callback is not None:
 return self._callback
-try:
-self._callback = get_callable(self._callback_str)
-except ImportError, e:
-mod_name, _ = get_mod_func(self._callback_str)
-raise ViewDoesNotExist("Could not import %s. Error was: %s" % 
(mod_name, str(e)))
-except AttributeError, e:
-mod_name, func_name = get_mod_func(self._callback_str)
-raise ViewDoesNotExist("Tried %s in module %s. Error was: %s" % 
(func_name, mod_name, str(e)))
+
+self._callback = get_callable(self._callback_str)
 return self._callback
 
 class RegexURLResolver(LocaleRegexProvider):
@@ -325,10 +329,7 @@
 # Lazy import, since urls.defaults imports this file
 from django.conf.urls import defaults
 callback = getattr(defaults, 'handler%s' % view_type)
-try:
-return get_callable(callback), {}
-except (ImportError, AttributeError), e:
-raise ViewDoesNotExist("Tried %s. Error was: %s" % (callback, 
str(e)))
+return get_callable(callback), {}
 
 def resolve404(self):
 return self._resolve_special('404')

Added: django/trunk/tests/regressiontests/urlpatterns_reverse/erroneous_urls.py
===
--- django/trunk/tests/regressiontests/urlpatterns_reverse/erroneous_urls.py
(rev 0)
+++ django/trunk/tests/regressiontests/urlpatterns_reverse/erroneous_urls.py
2011-06-16 16:41:14 UTC (rev 16420)
@@ -0,0 +1,14 @@
+from django.conf.urls.defaults import patterns, url
+
+urlpatterns = patterns('',
+# View has erroneous import
+url(r'erroneous_inner/$', 
'regressiontests.urlpatterns_reverse.views.erroneous_view'),
+# Module has erroneous import
+url(r'erroneous_outer/$', 
'regressiontests.urlpatterns_reverse.erroneous_views_module.erroneous_view'),
+# View does not exist
+url(r'missing_inner/$', 
'regressiontests.urlpatterns_

Re: [Django] #10802: urlresolvers RegexURLResolver._get_callback should not catch ImportError and AttributeError

[Django]

#10802: urlresolvers RegexURLResolver._get_callback should not catch ImportError
and AttributeError
-+-
   Reporter: |  Owner:  nobody
  IonelMaries| Status:  closed
   Type:  Bug|  Component:  Core (Other)
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:
 Resolution:  fixed  |  Has patch:  1
   Triage Stage:  Ready for  |Needs tests:  0
  checkin|  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by jezdez):

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


Comment:

 In [16420]:
 {{{
 #!CommitTicketReference repository="" revision="16420"
 Fixed #10802 -- Handle ImportErrors and AttributeErrors gracefully when
 raised by the URL resolver system during startup. Many thanks, IonelMaries
 and Bas Peschier.
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #9588: provide **kwargs argument to GenericInlineModelAdmin.get_formset

[Django]

#9588: provide **kwargs argument to GenericInlineModelAdmin.get_formset
-+-
   Reporter:  lakin@…|  Owner:  brosner
   Type:  New| Status:  closed
  feature|  Component:
  Milestone: |  contrib.contenttypes
Version:  SVN|   Severity:  Normal
 Resolution:  fixed  |   Keywords:
   Triage Stage:  Ready for  |  Has patch:  1
  checkin|Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
-+-
Changes (by jezdez):

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


Comment:

 In [16419]:
 {{{
 #!CommitTicketReference repository="" revision="16419"
 Fixed #9588 -- Allow passing kwargs to
 `GenericInlineModelAdmin.get_formset` just like the InlineModelAdmin.
 Thanks, prestontimmons.
 }}}

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

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

[noreply]

Author: jezdez
Date: 2011-06-16 09:35:04 -0700 (Thu, 16 Jun 2011)
New Revision: 16419

Modified:
   django/trunk/django/contrib/contenttypes/generic.py
   django/trunk/tests/regressiontests/generic_inline_admin/tests.py
Log:
Fixed #9588 -- Allow passing kwargs to `GenericInlineModelAdmin.get_formset` 
just like the InlineModelAdmin. Thanks, prestontimmons.

Modified: django/trunk/django/contrib/contenttypes/generic.py
===
--- django/trunk/django/contrib/contenttypes/generic.py 2011-06-16 16:34:55 UTC 
(rev 16418)
+++ django/trunk/django/contrib/contenttypes/generic.py 2011-06-16 16:35:04 UTC 
(rev 16419)
@@ -396,7 +396,7 @@
 ct_fk_field = "object_id"
 formset = BaseGenericInlineFormSet
 
-def get_formset(self, request, obj=None):
+def get_formset(self, request, obj=None, **kwargs):
 if self.declared_fieldsets:
 fields = flatten_fieldsets(self.declared_fieldsets)
 else:
@@ -420,6 +420,7 @@
 "max_num": self.max_num,
 "exclude": exclude
 }
+defaults.update(kwargs)
 return generic_inlineformset_factory(self.model, **defaults)
 
 class GenericStackedInline(GenericInlineModelAdmin):

Modified: django/trunk/tests/regressiontests/generic_inline_admin/tests.py
===
--- django/trunk/tests/regressiontests/generic_inline_admin/tests.py
2011-06-16 16:34:55 UTC (rev 16418)
+++ django/trunk/tests/regressiontests/generic_inline_admin/tests.py
2011-06-16 16:35:04 UTC (rev 16419)
@@ -1,12 +1,13 @@
 # coding: utf-8
 
 from django.conf import settings
+from django.contrib.admin.sites import AdminSite
 from django.contrib.contenttypes.generic import generic_inlineformset_factory
 from django.test import TestCase
 
 # local test models
-from models import Episode, EpisodeExtra, EpisodeMaxNum, EpisodeExclude, \
-   Media, EpisodePermanent, MediaPermanentInline, Category
+from models import (Episode, EpisodeExtra, EpisodeMaxNum, EpisodeExclude,
+Media, MediaInline, EpisodePermanent, MediaPermanentInline, Category)
 
 
 class GenericAdminViewTest(TestCase):
@@ -214,3 +215,18 @@
 fake_request = object()
 formset = inline.get_formset(fake_request)
 self.assertFalse(formset.can_delete)
+
+class GenericInlineModelAdminTest(TestCase):
+
+def test_get_formset_kwargs(self):
+media_inline = MediaInline(Media, AdminSite())
+
+# Create a formset with default arguments
+formset = media_inline.get_formset(None)
+self.assertEqual(formset.max_num, None)
+self.assertEqual(formset.can_order, False)
+
+# Create a formset with custom keyword arguments
+formset = media_inline.get_formset(None, max_num=100, can_order=True)
+self.assertEqual(formset.max_num, 100)
+self.assertEqual(formset.can_order, 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] r16418 - in django/trunk: django/utils docs/ref tests/regressiontests/utils

[noreply]

Author: jezdez
Date: 2011-06-16 09:34:55 -0700 (Thu, 16 Jun 2011)
New Revision: 16418

Modified:
   django/trunk/django/utils/datastructures.py
   django/trunk/docs/ref/request-response.txt
   django/trunk/tests/regressiontests/utils/datastructures.py
Log:
Fixed #12375 -- Added a dict() method to convert a MultiValueDict (such as a 
QueryDict) to a dictionary of key-value pairs. Thanks, oinopion and hvdklauw.

Modified: django/trunk/django/utils/datastructures.py
===
--- django/trunk/django/utils/datastructures.py 2011-06-16 16:34:46 UTC (rev 
16417)
+++ django/trunk/django/utils/datastructures.py 2011-06-16 16:34:55 UTC (rev 
16418)
@@ -391,6 +391,12 @@
 for key, value in kwargs.iteritems():
 self.setlistdefault(key, []).append(value)
 
+def dict(self):
+"""
+Returns current object as a dict with singular values.
+"""
+return dict((key, self[key]) for key in self)
+
 class DotExpandedDict(dict):
 """
 A special dictionary constructor that takes a dictionary in which the keys

Modified: django/trunk/docs/ref/request-response.txt
===
--- django/trunk/docs/ref/request-response.txt  2011-06-16 16:34:46 UTC (rev 
16417)
+++ django/trunk/docs/ref/request-response.txt  2011-06-16 16:34:55 UTC (rev 
16418)
@@ -482,6 +482,18 @@
 >>> q.lists()
 [(u'a', [u'1', u'2', u'3'])]
 
+.. method:: QueryDict.dict()
+
+.. versionadded:: 1.4
+
+Returns ``dict`` representation of ``QueryDict``. For every (key, list)
+pair in ``QueryDict``, ``dict`` will have (key, item), where item is one
+element of the list, using same logic as :meth:`QueryDict.__getitem__()`::
+
+>>> q = QueryDict('a=1&a=3&a=5')
+>>> q.dict()
+{u'a': u'5'}
+
 .. method:: QueryDict.urlencode([safe])
 
 Returns a string of the data in query-string format. Example::

Modified: django/trunk/tests/regressiontests/utils/datastructures.py
===
--- django/trunk/tests/regressiontests/utils/datastructures.py  2011-06-16 
16:34:46 UTC (rev 16417)
+++ django/trunk/tests/regressiontests/utils/datastructures.py  2011-06-16 
16:34:55 UTC (rev 16418)
@@ -235,7 +235,19 @@
 self.assertEqual(d1["key"], ["Penguin"])
 self.assertEqual(d2["key"], ["Penguin"])
 
+def test_dict_translation(self):
+mvd = MultiValueDict({
+'devs': ['Bob', 'Joe'],
+'pm': ['Rory'],
+})
+d = mvd.dict()
+self.assertEqual(d.keys(), mvd.keys())
+for key in mvd.keys():
+self.assertEqual(d[key], mvd[key])
 
+self.assertEqual({}, MultiValueDict().dict())
+
+
 class DotExpandedDictTests(DatastructuresTestCase):
 
 def test_dotexpandeddict(self):

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

Re: [Django] #12375: updating QueryDict in another dict gives unexpected results.

[Django]

#12375: updating QueryDict in another dict gives unexpected results.
-+-
   Reporter:  hvdklauw   |  Owner:  oinopion
   Type:  Bug| Status:  closed
  Milestone: |  Component:  HTTP handling
Version:  1.1|   Severity:  Normal
 Resolution:  fixed  |   Keywords:  QueryDict, dceu2011
   Triage Stage:  Ready for  |  Has patch:  1
  checkin|Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by jezdez):

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


Comment:

 In [16418]:
 {{{
 #!CommitTicketReference repository="" revision="16418"
 Fixed #12375 -- Added a dict() method to convert a MultiValueDict (such as
 a QueryDict) to a dictionary of key-value pairs. Thanks, oinopion and
 hvdklauw.
 }}}

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

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

[noreply]

Author: jezdez
Date: 2011-06-16 09:34:46 -0700 (Thu, 16 Jun 2011)
New Revision: 16417

Modified:
   django/trunk/django/http/__init__.py
   django/trunk/tests/regressiontests/httpwrappers/tests.py
Log:
Fixed #14020 -- Made the `HttpResponse` class slightly more behave like a 
dictionary, allowing the alternative argument to be unset. Serious thanks to 
schmichael and moopet.

Modified: django/trunk/django/http/__init__.py
===
--- django/trunk/django/http/__init__.py2011-06-16 16:34:38 UTC (rev 
16416)
+++ django/trunk/django/http/__init__.py2011-06-16 16:34:46 UTC (rev 
16417)
@@ -615,7 +615,7 @@
 def items(self):
 return self._headers.values()
 
-def get(self, header, alternate):
+def get(self, header, alternate=None):
 return self._headers.get(header.lower(), (None, alternate))[1]
 
 def set_cookie(self, key, value='', max_age=None, expires=None, path='/',

Modified: django/trunk/tests/regressiontests/httpwrappers/tests.py
===
--- django/trunk/tests/regressiontests/httpwrappers/tests.py2011-06-16 
16:34:38 UTC (rev 16416)
+++ django/trunk/tests/regressiontests/httpwrappers/tests.py2011-06-16 
16:34:46 UTC (rev 16417)
@@ -243,6 +243,13 @@
 self.assertRaises(BadHeaderError, r.__setitem__, 'test\rstr', 'test')
 self.assertRaises(BadHeaderError, r.__setitem__, 'test\nstr', 'test')
 
+def test_dict_behavior(self):
+"""
+Test for bug #14020: Make HttpResponse.get work like dict.get
+"""
+r = HttpResponse()
+self.assertEqual(r.get('test'), None)
+
 class CookieTests(unittest.TestCase):
 def test_encode(self):
 """

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

Re: [Django] #14020: Make HttpResponse.get work like dict.get

[Django]

#14020: Make HttpResponse.get work like dict.get
-+-
   Reporter: |  Owner:  anonymous
  schmichael | Status:  closed
   Type:  New|  Component:  HTTP handling
  feature|   Severity:  Normal
  Milestone: |   Keywords:
Version:  SVN|  Has patch:  1
 Resolution:  fixed  |Needs tests:  0
   Triage Stage:  Ready for  |  Easy pickings:  0
  checkin|
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by jezdez):

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


Comment:

 In [16417]:
 {{{
 #!CommitTicketReference repository="" revision="16417"
 Fixed #14020 -- Made the `HttpResponse` class slightly more behave like a
 dictionary, allowing the alternative argument to be unset. Serious thanks
 to schmichael and moopet.
 }}}

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

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

[noreply]

Author: jezdez
Date: 2011-06-16 09:34:38 -0700 (Thu, 16 Jun 2011)
New Revision: 16416

Modified:
   django/trunk/django/forms/fields.py
   django/trunk/tests/regressiontests/forms/tests/forms.py
Log:
Fixed #15127 -- Properly copy the choices of choice fields. Thanks, dready and 
Julian Phalip.

Modified: django/trunk/django/forms/fields.py
===
--- django/trunk/django/forms/fields.py 2011-06-16 16:34:28 UTC (rev 16415)
+++ django/trunk/django/forms/fields.py 2011-06-16 16:34:38 UTC (rev 16416)
@@ -657,6 +657,11 @@
 initial=initial, help_text=help_text, 
*args, **kwargs)
 self.choices = choices
 
+def __deepcopy__(self, memo):
+result = super(ChoiceField, self).__deepcopy__(memo)
+result._choices = copy.deepcopy(self._choices, memo)
+return result
+
 def _get_choices(self):
 return self._choices
 

Modified: django/trunk/tests/regressiontests/forms/tests/forms.py
===
--- django/trunk/tests/regressiontests/forms/tests/forms.py 2011-06-16 
16:34:28 UTC (rev 16415)
+++ django/trunk/tests/regressiontests/forms/tests/forms.py 2011-06-16 
16:34:38 UTC (rev 16416)
@@ -771,6 +771,26 @@
 f = Person(name_max_length=None)
 self.assertEqual(f['first_name'].field.max_length, 
f['last_name'].field.max_length, (30, 30))
 
+# Similarly, choices do not persist from one Form instance to the next.
+# Refs #15127.
+class Person(Form):
+first_name = CharField(required=False)
+last_name = CharField(required=False)
+gender = ChoiceField(choices=(('f', 'Female'), ('m', 'Male')))
+
+def __init__(self, allow_unspec_gender=False, *args, **kwargs):
+super(Person, self).__init__(*args, **kwargs)
+
+if allow_unspec_gender:
+self.fields['gender'].choices += (('u', 'Unspecified'),)
+
+f = Person()
+self.assertEqual(f['gender'].field.choices, [('f', 'Female'), ('m', 
'Male')])
+f = Person(allow_unspec_gender=True)
+self.assertEqual(f['gender'].field.choices, [('f', 'Female'), ('m', 
'Male'), ('u', 'Unspecified')])
+f = Person()
+self.assertEqual(f['gender'].field.choices, [('f', 'Female'), ('m', 
'Male')])
+
 def test_hidden_widget(self):
 # HiddenInput widgets are displayed differently in the as_table(), 
as_ul())
 # and as_p() output of a Form -- their verbose names are not 
displayed, and a
@@ -1154,7 +1174,7 @@
 def test_boundfield_values(self):
 # It's possible to get to the value which would be used for rendering
 # the widget for a field by using the BoundField's value method.
- 
+
 class UserRegistration(Form):
 username = CharField(max_length=10, initial='djangonaut')
 password = CharField(widget=PasswordInput)

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #15127: form.fields is still tied to class variables

[Django]

#15127: form.fields is still tied to class variables
-+
   Reporter:  absoludity |  Owner:  nobody
   Type:  Bug| Status:  closed
  Milestone: |  Component:  Forms
Version:  SVN|   Severity:  Normal
 Resolution:  fixed  |   Keywords:
   Triage Stage:  Ready for checkin  |  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:

 In [16416]:
 {{{
 #!CommitTicketReference repository="" revision="16416"
 Fixed #15127 -- Properly copy the choices of choice fields. Thanks, dready
 and Julian Phalip.
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #12882: jQuery.noConflict() in admin breaks site specific code with jQuery

[Django]

#12882: jQuery.noConflict() in admin breaks site specific code with jQuery
-+-
   Reporter:  krejcik@…  |Owner:  jezdez
   Type: |   Status:  closed
  Milestone:  1.2|Component:  contrib.admin
Version:  SVN| Severity:
 Resolution:  fixed  | Keywords:  jQuery admin
   Triage Stage:  Accepted   |Has patch:  1
Needs documentation:  0  |  Needs tests:  1
Patch needs improvement:  1  |
-+-

Comment (by jezdez):

 In [16415]:
 {{{
 #!CommitTicketReference repository="" revision="16415"
 Stopped the admin JavaScript code from completely removing the `jQuery`
 object from the global namespace to ease the use of jQuery plugins. The
 `django.jQuery` object is still supposed to be used by Django's own
 JavaScript files. Refs #12882.
 }}}

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

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

[noreply]

Author: jezdez
Date: 2011-06-16 09:34:28 -0700 (Thu, 16 Jun 2011)
New Revision: 16415

Modified:
   django/trunk/django/contrib/admin/media/js/jquery.init.js
Log:
Stopped the admin JavaScript code from completely removing the `jQuery` object 
from the global namespace to ease the use of jQuery plugins. The 
`django.jQuery` object is still supposed to be used by Django's own JavaScript 
files. Refs #12882.

Modified: django/trunk/django/contrib/admin/media/js/jquery.init.js
===
--- django/trunk/django/contrib/admin/media/js/jquery.init.js   2011-06-16 
16:34:20 UTC (rev 16414)
+++ django/trunk/django/contrib/admin/media/js/jquery.init.js   2011-06-16 
16:34:28 UTC (rev 16415)
@@ -1,4 +1,4 @@
 // Puts the included jQuery into our own namespace
 var django = {
-"jQuery": jQuery.noConflict(true)
+"jQuery": jQuery.noConflict()
 };

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] r16414 - in django/trunk/docs: ref/templates topics/i18n

[noreply]

Author: jezdez
Date: 2011-06-16 09:34:20 -0700 (Thu, 16 Jun 2011)
New Revision: 16414

Modified:
   django/trunk/docs/ref/templates/builtins.txt
   django/trunk/docs/topics/i18n/internationalization.txt
Log:
Fixed #15908 -- Mention blocktrans in the pluralize filter documentation 
section. Thanks, Julien Phalip.

Modified: django/trunk/docs/ref/templates/builtins.txt
===
--- django/trunk/docs/ref/templates/builtins.txt2011-06-16 16:34:12 UTC 
(rev 16413)
+++ django/trunk/docs/ref/templates/builtins.txt2011-06-16 16:34:20 UTC 
(rev 16414)
@@ -1794,6 +1794,8 @@
 
 You have {{ num_cherries }} cherr{{ num_cherries|pluralize:"y,ies" }}.
 
+.. note:: Use :ttag:`blocktrans` to pluralize translated strings.
+
 .. templatefilter:: pprint
 
 pprint

Modified: django/trunk/docs/topics/i18n/internationalization.txt
===
--- django/trunk/docs/topics/i18n/internationalization.txt  2011-06-16 
16:34:12 UTC (rev 16413)
+++ django/trunk/docs/topics/i18n/internationalization.txt  2011-06-16 
16:34:20 UTC (rev 16414)
@@ -451,6 +451,8 @@
 %}``. If your translations require strings with variables (placeholders), use
 ``{% blocktrans %}`` instead.
 
+.. templatetag:: blocktrans
+
 ``blocktrans`` template tag
 ---
 

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #15908: Mention proper i18n approach in documentation for "pluralize" filter

[Django]

#15908: Mention proper i18n approach in documentation for "pluralize" filter
-+-
   Reporter:  wbolster   |  Owner:  gandalfar
   Type: | Status:  closed
  Cleanup/optimization   |  Component:  Documentation
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution:  fixed  |  Has patch:  1
   Triage Stage:  Ready for  |Needs tests:  0
  checkin|  Easy pickings:  1
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by jezdez):

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


Comment:

 In [16414]:
 {{{
 #!CommitTicketReference repository="" revision="16414"
 Fixed #15908 -- Mention blocktrans in the pluralize filter documentation
 section. Thanks, Julien Phalip.
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] r16413 - in django/trunk/docs: . howto/deployment topics

[noreply]

Author: jezdez
Date: 2011-06-16 09:34:12 -0700 (Thu, 16 Jun 2011)
New Revision: 16413

Added:
   django/trunk/docs/howto/deployment/uwsgi.txt
Modified:
   django/trunk/docs/howto/deployment/index.txt
   django/trunk/docs/index.txt
   django/trunk/docs/topics/install.txt
Log:
Fixed #16057 -- Extended deployment documentation with instructions for uWSGI. 
Thanks, jpic and aaugustin.

Modified: django/trunk/docs/howto/deployment/index.txt
===
--- django/trunk/docs/howto/deployment/index.txt2011-06-16 16:34:02 UTC 
(rev 16412)
+++ django/trunk/docs/howto/deployment/index.txt2011-06-16 16:34:12 UTC 
(rev 16413)
@@ -10,16 +10,18 @@
:maxdepth: 1
 
modwsgi
+   uwsgi
fastcgi
mod_python (deprecated) 
 
 If you're new to deploying Django and/or Python, we'd recommend you try
-:doc:`mod_wsgi ` first. In most cases it'll be the 
easiest,
-fastest, and most stable deployment choice.
+:doc:`mod_wsgi ` first. In most cases it'll be
+the easiest, fastest, and most stable deployment choice.
 
 .. seealso::
 
-* `Chapter 12 of The Django Book`_ discusses deployment and especially
-  scaling in more detail.
+* `Chapter 12 of the Django Book`_ discusses deployment and especially
+  scaling in more detail. However, it hasn't been updated since mod_python
+  was deprecated.
 
 .. _chapter 12 of the django book: http://djangobook.com/en/2.0/chapter12/

Added: django/trunk/docs/howto/deployment/uwsgi.txt
===
--- django/trunk/docs/howto/deployment/uwsgi.txt
(rev 0)
+++ django/trunk/docs/howto/deployment/uwsgi.txt2011-06-16 16:34:12 UTC 
(rev 16413)
@@ -0,0 +1,255 @@
+
+How to use Django with uWSGI
+
+
+.. highlight:: bash
+
+uWSGI_ is a fast, self-healing and developer/sysadmin-friendly application
+container server coded in pure C.
+
+It also provides a fast `caching framework`_ but its documentation is not the
+purpose of this document.
+
+.. _uWSGI: http://projects.unbit.it/uwsgi/
+.. _caching framework: http://projects.unbit.it/uwsgi/wiki/CachingFramework
+
+
+Prerequisite: uWSGI
+===
+
+The wiki describes several `installation procedures`_. Using pip, the python
+package manager, installing any uWSGI version can be done with one command
+line. For example::
+
+# install current stable version
+pip install uwsgi
+
+# or install LTS (long term support)
+pip install http://projects.unbit.it/downloads/uwsgi-lts.tar.gz
+
+.. _installation procedures: http://projects0.unbit.it/uwsgi/wiki/Install
+
+Prerequisite: general concept
+=
+
+uWSGI model
+---
+
+uWSGI operates on a client-server model. Your Web server (ie. nginx, Apache)
+communicates with a django-uwsgi "worker" process to serve dynamic contents.
+The Web server can communicate with the uWSGI process either:
+
+* directly by the uWSGI protocol through a socket created by uWSGI,
+* or by proxying HTTP requests to the minimalist HTTP server built in uWSGI.
+
+In the first case: the Web server can do uWSGI protocol (often with a
+module). It can then use either a Unix domain socket (a "named pipe" on Win32
+systems), or it can use a TCP socket. What you choose is a matterr of
+preference. Usually, a TCP socket is easier because connecting to a port
+doesn't require special permissions.
+
+In the second case, the Web server doesn't need to do uWSGI protocol. It just
+needs to be able to proxy HTTP requests to the HTTP server built-in uWSGI.
+The procedure is the same than proxying any HTTP server. Note that the Web
+server is a "reverse proxy" in this case.
+
+Configuring the uWSGI server
+
+
+In any case, when you set up your Web server, you'll just need to point its
+uwsgi or proxy module to the host/port or socket you specified when starting
+the uWSGI server.
+
+.. admonition:: Choosing the socket
+
+The easiest is to set the socket to a high level (>49152) local port like
+127.0.0.1:49152. If the socket is a file, the system administrator must
+ensure that the Web server process has read, write and execute privileges
+on that file.
+
+uWSGI is highly configurable and thus there are many ways to start the
+process. For example, uwsgi version 0.9.6.8 provides a hundred switches.
+This guide demonstrates the most important of them, but does not intent to
+substitute the official manual and online documentation.
+
+uWSGI supports configuration through:
+
+* environment variables
+* command line switches
+* ldap
+* ini files
+* xml files
+* yaml files
+
+Managing the uWSGI server
+-
+
+The system administrator controls the worker process pool by sending signals
+to the master process. For example, the unix kill command sends such signals.
+uWSGI can write the master process

Re: [Django] #16057: uWSGI documentation

[Django]

#16057: uWSGI documentation
-+-
   Reporter:  jpic   |  Owner:  nobody
   Type:  New| Status:  closed
  feature|  Component:  Documentation
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:  uwsgi
 Resolution:  fixed  |  Has patch:  1
   Triage Stage:  Ready for  |Needs tests:  0
  checkin|  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by jezdez):

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


Comment:

 In [16413]:
 {{{
 #!CommitTicketReference repository="" revision="16413"
 Fixed #16057 -- Extended deployment documentation with instructions for
 uWSGI. Thanks, jpic and aaugustin.
 }}}

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

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

Re: [Django] #16031: Custom comment form is incomplete and wrong.

[Django]

#16031: Custom comment form is incomplete and wrong.
-+-
   Reporter:  ddshore@…  |  Owner:  teraom
   Type: | Status:  closed
  Cleanup/optimization   |  Component:  Documentation
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution:  fixed  |  Has patch:  1
   Triage Stage:  Ready for  |Needs tests:  0
  checkin|  Easy pickings:  1
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by jezdez):

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


Comment:

 In [16412]:
 {{{
 #!CommitTicketReference repository="" revision="16412"
 Fixed #16031 -- Corrected comments template examples. Thanks, teraom.
 }}}

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

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

[noreply]

Author: jezdez
Date: 2011-06-16 09:34:02 -0700 (Thu, 16 Jun 2011)
New Revision: 16412

Modified:
   django/trunk/docs/ref/contrib/comments/example.txt
   django/trunk/docs/ref/contrib/comments/index.txt
Log:
Fixed #16031 -- Corrected comments template examples. Thanks, teraom.

Modified: django/trunk/docs/ref/contrib/comments/example.txt
===
--- django/trunk/docs/ref/contrib/comments/example.txt  2011-06-16 16:33:54 UTC 
(rev 16411)
+++ django/trunk/docs/ref/contrib/comments/example.txt  2011-06-16 16:34:02 UTC 
(rev 16412)
@@ -103,13 +103,16 @@
   
   
-  
-{{ form }}
-
-  
-  
-
-  
+
+  {% csrf_token %}
+  {{ form }}
+  
+
+  
+  
+
+  
+
   
 
 Flagging

Modified: django/trunk/docs/ref/contrib/comments/index.txt
===
--- django/trunk/docs/ref/contrib/comments/index.txt2011-06-16 16:33:54 UTC 
(rev 16411)
+++ django/trunk/docs/ref/contrib/comments/index.txt2011-06-16 16:34:02 UTC 
(rev 16412)
@@ -218,13 +218,18 @@
 A complete form might look like::
 
 {% get_comment_form for event as form %}
-
-  {{ form }}
-  
-
-
-  
-
+
+  
+{% csrf_token %}
+{{ form }}
+
+  
+
+
+  
+
+  
+
 
 Be sure to read the `notes on the comment form`_, below, for some special
 considerations you'll need to make if you're using this approach.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #16221: Wrong usage for comment permalink template tag in the docstring

[Django]

#16221: Wrong usage for comment permalink template tag in the docstring
-+-
   Reporter: |  Owner:  nobody
  thejaswi_puthraya  | Status:  closed
   Type: |  Component:  Documentation
  Cleanup/optimization   |   Severity:  Normal
  Milestone: |   Keywords:  dceu2011
Version:  SVN|  Has patch:  1
 Resolution:  fixed  |Needs tests:  0
   Triage Stage:  Ready for  |  Easy pickings:  1
  checkin|
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by jezdez):

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


Comment:

 In [16411]:
 {{{
 #!CommitTicketReference repository="" revision="16411"
 Fixed #16221 -- Corrected doc string example in comments permalink
 template tag. Thanks, Thejaswi Puthraya.
 }}}

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

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

[noreply]

Author: jezdez
Date: 2011-06-16 09:33:54 -0700 (Thu, 16 Jun 2011)
New Revision: 16411

Modified:
   django/trunk/django/contrib/comments/templatetags/comments.py
Log:
Fixed #16221 -- Corrected doc string example in comments permalink template 
tag. Thanks, Thejaswi Puthraya.

Modified: django/trunk/django/contrib/comments/templatetags/comments.py
===
--- django/trunk/django/contrib/comments/templatetags/comments.py   
2011-06-16 16:33:47 UTC (rev 16410)
+++ django/trunk/django/contrib/comments/templatetags/comments.py   
2011-06-16 16:33:54 UTC (rev 16411)
@@ -323,7 +323,7 @@
 named anchor to be appended to the end of the URL.
 
 Example::
-{{ get_comment_permalink comment "#c%(id)s-by-%(user_name)s" }}
+{% get_comment_permalink comment "#c%(id)s-by-%(user_name)s" %}
 """
 
 if anchor_pattern:

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

[noreply]

Author: jezdez
Date: 2011-06-16 09:33:47 -0700 (Thu, 16 Jun 2011)
New Revision: 16410

Modified:
   django/trunk/django/template/defaulttags.py
Log:
Fixed #16200 -- Stopped TemplateIfParser from returning something in 
`__init__`. Thanks, traff.

Modified: django/trunk/django/template/defaulttags.py
===
--- django/trunk/django/template/defaulttags.py 2011-06-16 15:28:12 UTC (rev 
16409)
+++ django/trunk/django/template/defaulttags.py 2011-06-16 16:33:47 UTC (rev 
16410)
@@ -846,7 +846,7 @@
 
 def __init__(self, parser, *args, **kwargs):
 self.template_parser = parser
-return super(TemplateIfParser, self).__init__(*args, **kwargs)
+super(TemplateIfParser, self).__init__(*args, **kwargs)
 
 def create_var(self, value):
 return TemplateLiteral(self.template_parser.compile_filter(value), 
value)

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #16200: __init__ of TemplateIfParser has return statement

[Django]

#16200: __init__ of TemplateIfParser has return statement
-+-
   Reporter:  traff  |  Owner:  nobody
   Type:  Bug| Status:  closed
  Milestone: |  Component:  Template system
Version:  1.3|   Severity:  Normal
 Resolution:  fixed  |   Keywords:
   Triage Stage:  Ready for  |  Has patch:  1
  checkin|Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by jezdez):

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


Comment:

 In [16410]:
 {{{
 #!CommitTicketReference repository="" revision="16410"
 Fixed #16200 -- Stopped TemplateIfParser from returning something in
 `__init__`. Thanks, traff.
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #16076: Updated locale formats for hungarian language

[Django]

#16076: Updated locale formats for hungarian language
-+-
   Reporter:  slink  |  Owner:  nobody
   Type:  New| Status:  new
  feature|  Component:
  Milestone: |  Internationalization
Version:  SVN|   Severity:  Normal
 Resolution: |   Keywords:  locale, formats
   Triage Stage:  Ready for  |  Has patch:  1
  checkin|Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-

Comment (by slink):

 @jezdez it was mispelled, thanks for the report. Just uploaded the fixed
 patch.

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

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

Re: [Django] #10870: Aggregates with joins ignore extra filters provided by setup_joins

[Django]

#10870: Aggregates with joins ignore extra filters provided by setup_joins
-+-
   Reporter:  fas|  Owner:  fas
   Type:  Bug| Status:  new
  Milestone:  1.3|  Component:  ORM aggregation
Version:  SVN|   Severity:  Normal
 Resolution: |   Keywords:  orm, aggregation,
   Triage Stage:  Accepted   |  join, contenttypes, filter
Needs documentation:  0  |  Has patch:  0
Patch needs improvement:  0  |Needs tests:  0
  UI/UX:  0  |  Easy pickings:  0
-+-
Changes (by joeri@…):

 * cc: joeri@… (added)
 * ui_ux:   => 0
 * easy:   => 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] #16076: Updated locale formats for hungarian language

[Django]

#16076: Updated locale formats for hungarian language
-+-
   Reporter:  slink  |  Owner:  nobody
   Type:  New| Status:  new
  feature|  Component:
  Milestone: |  Internationalization
Version:  SVN|   Severity:  Normal
 Resolution: |   Keywords:  locale, formats
   Triage Stage:  Ready for  |  Has patch:  1
  checkin|Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-

Comment (by jezdez):

 Is the first entry to `TIME_INPUT_FORMATS` supposed to have a comma?

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

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

[Django]

#16228: "Using logging" needs clarification?
-+-
   Reporter: |  Owner:  nobody
  shige.abe@…| Status:  new
   Type: |  Component:  Documentation
  Cleanup/optimization   |   Severity:  Normal
  Milestone: |   Keywords:
Version:  1.3|  Has patch:  0
 Resolution: |Needs tests:  0
   Triage Stage:  Accepted   |  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-

Comment (by shige.abe@…):

 Thanks for accepting this ticket.

 I'm not an expert on how this works which is why I was confused, but I
 would think it should start off with the changes to settings followed by
 how to setup logging in models ending with some way to verify that
 something is being logged.

 It would be super if the example showed emailing, logging to files and any
 other common use cases.  For example, I'm not sure why logging to files as
 I have it set records useful info, but the emailed version is essentially
 blank!

 It sounds like the Python docs talk about this in a lot more detail so we
 shouldn't duplicate that but I think it wouldn't be bad to expand the
 Django docs a little more to present a functional mini-tutorial.

 Thanks again,
 Shige

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

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

Re: [Django] #14678: Users are able to add more than one page to the same url (was: [flatpages] Users are able to add more than one page to the same url)

[Django]

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

 * 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] #16188: Added locale formats for swiss german language

[Django]

#16188: Added locale formats for swiss german language
-+-
   Reporter:  sspross|  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |  Component:
  Milestone: |  Internationalization
Version:  SVN|   Severity:  Normal
 Resolution: |   Keywords:  locale, formats
   Triage Stage:  Ready for  |  Has patch:  1
  checkin|Needs tests:  0
Needs documentation:  0  |  Easy pickings:  1
Patch needs improvement:  1  |
  UI/UX:  0  |
-+-
Changes (by jezdez):

 * needs_better_patch:  0 => 1


Comment:

 So I'm not actually sure this is correct, since according to the
 government regulations the dot is only used for monetary values, not
 generally for numbers.
 http://www.bk.admin.ch/dokumentation/sprachen/04915/05016/index.html?lang=de

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #16273: Missing quotes in "Managing Static Files"

[Django]

#16273: Missing quotes in "Managing Static Files"
-+-
   Reporter: |  Owner:  nobody
  BernhardEssl   | Status:  closed
   Type: |  Component:  Documentation
  Cleanup/optimization   |   Severity:  Normal
  Milestone: |   Keywords:
Version:  1.3|  Has patch:  1
 Resolution:  fixed  |Needs tests:  0
   Triage Stage:  Ready for  |  Easy pickings:  0
  checkin|
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-

Comment (by jezdez):

 In [16409]:
 {{{
 #!CommitTicketReference repository="" revision="16409"
 [1.3.X] Fixed #16273 -- Fixed typo in staticfiles docs. Thanks,
 BernhardEssl.

 Backport from trunk (r16407).
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] r16409 - django/branches/releases/1.3.X/docs/howto

[noreply]

Author: jezdez
Date: 2011-06-16 08:28:12 -0700 (Thu, 16 Jun 2011)
New Revision: 16409

Modified:
   django/branches/releases/1.3.X/docs/howto/static-files.txt
Log:
[1.3.X] Fixed #16273 -- Fixed typo in staticfiles docs. Thanks, BernhardEssl.

Backport from trunk (r16407).

Modified: django/branches/releases/1.3.X/docs/howto/static-files.txt
===
--- django/branches/releases/1.3.X/docs/howto/static-files.txt  2011-06-16 
15:27:19 UTC (rev 16408)
+++ django/branches/releases/1.3.X/docs/howto/static-files.txt  2011-06-16 
15:28:12 UTC (rev 16409)
@@ -68,7 +68,7 @@
 
.. code-block:: html+django
 
-   
 
See :ref:`staticfiles-in-templates` for more details, including an
alternate method using a template tag.
@@ -167,7 +167,7 @@
 
 .. code-block:: html+django
 
- 
 
 If ``{{ STATIC_URL }}`` isn't working in your template, you're probably not
 using :class:`~django.template.RequestContext` when rendering the template.

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

[Django]

#16264: Improve widget documentation
-+-
   Reporter: |  Owner:  bpeschier
  from_a_far@…   | Status:  closed
   Type: |  Component:  Documentation
  Cleanup/optimization   |   Severity:  Normal
  Milestone: |   Keywords:  docs
Version:  1.3|  Has patch:  1
 Resolution:  fixed  |Needs tests:  0
   Triage Stage:  Ready for  |  Easy pickings:  1
  checkin|
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by jezdez):

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


Comment:

 In [16408]:
 {{{
 #!CommitTicketReference repository="" revision="16408"
 Fixed #16264 -- Improved form widget documentation. Many thanks to Bas
 Peschier.
 }}}

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

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

[noreply]

Author: jezdez
Date: 2011-06-16 08:27:19 -0700 (Thu, 16 Jun 2011)
New Revision: 16408

Modified:
   django/trunk/docs/ref/forms/fields.txt
   django/trunk/docs/ref/forms/widgets.txt
Log:
Fixed #16264 -- Improved form widget documentation. Many thanks to Bas Peschier.

Modified: django/trunk/docs/ref/forms/fields.txt
===
--- django/trunk/docs/ref/forms/fields.txt  2011-06-16 15:27:11 UTC (rev 
16407)
+++ django/trunk/docs/ref/forms/fields.txt  2011-06-16 15:27:19 UTC (rev 
16408)
@@ -278,6 +278,7 @@
 See the :ref:`format localization ` documentation for
 more information.
 
+.. _built-in fields:
 
 Built-in ``Field`` classes
 --

Modified: django/trunk/docs/ref/forms/widgets.txt
===
--- django/trunk/docs/ref/forms/widgets.txt 2011-06-16 15:27:11 UTC (rev 
16407)
+++ django/trunk/docs/ref/forms/widgets.txt 2011-06-16 15:27:19 UTC (rev 
16408)
@@ -11,9 +11,181 @@
 handles the rendering of the HTML, and the extraction of data from a GET/POST
 dictionary that corresponds to the widget.
 
+Specifying widgets
+--
+
+Whenever you specify a field on a form, Django will use a default widget
+that is appropriate to the type of data that is to be displayed. To find
+which widget is used on which field, see the documentation about
+:ref:`built-in fields`.
+
+However, if you want to use a different widget for a field, you can
+just use the :attr:`~Field.widget` argument on the field definition. For
+example:
+
+.. code-block:: python
+
+from django import forms
+
+class CommentForm(forms.Form):
+name = forms.CharField()
+url = forms.URLField()
+comment = forms.CharField(widget=forms.Textarea)
+
+This would specify a form with a comment that uses a larger :class:`Textarea`
+widget, rather than the default :class:`TextInput` widget.
+
+
+Setting arguments for widgets
+-
+
+Many widgets have optional extra arguments; they can be set when defining the
+widget on the field. In the following example, the
+:attr:`~SelectDateWidget.years` attribute is set for a
+:class:`~django.forms.widgets.extras.SelectDateWidget`:
+
+.. code-block:: python
+
+from django.forms.fields import DateField, ChoiceField, 
MultipleChoiceField
+from django.forms.widgets import RadioSelect, CheckboxSelectMultiple
+from django.forms.widgets.extras import SelectDateWidget
+
+BIRTH_YEAR_CHOICES = ('1980', '1981', '1982')
+GENDER_CHOICES = (('m', 'Male'), ('f', 'Female'))
+FAVOURITE_COLORS_CHOICES = (('blue', 'Blue'),
+('green', 'Green'),
+('black', 'Black'))
+
+class SimpleForm(forms.Form):
+birth_year = DateField(widget=SelectDateWidget(years=YEAR_CHOICES))
+gender = ChoiceField(widget=RadioSelect, choices=RADIO_CHOICES)
+favourite_colors = forms.MultipleChoiceField(required=False,
+widget=CheckboxSelectMultiple, choices=CHECKBOX_CHOICES)
+
+See the :ref:`built-in widgets` for more information about which widgets
+are available and which arguments they accept.
+
+
+Widgets inheriting from the Select widget
+-
+
+Widgets inheriting from the :class:`Select` widget deal with choices. They
+present the user with a list of options to choose from. The different widgets
+present this choice differently; the :class:`Select` widget itself uses a
+ HTML list representation, while :class:`RadioSelect` uses radio
+buttons.
+
+:class:`Select` widgets are used by default on :class:`ChoiceField` fields. The
+choices displayed on the widget are inherited from the :class:`ChoiceField` and
+changing :attr:`ChoiceField.choices` will update :attr:`Select.choices`. For
+example:
+
+.. code-block:: python
+
+>>> from django import forms
+>>> CHOICES = (('1', 'First',), ('2', 'Second',)))
+>>> choice_field = forms.ChoiceField(widget=forms.RadioSelect, 
choices=CHOICES)
+>>> choice_field.choices
+[('1', 'First'), ('2', 'Second')]
+>>> choice_field.widget.choices
+[('1', 'First'), ('2', 'Second')]
+>>> choice_field.widget.choices = ()
+>>> choice_field.choices = (('1', 'First and only',),)
+>>> choice_field.widget.choices
+[('1', 'First and only')]
+
+
+Widgets which offer a :attr:`~Select.choices` attribute can however be used
+with fields which are not based on choice -- such as a :class:`CharField` --
+but it is recommended to use a :class:`ChoiceField`-based field when the
+choices are inherent to the model and not just the representational widget.
+
+Customizing widget instances
+
+
+When Django renders a widget as HTML, it only renders the bare minimum
+HTML - Django 

Re: [Django] #16273: Missing quotes in "Managing Static Files"

[Django]

#16273: Missing quotes in "Managing Static Files"
-+-
   Reporter: |  Owner:  nobody
  BernhardEssl   | Status:  closed
   Type: |  Component:  Documentation
  Cleanup/optimization   |   Severity:  Normal
  Milestone: |   Keywords:
Version:  1.3|  Has patch:  1
 Resolution:  fixed  |Needs tests:  0
   Triage Stage:  Ready for  |  Easy pickings:  0
  checkin|
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by jezdez):

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


Comment:

 In [16407]:
 {{{
 #!CommitTicketReference repository="" revision="16407"
 Fixed #16273 -- Fixed typo in staticfiles docs. Thanks, BernhardEssl.
 }}}

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

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

[noreply]

Author: jezdez
Date: 2011-06-16 08:27:11 -0700 (Thu, 16 Jun 2011)
New Revision: 16407

Modified:
   django/trunk/docs/howto/static-files.txt
Log:
Fixed #16273 -- Fixed typo in staticfiles docs. Thanks, BernhardEssl.

Modified: django/trunk/docs/howto/static-files.txt
===
--- django/trunk/docs/howto/static-files.txt2011-06-15 23:52:44 UTC (rev 
16406)
+++ django/trunk/docs/howto/static-files.txt2011-06-16 15:27:11 UTC (rev 
16407)
@@ -68,7 +68,7 @@
 
.. code-block:: html+django
 
-   
 
See :ref:`staticfiles-in-templates` for more details, including an
alternate method using a template tag.
@@ -167,7 +167,7 @@
 
 .. code-block:: html+django
 
- 
 
 If ``{{ STATIC_URL }}`` isn't working in your template, you're probably not
 using :class:`~django.template.RequestContext` when rendering the template.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #4287: FloatField will not handle infinity values

[Django]

#4287: FloatField will not handle infinity values
-+-
   Reporter:  oBeattie   |  Owner:  nobody
  (oliver@…  | Status:  new
   Type:  Bug|  Component:  Database layer
  Milestone: |  (models, ORM)
Version:  SVN|   Severity:  Normal
 Resolution: |   Keywords:  infinity, mysql,
   Triage Stage:  Accepted   |  float
Needs documentation:  0  |  Has patch:  1
Patch needs improvement:  0  |Needs tests:  1
  UI/UX:  0  |  Easy pickings:  0
-+-
Changes (by calmez):

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


Comment:

 I did another patch that adds the feature to enable saving infinity values
 on !FloatFields. After enabling this a check happens if the used database
 is supporting this. By default this support is disabled. I enabled it for
 the sqlite backend since it can store infinity values in float columns.
 Now the user can decide to be able to store infinity. If the user's setup
 does not allow storing infinity the reaction to that will be more
 appropriate.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #16284: djangojs uses en as fallback language rather than projects language code

[Django]

#16284: djangojs uses en as fallback language rather than projects language code
---+---
 Reporter:  anonymous  |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Milestone: |  Component:  Uncategorized
  Version:  1.3|   Severity:  Normal
 Keywords: |   Triage Stage:  Unreviewed
Has patch:  0  |  Easy pickings:  0
UI/UX:  0  |
---+---
 In views/i18n.py there is code:

 {{{
 # first load all english languages files for defaults
 for package in packages:
 p = importlib.import_module(package)
 path = os.path.join(os.path.dirname(p.__file__), 'locale')
 paths.append(path)
 try:
 catalog = gettext_module.translation(domain, path, ['en'])
 t.update(catalog._catalog)
 except IOError:
 pass
 else:
 # 'en' is the selected language and at least one of the
 packages
 # listed in `packages` has an 'en' catalog
 if en_selected:
 en_catalog_missing = False

 }}}

 I believe django should first check if LANGUAGE_CODE setting is not set
 and use this for defaults. Our main language is polish and while we have
 english translations available, we don't want django to fallback to
 english.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #12064: Impossible to conditionally include potentially non-existant templates

[Django]

#12064: Impossible to conditionally include potentially non-existant templates
-+-
   Reporter: |  Owner:  nobody
  mkruisselbrink | Status:  new
   Type:  New|  Component:  Template system
  feature|   Severity:  Normal
  Milestone: |   Keywords:
Version:  1.1|  Has patch:  1
 Resolution: |Needs tests:  1
   Triage Stage:  Design |  Easy pickings:  0
  decision needed|
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by akaihola):

 * ui_ux:   => 0


Comment:

 I'd very much like to see this applied and am willing to contribute to
 make it happen. We're relying on the silent failure in production, but
 it's a hassle to comment out the includes when developing in debug mode.

 I see that the triage stage for both #12008 and #3544 is "Accepted". Would
 one or both of those fix this issue as well? #16147 is "Design decision
 needed". Should I just write tests for this ticket as [#comment:3
 lukeplant suggested], or should I direct my efforts at one of the related
 tickets?

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #16245: send_robust should include traceback in response when Exception occurs

[Django]

#16245: send_robust should include traceback in response when Exception occurs
-+-
   Reporter:  jsdalton   |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |  Component:  Core (Other)
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:  signals
 Resolution: |  Has patch:  1
   Triage Stage:  Design |Needs tests:  0
  decision needed|  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-

Comment (by jsdalton):

 I have updated the patch to reflect my last comment. Adding the traceback
 as a third item the tuple response is now an option via
 `append_traceback`, the default for which is False.

 Existing implementation of `send_robust()` will now work as is. To make
 use of my proposed feature, you would need to set append_traceback to True
 when calling `send_robust()`.

 If anyone has any objections or concerns I'd like to hear them. Accessing
 the traceback at the point an exception occurs in a receiver function is
 currently not possible. This makes it difficult if not impossible to debug
 if something goes wrong in one of the receiver functions.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #16199: Create a secure cookie-based session backend

[Django]

#16199: Create a secure cookie-based session backend
---+--
   Reporter:  floguy   |  Owner:  nobody
   Type:  New feature  | Status:  new
  Milestone:   |  Component:  contrib.sessions
Version:  SVN  |   Severity:  Normal
 Resolution:   |   Keywords:
   Triage Stage:  Accepted |  Has patch:  1
Needs documentation:  1|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+--

Comment (by lukeplant):

 #14579 was a duplicate.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #14579: Use built-in sessions middleware for entirely cookie-based sessions

[Django]

#14579: Use built-in sessions middleware for entirely cookie-based sessions
---+--
   Reporter:  oran |  Owner:  nobody
   Type:  New feature  | Status:  closed
  Milestone:  1.4  |  Component:  contrib.sessions
Version:  1.2  |   Severity:  Normal
 Resolution:  duplicate|   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 lukeplant):

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


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #14579: Use built-in sessions middleware for entirely cookie-based sessions

[Django]

#14579: Use built-in sessions middleware for entirely cookie-based sessions
---+--
   Reporter:  oran |  Owner:  nobody
   Type:  New feature  | Status:  new
  Milestone:  1.4  |  Component:  contrib.sessions
Version:  1.2  |   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 lukeplant):

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


Comment:

 #16199 is a duplicate, and has a much nicer approach, showing that Django
 does not need to be patched for this to work.

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

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

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

[Django]

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

 * severity:  Normal => Release blocker


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #16283: my application project.auth takes models from django.contrib.auth

[Django]

#16283: my application project.auth takes models from django.contrib.auth
--+--
   Reporter:  TheRoSS |  Owner:  nobody
   Type:  Bug | Status:  closed
  Milestone:  |  Component:  contrib.auth
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 aaugustin):

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


Comment:

 **tl;dr** don't call your app "auth" :)

 

 You have `django.contrib.auth.middleware.AuthenticationMiddleware` in
 `MIDDLEWARE_CLASSES`.

 By default, this will use `django.contrib.auth.backends.ModelBackend` as
 an authentication backend
 (https://docs.djangoproject.com/en/dev/ref/settings/#authentication-
 backends).

 This backend imports `django.contrib.auth.models`
 
(https://code.djangoproject.com/browser/django/trunk/django/contrib/auth/backends.py)

 Thus, even if you haven't declared `django.contrib.auth` in
 `INSTALLED_APPS`, it gets registered in the application cache, creating a
 conflict with your app.

 I hope this helps!

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #16281: ContentType.get_object_for_this_type using wrong database for creating object

[Django]

#16281: ContentType.get_object_for_this_type using wrong database for creating
object
-+-
   Reporter: |  Owner:  nobody
  tfrydrychewicz@…   | Status:  new
   Type:  Bug|  Component:
  Milestone: |  contrib.contenttypes
Version:  SVN|   Severity:  Release blocker
 Resolution: |   Keywords:  contenttype, object
   Triage Stage:  Accepted   |  get_object_for_this_type, database,
Needs documentation:  0  |  multiple
Patch needs improvement:  0  |  Has patch:  1
  UI/UX:  0  |Needs tests:  1
 |  Easy pickings:  0
-+-
Changes (by melinath):

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


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

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

Re: [Django] #13252: Use the natural key instead of the primary key when serializing

[Django]

#13252: Use the natural key instead of the primary key when serializing
-+-
   Reporter: |  Owner:  mtredinnick
  SmileyChris| Status:  reopened
   Type:  New|  Component:  Core
  feature|  (Serialization)
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by claudep):

 * needs_better_patch:  1 => 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] #16283: my application project.auth takes models from django.contrib.auth

[Django]

#16283: my application project.auth takes models from django.contrib.auth
--+--
   Reporter:  TheRoSS |  Owner:  nobody
   Type:  Bug | Status:  reopened
  Milestone:  |  Component:  contrib.auth
Version:  1.3 |   Severity:  Normal
 Resolution:  |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+--
Changes (by TheRoSS):

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


Comment:

 No! The problem is that I didn't used 'django.contrib.auth' at all! But
 cannot name my application 'auth'.

 My settings.py file:

 {{{
 DEBUG = True
 TEMPLATE_DEBUG = DEBUG

 DATABASES = {
 'default': {
 'ENGINE': 'django.db.backends.mysql', # Add 'postgresql_psycopg2',
 'postgresql', 'mysql', 'sqlite3' or 'oracle'.
 'NAME': 'seka',  # Or path to database file if
 using sqlite3.
 'USER': 'root',  # Not used with sqlite3.
 'PASSWORD': 'root',  # Not used with sqlite3.
 'HOST': '',  # Set to empty string for
 localhost. Not used with sqlite3.
 'PORT': '',  # Set to empty string for
 default. Not used with sqlite3.
 }
 }

 MIDDLEWARE_CLASSES = (
 'django.middleware.common.CommonMiddleware',
 'django.contrib.sessions.middleware.SessionMiddleware',
 'django.middleware.csrf.CsrfViewMiddleware',
 )

 ROOT_URLCONF = 'seka.urls'

 INSTALLED_APPS = (
 'seka.auth',
 )

 }}}


 My models.py:

 {{{
 from django.db import models
 from django.utils.translation import ugettext_lazy as _

 # Create your models here.
 class User (models.Model):
 username = models.CharField(_('username'), max_length=30, unique=True,
 help_text=_("Required. 30 characters or fewer. Letters, numbers and
 @/./+/-/_ characters"))

 }}}

 Bu running 'manage.py sql auth' gives:

 {{{
 BEGIN;
 CREATE TABLE `auth_permission` (
 `id` integer AUTO_INCREMENT NOT NULL PRIMARY KEY,
 `name` varchar(50) NOT NULL,
 `content_type_id` integer NOT NULL,
 `codename` varchar(100) NOT NULL,
 UNIQUE (`content_type_id`, `codename`)
 )
 ;
 CREATE TABLE `auth_group_permissions` (
 `id` integer AUTO_INCREMENT NOT NULL PRIMARY KEY,
 `group_id` integer NOT NULL,
 `permission_id` integer NOT NULL,
 UNIQUE (`group_id`, `permission_id`)
 )
 ;
 ALTER TABLE `auth_group_permissions` ADD CONSTRAINT
 `permission_id_refs_id_5886d21f` FOREIGN KEY (`permission_id`) REFERENCES
 `auth_permission` (`id`);
 CREATE TABLE `auth_group` (
 `id` integer AUTO_INCREMENT NOT NULL PRIMARY KEY,
 `name` varchar(80) NOT NULL UNIQUE
 )
 ;
 ALTER TABLE `auth_group_permissions` ADD CONSTRAINT
 `group_id_refs_id_3cea63fe` FOREIGN KEY (`group_id`) REFERENCES
 `auth_group` (`id`);
 CREATE TABLE `auth_user_user_permissions` (
 `id` integer AUTO_INCREMENT NOT NULL PRIMARY KEY,
 `user_id` integer NOT NULL,
 `permission_id` integer NOT NULL,
 UNIQUE (`user_id`, `permission_id`)
 )
 ;
 ALTER TABLE `auth_user_user_permissions` ADD CONSTRAINT
 `permission_id_refs_id_67e79cb` FOREIGN KEY (`permission_id`) REFERENCES
 `auth_permission` (`id`);
 CREATE TABLE `auth_user_groups` (
 `id` integer AUTO_INCREMENT NOT NULL PRIMARY KEY,
 `user_id` integer NOT NULL,
 `group_id` integer NOT NULL,
 UNIQUE (`user_id`, `group_id`)
 )
 ;
 ALTER TABLE `auth_user_groups` ADD CONSTRAINT `group_id_refs_id_f116770`
 FOREIGN KEY (`group_id`) REFERENCES `auth_group` (`id`);
 CREATE TABLE `auth_user` (
 `id` integer AUTO_INCREMENT NOT NULL PRIMARY KEY,
 `username` varchar(30) NOT NULL UNIQUE,
 `first_name` varchar(30) NOT NULL,
 `last_name` varchar(30) NOT NULL,
 `email` varchar(75) NOT NULL,
 `password` varchar(128) NOT NULL,
 `is_staff` bool NOT NULL,
 `is_active` bool NOT NULL,
 `is_superuser` bool NOT NULL,
 `last_login` datetime NOT NULL,
 `date_joined` datetime NOT NULL
 )
 ;
 ALTER TABLE `auth_user_user_permissions` ADD CONSTRAINT
 `user_id_refs_id_dfbab7d` FOREIGN KEY (`user_id`) REFERENCES `auth_user`
 (`id`);
 ALTER TABLE `auth_user_groups` ADD CONSTRAINT `user_id_refs_id_7ceef80f`
 FOREIGN KEY (`user_id`) REFERENCES `auth_user`(`id`);
 CREATE TABLE `auth_message` (
 `id` integer AUTO_INCREMENT NOT NULL PRIMARY KEY,
 `user_id` integer NOT NULL,
 `message` longtext NOT NULL
 )
 ;
 ALTER TABLE `auth_message` ADD CONSTRAINT `user_id_refs_id_650f49a6`
 FOREIGN KEY (`user_id`) REFERENCES `auth_user` (`id`);
 -- The following references should be added but depend on non-existent
 tables:
 -- ALTER TABL

Re: [Django] #16282: CommentTemplateTagTests.testRenderCommentFormFromObjectWithQueryCount fails on MySQL

[Django]

#16282: CommentTemplateTagTests.testRenderCommentFormFromObjectWithQueryCount 
fails
on MySQL
--+---
   Reporter:  ojii|  Owner:  nobody
   Type:  Bug | Status:  new
  Milestone:  |  Component:  Testing framework
Version:  SVN |   Severity:  Normal
 Resolution:  |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+---
Changes (by ojii):

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


Comment:

 Using mysql  Ver 14.14 Distrib 5.1.41, for debian-linux-gnu (x86_64) using
 readline 6.1

 Running in --pair mode against text.TextTests.test_cookie_date to make the
 tests run in an acceptable time

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #16199: Create a secure cookie-based session backend

[Django]

#16199: Create a secure cookie-based session backend
---+--
   Reporter:  floguy   |  Owner:  nobody
   Type:  New feature  | Status:  new
  Milestone:   |  Component:  contrib.sessions
Version:  SVN  |   Severity:  Normal
 Resolution:   |   Keywords:
   Triage Stage:  Accepted |  Has patch:  1
Needs documentation:  1|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+--
Changes (by jezdez):

 * needs_better_patch:  1 => 0


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

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

Re: [Django] #16283: my application project.auth takes models from django.contrib.auth

[Django]

#16283: my application project.auth takes models from django.contrib.auth
--+--
   Reporter:  TheRoSS |  Owner:  nobody
   Type:  Bug | Status:  closed
  Milestone:  |  Component:  contrib.auth
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 aaugustin):

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


Comment:

 This works as advertised:
 https://docs.djangoproject.com/en/dev/ref/settings/#installed-apps

 It's very hard to remove this limitation in a backwards compatible way
 because Django references models in many places as
 `.`, which gets translated to
 `...models.`.

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

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

[Django]

#11305: Support for "Conditional Aggregates"
-+-
   Reporter:  bendavis78 |  Owner:
   Type:  New feature| Status:  new
  Milestone: |  Component:  ORM aggregation
Version:  1.0|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Someday/Maybe  |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
Changes (by foxwhisper):

 * cc: cal@… (added)
 * ui_ux:   => 0
 * easy:   => 0


Comment:

 Hi all,

 I came across this same problem myself today, and spoke to Russ who
 pointed me to this thread.

 I was planning on writing up a patch for this myself (for consideration
 into the core), which had support for Q() / F(), and such. However, the
 patch would have needed to be cross database compatible, and sadly, I just
 don't have the spare time to write this for all the databases.

 Full discussion here:
 http://groups.google.com/group/django-
 users/browse_thread/thread/723ce5a13530992d

 I would be more than willing to write the MySQL aggregates patch, if
 others can contribute with the other supported databases and testing etc.
 If anyone would like to join forces on this to help get it included in the
 core, let me know via ticket.

 Cal Leeming

 PS: My use case for this +1 feature vote, is due to having 40 million rows
 of data, and needing to avoid using layers of filter().aggregate(), which
 would in turn cause multiple queries needing to be run.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #16218: Class-based month archive doesn't behave like previous generic view

[Django]

#16218: Class-based month archive doesn't behave like previous generic view
--+---
   Reporter:  nnrcschmdt  |  Owner:  nobody
   Type:  Bug | Status:  new
  Milestone:  |  Component:  Generic views
Version:  SVN |   Severity:  Normal
 Resolution:  |   Keywords:
   Triage Stage:  Accepted|  Has patch:  1
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+---
Changes (by bpeschier):

 * has_patch:  0 => 1


Comment:

 Patch updates generic CBV to sort {{{date_list}}} in basic index view
 descending and year/month view ascending. It also adds tests to check the
 order. This covers the first fail in the report.

 The second fail is a different story: in the generic CBV code there is a
 section about preventing to link to empty pages ![1]. Conforming to that,
 the patch contains an update for the docs to clarify that behaviour with
 the {{{allow_empty}}} setting. This is different from the old generic
 views, where this data is given even if {{{allow_empty}}} is {{{False}}}.

 ![1]:
 
https://code.djangoproject.com/browser/django/trunk/django/views/generic/dates.py?rev=16363#L520

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #16283: my application project.auth takes models from django.contrib.auth

[Django]

#16283: my application project.auth takes models from django.contrib.auth
--+--
   Reporter:  TheRoSS |  Owner:  nobody
   Type:  Bug | Status:  new
  Milestone:  |  Component:  contrib.auth
Version:  1.3 |   Severity:  Normal
 Resolution:  |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+--
Changes (by TheRoSS):

 * cc: TheRoSS (added)
 * needs_docs:   => 0
 * needs_tests:   => 0
 * needs_better_patch:   => 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] #16283: my application project.auth takes models from django.contrib.auth

[Django]

#16283: my application project.auth takes models from django.contrib.auth
-+--
 Reporter:  TheRoSS  |  Owner:  nobody
 Type:  Bug  | Status:  new
Milestone:   |  Component:  contrib.auth
  Version:  1.3  |   Severity:  Normal
 Keywords:   |   Triage Stage:  Unreviewed
Has patch:  0|  Easy pickings:  0
UI/UX:  0|
-+--
 I intended to use django.contrib.auth with my own backends, so I included
 'django.contrib.auth.middleware.!AuthenticationMiddleware' into
 'MIDDLEWARE_CLASSES', excluded 'django.contrib.auth' from 'INSTALLED_APPS'
 and created my own authentication application.

 But if I named my authentication application as 'project.auth', django
 used models from 'django.contrib.auth'.
 If I gave it any other name, 'project.auth2' for example, models were
 mine.

 project.settings contains:

 {{{
 MIDDLEWARE_CLASSES = (
 'django.middleware.common.CommonMiddleware',
 'django.contrib.sessions.middleware.SessionMiddleware',
 'django.middleware.csrf.CsrfViewMiddleware',
 'django.contrib.auth.middleware.AuthenticationMiddleware',
 )

 INSTALLED_APPS = (
 'project.auth',# DOESN'T WORK!
 'project.auth2',   # works well
 )

 }}}


 I tracked down the source code and realized that
 django.db.models.loading.app_models dictionary has a record named 'auth'
 taken from 'django.contrib.auth' (upon middleware processing I suppose)
 which prevents my 'auth' application to be used.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #16281: ContentType.get_object_for_this_type using wrong database for creating object

[Django]

#16281: ContentType.get_object_for_this_type using wrong database for creating
object
-+-
   Reporter: |  Owner:  nobody
  tfrydrychewicz@…   | Status:  new
   Type:  Bug|  Component:
  Milestone: |  contrib.contenttypes
Version:  1.3|   Severity:  Release blocker
 Resolution: |   Keywords:  contenttype, object
   Triage Stage: |  get_object_for_this_type, database,
  Unreviewed |  multiple
Needs documentation:  0  |  Has patch:  1
Patch needs improvement:  0  |Needs tests:  1
  UI/UX:  0  |  Easy pickings:  0
-+-
Changes (by anonymous):

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


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

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

[Django] #16282: CommentTemplateTagTests.testRenderCommentFormFromObjectWithQueryCount fails on MySQL

[Django]

#16282: CommentTemplateTagTests.testRenderCommentFormFromObjectWithQueryCount 
fails
on MySQL
--+---
 Reporter:  ojii  |  Owner:  nobody
 Type:  Bug   | Status:  new
Milestone:|  Component:  Testing framework
  Version:  SVN   |   Severity:  Normal
 Keywords:|   Triage Stage:  Unreviewed
Has patch:  0 |  Easy pickings:  0
UI/UX:  0 |
--+---
 The test
 
regressiontests.comment_tests.tests.templatetag_tests.CommentTemplateTagTests.testRenderCommentFormFromObjectWithQueryCount
 fails under MySQL with AssertionError: 2 != 1 : 2 queries executed, 1
 expected on line 46 on Python 2.5, 2.6 and 2.7.

 See http://ci.django-
 cms.org/job/Django/database=mysql,python=python2.5/57/console

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #10802: urlresolvers RegexURLResolver._get_callback should not catch ImportError and AttributeError

[Django]

#10802: urlresolvers RegexURLResolver._get_callback should not catch ImportError
and AttributeError
-+-
   Reporter: |  Owner:  nobody
  IonelMaries| Status:  new
   Type:  Bug|  Component:  Core (Other)
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage:  Ready for  |Needs tests:  0
  checkin|  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by bpeschier):

 * needs_better_patch:  1 => 0


Comment:

 Updated trunk and rediffed.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #10802: urlresolvers RegexURLResolver._get_callback should not catch ImportError and AttributeError

[Django]

#10802: urlresolvers RegexURLResolver._get_callback should not catch ImportError
and AttributeError
-+-
   Reporter: |  Owner:  nobody
  IonelMaries| Status:  new
   Type:  Bug|  Component:  Core (Other)
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage:  Ready for  |Needs tests:  0
  checkin|  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  1  |
  UI/UX:  0  |
-+-
Changes (by jezdez):

 * needs_better_patch:  0 => 1


Comment:

 Doesn't apply to trunk after the i18n urls landed.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #16218: Class-based month archive doesn't behave like previous generic view

[Django]

#16218: Class-based month archive doesn't behave like previous generic view
--+---
   Reporter:  nnrcschmdt  |  Owner:  nobody
   Type:  Bug | Status:  new
  Milestone:  |  Component:  Generic views
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 bpeschier):

 * stage:  Unreviewed => Accepted


Comment:

 According to the docs at https://docs.djangoproject.com/en/dev/ref/class-
 based-views/#montharchiveview, date_list should be ordered ascending.
 Seems like that is not the case, I added a test for ascending order in the
 generic CBV tests, which gives:

 {{{
 FAIL: test_date_list_order
 (regressiontests.generic_views.dates.ArchiveIndexViewTests)
 date_list should be ascending
 --
 Traceback (most recent call last):
   File "/Users/bpeschier/dev/python/envs/django-dev/django-
 trunk/tests/regressiontests/generic_views/dates.py", line 83, in
 test_date_list_order
 self.assertEqual(res.context['date_list'],
 list(sorted(res.context['date_list'])))
 AssertionError: Lists differ: [datetime.datetime(2011, 1, 1,... !=
 [datetime.datetime(2006, 1, 1,...
 }}}

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

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

Re: [Django] #10802: urlresolvers RegexURLResolver._get_callback should not catch ImportError and AttributeError

[Django]

#10802: urlresolvers RegexURLResolver._get_callback should not catch ImportError
and AttributeError
-+-
   Reporter: |  Owner:  nobody
  IonelMaries| Status:  new
   Type:  Bug|  Component:  Core (Other)
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage:  Ready for  |Needs tests:  0
  checkin|  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by russellm):

 * stage:  Design decision needed => Ready for checkin


Comment:

 First patch from bpeschier looks good to me.

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

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

Re: [Django] #16264: Improve widget documentation

[Django]

#16264: Improve widget documentation
-+-
   Reporter: |  Owner:  bpeschier
  from_a_far@…   | Status:  new
   Type: |  Component:  Documentation
  Cleanup/optimization   |   Severity:  Normal
  Milestone: |   Keywords:  docs
Version:  1.3|  Has patch:  1
 Resolution: |Needs tests:  0
   Triage Stage:  Ready for  |  Easy pickings:  1
  checkin|
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by julien):

 * stage:  Accepted => Ready for checkin


Comment:

 In concertation with bpeschier on IRC, this is good to go. Thanks for your
 awesome work!

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

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

[Django]

#16264: Improve widget documentation
-+-
   Reporter: |  Owner:  bpeschier
  from_a_far@…   | Status:  new
   Type: |  Component:  Documentation
  Cleanup/optimization   |   Severity:  Normal
  Milestone: |   Keywords:  docs
Version:  1.3|  Has patch:  1
 Resolution: |Needs tests:  0
   Triage Stage:  Accepted   |  Easy pickings:  1
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-

Comment (by julien):

 OK, I've posted a new patch with PEP8's 80 characters limit (except for
 code samples), explicit imports as suggested in comment:13, more realistic
 field names and values for the `SimpleForm` example and a few more
 insignificant tweaks.

 @anonymous: to see the changes you need to apply the attached patch to
 your checkout of Django trunk. See
 https://docs.djangoproject.com/en/dev/internals/contributing/writing-
 documentation/ for more details on how the doc works.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #16281: ContentType.get_object_for_this_type using wrong database for creating object

[Django]

#16281: ContentType.get_object_for_this_type using wrong database for creating
object
-+-
 Reporter:  tfrydrychewicz@… |  Owner:  nobody
 Type:  Bug  | Status:  new
Milestone:   |  Component:
  Version:  1.3  |  contrib.contenttypes
 Keywords:  contenttype, object  |   Severity:  Release blocker
  get_object_for_this_type,  |   Triage Stage:  Unreviewed
  database, multiple |  Easy pickings:  0
Has patch:  1|
UI/UX:  0|
-+-
 There is a subtle error in
 
[https://docs.djangoproject.com/en/1.3/ref/contrib/contenttypes/#django.contrib.contenttypes.models.ContentType.get_object_for_this_type
 ContentType.get_object_for_this_type] method.

 {{{
 def get_object_for_this_type(self, **kwargs):
 return
 self.model_class()._default_manager.using(self._state.db).get(**kwargs)
 }}}

 Database used to ''get'' ''model_class'' object is taken from
 self._state.db, which provides an error when ''contenttype'' model is hold
 in one database and model, of which object we're going to create, in
 another one.

 Database should be provided using self.model_class().objects.db not
 self._state.db.

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

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

[Django]

#16264: Improve widget documentation
-+-
   Reporter: |  Owner:  bpeschier
  from_a_far@…   | Status:  new
   Type: |  Component:  Documentation
  Cleanup/optimization   |   Severity:  Normal
  Milestone: |   Keywords:  docs
Version:  1.3|  Has patch:  1
 Resolution: |Needs tests:  0
   Triage Stage:  Accepted   |  Easy pickings:  1
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-

Comment (by anonymous):

 You guys are amazing! Thank you very much!

 Just two things:

  - Where can I see these changes (or do I need to install stuff and do
 repository/git things)
  - Any chance the import locations (e.g. `from django.forms.widgets import
 RadioSelect` and `from django.forms.extras.widgets import
 SelectDateWidget`) can be included with description/examples. This would
 be seriously helpful to us new-bees. (Can't use stuff if you don't know
 how to get 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] #6422: Support for 'DISTINCT ON' queries with QuerySet.distinct()

[Django]

#6422: Support for 'DISTINCT ON' queries with QuerySet.distinct()
-+-
   Reporter:  Manfred|  Owner:  jgelens
  Wassmann | Status:  assigned
   Type:  New|  Component:  Database layer
  feature|  (models, ORM)
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:  dceu2011
 Resolution: |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  1  |
  UI/UX:  0  |
-+-

Comment (by jgelens):

 Fixed your new issue, will create a patch later today.

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

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

[Django]

#16264: Improve widget documentation
-+-
   Reporter: |  Owner:  bpeschier
  from_a_far@…   | Status:  new
   Type: |  Component:  Documentation
  Cleanup/optimization   |   Severity:  Normal
  Milestone: |   Keywords:  docs
Version:  1.3|  Has patch:  1
 Resolution: |Needs tests:  0
   Triage Stage:  Accepted   |  Easy pickings:  1
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by bpeschier):

 * needs_better_patch:  1 => 0


Comment:

 Used an example from {{{SpliteDateTimeWidget}}} to explain compress.

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

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

[Django]

#16264: Improve widget documentation
-+-
   Reporter: |  Owner:  bpeschier
  from_a_far@…   | Status:  new
   Type: |  Component:  Documentation
  Cleanup/optimization   |   Severity:  Normal
  Milestone: |   Keywords:  docs
Version:  1.3|  Has patch:  1
 Resolution: |Needs tests:  0
   Triage Stage:  Accepted   |  Easy pickings:  1
Needs documentation:  0  |
Patch needs improvement:  1  |
  UI/UX:  0  |
-+-
Changes (by julien):

 * needs_better_patch:  0 => 1


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

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

Re: [Django] #16264: Improve widget documentation

[Django]

#16264: Improve widget documentation
-+-
   Reporter: |  Owner:  bpeschier
  from_a_far@…   | Status:  new
   Type: |  Component:  Documentation
  Cleanup/optimization   |   Severity:  Normal
  Milestone: |   Keywords:  docs
Version:  1.3|  Has patch:  1
 Resolution: |Needs tests:  0
   Triage Stage:  Accepted   |  Easy pickings:  1
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-

Comment (by julien):

 OK, I promise this is the last time I send it back :-)

 * Rename `choice` to `choice_field` in the "Widgets inheriting from the
 Select widget" section's code sample.
 * Clarify what "compress" or a "compressed" value means, in the
 "MultiWidget" section.
 * Also in the "MultiWidget" section, use back-quotes and/or cross-
 references for types and method names.

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

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

Re: [Django] #16264: Improve widget documentation

[Django]

#16264: Improve widget documentation
-+-
   Reporter: |  Owner:  bpeschier
  from_a_far@…   | Status:  new
   Type: |  Component:  Documentation
  Cleanup/optimization   |   Severity:  Normal
  Milestone: |   Keywords:  docs
Version:  1.3|  Has patch:  1
 Resolution: |Needs tests:  0
   Triage Stage:  Accepted   |  Easy pickings:  1
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by bpeschier):

 * needs_better_patch:  1 => 0


Comment:

 No problem!

 Fixed a reference to {{{CharField}}} and mentioned format localization as
 well, while we are at 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.