Re: [Django] #3615: Can't define forward references in fixtures using MySQL with InnoDB

2011-06-25 Thread Django
#3615: Can't define forward references in fixtures using MySQL with InnoDB
-+-
   Reporter:  russellm   |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Database layer
Version:  SVN|  (models, ORM)
 Resolution: |   Severity:  Normal
   Triage Stage:  Accepted   |   Keywords:  mysql innodb myisam
Needs documentation:  0  |  reference fixture
Patch needs improvement:  0  |  Has patch:  1
  UI/UX:  0  |Needs tests:  0
 |  Easy pickings:  0
-+-
Changes (by jsdalton):

 * needs_better_patch:  1 => 0


Comment:

 Okay, an improved patch is now attached. I'm unchecking the patch needs
 improvement flag; if anyone has any issues or concerns please feel free to
 point them out and re-check the flag and I will take a look.

 As mentioned in my previous comment, this patch allows for loading of data
 with forward references in MySQL by turning foreign key checks off
 temporarily. It also offers a mechanism to check the data after it was
 entered to ensure invalid foreign keys were not entered while checks were
 disabled.

 The improved patch just cleans up a few rough edges from the previous
 version.

 * Added tests for `DatabaseIntrospection.get_key_columns()`
 * Create meaningful error message when invalid row found. The message
 includes which row, values and columns triggered the missing foreign key
 error, which is useful for debugging bad data in fixture.
 * Raise error on first bad row. As soon as
 `check_for_invalid_foreign_keys()` hits a bad row, it raises an error.
 Reason for this discussed below.
 * Tweaked the API. The API is now more explicit:
 `disable_foreign_key_checks()` and `enable_foreign_key_checks()`. These
 now return boolean values (always True) when implemented. This means you
 can determine if foreign key checks were disabled and then re-enable and
 check for invalid foreign keys only if they were.
 * Added tests disable/enable checks around necessary tests. I ran through
 the test suite and tried to find places where MySQL required this pattern
 for the test to load properly. I found one or two spots that Karen had in
 her original patch and included those.
 * Document new methods. Documentation was added as needed.

 I didn't want to spend any more time gold plating this, but here are
 possible ways this could be improved. I don't think any are really
 necessary or in the scope of this ticket though.

 * Improve fixture error reporting. As mentioned above, I decided to
 trigger foreign key errors when using  `check_for_invalid_foreign_keys()`
 instead of collecting all bad rows and reporting them in the `loaddata`
 error. The reason is that if we are going to make a feature for MySQL like
 this, it should probably be implemented in all backends. It could be
 useful when debugging bad fixture data, but I think it's unnecessary.
 * Scope foreign key checks to given IDs. Right now,
 `check_for_invalid_foreign_keys()` looks at the entire table and raises an
 `IntegrityError` if it finds any bad data. `loaddata` would then roll back
 the fixture load. An issue could arise where bad data is already
 preexisting in the table where data is being loaded, and thus new data
 would not be loaded because of the `IntegrityError` this would raise, even
 though the new fixture data loaded does not actually have any problems.
 Conceivably, you could pass a list of IDs along with the table name and
 limit the checks to only those, but I felt this was an edge case and not
 worth the complexity.
 * Implement as context manager. It'd be cool to do...

 {{{
 with connection.foreign_key_checks_disabled():
 # Load some data with forward references
 }}}

 ...and then implement the checks in the `__exit__` method of the context
 manager, but I couldn't think of a clean way to pass any of the tables
 touched during any load data activities back to that method for checks.
 Since this is really only used in loaddata and not much anywhere else it's
 also probably overkill IMO.

 I've tested this on MySQL 5.1.4 with InnoDB tables and it looks good. As I
 said, if anyone spots any issues let me know.

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

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



Re: [Django] #16342: Django unittests run against installed django by default (rather than the checkout)

2011-06-25 Thread Django
#16342: Django unittests run against installed django by default (rather than 
the
checkout)
--+---
   Reporter:  soren   |  Owner:  nobody
   Type:  Bug | Status:  closed
  Milestone:  |  Component:  Testing framework
Version:  1.3 |   Severity:  Normal
 Resolution:  duplicate   |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  1
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  1   |  Easy pickings:  0
  UI/UX:  0   |
--+---
Changes (by russellm):

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


Comment:

 @Soren - the bug management rules here are that if you have found a
 duplicate, you close the new ticket as a duplicate. Jacob's comment on
 closing #9947 still apply, so I don't see any action required 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] #3777: Persistent change_list filtering in admin

2011-06-25 Thread Django
#3777: Persistent change_list filtering in admin
-+-
   Reporter:  matt   |  Owner:  nobody
   | Status:  reopened
   Type:  New|  Component:  contrib.admin
  feature|   Severity:  Normal
  Milestone: |   Keywords:  filter session
Version:  SVN|  Has patch:  1
 Resolution: |Needs tests:  1
   Triage Stage: |  Easy pickings:  0
  Unreviewed |
Needs documentation:  1  |
Patch needs improvement:  1  |
  UI/UX:  1  |
-+-
Changes (by kmike):

 * status:  closed => reopened
 * cc: kmike (added)
 * needs_better_patch:  0 => 1
 * needs_tests:  0 => 1
 * type:  Uncategorized => New feature
 * ui_ux:  0 => 1
 * resolution:  worksforme =>


Comment:

 I think that shouldn't be closed as 'worksforme' because change_list
 filters are not persistent in django admin and provided workarounds have
 their own issues.

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

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



Re: [Django] #15785: HttpRequest.read(NUM_BYTES) can read beyond the end of wsgi.input stream. (Violation of WSGI spec & under-defined behaviour)

2011-06-25 Thread Django
#15785: HttpRequest.read(NUM_BYTES) can read beyond the end of wsgi.input 
stream.
(Violation of WSGI spec & under-defined behaviour)
-+-
   Reporter: |  Owner:  tomchristie
  tomchristie| Status:  new
   Type:  Bug|  Component:  HTTP handling
  Milestone:  1.3|   Severity:  Normal
Version:  1.3-rc1|   Keywords:  http, wsgi
 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
 * ui_ux:   => 0


Comment:

 Not sure what's wrong, but one test doesn't pass anymore:

 {{{

 Creating test database for alias 'default'...
 Creating test database for alias 'other'...
 Destroying old test database 'other'...
 F...
 ==
 FAIL: test_empty_multipart_raises_error
 (regressiontests.file_uploads.tests.FileUploadTests)
 --
 Traceback (most recent call last):
   File
 "/Users/jezdez/Code/git/django/tests/regressiontests/file_uploads/tests.py",
 line 217, in test_empty_multipart_raises_error
 self.assertRaises(MultiPartParserError, lambda r:
 self.client.request(**r), r)
 AssertionError: MultiPartParserError not raised

 --
 Ran 16 tests in 1.351s

 FAILED (failures=1)
 Destroying test database for alias 'default'...
 Destroying test database for alias 'other'...
 }}}

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

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



Re: [Django] #12761: Paraguayan local flavor

2011-06-25 Thread Django
#12761: Paraguayan local flavor
-+-
   Reporter:  dschulz|  Owner:  BernhardEssl
   Type:  New| Status:  assigned
  feature|  Component:  contrib.localflavor
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:  local flavor
 Resolution: |  paraguay
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
Changes (by BernhardEssl):

 * status:  new => assigned
 * needs_tests:  1 => 0
 * easy:   => 0
 * owner:  nobody => BernhardEssl
 * needs_docs:  1 => 0
 * ui_ux:   => 0


Comment:

 I wrote a patch from the tar and also added tests and documentation.

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

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



Re: [Django] #16334: cache_page decorator does not accept "cache" keyword argument

2011-06-25 Thread Django
#16334: cache_page decorator does not accept "cache" keyword argument
-+-
   Reporter:  anonymous  |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |  Component:  Documentation
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution: |  Has patch:  0
   Triage Stage: |Needs tests:  0
  Unreviewed |  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by anonymous):

 * type:  Bug => Cleanup/optimization
 * component:  Core (Cache system) => Documentation


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

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



Re: [Django] #16297: unexpected behavior with make_list filter

2011-06-25 Thread Django
#16297: unexpected behavior with make_list filter
+---
   Reporter:  ned   |  Owner:  teraom
   Type:  Bug   | Status:  assigned
  Milestone:|  Component:  Documentation
Version:  SVN   |   Severity:  Normal
 Resolution:|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  1
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  1
  UI/UX:  0 |
+---
Changes (by teraom):

 * owner:  nobody => teraom
 * status:  new => assigned
 * has_patch:  0 => 1


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

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



Re: [Django] #16344: Wrong render example in docs

2011-06-25 Thread Django
#16344: Wrong render example in docs
-+-
   Reporter:  Jure   |  Owner:  teraom
  Cuhalev | Status:  assigned
   Type:  Bug|  Component:  Documentation
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage:  Ready for  |Needs tests:  0
  checkin|  Easy pickings:  1
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by PaulM):

 * stage:  Accepted => Ready for checkin


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

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



Re: [Django] #16344: Wrong render example in docs

2011-06-25 Thread Django
#16344: Wrong render example in docs
-+-
   Reporter:  Jure   |  Owner:  teraom
  Cuhalev | Status:  assigned
   Type:  Bug|  Component:  Documentation
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  1
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by teraom):

 * status:  new => assigned
 * owner:  nobody => teraom
 * has_patch:  0 => 1


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

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



Re: [Django] #16344: Wrong render example in docs

2011-06-25 Thread Django
#16344: Wrong render example in docs
-+-
   Reporter:  Jure   |  Owner:  nobody
  Cuhalev | Status:  new
   Type:  Bug|  Component:  Documentation
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:
 Resolution: |  Has patch:  0
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  1
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by PaulM):

 * needs_docs:   => 0
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * easy:  0 => 1
 * 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] #16343: Reference to docs on how to run tests in README is out of date

2011-06-25 Thread Django
#16343: Reference to docs on how to run tests in README is out of date
-+-
   Reporter:  soren  |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Documentation
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Ready for  |  Has patch:  1
  checkin|Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by PaulM):

 * needs_docs:   => 0
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * stage:  Unreviewed => Ready for checkin


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

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



Re: [Django] #16342: Django unittests run against installed django by default (rather than the checkout)

2011-06-25 Thread Django
#16342: Django unittests run against installed django by default (rather than 
the
checkout)
--+---
   Reporter:  soren   |  Owner:  nobody
   Type:  Bug | Status:  new
  Milestone:  |  Component:  Testing framework
Version:  1.3 |   Severity:  Normal
 Resolution:  |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  1
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  1   |  Easy pickings:  0
  UI/UX:  0   |
--+---

Comment (by PaulM):

 I agree that this turns off new developers, but it's an absolute non-issue
 for the more experienced devs. To the best of my knowledge, everyone who
 does much work on the codebase uses virtualenv to isolate their
 environment. This means that there isn't a system install of Django at
 all, and there's absolutely no chance that there is more than one valid
 "django" to import.

 We should really be teaching new users to use virtualenv at the end of the
 tutorial. If we can't get it there, we should at least include it in the
 documentation on writing tests or working on Django.

 Mucking around with the path in the test suite is likely to be a
 nonstarter. It's much better to let Python do the imports as expected, and
 require users to modify the environment themselves where necessary.

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

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



Re: [Django] #16336: Weak salts for auth backend

2011-06-25 Thread Django
#16336: Weak salts for auth backend
-+--
   Reporter:  ninjaneo   |  Owner:  nobody
   Type:  Uncategorized  | Status:  closed
  Milestone: |  Component:  contrib.auth
Version:  1.3|   Severity:  Normal
 Resolution:  duplicate  |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+--

Comment (by PaulM):

 Read the code again. Maybe try it in a Python interpreter. The function
 takes two long random inputs, hashes them, and only then truncates the
 resulting hash. The hash is truncated, not the random number. So you're
 really looking at 16^5^ = 1048576 possibilities. I agree that it's still
 too short, but it's not at all as bad as you make it out to be.

 When you report issues like this, please take the time to verify that the
 code actually works the way you think it does. It makes it a lot easier
 for everyone if the bug report doesn't contain misleading information.

 Also, for the record, iterative hashing is an issue which is completely
 orthogonal to salting. They both contribute to security, but in different
 ways. Iterative hashing is related to algorithm choice. Salting is
 designed to prevent pre-computed dictionary attacks.

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

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



Re: [Django] #11954: ?next linking to a login_required view doesn't work

2011-06-25 Thread Django
#11954: ?next linking to a login_required view doesn't work
--+--
   Reporter:  libwilliam  |  Owner:  nobody
   Type:  Bug | Status:  closed
  Milestone:  |  Component:  contrib.auth
Version:  1.1 |   Severity:  Normal
 Resolution:  fixed   |   Keywords:
   Triage Stage:  Accepted|  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+--
Changes (by jezdez):

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


Comment:

 I believe this has been fixed a while ago.

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

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



Re: [Django] #15820: inline admin formset uses incorrect form

2011-06-25 Thread Django
#15820: inline admin formset uses incorrect form
-+-
   Reporter:  shanyu |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  contrib.admin
Version:  1.2|   Severity:  Normal
 Resolution: |   Keywords:  inlinemodeladmin,
   Triage Stage:  Ready for  |  inlines
  checkin|  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
Changes (by prestontimmons):

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


Comment:

 I applied and reviewed this patch for r16452. It looks good. Marking as
 RFC.

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

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



Re: [Django] #16262: ValueError when authenticating

2011-06-25 Thread Django
#16262: ValueError when authenticating
---+--
   Reporter:  mitar|  Owner:  nobody
   Type:  New feature  | Status:  reopened
  Milestone:   |  Component:  contrib.auth
Version:  1.3  |   Severity:  Normal
 Resolution:   |   Keywords:  auth backend
   Triage Stage:  Accepted |  Has patch:  1
Needs documentation:  1|Needs tests:  1
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+--
Changes (by jezdez):

 * stage:  Design decision needed => Accepted


Comment:

 After talking to some during the sprint, marking as 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] #16334: cache_page decorator does not accept "cache" keyword argument

2011-06-25 Thread Django
#16334: cache_page decorator does not accept "cache" keyword argument
-+-
   Reporter:  anonymous  |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Core (Cache system)
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-

Comment (by anonymous):

 Keryn, ah yes .. you're right. This makes a lot more sense now. I had a
 feeling it wasn't meant for what I thought it was for, but the
 documentation was confusing in that aspect.

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

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



Re: [Django] #16115: New hook to allow change objects after all inline formsets have been saved

2011-06-25 Thread Django
#16115: New hook to allow change objects after all inline formsets have been 
saved
-+-
   Reporter:  igors  |  Owner:
   Type:  New| Status:  new
  feature|  Component:  contrib.admin
  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 prestontimmons):

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


Comment:

 I applied and reviewed the patch at r16452. It looks good to me. Updating
 to RFC.

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

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



Re: [Django] #15907: Generic inlines ignoring the exclude information from a custom form.

2011-06-25 Thread Django
#15907: Generic inlines ignoring the exclude information from a custom form.
-+-
   Reporter: |  Owner:  nobody
  leonelfreire   | Status:  new
   Type:  Bug|  Component:  Forms
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:  form, exclude,
 Resolution: |  generic, inline
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
Changes (by prestontimmons):

 * 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] #15907: Generic inlines ignoring the exclude information from a custom form.

2011-06-25 Thread Django
#15907: Generic inlines ignoring the exclude information from a custom form.
-+-
   Reporter: |  Owner:  nobody
  leonelfreire   | Status:  new
   Type:  Bug|  Component:  Forms
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:  form, exclude,
 Resolution: |  generic, inline
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  1  |  Easy pickings:  0
  UI/UX:  0  |
-+-
Changes (by prestontimmons):

 * needs_better_patch:  0 => 1
 * ui_ux:   => 0


Comment:

 The attached patch is a bad fix. It conflicts with behavior expected in
 #8999, which depends on the exclude argument to modelformset_factory
 trumping exclude information in the ModelForm.Meta.

 A better place to fix this is in generic_inlineformset_factory. When
 exclude information isn't passed in, combine the default contenttype
 fields with the model form meta fields.

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

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



Re: [Django] #811: IPv6 address field support

2011-06-25 Thread Django
#811: IPv6 address field support
-+-
   Reporter: |  Owner:  erikr
  mattimustang@… | Status:  closed
   Type:  New|  Component:  Core (Other)
  feature|   Severity:  Normal
  Milestone: |   Keywords:  ipv6 IPAddressField
Version:  SVN|  dceu2011
 Resolution:  fixed  |  Has patch:  1
   Triage Stage:  Ready for  |Needs tests:  0
  checkin|  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-

Comment (by onelson):

 I realize this is a bit beside the point, but in case it's useful I
 recently put out a simple model field:
 https://bitbucket.org/onelson/django-ipyfield

 As for my case, I didn't have a problem delegating the validation of input
 to IPy and I also needed a single field able to handle the storage of both
 v4 and v6 addresses. To dodge the potential storage issues on the db side,
 I leverage IPy to store all addresses as longs.

 I guess this isn't good for core, or contrib dependencies because of the
 dependency on IPy, but I just wanted to let you know!

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

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



Re: [Django] #15884: Model validation allows nullable primary key field.

2011-06-25 Thread Django
#15884: Model validation allows nullable primary key field.
-+-
   Reporter: |  Owner:  JustinTArthur
  JustinTArthur  | Status:  assigned
   Type:  Bug|  Component:  Database layer
  Milestone: |  (models, ORM)
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
Changes (by jpichon):

 * cc: julie@… (added)
 * ui_ux:   => 0
 * needs_tests:  1 => 0


Comment:

 I'm attaching a patch with a test for the new validation behaviour -- the
 patch also includes JustinTArthur's diff as there was a missing double-
 quote around the field name.

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

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



Re: [Django] #15852: Exception when http.parse_cookie recieves bad cookie

2011-06-25 Thread Django
#15852: Exception when http.parse_cookie recieves bad cookie
-+-
   Reporter:  Fredrik|  Owner:  nobody
  Stålnacke  | Status:  closed
   Type:  Bug|  Component:  HTTP handling
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:  parse_cookie
 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:  new => closed
 * resolution:   => fixed


Comment:

 In [16452]:
 {{{
 #!CommitTicketReference repository="" revision="16452"
 Fixed #15852 -- Modified cookie parsing so it can handle duplicate invalid
 cookie names. Thanks goes to Fredrik Stålnacke for the report and to vung
 for the patch.
 }}}

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

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



[Changeset] r16452 - in django/trunk: django/http tests/regressiontests/httpwrappers

2011-06-25 Thread noreply
Author: ramiro
Date: 2011-06-25 09:18:40 -0700 (Sat, 25 Jun 2011)
New Revision: 16452

Modified:
   django/trunk/django/http/__init__.py
   django/trunk/tests/regressiontests/httpwrappers/tests.py
Log:
Fixed #15852 -- Modified cookie parsing so it can handle duplicate invalid 
cookie names. Thanks goes to Fredrik St?\195?\165lnacke for the report and to 
vung for the patch.

Modified: django/trunk/django/http/__init__.py
===
--- django/trunk/django/http/__init__.py2011-06-25 13:14:31 UTC (rev 
16451)
+++ django/trunk/django/http/__init__.py2011-06-25 16:18:40 UTC (rev 
16452)
@@ -91,7 +91,7 @@
 if not _cookie_allows_colon_in_names:
 def load(self, rawdata, ignore_parse_errors=False):
 if ignore_parse_errors:
-self.bad_cookies = []
+self.bad_cookies = set()
 self._BaseCookie__set = self._loose_set
 super(SimpleCookie, self).load(rawdata)
 if ignore_parse_errors:
@@ -105,8 +105,8 @@
 try:
 self._strict_set(key, real_value, coded_value)
 except Cookie.CookieError:
-self.bad_cookies.append(key)
-dict.__setitem__(self, key, None)
+self.bad_cookies.add(key)
+dict.__setitem__(self, key, Cookie.Morsel())
 
 
 class CompatCookie(SimpleCookie):

Modified: django/trunk/tests/regressiontests/httpwrappers/tests.py
===
--- django/trunk/tests/regressiontests/httpwrappers/tests.py2011-06-25 
13:14:31 UTC (rev 16451)
+++ django/trunk/tests/regressiontests/httpwrappers/tests.py2011-06-25 
16:18:40 UTC (rev 16452)
@@ -285,3 +285,9 @@
 Test that a single non-standard cookie name doesn't affect all 
cookies. Ticket #13007.
 """
 self.assertTrue('good_cookie' in 
parse_cookie('good_cookie=yes;bad:cookie=yes').keys())
+
+def test_repeated_nonstandard_keys(self):
+"""
+Test that a repeated non-standard name doesn't affect all cookies. 
Ticket #15852
+"""
+self.assertTrue('good_cookie' in parse_cookie('a,=b; a,=c; 
good_cookie=yes').keys())

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



Re: [Django] #16130: Add some information about admin media in staticfiles documentation

2011-06-25 Thread Django
#16130: Add some information about admin media in staticfiles documentation
-+-
   Reporter:  aroy   |  Owner:
   Type: | Status:  new
  Cleanup/optimization   |  Component:  Documentation
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution: |  Has patch:  0
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  1
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by d0ugal):

 * owner:  d0ugal =>
 * status:  assigned => new
 * 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] #15497: BooleanField should work for all PostgreSQL expressions

2011-06-25 Thread Django
#15497: BooleanField should work for all PostgreSQL expressions
-+-
   Reporter:  lsaffre|  Owner:  nobody
   Type:  New| Status:  new
  feature|  Component:  Database layer
  Milestone: |  (models, ORM)
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 jpichon):

 * cc: julie@… (added)
 * ui_ux:   => 0
 * easy:   => 0
 * needs_tests:  1 => 0


Comment:

 I attached a patch that includes Isaffre's diff, makes the same change for
 NullBooleanField and adds a couple of tests.

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

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



Re: [Django] #16342: Django unittests run against installed django by default (rather than the checkout)

2011-06-25 Thread Django
#16342: Django unittests run against installed django by default (rather than 
the
checkout)
--+---
   Reporter:  soren   |  Owner:  nobody
   Type:  Bug | Status:  new
  Milestone:  |  Component:  Testing framework
Version:  1.3 |   Severity:  Normal
 Resolution:  |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  1
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  1   |  Easy pickings:  0
  UI/UX:  0   |
--+---
Changes (by aaugustin):

 * needs_better_patch:  0 => 1


Comment:

 An alternative is to implement a warning when the tests are run against a
 version of Django that is not the local checkout. That might be acceptable
 by the core developers.

 Technically, your ticket is a duplicate of another ticket that was closed
 by a core developer as wontfix. The standard procedure would be to close
 it and tell you to start a discussion on django-developers.

 However, I think it's something that can easily turn off new contributors,
 so we should try to help them a little bit without hindering the workflow
 of the core developers. I'll try to get some feedback, and I don't close
 the ticket right now.

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

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



Re: [Django] #16304: Add HTML5 'placeholder' attribute support to form fields.

2011-06-25 Thread Django
#16304: Add HTML5 'placeholder' attribute support to form fields.
-+-
   Reporter:  rich@… |  Owner:  nobody
   Type:  New| Status:  new
  feature|  Component:  Forms
  Milestone: |   Severity:  Normal
Version:  SVN|   Keywords:  forms, placeholder,
 Resolution: |  html5
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  1  |Needs tests:  1
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  1  |
-+-

Comment (by d0ugal):

 I think this ticket needs to be coordinated with the form rendering GSOC
 as a number of changes are being made in this area. Thus you may want to
 add it to the discussion on the mailing list:
 https://groups.google.com/d/topic/django-developers/N5EVJhb9la4/discussion

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

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



Re: [Django] #15117: get_or_create() raises "DatabaseError: no such savepoint" instead of IntegrityError (PostgreSQL)

2011-06-25 Thread Django
#15117: get_or_create() raises "DatabaseError: no such savepoint" instead of
IntegrityError (PostgreSQL)
-+-
   Reporter:  akaihola   |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone:  1.4|  Component:  Database layer
Version:  SVN|  (models, ORM)
 Resolution: |   Severity:  Normal
   Triage Stage:  Accepted   |   Keywords:
Needs documentation:  0  |  Has patch:  0
Patch needs improvement:  0  |Needs tests:  0
  UI/UX:  0  |  Easy pickings:  0
-+-

Comment (by andrewgodwin):

 So, I worked with Dougal on this at the Europython sprints, and the
 problem is that the code tries to COMMIT the previous transaction, which
 fails, and then tries to ROLLBACK TO SAVEPOINT after the commit has
 failed.

 As far as I can tell, the failing COMMIT implicitly clears the savepoints
 in the previous transaction. The postgres client libraries reflect this by
 sending a BEGIN along with the ROLLBACK TO SAVEPOINT, as they assume the
 failing COMMIT cancels the previous transaction. This then causes the
 ROLLBACK TO SAVEPOINT to fail, as it's a new transaction without that
 savepoint.

 We changed the backend to not send the BEGIN after the COMMIT, but then
 Postgres complained that this was invalid, and so I suspect it's not valid
 to send ROLLBACK TO SAVEPOINT _after_ COMMIT (all the examples in the
 postgres docs have it before a COMMIT).

 It seems, then, that the "clean" fix would be to make this code just start
 a new transaction if its COMMIT fails, but that leads to potential nesting
 errors depending if the outer code has already started a transaction or
 not. I can't see a nice way to roll back to the savepoint at the moment,
 but my brain hurts after too much poking around with transactions, and I
 can't find the part of the SQL spec that Postgres is apparently adhering
 to in this regard (I think it's in SQL 1999, and I can't find where to
 download 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] #16342: Django unittests run against installed django by default (rather than the checkout)

2011-06-25 Thread Django
#16342: Django unittests run against installed django by default (rather than 
the
checkout)
--+---
   Reporter:  soren   |  Owner:  nobody
   Type:  Bug | Status:  new
  Milestone:  |  Component:  Testing framework
Version:  1.3 |   Severity:  Normal
 Resolution:  |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  1
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+---

Comment (by soren):

 I was just told about ticket #9947, which refers to the same issue.

 I'd like to attack this problem somehow. I'm not familiar with the bug
 management rules here. If it's more appropriate to reopen the old one and
 ditch this one, that's fine. Feel free to close this.

 I can vaguely relate to the desire to run new tests against old code.

 For those of you who actually make use of this, am I correct to assume
 that this is less common than running new tests against new code? I mean,
 it seems more natural to me that development of both "real" code and tests
 happens in the code checkout, but I've been surprised before :)

 Would everyone's needs be met if the default was to prepend the toplevel
 dir to sys.path, but there was a simple way to disable this behaviour
 (like setting an environment variable or something)?

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

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

2011-06-25 Thread Django
#16344: Wrong render example in docs
--+---
 Reporter:  Jure Cuhalev   |  Owner:  nobody
 Type:  Bug   | Status:  new
Milestone:|  Component:  Documentation
  Version:  SVN   |   Severity:  Normal
 Keywords:|   Triage Stage:  Unreviewed
Has patch:  0 |  Easy pickings:  0
UI/UX:  0 |
--+---
 In second example for render():
 https://docs.djangoproject.com/en/dev/topics/http/shortcuts/#example

 it imports Context but then uses RequestContext.

 Fix:
 change:
 c = RequestContext(request, {'foo': 'bar'})
 to:

 c = Context(request, {'foo': 'bar'})

 since it's a simple render

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #16343: Reference to docs on how to run tests in README is out of date

2011-06-25 Thread Django
#16343: Reference to docs on how to run tests in README is out of date
---+---
 Reporter:  soren  |  Owner:  nobody
 Type:  Bug| Status:  new
Milestone: |  Component:  Documentation
  Version:  1.3|   Severity:  Normal
 Keywords: |   Triage Stage:  Unreviewed
Has patch:  1  |  Easy pickings:  0
UI/UX:  0  |
---+---
 The docs on uni tets have moved from docs/internals/contributing.txt to
 docs/internals/contributing/writing-code/unit-tests.txt. The top-level
 README still points to the old location.

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

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



Re: [Django] #16342: Django unittests run against installed django by default (rather than the checkout) (was: Django unittests run against install django by default (rather than the checkout))

2011-06-25 Thread Django
#16342: Django unittests run against installed django by default (rather than 
the
checkout)
--+---
   Reporter:  soren   |  Owner:  nobody
   Type:  Bug | Status:  new
  Milestone:  |  Component:  Testing framework
Version:  1.3 |   Severity:  Normal
 Resolution:  |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  1
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  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] #16342: Django unittests run against install django by default (rather than the checkout)

2011-06-25 Thread Django
#16342: Django unittests run against install django by default (rather than the
checkout)
--+---
   Reporter:  soren   |  Owner:  nobody
   Type:  Bug | Status:  new
  Milestone:  |  Component:  Testing framework
Version:  1.3 |   Severity:  Normal
 Resolution:  |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  1
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+---
Changes (by soren):

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


Comment:

 Attached a patch to fix it. I've no clue how to test this (or whether to
 do so at all, really). Feedback happily 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.



[Django] #16342: Django unittests run against install django by default (rather than the checkout)

2011-06-25 Thread Django
#16342: Django unittests run against install django by default (rather than the
checkout)
---+---
 Reporter:  soren  |  Owner:  nobody
 Type:  Bug| Status:  new
Milestone: |  Component:  Testing framework
  Version:  1.3|   Severity:  Normal
 Keywords: |   Triage Stage:  Unreviewed
Has patch:  0  |  Easy pickings:  0
UI/UX:  0  |
---+---
 By default, tests/runtests.py will import various things from "django".
 This means that if you're lucky, you don't have a Django install in your
 standard PYTHONPATH and you'll get an error, realise the error of your
 ways, and you can amend your PYTHONPATH. If you're less lucky, runtests.py
 will happily import the *installed* django, and you will get very, very
 confused why tests are passing even though you know you broke something.

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

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



Re: [Django] #6189: IntegrityError: Field "may not be NULL" even though blank=True

2011-06-25 Thread Django
#6189: IntegrityError: Field "may not be NULL" even though blank=True
-+-
   Reporter:  Tyson  |  Owner:  nobody
  Tate  | Status:  closed
   Type: |  Component:  contrib.admin
  Uncategorized  |   Severity:  Normal
  Milestone: |   Keywords:  integrityerror,
Version:  SVN|  blank, null
 Resolution:  invalid|  Has patch:  0
   Triage Stage: |Needs tests:  0
  Unreviewed |  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by ramiro):

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


Comment:

 Sorry for the noise. I mis typed the ticket number in a commit message.

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

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



Re: [Django] #6189: IntegrityError: Field "may not be NULL" even though blank=True

2011-06-25 Thread Django
#6189: IntegrityError: Field "may not be NULL" even though blank=True
-+-
   Reporter:  Tyson  |  Owner:  nobody
  Tate  | Status:  reopened
   Type: |  Component:  contrib.admin
  Uncategorized  |   Severity:  Normal
  Milestone: |   Keywords:  integrityerror,
Version:  SVN|  blank, null
 Resolution: |  Has patch:  0
   Triage Stage: |Needs tests:  0
  Unreviewed |  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by ramiro):

 * status:  closed => reopened
 * severity:   => Normal
 * type:   => Uncategorized
 * easy:   => 0
 * ui_ux:   => 0
 * resolution:  fixed =>


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

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



Re: [Django] #16189: Tests with URLField(verify_exists=True) should use a mock and not access the internet directly.

2011-06-25 Thread Django
#16189: Tests with URLField(verify_exists=True) should use a mock and not access
the internet directly.
-+-
   Reporter: |  Owner:  gregmuellegger
  gregmuellegger | Status:  closed
   Type: |  Component:  Testing framework
  Cleanup/optimization   |   Severity:  Normal
  Milestone: |   Keywords:  verify_exists
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 ramiro):

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


Comment:

 In [16451]:

 Fixed #16189 -- Modified test that need Internet access so they use a mock
 instead. Thanks Gregor Müellegger for the patch.

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

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



Re: [Django] #16208: natural key YAML deserialization using non-list natural keys broken (with fixing patch)

2011-06-25 Thread Django
#16208: natural key YAML deserialization using non-list natural keys broken 
(with
fixing patch)
+--
   Reporter:  jeff.k@…  |  Owner:  nobody
   Type:  Bug   | Status:  new
  Milestone:|  Component:  Core (Serialization)
Version:  1.2   |   Severity:  Normal
 Resolution:|   Keywords:  yaml
   Triage Stage:  Accepted  |  Has patch:  1
Needs documentation:  0 |Needs tests:  1
Patch needs improvement:  1 |  Easy pickings:  1
  UI/UX:  0 |
+--

Comment (by gserra):

 Dear Agustin,

 Have you considered that the deserialization field "Hemingway" is not
 correct? If you check the django docs you can see that is necessary for
 the serialization of the naturals keys to return a tuple.

 So, in that case, I would consider you to return (self.name,)

 {{{
 class AuthorManager(models.Manager):
 def get_by_natural_key(self, name):
 return (self.get(name=name),)
 }}}

 And see if it fails again.

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

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



[Changeset] r16451 - django/trunk/tests/regressiontests/forms/tests

2011-06-25 Thread noreply
Author: ramiro
Date: 2011-06-25 06:14:31 -0700 (Sat, 25 Jun 2011)
New Revision: 16451

Modified:
   django/trunk/tests/regressiontests/forms/tests/error_messages.py
   django/trunk/tests/regressiontests/forms/tests/fields.py
Log:
Fixed #6189 -- Modified test that need Internet access so they use a mock 
instead. Thanks Gregor M?\195?\188ellegger for the patch.

Modified: django/trunk/tests/regressiontests/forms/tests/error_messages.py
===
--- django/trunk/tests/regressiontests/forms/tests/error_messages.py
2011-06-25 12:39:57 UTC (rev 16450)
+++ django/trunk/tests/regressiontests/forms/tests/error_messages.py
2011-06-25 13:14:31 UTC (rev 16451)
@@ -4,6 +4,7 @@
 from django.test import TestCase
 from django.utils.safestring import mark_safe
 from django.utils import unittest
+from regressiontests.forms.tests.fields import verify_exists_urls
 
 class AssertFormErrorsMixin(object):
 def assertFormErrors(self, expected, the_callable, *args, **kwargs):
@@ -139,6 +140,7 @@
 self.assertFormErrors([u'EMPTY FILE'], f.clean, 
SimpleUploadedFile('name', None))
 self.assertFormErrors([u'EMPTY FILE'], f.clean, 
SimpleUploadedFile('name', ''))
 
+@verify_exists_urls()
 def test_urlfield(self):
 e = {
 'required': 'REQUIRED',

Modified: django/trunk/tests/regressiontests/forms/tests/fields.py
===
--- django/trunk/tests/regressiontests/forms/tests/fields.py2011-06-25 
12:39:57 UTC (rev 16450)
+++ django/trunk/tests/regressiontests/forms/tests/fields.py2011-06-25 
13:14:31 UTC (rev 16451)
@@ -25,11 +25,11 @@
 __init__(). For example, CharField has a max_length option.
 """
 import datetime
-import time
 import re
 import os
 import urllib2
 from decimal import Decimal
+from functools import wraps
 
 from django.core.files.uploadedfile import SimpleUploadedFile
 from django.forms import *
@@ -48,6 +48,28 @@
 return x
 
 
+def verify_exists_urls(existing_urls=()):
+def decorator(func):
+@wraps(func)
+def wrapper(*args, **kwargs):
+from django.core import validators
+# patch urllib2
+original_urlopen = validators.urllib2.urlopen
+def urlopen(req):
+url = req.get_full_url()
+if url in existing_urls:
+return True
+raise Exception()
+try:
+urllib2.urlopen = urlopen
+func(*args, **kwargs)
+finally:
+# unpatch urllib2
+validators.urllib2.urlopen = original_urlopen
+return wrapper
+return decorator
+
+
 class FieldsTests(TestCase):
 
 def assertRaisesErrorWithMessage(self, error, message, callable, *args, 
**kwargs):
@@ -595,9 +617,10 @@
 self.assertRaisesErrorWithMessage(ValidationError, "[u'Enter a valid 
URL.']", f.clean, 'http://example.')
 self.assertRaisesErrorWithMessage(ValidationError, "[u'Enter a valid 
URL.']", f.clean, 'http://.com')
 
+@verify_exists_urls(('http://www.google.com/',))
 def test_urlfield_3(self):
 f = URLField(verify_exists=True)
-self.assertEqual(u'http://www.google.com/', 
f.clean('http://www.google.com')) # This will fail if there's no Internet 
connection
+self.assertEqual(u'http://www.google.com/', 
f.clean('http://www.google.com'))
 self.assertRaisesErrorWithMessage(ValidationError, "[u'Enter a valid 
URL.']", f.clean, 'http://example')
 self.assertRaises(ValidationError, f.clean, 
'http://www.broken.djangoproject.com') # bad domain
 self.assertRaises(ValidationError, f.clean, 
'http://qa-dev.w3.org/link-testsuite/http.php?code=405') # Method not allowed
@@ -611,10 +634,11 @@
 except ValidationError, e:
 self.assertEqual("[u'This URL appears to be a broken link.']", 
str(e))
 
+@verify_exists_urls(('http://www.google.com/',))
 def test_urlfield_4(self):
 f = URLField(verify_exists=True, required=False)
 self.assertEqual(u'', f.clean(''))
-self.assertEqual(u'http://www.google.com/', 
f.clean('http://www.google.com')) # This will fail if there's no Internet 
connection
+self.assertEqual(u'http://www.google.com/', 
f.clean('http://www.google.com'))
 
 def test_urlfield_5(self):
 f = URLField(min_length=15, max_length=20)
@@ -663,17 +687,12 @@
 except ValidationError, e:
 self.assertEqual("[u'This URL appears to be a broken link.']", 
str(e))
 
+@verify_exists_urls(('http://xn--tr-xka.djangoproject.com/',))
 def test_urlfield_10(self):
-# UTF-8 char in path, enclosed by a monkey-patch to make sure
-# the encoding is passed to urllib2.urlopen
+# UTF-8 char in path
 f = URLField(verify_exists=True)
-try:
-_orig_urlopen = urllib2.urlopen
-

Re: [Django] #6189: IntegrityError: Field "may not be NULL" even though blank=True

2011-06-25 Thread Django
#6189: IntegrityError: Field "may not be NULL" even though blank=True
-+-
   Reporter:  Tyson  |Owner:  nobody
  Tate  |   Status:  closed
   Type: |Component:  contrib.admin
  Milestone: | Severity:
Version:  SVN| Keywords:  integrityerror,
 Resolution:  fixed  |  blank, null
   Triage Stage: |Has patch:  0
  Unreviewed |  Needs tests:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by ramiro):

 * resolution:  invalid => fixed


Comment:

 In [16451]:
 {{{
 #!CommitTicketReference repository="" revision="16451"
 Fixed #6189 -- Modified test that need Internet access so they use a mock
 instead. Thanks Gregor Müellegger for the patch.
 }}}

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

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



Re: [Django] #16209: Add alternative repositories to 'Installing the development version' in the docs.

2011-06-25 Thread Django
#16209: Add alternative repositories to 'Installing the development version' in 
the
docs.
-+-
   Reporter:  ShawnMilo  |  Owner:  ShawnMilo
   Type:  New| Status:  new
  feature|  Component:  Documentation
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage:  Ready for  |Needs tests:  0
  checkin|  Easy pickings:  1
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by jezdez):

 * stage:  Accepted => Ready for checkin


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

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



Re: [Django] #16340: get_or_create should preserve the original traceback.

2011-06-25 Thread Django
#16340: get_or_create should preserve the original traceback.
-+-
   Reporter:  d0ugal |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |  Component:  Database layer
  Milestone: |  (models, ORM)
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+-
Changes (by ramiro):

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



[Changeset] r16450 - django/trunk/docs/topics

2011-06-25 Thread noreply
Author: ramiro
Date: 2011-06-25 05:39:57 -0700 (Sat, 25 Jun 2011)
New Revision: 16450

Modified:
   django/trunk/docs/topics/auth.txt
Log:
Fixed #16207 -- Enhanced documentation about user profile model instance 
creation. Thanks foxwhisper for the report, melinath for the patch and Julien 
for reviewing it.

Modified: django/trunk/docs/topics/auth.txt
===
--- django/trunk/docs/topics/auth.txt   2011-06-25 12:39:48 UTC (rev 16449)
+++ django/trunk/docs/topics/auth.txt   2011-06-25 12:39:57 UTC (rev 16450)
@@ -262,9 +262,10 @@
 
 Returns a site-specific profile for this user. Raises
 :exc:`django.contrib.auth.models.SiteProfileNotAvailable` if the
-current site doesn't allow profiles. For information on how to define a
-site-specific user profile, see the section on `storing additional user
-information`_ below.
+current site doesn't allow profiles, or
+:exc:`django.core.exceptions.ObjectDoesNotExist` if the user does not
+have a profile. For information on how to define a site-specific user
+profile, see the section on `storing additional user information`_ 
below.
 
 .. _storing additional user information: 
#storing-additional-information-about-users
 
@@ -470,8 +471,19 @@
 :class:`~django.db.models.Field.OneToOneField` named ``user`` from your model
 to the :class:`~django.contrib.auth.models.User` model. This will ensure only
 one instance of your model can be created for each
-:class:`~django.contrib.auth.models.User`.
+:class:`~django.contrib.auth.models.User`. For example::
 
+from django.contrib.auth.models import User
+
+class UserProfile(models.Model):
+# This field is required.
+user = models.OneToOneField(User)
+
+# Other fields here
+accepted_eula = models.BooleanField()
+favorite_animal = models.CharField(max_length=20, default="Dragons.")
+
+
 To indicate that this model is the user profile model for a given site, fill in
 the setting :setting:`AUTH_PROFILE_MODULE` with a string consisting of the
 following items, separated by a dot:
@@ -496,15 +508,27 @@
 :class:`~django.contrib.auth.models.User`.
 
 The method :class:`~django.contrib.auth.models.User.get_profile()`
-does not create the profile, if it does not exist. You need to
-register a handler for the signal
-:attr:`django.db.models.signals.post_save` on the User model, and, in
-the handler, if created=True, create the associated user profile.
+does not create a profile if one does not exist. You need to register a handler
+for the User model's :attr:`django.db.models.signals.post_save` signal and, in
+the handler, if ``created`` is ``True``, create the associated user profile::
 
-For more information, see `Chapter 12 of the Django book`_.
+# in models.py
 
-.. _Chapter 12 of the Django book: 
http://www.djangobook.com/en/1.0/chapter12/#cn222
+from django.contrib.auth.models import User
+from django.db.models.signals import post_save
 
+# definition of UserProfile from above
+# ...
+
+def create_user_profile(sender, instance, created, **kwargs):
+if created:
+UserProfile.objects.create(user=instance)
+
+post_save.connect(create_user_profile, sender=User)
+
+.. seealso:: :doc:`/topics/signals` for more information on Django's signal
+dispatcher.
+
 Authentication in Web requests
 ==
 

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



Re: [Django] #16207: UserProfile documentation (not extensive enough)

2011-06-25 Thread Django
#16207: UserProfile documentation (not extensive enough)
-+-
   Reporter: |  Owner:  melinath
  foxwhisper | Status:  closed
   Type:  Bug|  Component:  Documentation
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:  userprofile
 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 ramiro):

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


Comment:

 In [16450]:
 {{{
 #!CommitTicketReference repository="" revision="16450"
 Fixed #16207 -- Enhanced documentation about user profile model instance
 creation. Thanks foxwhisper for the report, melinath for the patch and
 Julien for reviewing 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] #16214: Simplify docs for 404 and 500 views

2011-06-25 Thread Django
#16214: Simplify docs for 404 and 500 views
-+-
   Reporter:  aaugustin  |  Owner:  nobody
   Type: | Status:  closed
  Cleanup/optimization   |  Component:  Documentation
  Milestone: |   Severity:  Normal
Version:  SVN|   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 ramiro):

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


Comment:

 In [16449]:
 {{{
 #!CommitTicketReference repository="" revision="16449"
 Fixed #16214 -- Enhanced documentation about HTTP 404 and 500 status views
 and templates. Thanks Aymeric Augustin for the report and patch.
 }}}

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

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



[Changeset] r16448 - django/trunk/django/contrib/localflavor/in_

2011-06-25 Thread noreply
Author: ramiro
Date: 2011-06-25 05:39:38 -0700 (Sat, 25 Jun 2011)
New Revision: 16448

Modified:
   django/trunk/django/contrib/localflavor/in_/in_states.py
Log:
Fixed #16223 -- Removed a duplicate item from India normalized states names 
list. Thanks traff for the report and patch.

Modified: django/trunk/django/contrib/localflavor/in_/in_states.py
===
--- django/trunk/django/contrib/localflavor/in_/in_states.py2011-06-25 
12:39:29 UTC (rev 16447)
+++ django/trunk/django/contrib/localflavor/in_/in_states.py2011-06-25 
12:39:38 UTC (rev 16448)
@@ -79,6 +79,5 @@
 'orisa': 'OR',
 'odisa': 'OR',
 'or': 'OR',
-'ar': 'AR',
 }
 

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

2011-06-25 Thread noreply
Author: ramiro
Date: 2011-06-25 05:39:29 -0700 (Sat, 25 Jun 2011)
New Revision: 16447

Modified:
   django/trunk/django/contrib/localflavor/at/forms.py
   django/trunk/docs/ref/contrib/localflavor.txt
   django/trunk/tests/regressiontests/forms/localflavor/at.py
Log:
Fixed #16338 -- Fixed Austrian postal codes validation. Thanks Bernhard Essl 
for the report and patch.

Modified: django/trunk/django/contrib/localflavor/at/forms.py
===
--- django/trunk/django/contrib/localflavor/at/forms.py 2011-06-25 08:41:58 UTC 
(rev 16446)
+++ django/trunk/django/contrib/localflavor/at/forms.py 2011-06-25 12:39:29 UTC 
(rev 16447)
@@ -16,13 +16,13 @@
 """
 A form field that validates its input is an Austrian postcode.
 
-Accepts 4 digits.
+Accepts 4 digits (first digit must be greater than 0).
 """
 default_error_messages = {
 'invalid': _('Enter a zip code in the format .'),
 }
 def __init__(self, max_length=None, min_length=None, *args, **kwargs):
-super(ATZipCodeField, self).__init__(r'^\d{4}$',
+super(ATZipCodeField, self).__init__(r'^[1-9]{1}\d{3}$',
 max_length, min_length, *args, **kwargs)
 
 class ATStateSelect(Select):

Modified: django/trunk/docs/ref/contrib/localflavor.txt
===
--- django/trunk/docs/ref/contrib/localflavor.txt   2011-06-25 08:41:58 UTC 
(rev 16446)
+++ django/trunk/docs/ref/contrib/localflavor.txt   2011-06-25 12:39:29 UTC 
(rev 16447)
@@ -243,7 +243,8 @@
 
 .. class:: at.forms.ATZipCodeField
 
-A form field that validates its input as an Austrian zip code.
+A form field that validates its input as an Austrian zip code, with the
+format  (first digit must be greater than 0).
 
 .. class:: at.forms.ATStateSelect
 

Modified: django/trunk/tests/regressiontests/forms/localflavor/at.py
===
--- django/trunk/tests/regressiontests/forms/localflavor/at.py  2011-06-25 
08:41:58 UTC (rev 16446)
+++ django/trunk/tests/regressiontests/forms/localflavor/at.py  2011-06-25 
12:39:29 UTC (rev 16447)
@@ -28,6 +28,8 @@
 '8020': '8020',
 }
 invalid = {
+''  : error_format,
+'0123'  : error_format,
 '111222': error_format,
 'eeffee': error_format,
 }

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



Re: [Django] #16338: at.forms.ATZipCodeField accept invalid input

2011-06-25 Thread Django
#16338: at.forms.ATZipCodeField accept invalid input
-+-
   Reporter: |  Owner:  BernhardEssl
  BernhardEssl   | Status:  closed
   Type:  Bug|  Component:  contrib.localflavor
  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 ramiro):

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


Comment:

 In [16447]:
 {{{
 #!CommitTicketReference repository="" revision="16447"
 Fixed #16338 -- Fixed Austrian postal codes validation. Thanks Bernhard
 Essl for the report and patch.
 }}}

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

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



[Django] #16341: my connection to Stronghold Kingdom

2011-06-25 Thread Django
#16341: my connection to Stronghold Kingdom
--+---
 Reporter:  Ergander  |  Owner:  nobody
 Type:  Bug   | Status:  new
Milestone:|  Component:  Uncategorized
  Version:  1.3   |   Severity:  Normal
 Keywords:|   Triage Stage:  Unreviewed
Has patch:  0 |  Easy pickings:  0
UI/UX:  0 |
--+---
 Good afternoon,

 My connection hase cancel this afternoon cause a problem is occured. The
 ticket i received say like i must to contact you're service for have some
 actions against this casualty.

 I precise it's append when i was in the game...

 I hope it's not a deep problem and i say thank you to reinstal this
 quicly... My best salutations.

 Barbey Roland François

 barbeyfrrol...@hotmail.fr

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

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



Re: [Django] #16209: Add alternative repositories to 'Installing the development version' in the docs.

2011-06-25 Thread Django
#16209: Add alternative repositories to 'Installing the development version' in 
the
docs.
---+---
   Reporter:  ShawnMilo|  Owner:  ShawnMilo
   Type:  New feature  | Status:  new
  Milestone:   |  Component:  Documentation
Version:  1.3  |   Severity:  Normal
 Resolution:   |   Keywords:
   Triage Stage:  Accepted |  Has patch:  1
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  1
  UI/UX:  0|
---+---
Changes (by bedmondmark):

 * needs_better_patch:  1 => 0


Comment:

 Notes by jezdez now addressed.

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

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



Re: [Django] #16208: natural key YAML deserialization using non-list natural keys broken (with fixing patch)

2011-06-25 Thread Django
#16208: natural key YAML deserialization using non-list natural keys broken 
(with
fixing patch)
+--
   Reporter:  jeff.k@…  |  Owner:  nobody
   Type:  Bug   | Status:  new
  Milestone:|  Component:  Core (Serialization)
Version:  1.2   |   Severity:  Normal
 Resolution:|   Keywords:  yaml
   Triage Stage:  Accepted  |  Has patch:  1
Needs documentation:  0 |Needs tests:  1
Patch needs improvement:  1 |  Easy pickings:  1
  UI/UX:  0 |
+--
Changes (by gserra):

 * needs_better_patch:  0 => 1


Comment:

 The current patch does not pass the django unit tests. Seems that when
 field_value is an integer, it executes
 {{{
 obj =
 field.rel.to._default_manager.db_manager(db).get_by_natural_key(field_value)
 }}}

 But requires a 2 parameters instead of one.

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

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



Re: [Django] #16340: get_or_create should preserve the original traceback.

2011-06-25 Thread Django
#16340: get_or_create should preserve the original traceback.
-+-
   Reporter:  d0ugal |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |  Component:  Database layer
  Milestone: |  (models, ORM)
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage: |  Has patch:  1
  Unreviewed |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  1
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by d0ugal):

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


Comment:

 Added a patch that preserves the original traceback with a test. The test
 isn't ideal since we need to check the contents of a traceback, but it
 looks for the save call since this is where the IntegrityError comes from
 (in other words its the safest thing we can bet on being there.)

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

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



Re: [Django] #16336: Weak salts for auth backend

2011-06-25 Thread Django
#16336: Weak salts for auth backend
-+--
   Reporter:  ninjaneo   |  Owner:  nobody
   Type:  Uncategorized  | Status:  closed
  Milestone: |  Component:  contrib.auth
Version:  1.3|   Severity:  Normal
 Resolution:  duplicate  |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+--

Comment (by anonymous):

 Was refering to the use of str(random.random())[:5] sample output:

 >>> str(random.random())[:5]
 '0.545'
 '0.895'
 etc.

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

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



[Django] #16340: get_or_create should preserve the original traceback.

2011-06-25 Thread Django
#16340: get_or_create should preserve the original traceback.
+--
 Reporter:  d0ugal  |  Owner:  nobody
 Type:  | Status:  new
  Cleanup/optimization  |  Component:  Database layer (models, ORM)
Milestone:  |   Severity:  Normal
  Version:  1.3 |   Triage Stage:  Unreviewed
 Keywords:  |  Easy pickings:  1
Has patch:  0   |
UI/UX:  0   |
+--
 (more context in #15117)

 get_or_create in django.db.models.query re-raises the last exception as
 below. This modifies the traceback and the exception should preserve this.

 {{{
 except IntegrityError, e:
 transaction.savepoint_rollback(sid, using=self.db)
 try:
 return self.get(**lookup), False
 except self.model.DoesNotExist:
 raise e
 }}}

 this can be fixed with

 {{{
 exc_info = sys.exc_info()
 try:
 return self.get(**lookup), False
 except self.model.DoesNotExist:
 raise exc_info[1], None, exc_info[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] #15750: smtp.EmailBackend won't use empty username/password

2011-06-25 Thread Django
#15750: smtp.EmailBackend won't use empty username/password
--+-
   Reporter:  thialfihar  |  Owner:  bedmondmark
   Type:  Bug | Status:  new
  Milestone:  1.4 |  Component:  Core (Mail)
Version:  1.3-beta|   Severity:  Normal
 Resolution:  |   Keywords:
   Triage Stage:  Accepted|  Has patch:  1
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  1
  UI/UX:  0   |
--+-
Changes (by bedmondmark):

 * owner:  nobody => bedmondmark


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

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



Re: [Django] #15117: get_or_create() raises "DatabaseError: no such savepoint" instead of IntegrityError (PostgreSQL)

2011-06-25 Thread Django
#15117: get_or_create() raises "DatabaseError: no such savepoint" instead of
IntegrityError (PostgreSQL)
-+-
   Reporter:  akaihola   |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone:  1.4|  Component:  Database layer
Version:  SVN|  (models, ORM)
 Resolution: |   Severity:  Normal
   Triage Stage:  Accepted   |   Keywords:
Needs documentation:  0  |  Has patch:  0
Patch needs improvement:  0  |Needs tests:  0
  UI/UX:  0  |  Easy pickings:  0
-+-
Changes (by d0ugal):

 * ui_ux:   => 0


Comment:

 I turned on the log in postgres to see what was happening in the SQL.

 {{{
 2011-06-25 03:03:12 PDT LOG:  statement: SELECT
 "get_or_create_integrityerrortest"."country_id",
 "get_or_create_integrityerrortest"."info" FROM
 "get_or_create_integrityerrortest" WHERE
 "get_or_create_integrityerrortest"."country_id" = 1
 2011-06-25 03:03:12 PDT LOG:  statement: SAVEPOINT s1217009984_x1
 2011-06-25 03:03:12 PDT LOG:  statement: INSERT INTO
 "get_or_create_integrityerrortest" ("country_id", "info") VALUES (1, E'')
 2011-06-25 03:03:12 PDT LOG:  statement: COMMIT
 2011-06-25 03:03:12 PDT ERROR:  insert or update on table
 "get_or_create_integrityerrortest" violates foreign key constraint
 "get_or_create_integrityerrortest_country_id_fkey"
 2011-06-25 03:03:12 PDT DETAIL:  Key (country_id)=(1) is not present in
 table "get_or_create_person".
 2011-06-25 03:03:12 PDT STATEMENT:  COMMIT
 2011-06-25 03:03:12 PDT LOG:  statement: BEGIN; SET TRANSACTION ISOLATION
 LEVEL READ COMMITTED
 2011-06-25 03:03:12 PDT LOG:  statement: ROLLBACK TO SAVEPOINT
 s1217009984_x1
 2011-06-25 03:03:12 PDT ERROR:  no such savepoint
 2011-06-25 03:03:12 PDT STATEMENT:  ROLLBACK TO SAVEPOINT s1217009984_x1
 2011-06-25 03:03:12 PDT LOG:  statement: ROLLBACK
 }}}

 It appears that postgres has gotten rid of the savepoint.

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

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



Re: [Django] #16339: The RSS feeds have not updated in almost 4 days

2011-06-25 Thread Django
#16339: The RSS feeds have not updated in almost 4 days
-+-
   Reporter:  pydanny@…  |  Owner:  nobody
   Type:  Bug| Status:  closed
  Milestone: |  Component:  Djangoproject.com
Version:  1.3|  Web site
 Resolution:  fixed  |   Severity:  Normal
   Triage Stage:  Accepted   |   Keywords:
Needs documentation:  0  |  Has patch:  0
Patch needs improvement:  0  |Needs tests:  0
  UI/UX:  0  |  Easy pickings:  0
-+-
Changes (by jezdez):

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


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

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



Re: [Django] #16322: Some mobile Accept-Language headers are not parsed

2011-06-25 Thread Django
#16322: Some mobile Accept-Language headers are not parsed
-+-
   Reporter:  Max|  Owner:  nobody
  Arnold   | Status:  new
   Type:  Bug|  Component:
  Milestone: |  Internationalization
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Ready for  |  Has patch:  1
  checkin|Needs tests:  0
Needs documentation:  0  |  Easy pickings:  1
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by mark.smith@…):

 * has_patch:  0 => 1
 * needs_tests:  1 => 0
 * stage:  Accepted => Ready for checkin


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

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



[Changeset] r16446 - django/trunk/docs/topics

2011-06-25 Thread noreply
Author: andrewgodwin
Date: 2011-06-25 01:41:58 -0700 (Sat, 25 Jun 2011)
New Revision: 16446

Modified:
   django/trunk/docs/topics/auth.txt
Log:
Its always good to get it's apostophe right.

Modified: django/trunk/docs/topics/auth.txt
===
--- django/trunk/docs/topics/auth.txt   2011-06-22 12:20:52 UTC (rev 16445)
+++ django/trunk/docs/topics/auth.txt   2011-06-25 08:41:58 UTC (rev 16446)
@@ -750,7 +750,7 @@
 Note that if you provide a value to ``redirect_field_name``, you will most
 likely need to customize your login template as well, since the template
 context variable which stores the redirect path will use the value of
-``redirect_field_name`` as it's key rather than ``"next"`` (the default).
+``redirect_field_name`` as its key rather than ``"next"`` (the default).
 
 .. versionadded:: 1.3
 

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



Re: [Django] #16339: The RSS feeds have not updated in almost 4 days

2011-06-25 Thread Django
#16339: The RSS feeds have not updated in almost 4 days
-+-
   Reporter:  pydanny@…  |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Djangoproject.com
Version:  1.3|  Web site
 Resolution: |   Severity:  Normal
   Triage Stage:  Accepted   |   Keywords:
Needs documentation:  0  |  Has patch:  0
Patch needs improvement:  0  |Needs tests:  0
  UI/UX:  0  |  Easy pickings:  0
-+-
Changes (by aaugustin):

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


Comment:

 Yes, this problem has been showing up intermittently for a few days, it's
 been discussed on IRC, but not resolved yet.

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

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



Re: [Django] #16335: Cannot iterate defaultdict in template

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

 * stage:  Unreviewed => Accepted


Comment:

 Indeed, it boils down to the fact that the template language uses the same
 syntax for dictionary and attribute lookups. The resolution order is
 documented here:
 https://docs.djangoproject.com/en/1.3/topics/templates/#variables. It's
 probably a bad idea to change it.

 We could add a note there to warn about objects that accept a dictionary
 lookup with any name, suggesting to convert them to `dict` before passing
 them to the view, in your example:
 {{{
 context['dictionary'] = dict(dictionary)
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #16339: The RSS feeds have not updated in almost 4 days

2011-06-25 Thread Django
#16339: The RSS feeds have not updated in almost 4 days
---+
 Reporter:  pydanny@…  |  Owner:  nobody
 Type:  Bug| Status:  new
Milestone: |  Component:  Djangoproject.com Web site
  Version:  1.3|   Severity:  Normal
 Keywords: |   Triage Stage:  Unreviewed
Has patch:  0  |  Easy pickings:  0
UI/UX:  0  |
---+
 The last updates were on June 21st. In 30 minutes my time it will be JUne
 25th.

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

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



Re: [Django] #16337: django.contrib.auth.forms.UserCreationFormTest.test_success fails

2011-06-25 Thread Django
#16337: django.contrib.auth.forms.UserCreationFormTest.test_success fails
--+--
   Reporter:  tooxie  |  Owner:  nobody
   Type:  Bug | Status:  closed
  Milestone:  |  Component:  contrib.auth
Version:  1.3 |   Severity:  Normal
 Resolution:  worksforme  |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  1
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  1
  UI/UX:  0   |
--+--
Changes (by aaugustin):

 * status:  new => closed
 * resolution:   => worksforme
 * component:  Forms => contrib.auth
 * needs_tests:   => 0
 * needs_better_patch:   => 0
 * needs_docs:   => 0
 * type:  Uncategorized => Bug


Comment:

 Tests pass without this patch.

 {{{
 trunk % cd tests
 tests % PYTHONPATH=.. ./runtests.py --settings=test_sqlite auth
 Creating test database for alias 'default'...
 Creating test database for alias 'other'...
 
..
 --
 Ran 106 tests in 2.701s

 OK
 Destroying test database for alias 'default'...
 Destroying test database for alias 'other'...
 }}}

 They no longer do if it's applied.

 {{{
 trunk % patch -p0 < ~/Downloads/forms.patch
 patching file django/contrib/auth/tests/forms.py
 Hunk #1 succeeded at 75 (offset 4 lines).
 trunk % cd tests
 tests % PYTHONPATH=.. ./runtests.py --settings=test_sqlite auth
 Creating test database for alias 'default'...
 Creating test database for alias 'other'...
 
F.
 ==
 FAIL: test_success (django.contrib.auth.tests.forms.UserCreationFormTest)
 --
 Traceback (most recent call last):
   File "/Users/myk/Desktop/django-
 trunk/django/contrib/auth/tests/forms.py", line 78, in test_success
 self.assertEqual(repr(u), '>')
 AssertionError: '' != '>'

 --
 Ran 106 tests in 2.656s

 FAILED (failures=1)
 Destroying test database for alias 'default'...
 Destroying test database for alias 'other'...
 }}}

 You've probably changed something to the User model, but it's hard to tell
 what with the information contained in your report.

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

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



Re: [Django] #16003: Admin incompatible with USE_ETAGS = True

2011-06-25 Thread Django
#16003: Admin incompatible with USE_ETAGS = True
+-
   Reporter:  lamby |  Owner:  nobody
   Type:  Bug   | Status:  new
  Milestone:|  Component:  contrib.admin
Version:  SVN   |   Severity:  Release blocker
 Resolution:|   Keywords:  regression
   Triage Stage:  Accepted  |  Has patch:  1
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+-

Comment (by mrmachine):

 The patch here seems to go against the advice from core committers in the
 past regarding middleware having to perform repetitive behaviour such as
 interrogate a response to find out whether or not it can access or replace
 the content (e.g. checking if the content is a string or a generator, for
 streaming responses).

 If we start heading down this path of middleware being required to ask
 each response if it has rendered content (or generator content) and
 conditionally performing an action, where does it end?

 If middleware can't be certain that response.content will be a string,
 then ALL bundled and 3rd party middleware will always need to perform this
 (and possibly other) checks before taking conditional or no action.

 There was some discussion in the past about the best way to conditionally
 disable middleware for a particular response or class of responses (e.g.
 streaming) without having to make every middleware perform these checks.
 But no consensus was ever reached. And with this issue now breaking the
 admin when used with etags, it seems we need to at least work-around it or
 roll back the change that introduced this breakage while the larger issues
 are examined.

 See http://groups.google.com/group/django-
 developers/browse_thread/thread/3e0d78b98498c159/f08036fb1e7fe6b9 and also
 #7581 for past discussions.

 I think that the solution should be for TemplateResponse to render it's
 content when `.content` is accessed, in combination with a mechanism for
 people to specify that certain middleware should not run for certain
 responses. This could lead to unexpected behaviour though, if a user is
 attempting to replace a template before rendering in another middleware.

 Alternatively, there could be a generic way to defer processing of a
 certain middleware in `HttpResponse` subclasses, such as
 `TemplateResponse` (and maybe a new `StreamingResponse`). But it is not
 practical for an `HttpResponse` subclass to know all the middleware that
 it may be exposed to. There are also complex issues with general
 capabilities checking for responses and middleware.

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

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



Re: [Django] #16338: at.forms.ATZipCodeField accept invalid input

2011-06-25 Thread Django
#16338: at.forms.ATZipCodeField accept invalid input
-+-
   Reporter: |  Owner:  BernhardEssl
  BernhardEssl   | Status:  assigned
   Type:  Bug|  Component:  contrib.localflavor
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage:  Ready for  |Needs tests:  0
  checkin|  Easy pickings:  1
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by aaugustin):

 * stage:  Accepted => Ready for checkin


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

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



Re: [Django] #16338: at.forms.ATZipCodeField accept invalid input

2011-06-25 Thread Django
#16338: at.forms.ATZipCodeField accept invalid input
-+-
   Reporter: |  Owner:  BernhardEssl
  BernhardEssl   | Status:  assigned
   Type:  Bug|  Component:  contrib.localflavor
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  1
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by aaugustin):

 * easy:  0 => 1
 * 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.