Re: [Django] #15013: Add Russian (ru) local flavour

[Django]

#15013: Add Russian (ru) local flavour
-+-
   Reporter: |  Owner:  blackraven
  blackraven | Status:  assigned
   Type:  New|  Component:  contrib.localflavor
  feature|   Severity:  Normal
  Milestone:  1.4|   Keywords:  localflavor russian
Version:  SVN|  Has patch:  1
 Resolution: |Needs tests:  0
   Triage Stage:  Ready for  |  Easy pickings:  0
  checkin|
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by julien):

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


Comment:

 Thank you for your work. I have just added a missing import and did some
 minor edits in the doc.

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

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

Re: [Django] #9089: urlencode should support MutliValueDict

[Django]

#9089: urlencode should support MutliValueDict
-+-
   Reporter:  guettli|  Owner:  gptvnt
   Type:  New| Status:  assigned
  feature|  Component:  Core (Other)
  Milestone: |   Severity:  Normal
Version:  1.0|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage:  Ready for  |Needs tests:  0
  checkin|  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by julien):

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

Re: [Django] #15832: Use Babel instead of xgettext for handling .po files.

[Django]

#15832: Use Babel instead of xgettext for handling .po files.
-+-
   Reporter:  lrekucki   |  Owner:  nobody
   Type:  New| Status:  new
  feature|  Component:
  Milestone: |  Internationalization
Version: |   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+-
Changes (by jacob):

 * milestone:  1.4 =>
 * easy:   => 0
 * stage:  Unreviewed => Accepted


Comment:

 This would also fix #14045.

 Marking accepted somewhat optimistically, but I think the general
 consensus is that we should get there eventually. Jannis, feel free to
 override me if I'm wrong :)

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

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

Re: [Django] #14045: makemessage miss some gettext in javascript

[Django]

#14045: makemessage miss some gettext in javascript
+--
   Reporter:  shaohao   |  Owner:  nedbatchelder
   Type:  Bug   | Status:  new
  Milestone:|  Component:  Internationalization
Version:  1.2   |   Severity:  Normal
 Resolution:|   Keywords:  xgettext
   Triage Stage:  Accepted  |  Has patch:  1
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
+--
Changes (by jacob):

 * easy:   => 0


Comment:

 See also #15832 (which covers switching to Babel).

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

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

Re: [Django] #15815: Support memcached binary protocol in PyLibMCCache

[Django]

#15815: Support memcached binary protocol in PyLibMCCache
-+-
   Reporter:  mtigas |  Owner:  nobody
   Type:  New| Status:  new
  feature|  Component:  Core (Cache system)
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  1
Needs documentation:  1  |  Easy pickings:  0
Patch needs improvement:  1  |
-+-
Changes (by jacob):

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


Comment:

 The patch isn't ideal - special-casing "binary" is a bit annoying - but
 this is totally worth having.

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

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

Re: [Django] #15807: order by 'pk' alias doesn't work with inherited models when parent has an ordering set

[Django]

#15807: order by 'pk' alias doesn't work with inherited models when parent has 
an
ordering set
-+-
   Reporter:  mat|  Owner:  nobody
   Type:  Bug| Status:  closed
  Milestone: |  Component:  Database layer
Version:  SVN|  (models, ORM)
 Resolution:  wontfix|   Severity:  Normal
   Triage Stage: |   Keywords:
  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+-
Changes (by jacob):

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


Comment:

 So here's why this is happening:

 `pk` is translated to "the name of the primary key column". `Child`, as a
 concrete subclass, has a primary key that has a foreign key (technically a
 `OneToOneField` with `parent_link=True`) to `Foo`. In other words, your
 models, with the field implicitly added by the subclassing, ''actually''
 are like:

 {{{
 #!python
 class Foo(models.Model):
 bar = models.PositiveSmallIntegerField(default=1)

 class Child(models.Model):
 foo_ptr = models.OneToOneField(Foo, parent_link=True)
 barchild = models.PositiveSmallIntegerField(default=1)
 }}}

 This means that `Child.objects.order_by("pk")` actually translates to
 `Child.objects.order_by("foo_ptr")`. Remember, `foo_ptr` is a foreign key
 (one-to-one fields are just a special kind of foreign key). This is
 important, because `order_by("some_foreign_key")` translates to "order by
 the default ordering for the object pointed to by the foreign key". As
 [http://docs.djangoproject.com/en/dev/ref/models/querysets/#order-by the
 documentation says]:

   If you try to order by a field that is a relation to another model,
 Django will use the default ordering on the related model (or order by the
 related model's primary key if there is no Meta.ordering specified.

 The object pointed to, in this case, is `Foo`. So
 `Child.objects.order_by("pk")` is in fact working correctly, if a bit
 counterintuitively.

 We ''could'' change this, but it would introduce other subtle
 counterintuitive problems and would quite likely be backwards-
 incompatible. So I'm going to mark this wontfix. I know it's not ideal,
 but I'm afraid the cure is worse than the disease 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] #15825: File-based caching doesn't cull truly randomly

[Django]

#15825: File-based caching doesn't cull truly randomly
-+-
   Reporter:  gkuenning  |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Core (Cache system)
Version:  SVN|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+-

Comment (by jacob):

 See also #15806. Not exactly related, but right around in that same part
 of code and probably worth fixing at the same time.

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

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

Re: [Django] #15806: Error in filebased cache culling

[Django]

#15806: Error in filebased cache culling
+-
   Reporter:  witek@…   |  Owner:  nobody
   Type:  Bug   | Status:  new
  Milestone:|  Component:  Core (Cache system)
Version:  1.3   |   Severity:  Normal
 Resolution:|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
+-
Changes (by jacob):

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


Comment:

 See also #15825. Not exactly related, but right around in that same part
 of code and probably worth fixing at the same time.

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

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

Re: [Django] #15773: MultiValueField could be more convenient

[Django]

#15773: MultiValueField could be more convenient
-+-
   Reporter:  Aryeh  |  Owner:  nobody
  Leib Taurog | Status:  new
   Type:  New|  Component:  Forms
  feature|   Severity:  Normal
  Milestone: |   Keywords:
Version:  1.3|  Has patch:  0
 Resolution: |Needs tests:  0
   Triage Stage: |  Easy pickings:  0
  Unreviewed |
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by jacob):

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


Comment:

 I'm not sure I get it. Can you share a specific use case or a problem you
 have that this solves?

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

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

Re: [Django] #15740: Manipulating the test client session doesn't work as documented

[Django]

#15740: Manipulating the test client session doesn't work as documented
-+-
   Reporter: |  Owner:  mir
  prestontimmons | Status:  new
   Type:  Bug|  Component:  Testing framework
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage:  Design |Needs tests:  0
  decision needed|  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by jacob):

 * stage:  Unreviewed => Design decision needed


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

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

Re: [Django] #15823: incorrect join condition when combining Q objects

[Django]

#15823: incorrect join condition when combining Q objects
-+-
   Reporter:  dcwatson   |  Owner:
   Type:  Bug| Status:  new
  Milestone:  1.4|  Component:  Database layer
Version:  SVN|  (models, ORM)
 Resolution: |   Severity:  Normal
   Triage Stage:  Ready for  |   Keywords:  query, q, join
  checkin|  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+-
Changes (by mir):

 * owner:  mir =>
 * stage:  Unreviewed => Ready for checkin


Comment:

 Someone with a deep knowledge of the ORM should review this. It works
 perfect (tested with sqlite), but I'm not in a position to understand
 possible side-effects.

 @dcwatson: Thanks for a perfect bug report, you're making triage a joy ;-)

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

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

Re: [Django] #15823: incorrect join condition when combining Q objects

[Django]

#15823: incorrect join condition when combining Q objects
-+-
   Reporter:  dcwatson   |  Owner:  mir
   Type:  Bug| Status:  new
  Milestone:  1.4|  Component:  Database layer
Version:  SVN|  (models, ORM)
 Resolution: |   Severity:  Normal
   Triage Stage: |   Keywords:  query, q, join
  Unreviewed |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+-
Changes (by mir):

 * owner:  dcwatson => mir
 * easy:   => 0


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

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

Re: [Django] #15740: Manipulating the test client session doesn't work as documented

[Django]

#15740: Manipulating the test client session doesn't work as documented
-+-
   Reporter: |  Owner:  mir
  prestontimmons | Status:  new
   Type:  Bug|  Component:  Testing framework
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage: |Needs tests:  0
  Unreviewed |  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-

Comment (by mir):

 I've posted a question about how to deal with this on the django developer
 list.

 http://groups.google.com/group/django-
 developers/browse_thread/thread/90e422f2a8231670

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

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

Re: [Django] #15740: Manipulating the test client session doesn't work as documented

[Django]

#15740: Manipulating the test client session doesn't work as documented
-+-
   Reporter: |  Owner:  mir
  prestontimmons | Status:  new
   Type:  Bug|  Component:  Testing framework
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage: |Needs tests:  0
  Unreviewed |  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by mir):

 * status:  reopened => new
 * owner:  prestontimmons => mir


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

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

Re: [Django] #15789: floatformat filter works incorrectly when decimal precision is set low

[Django]

#15789: floatformat filter works incorrectly when decimal precision is set low
+-
   Reporter:  akaihola  |  Owner:  nobody
   Type:  Bug   | Status:  new
  Milestone:|  Component:  Template system
Version:  SVN   |   Severity:  Normal
 Resolution:|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  0
Needs documentation:  0 |Needs tests:  1
Patch needs improvement:  0 |  Easy pickings:  1
+-
Changes (by mir):

 * needs_tests:  0 => 1
 * easy:   => 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] #15781: Multiple databases with same model names causing get errors

[Django]

#15781: Multiple databases with same model names causing get errors
--+---
   Reporter:  anonymous   |  Owner:  mir
   Type:  Bug | Status:  closed
  Milestone:  |  Component:  Uncategorized
Version:  1.2 |   Severity:  Normal
 Resolution:  invalid |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
--+---
Changes (by mir):

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


Comment:

 This looks like a user error - you forgot to import everyone. Please post
 full error messages and use the right formatting for code snippets. For
 support, please use the django-users mailing list.

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

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

Re: [Django] #15781: Multiple databases with same model names causing get errors

[Django]

#15781: Multiple databases with same model names causing get errors
--+---
   Reporter:  anonymous   |  Owner:  mir
   Type:  Bug | Status:  assigned
  Milestone:  |  Component:  Uncategorized
Version:  1.2 |   Severity:  Normal
 Resolution:  |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
--+---
Changes (by mir):

 * status:  new => assigned
 * owner:  nobody => mir
 * easy:   => 0


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

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

Re: [Django] #15805: assertFieldOutput should not use assertRaisesRegexp

[Django]

#15805: assertFieldOutput should not use assertRaisesRegexp
+---
   Reporter:  julien|  Owner:  nobody
   Type:  Bug   | Status:  new
  Milestone:|  Component:  Testing framework
Version:  1.2   |   Severity:  Release blocker
 Resolution:|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  1
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
+---

Comment (by julien):

 For the record, I've created #15838 to suggest moving `assertFieldOutput`
 to the general `TestCase`.

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

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

Re: [Django] #15805: assertFieldOutput should not use assertRaisesRegexp

[Django]

#15805: assertFieldOutput should not use assertRaisesRegexp
+---
   Reporter:  julien|  Owner:  nobody
   Type:  Bug   | Status:  new
  Milestone:|  Component:  Testing framework
Version:  1.2   |   Severity:  Release blocker
 Resolution:|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  1
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
+---
Changes (by lrekucki):

 * easy:   => 0
 * 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] #15811: Lazy doesn't take into account methods defined in parents

[Django]

#15811: Lazy doesn't take into account methods defined in parents
+--
   Reporter:  abki  |  Owner:  nobody
   Type:  Bug   | Status:  new
  Milestone:|  Component:  Core (Other)
Version:  SVN   |   Severity:  Normal
 Resolution:|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  1
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  1 |  Easy pickings:  0
+--
Changes (by lukeplant):

 * needs_better_patch:  0 => 1
 * component:  Uncategorized => Core (Other)
 * easy:   => 0
 * stage:  Unreviewed => Accepted


Comment:

 'deep copy' is confusing terminology - it normally refers to
 `copy.deepcopy`. What you are referring to is checking base class methods.
 The test name and comments need to be updated accordingly.

 In addition, I think that test should not implicitly rely on the fact that
 SortedDict doesn't have `__getitem__` defined - that could easily change.
 I would define a pair of custom classes that show the problem, probably
 within the test method itself.

 Otherwise, this looks pretty good.

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

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

Re: [Django] #11603: Add an assertFormSetError function to django.test.TestCase

[Django]

#11603: Add an assertFormSetError function to django.test.TestCase
-+-
   Reporter: |  Owner:  martin_speleo
  martin_speleo  | Status:  new
   Type:  New|  Component:  Testing framework
  feature|   Severity:  Normal
  Milestone: |   Keywords:  formset
Version:  SVN|  Has patch:  1
 Resolution: |Needs tests:  0
   Triage Stage:  Accepted   |  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  1  |
-+-
Changes (by julien):

 * needs_better_patch:  0 => 1
 * easy:   => 0


Comment:

 Thanks for your patch, it looks pretty good. It would need to be updated
 to apply to trunk though. Also, the tests could be made more elegant by
 using `assertRaises` and the `with` statement
 (http://docs.python.org/library/unittest.html#unittest.TestCase.assertRaises)
 instead of all those try/except/else's. By the way, you can import the
 `with` statement in Python 2.5 by doing: `from __future__ import
 with_statement`

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

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

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

[Django]

#15852: Exception when http.parse_cookie recieves bad cookie
-+-
   Reporter:  Fredrik|  Owner:  nobody
  Stålnacke  | Status:  new
   Type:  Bug|  Component:  HTTP handling
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:  parse_cookie
 Resolution: |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  1
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  1  |
-+-
Changes (by aaugustin):

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


Comment:

 I am not sure about what happens exactly. However, I confirmed that the
 bug occurs with Django's patched version of !SimpleCookie and not with
 Python's original version.

 {{{
 >>> from Cookie import SimpleCookie
 >>> SimpleCookie().load(evil_cookie)
 Traceback (most recent call last):
   File "", line 1, in 
   File
 
"/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/Cookie.py",
 line 627, in load
 self.__ParseString(rawdata)
   File
 
"/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/Cookie.py",
 line 660, in __ParseString
 self.__set(K, rval, cval)
   File
 
"/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/Cookie.py",
 line 580, in __set
 M.set(key, real_value, coded_value)
   File
 
"/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/Cookie.py",
 line 455, in set
 raise CookieError("Illegal key value: %s" % key)
 Cookie.CookieError: Illegal key value: xmlns:xsi
 }}}
 (that exception would be catched properly in Django).

 The patch does not seem appropriate. We should fix the root cause and not
 mask it by arbitrarily catching an exception.

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

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

Re: [Django] #15766: select_related() changes type of DecimalField

[Django]

#15766: select_related() changes type of DecimalField
-+-
   Reporter:  CarstenF   |  Owner:  nobody
   Type:  Bug| Status:  closed
  Milestone: |  Component:  Database layer
Version:  1.3|  (models, ORM)
 Resolution: |   Severity:  Normal
  worksforme |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
-+-
Changes (by lukeplant):

 * status:  new => closed
 * needs_better_patch:   => 0
 * component:  Uncategorized => Database layer (models, ORM)
 * needs_tests:   => 0
 * easy:   => 0
 * needs_docs:   => 0
 * resolution:   => worksforme


Comment:

 I can't reproduce this. I'm using Oracle 10g Express Edition,
 instantclient 11.2. I tested with Python 2.5 and Python 2.6, Django trunk,
 and got the following results:

 {{{

 In [1]: import decimal

 In [2]: from ticket15766.models import *

 In [3]: c = Code(grenzwert=decimal.Decimal('10.00'), id=1)

 In [4]: c.save()

 In [5]: e = Erfasst(code=c)

 In [6]: e.save()

 In [7]: Erfasst.objects.get(id=1).code.grenzwert
 Out[7]: Decimal("10.00")

 In [8]: Erfasst.objects.select_related().get(id=1).code.grenzwert
 Out[8]: Decimal("10")

 In [9]: type(Erfasst.objects.select_related().get(id=1).code.grenzwert)
 Out[9]: 
 }}}

 If you can provide enough info for us to reproduce it, please do so and
 re-open this ticket.

 Also, I notice that in my results, the value `Decimal("10")` given with
 `select_related()` is strictly speaking different from `Decimal("10.00")`.
 I don't have enough experience with Decimal to know if this is a material
 difference in itself. If it is, then you could re-open on that basis too.
 But the info to track down your exact problem would probably be useful
 anyway.

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

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

Re: [Django] #13322: Problem with inspectdb and encoding

[Django]

#13322: Problem with inspectdb and encoding
-+-
   Reporter: |  Owner:  nobody
  josemaria@…| Status:  closed
   Type:  Bug|  Component:  Core (Management
  Milestone: |  commands)
Version:  1.2-beta   |   Severity:  Normal
 Resolution:  needsinfo  |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  1
Patch needs improvement:  0  |  Easy pickings:  0
-+-
Changes (by claudep):

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


Comment:

 I attached a test that works for me (SQLite/Python2.6/Linux). But the
 problem might be triggered by a specific backend/python/OS combination.
 You should give more information about the conditions under which you are
 able to reproduce the bug.

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

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

Re: [Django] #15847: Spam control is misconfigured and rejects all anonymous bug reports

[Django]

#15847: Spam control is misconfigured and rejects all anonymous bug reports
-+-
   Reporter:  follower   |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |  Component:  Djangoproject.com
  Milestone: |  Web site
Version:  1.2|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+-
Changes (by aaugustin):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * easy:   => 0
 * needs_docs:   => 0
 * type:  Bug => Cleanup/optimization
 * stage:  Unreviewed => Accepted


Comment:

 This problem does not affect all anonymous bug reports. I just created and
 closed #15882 after logging out.

 I'll classify the ticket as "optimization" since it affects some users,
 but not all.

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

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

Re: [Django] #15882: Attempt to reproduce #15847

[Django]

#15882: Attempt to reproduce #15847
--+---
   Reporter:  anonymous   |  Owner:  nobody
   Type:  Bug | Status:  closed
  Milestone:  |  Component:  Uncategorized
Version:  |   Severity:  Normal
 Resolution:  invalid |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
--+---
Changes (by anonymous):

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


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

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

[Django] #15882: Attempt to reproduce #15847

[Django]

#15882: Attempt to reproduce #15847
---+---
 Reporter:  anonymous  |  Owner:  nobody
 Type:  Bug| Status:  new
Milestone: |  Component:  Uncategorized
  Version: |   Severity:  Normal
 Keywords: |   Triage Stage:  Unreviewed
Has patch:  0  |  Easy pickings:  0
---+---


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

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

Re: [Django] #15841: User model conflicts with CommentDetailsForm

[Django]

#15841: User model conflicts with CommentDetailsForm
--+--
   Reporter:  admin@… |  Owner:  nobody
   Type:  Bug | Status:  closed
  Milestone:  |  Component:  contrib.comments
Version:  1.3 |   Severity:  Normal
 Resolution:  needsinfo   |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
--+--
Changes (by aaugustin):

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


Comment:

 By design, !CommentDetailsForm requires an email address. As a direct
 consequence, so does !CommentForm. Many people rely on this behavior and
 it should not be changed lightly.

 If this is an issue for you, you can subclass !CommentDetailsForm and set
 `blank=True` for the email field.

 As far as I can tell, when a user is logged in and posts a comment without
 filling in his details,
 `django.contrib.comments.views.comments.post_comment` will add them based
 on the user's profile. However, this is not documented. Since a user
 without an email in his profile can always give it in the comments form, I
 don't think there's a bug.

 Please provide more information on how to reproduce your issue if this
 answer is not satisfying.

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

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

Re: [Django] #15856: Add a localflavor for Macedonia

[Django]

#15856: Add a localflavor for Macedonia
-+-
   Reporter: |  Owner:  nobody
  vasiliyeah | Status:  new
   Type:  New|  Component:  contrib.localflavor
  feature|   Severity:  Normal
  Milestone:  1.4|   Keywords:
Version:  SVN|  Has patch:  1
 Resolution: |Needs tests:  0
   Triage Stage:  Accepted   |  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  1  |
-+-

Comment (by anonymous):

 The alphabetical order may be out of line when importing tests (mk should
 go before mx). I'll fix that.

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

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

Re: [Django] #15837: Consolidate localflavor tests

[Django]

#15837: Consolidate localflavor tests
-+-
   Reporter:  julien |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |  Component:  contrib.localflavor
  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  |
-+-
Changes (by aaugustin):

 * version:  1.2 => 1.3
 * easy:   => 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] #15856: Add a localflavor for Macedonia

[Django]

#15856: Add a localflavor for Macedonia
-+-
   Reporter: |  Owner:  nobody
  vasiliyeah | Status:  new
   Type:  New|  Component:  contrib.localflavor
  feature|   Severity:  Normal
  Milestone:  1.4|   Keywords:
Version:  SVN|  Has patch:  1
 Resolution: |Needs tests:  0
   Triage Stage:  Accepted   |  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  1  |
-+-

Comment (by anonymous):

 The alphabetical order in the municipalities list looks as if it is not
 respected when you read it as it is with latin characters. When the
 translation is applied in Cyrillic it is in alphabetical order respecting
 the Cyrillic alphabet ordering абвгд... (abvgd). So it is like that
 intentionally os it's sorted properly when the translation to Macedonian
 is applied.

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

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

Re: [Django] #15856: Add a localflavor for Macedonia

[Django]

#15856: Add a localflavor for Macedonia
-+-
   Reporter: |  Owner:  nobody
  vasiliyeah | Status:  new
   Type:  New|  Component:  contrib.localflavor
  feature|   Severity:  Normal
  Milestone:  1.4|   Keywords:
Version:  SVN|  Has patch:  1
 Resolution: |Needs tests:  0
   Triage Stage:  Accepted   |  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  1  |
-+-
Changes (by aaugustin):

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


Comment:

 This work looks pretty good and the request is reasonable. Accepting the
 ticket.

 Reading through the patch, I noticed that sometimes the alphabetical order
 is not respected when inserting MK-related stuff in existing files; this
 should be 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] #13770: form BooleanField should clean the string u'false' as False.

[Django]

#13770: form BooleanField should clean the string u'false' as False.
+
   Reporter:  jordanb   |  Owner:  nobody
   Type:  Bug   | Status:  new
  Milestone:|  Component:  Forms
Version:  1.1   |   Severity:  Normal
 Resolution:|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  1
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
+
Changes (by claudep):

 * needs_better_patch:  1 => 0
 * has_patch:  0 => 1
 * easy:   => 0
 * needs_tests:  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] #15764: DeleteView does not have ModelFormMixin in its mixins

[Django]

#15764: DeleteView does not have ModelFormMixin in its mixins
+---
   Reporter:  linovia   |  Owner:  nobody
   Type:  Bug   | Status:  new
  Milestone:|  Component:  Documentation
Version:  1.3   |   Severity:  Normal
 Resolution:|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  1
+---
Changes (by lukeplant):

 * easy:   => 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] #15825: File-based caching doesn't cull truly randomly

[Django]

#15825: File-based caching doesn't cull truly randomly
-+-
   Reporter:  gkuenning  |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Core (Cache system)
Version:  SVN|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+-

Comment (by lukeplant):

 If this is fixed, please note that the tests will need some subtle fixing,
 particularly `FileBasedCacheTests.test_cull`. The tests check for a
 certain number deleted, but because of the way that files are grouped into
 folders in the file based backend, if this is randomized the number
 deleted can change. The 'sorted' call just a few lines above this line was
 added because of this issue, to fix a difference that appeared on
 different platforms, #14250.

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

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

Re: [Django] #15879: multipart/form-data filename="" not handled as file

[Django]

#15879: multipart/form-data filename="" not handled as file
+--
   Reporter:  j@…   |  Owner:  nobody
   Type:  Bug   | Status:  new
  Milestone:|  Component:  File uploads/storage
Version:  1.3   |   Severity:  Normal
 Resolution:|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  1
Needs documentation:  0 |Needs tests:  1
Patch needs improvement:  1 |  Easy pickings:  0
+--
Changes (by carljm):

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


Comment:

 Patch doesn't look quite right, based on the description - if there is no
 filename parameter it would be None, and the current code would skip it
 (continue) but the new could would not.

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

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

Re: [Django] #15881: FilteredSelectMultiple does not respect order

[Django]

#15881: FilteredSelectMultiple does not respect order
-+-
   Reporter:  bmihelac   |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |  Component:  contrib.admin
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:  javascript
 Resolution: |  Has patch:  0
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
-+-
Changes (by carljm):

 * needs_better_patch:   => 0
 * needs_docs:   => 0
 * needs_tests:   => 0
 * 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] #15844: Filtering by related objects causes unnecessary extra db hits when using model inheritance

[Django]

#15844: Filtering by related objects causes unnecessary extra db hits when using
model inheritance
-+-
   Reporter:  emulbreh   |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  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
 |  Easy pickings:  0
-+-
Changes (by carljm):

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


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

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

Re: [Django] #15825: File-based caching doesn't cull truly randomly

[Django]

#15825: File-based caching doesn't cull truly randomly
-+-
   Reporter:  gkuenning  |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Core (Cache system)
Version:  SVN|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+-
Changes (by carljm):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * version:  1.2 => SVN
 * easy:   => 0
 * needs_docs:   => 0
 * stage:  Unreviewed => Accepted


Comment:

 The referenced line of code in trunk is 123, or `doomed =
 [os.path.join(self._dir, k) for (i, k) in enumerate(filelist) if i %
 self._cull_frequency == 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] #15826: TestCase assertions should work with TemplateResponse

[Django]

#15826: TestCase assertions should work with TemplateResponse
+---
   Reporter:  bmihelac  |  Owner:  nobody
   Type:  Bug   | Status:  new
  Milestone:|  Component:  Testing framework
Version:  1.3   |   Severity:  Normal
 Resolution:|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
+---
Changes (by carljm):

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


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

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

Re: [Django] #15828: multiple inheritance in TestCases does not work with unittest2

[Django]

#15828: multiple inheritance in TestCases does not work with unittest2
-+-
   Reporter: |  Owner:  nobody
  ricardokirkner | Status:  new
   Type:  Bug|  Component:  Testing framework
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:  unittest2
 Resolution: |  Has patch:  0
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
-+-
Changes (by carljm):

 * easy:   => 0
 * stage:  Unreviewed => Accepted


Comment:

 We should follow the lead of unittest2 here - we don't want to diverge. It
 may be that this is most easily done by applying all the changes in 0.6.0
 at once rather than piecemeal, but in either case we should do this in the
 end.

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

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

Re: [Django] #15819: Admin searches should use distinct, if query involves joins

[Django]

#15819: Admin searches should use distinct, if query involves joins
-+-
   Reporter:  Adam   |  Owner:  ryankask
  Kochanowski | Status:  new
   Type:  Bug|  Component:  contrib.admin
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
-+-
Changes (by carljm):

 * stage:  Unreviewed => Accepted


Comment:

 Hi Ryan - this looks pretty good to me. The second patch doesn't appear to
 be complete, it only includes the changed test file, not the code changes.
 Can you upload a complete updated patch? (The boilerplate-removal in the
 second patch looks fine to me, it's related since its adding flexibility
 to test-support code that your added tests use).

 Re style, is there a reason for the field_needs_distinct function to be a
 closure defined inside get_query_set, rather than a module-level function?
 I would just do the latter for simplicity if we don't need the closure.

 Re the select_related() call, that's not, erm, related to this bug. It
 actually may be that we could call select_related in a couple more cases
 (specifically, one-to-ones and reverse one-to-ones), but we'd need a
 separate ticket for that optimization.

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

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

[Django]

#15881: FilteredSelectMultiple does not respect order
--+---
 Reporter:  bmihelac  |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Milestone:|  Component:  contrib.admin
  Version:  1.3   |   Severity:  Normal
 Keywords:  javascript|   Triage Stage:  Unreviewed
Has patch:  0 |  Easy pickings:  0
--+---
 WIth filter_horizontal and filter_vertical admin options moving items
 between available and chosen, these items would be moved to the end of
 respecting lists.

 I believe it would be useful and not so hard to preserve original sort
 order.

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

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

Re: [Django] #15880: manage.py: difficult to run in background (and crashes when input isn't a terminal)

[Django]

#15880: manage.py: difficult to run in background (and crashes when input isn't 
a
terminal)
-+-
   Reporter: |  Owner:  nobody
  dstndstn@… | Status:  new
   Type:  Bug|  Component:  Core (Management
  Milestone: |  commands)
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+-

Comment (by lukeplant):

 > A standard use case for me is to ssh to a remote server, run the
 devserver in the background while editing the code in the foreground

 Terminal multiplexers like tmux and screen will allow you to do this.
 Obviously this is only going to work if they are installed or can be
 installed. Another option is to simply have two remote sessions.

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

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

[noreply]

Author: ikelly
Date: 2011-04-21 10:43:22 -0700 (Thu, 21 Apr 2011)
New Revision: 16062

Modified:
   django/branches/releases/1.3.X/django/db/backends/creation.py
Log:
[1.3.X] Refs #15573, #15850: Added a check for whether the sites app is 
installed when creating the test database, in order to work around a bug in 
get_model.  Thanks to adsva and carljm.

Modified: django/branches/releases/1.3.X/django/db/backends/creation.py
===
--- django/branches/releases/1.3.X/django/db/backends/creation.py   
2011-04-21 00:00:32 UTC (rev 16061)
+++ django/branches/releases/1.3.X/django/db/backends/creation.py   
2011-04-21 17:43:22 UTC (rev 16062)
@@ -379,9 +379,10 @@
 # default site may or may not be 1, depending on how the sequence was
 # reset.  If the sites app is loaded, then we coerce it.
 from django.db.models import get_model
-Site = get_model('sites', 'Site')
-if Site is not None and 
Site.objects.using(self.connection.alias).count() == 1:
-
Site.objects.using(self.connection.alias).update(id=settings.SITE_ID)
+if 'django.contrib.sites' in settings.INSTALLED_APPS:
+Site = get_model('sites', 'Site')
+if Site is not None and 
Site.objects.using(self.connection.alias).count() == 1:
+
Site.objects.using(self.connection.alias).update(id=settings.SITE_ID)
 
 from django.core.cache import get_cache
 from django.core.cache.backends.db import BaseDatabaseCache

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

Re: [Django] #12103: Setting in contrib.auth AuthenticationForm to let inactive users log in

[Django]

#12103: Setting in contrib.auth AuthenticationForm to let inactive users log in
---+--
   Reporter:  ejucovy  |  Owner:  nobody
   Type:  New feature  | Status:  new
  Milestone:   |  Component:  contrib.auth
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
---+--
Changes (by ejucovy):

 * version:  1.1 => SVN
 * type:  Uncategorized => New feature
 * easy:   => 0


Comment:

 I realized the tests in my patch could be improved; here's a new version
 of the patch:

 
http://code.djangoproject.com/attachment/ticket/12103/12103_with_better_working_tests.diff

 The tests now exercise/document custom `ValidationError` logic in an
 `AuthenticationForm` subclass, in addition to logic that disables the
 default `user.is_inactive` check.

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

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

Re: [Django] #15850: Test runner fails when sites app not installed

[Django]

#15850: Test runner fails when sites app not installed
+---
   Reporter:  adsva |  Owner:  carljm
   Type:  Bug   | Status:  closed
  Milestone:|  Component:  Testing framework
Version:  SVN   |   Severity:  Normal
 Resolution:  fixed |   Keywords:
   Triage Stage:  Accepted  |  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
+---
Changes (by carljm):

 * easy:   => 0


Comment:

 This also needs to be fixed in 1.3.X. Backporting the fix for #15866 is
 not acceptable as a solution, because #15866 is not a regression and the
 fix is backwards-incompatible (albeit only to private internal API). I've
 proposed at http://code.djangoproject.com/ticket/15573#comment:8 that the
 best answer would be to modify the fix for #15573 to check INSTALLED_APPS
 rather than the return value of get_model - but I'd prefer if someone with
 access to test on Oracle would make that change.

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

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

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

[Django]

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

 * easy:   => 0


Comment:

 This change broke running of tests in a project without contrib.sites
 installed (#15850), due to the underlying issue #15866. I've fixed #15866
 in trunk, but wasn't planning to backport to 1.3.X for stability reasons,
 since #15866 itself is not a regression and the fix changes the behavior
 of (internal and undocumented) methods in a backwards-incompatible way.

 However, #15850 is a significant regression and still needs fixing in
 1.3.X. I think the least-invasive approach there will be to modify the
 change made in r16028 to check INSTALLED_APPS for django.contrib.sites
 rather than using the return value of get_model. I don't feel comfortable
 making that change myself, though, since I don't have Oracle available to
 ensure that the fix still works for the original purpose.

 Ian, would you be able to make that change in 1.3.X?

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

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

Re: [Django] #15880: manage.py: difficult to run in background (and crashes when input isn't a terminal)

[Django]

#15880: manage.py: difficult to run in background (and crashes when input isn't 
a
terminal)
-+-
   Reporter: |  Owner:  nobody
  dstndstn@… | Status:  new
   Type:  Bug|  Component:  Core (Management
  Milestone: |  commands)
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+-

Comment (by dstndstn@…):

 It used to work in previous releases :)

 A standard use case for me is to ssh to a remote server, run the devserver
 in the background while editing the code in the foreground.  This bug
 makes that difficult to do.

 Piping /dev/null to stdin was just an attempted hack to make it continue
 running in the background.

 If I run it normally and then try to put it in the background with "ctrl-Z
 bg" it stalls whenever the code is modified and has to be brought to the
 foreground before it resumes operation.  That means leaving my editor
 after every edit, bringing the devserver to the foreground for a moment,
 putting it back in the background and then returning to the editor.  That
 is not easier than just ctrl-Cing the devserver, which means that this bug
 cancels out the usefulness of the [extremely useful!] auto-reload
 functionality, at least when the devserver is used in this way.

 thanks!
 --dustin

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

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

Re: [Django] #14091: Fix incorrect quoting in connection.queries

[Django]

#14091: Fix incorrect quoting in connection.queries
-+-
   Reporter:  danielr|  Owner:
   Type:  Bug| Status:  new
  Milestone: |  Component:  Database layer
Version:  1.2|  (models, ORM)
 Resolution: |   Severity:  Normal
   Triage Stage:  Ready for  |   Keywords:
  checkin|  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+-
Changes (by aaugustin):

 * stage:  Accepted => Ready for checkin


Comment:

 This new patch implements Alex and Jacob's recommendation.

 Regarding SQLite, parameters are substituted at line 642 in
 `_sqlite/cursor.c`:
 {{{
 pysqlite_statement_bind_parameters(self->statement, parameters,
 allow_8bit_chars);
 }}}
 Unfortunately there is no way to reach `self->statement` from Python code.
 That's why I ended up quoting parameters with `SELECT QUOTE(?)`.

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

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

Re: [Django] #15795: [patch] __repr__ for RegexURLPattern not unicode safe

[Django]

#15795: [patch] __repr__ for  RegexURLPattern not unicode safe
-+-
   Reporter:  Mark   |  Owner:  nobody
  Raddatz    | Status:  new
   Type:  Bug|  Component:  Core (Other)
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:  debug unicode
 Resolution: |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  1
Needs documentation:  0  |  Easy pickings:  1
Patch needs improvement:  0  |
-+-
Changes (by carljm):

 * easy:  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] #15795: [patch] __repr__ for RegexURLPattern not unicode safe

[Django]

#15795: [patch] __repr__ for  RegexURLPattern not unicode safe
-+-
   Reporter:  Mark   |  Owner:  nobody
  Raddatz    | Status:  new
   Type:  Bug|  Component:  Core (Other)
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:  debug unicode
 Resolution: |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  1
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
-+-
Changes (by carljm):

 * needs_better_patch:   => 0
 * needs_docs:   => 0
 * easy:   => 0
 * needs_tests:   => 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] #15880: manage.py: difficult to run in background (and crashes when input isn't a terminal)

[Django]

#15880: manage.py: difficult to run in background (and crashes when input isn't 
a
terminal)
-+-
   Reporter: |  Owner:  nobody
  dstndstn@… | Status:  new
   Type:  Bug|  Component:  Core (Management
  Milestone: |  commands)
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Accepted   |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+-
Changes (by jacob):

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


Comment:

 I'm curious - why are you trying to run the dev server in the background?
 And why pipe /dev/null to stdin?

 We probably need to fix this, but I'm hesitant because it makes running
 the devserver as a "real" server easier, and we kinda try to prevent that.

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

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

Re: [Django] #15849: {% ifchanged %} not thread-safe

[Django]

#15849: {% ifchanged %} not thread-safe
+-
   Reporter:  akaihola  |  Owner:  nobody
   Type:  Bug   | Status:  new
  Milestone:|  Component:  Template system
Version:  SVN   |   Severity:  Normal
 Resolution:|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  1
Needs documentation:  0 |Needs tests:  1
Patch needs improvement:  0 |  Easy pickings:  0
+-
Changes (by carljm):

 * easy:   => 0
 * needs_tests:  0 => 1
 * stage:  Unreviewed => Accepted


Comment:

 I could see an argument that automated tests for template tag thread-
 safety or more difficult than they are worth, but I think we should at
 least have the argument ;-)

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

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

Re: [Django] #15860: modelform.is_valid() and modelform.errors fail to anticipate database integrity errors, allow exceptions to reach the user

[Django]

#15860: modelform.is_valid() and modelform.errors fail to anticipate database
integrity errors, allow exceptions to reach the user
--+
   Reporter:  legutierr   |  Owner:  nobody
   Type:  Bug | Status:  closed
  Milestone:  |  Component:  Forms
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
--+

Comment (by kmtracey):

 (that was me)

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

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

Re: [Django] #15860: modelform.is_valid() and modelform.errors fail to anticipate database integrity errors, allow exceptions to reach the user

[Django]

#15860: modelform.is_valid() and modelform.errors fail to anticipate database
integrity errors, allow exceptions to reach the user
--+
   Reporter:  legutierr   |  Owner:  nobody
   Type:  Bug | Status:  closed
  Milestone:  |  Component:  Forms
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
--+

Comment (by anonymous):

 That may be, but this still sounds to me like a dupe of #13091, which is
 still open. That's where perhaps the observation about why you don't want
 to take the existing form's instance's value into account. I think that
 was an unanswered question on that ticket -- why wouldn't you want to take
 the existing instance's values into account for these check, and what you
 have mentioned here may be a reason. I'm not sure what the ultimate
 resolution should be -- if it is possible to accommodate both needs that
 would be ideal, but I don't have time at the moment to work out whether it
 is possibleI just think the discussion of it should move to #13091.

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

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

Re: [Django] #14091: Fix incorrect quoting in connection.queries

[Django]

#14091: Fix incorrect quoting in connection.queries
-+-
   Reporter:  danielr|  Owner:
   Type:  Bug| Status:  new
  Milestone: |  Component:  Database layer
Version:  1.2|  (models, ORM)
 Resolution: |   Severity:  Normal
   Triage Stage:  Accepted   |   Keywords:
Needs documentation:  0  |  Has patch:  1
Patch needs improvement:  0  |Needs tests:  0
 |  Easy pickings:  0
-+-

Comment (by Alex):

 FWIW jacob, I spoke with aaugustin on IRC and I agree with your position,
 if we can do it in a non-hacky way (as psycopg2 is now), +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] #14091: Fix incorrect quoting in connection.queries

[Django]

#14091: Fix incorrect quoting in connection.queries
-+-
   Reporter:  danielr|  Owner:
   Type:  Bug| Status:  new
  Milestone: |  Component:  Database layer
Version:  1.2|  (models, ORM)
 Resolution: |   Severity:  Normal
   Triage Stage:  Accepted   |   Keywords:
Needs documentation:  0  |  Has patch:  1
Patch needs improvement:  0  |Needs tests:  0
 |  Easy pickings:  0
-+-

Comment (by jacob):

 aaugustin: also, add your name to AUTHORS if you'd like credit when we
 check this in!

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

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

Re: [Django] #14091: Fix incorrect quoting in connection.queries

[Django]

#14091: Fix incorrect quoting in connection.queries
-+-
   Reporter:  danielr|  Owner:
   Type:  Bug| Status:  new
  Milestone: |  Component:  Database layer
Version:  1.2|  (models, ORM)
 Resolution: |   Severity:  Normal
   Triage Stage:  Accepted   |   Keywords:
Needs documentation:  0  |  Has patch:  1
Patch needs improvement:  0  |Needs tests:  0
 |  Easy pickings:  0
-+-

Comment (by jacob):

 I disagree with Alex about the lack of value, but like Alex, I'm not sold
 on the approach under SQLite - it seems rather hackish and prone to
 failure. I aprove (highly) of the fixes for MySQL and Oracle, and I'd like
 to see those go in.

 I say we fix this where we can (MySQL and Oracle) and leave it as-is for
 SQLite. If there's a non-gross way of retrieving the last query from the
 `sqlite3` library then let's by all means use that, but if not we'll need
 to leave SQLite alone. We already have a good document explaining the
 differences between databases, so this can be another caveat there (and
 another reason to use a real database).

 aaugustin, if you make those changes feel free to mark this ticket RFC.
 Everything else looks good to me.

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

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

Re: [Django] #15860: modelform.is_valid() and modelform.errors fail to anticipate database integrity errors, allow exceptions to reach the user

[Django]

#15860: modelform.is_valid() and modelform.errors fail to anticipate database
integrity errors, allow exceptions to reach the user
--+
   Reporter:  legutierr   |  Owner:  nobody
   Type:  Bug | Status:  closed
  Milestone:  |  Component:  Forms
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
--+

Comment (by carljm):

 I think wontfix is actually the correct resolution for this bug report.
 The crux of the matter is "In my opinion, modelform.is_valid() should
 always report that a form is NOT valid if it is certain that a call to
 save() will raise an exception." This is wrong; it is never certain,
 because of the existence of `modelform.save(commit=False)` and code like
 this (presuming a model with FK to User, and a ModelForm that excludes the
 user FK):

 {{{
 if form.is_valid():
 obj = form.save(commit=False)
 obj.user = request.user
 obj.save()
 }}}

 This is a common and useful idiom, and it would be broken if ModelForm
 validation had the semantics suggested here. The actual semantics are that
 the ModelForm is responsible only for validating the fields included in
 it, and anything excluded is the responsibility of the application
 developer to handle appropriately.

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

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

Re: [Django] #14091: Fix incorrect quoting in connection.queries

[Django]

#14091: Fix incorrect quoting in connection.queries
-+-
   Reporter:  danielr|  Owner:
   Type:  Bug| Status:  new
  Milestone: |  Component:  Database layer
Version:  1.2|  (models, ORM)
 Resolution: |   Severity:  Normal
   Triage Stage:  Accepted   |   Keywords:
Needs documentation:  0  |  Has patch:  1
Patch needs improvement:  0  |Needs tests:  0
 |  Easy pickings:  0
-+-

Comment (by aaugustin):

 Alex, the reasons for fixing this are:

 - make it possible to test queries by copy-pasting from the debug bar or a
 debug log. That is useful to troubleshoot performance issues: `./manage
 dbshell` then `EXPLAIN  <>`. Re-quoting manually complex queries
 is just a pain. The framework should do that for us.
 - remove a common source of questions and frustration for users, as seen
 on #django and in duplicate tickets.

 Also, Django is supposed be a framework for perfectionnists; IMHO the
 status quo ''yeah, it's buggy, but we say it in the small print...''
 doesn't live up to this goal. Should we ask django-developers for other
 opinions?

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

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

Re: [Django] #15782: Runserver/runfcgi/startup with MySQL is unlike any other database

[Django]

#15782: Runserver/runfcgi/startup with MySQL is unlike any other database
-+-
   Reporter:  toofishes  |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Database layer
Version:  1.3|  (models, ORM)
 Resolution: |   Severity:  Normal
   Triage Stage:  Accepted   |   Keywords:
Needs documentation:  0  |  Has patch:  0
Patch needs improvement:  0  |Needs tests:  0
 |  Easy pickings:  0
-+-
Changes (by jacob):

 * stage:  Design decision needed => Accepted


Comment:

 Yeah, this shouldn't blow up. It should either display a nice error, or
 fail consistently (i.e. in the same way that other databases fail).

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

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

Re: [Django] #14091: Fix incorrect quoting in connection.queries

[Django]

#14091: Fix incorrect quoting in connection.queries
-+-
   Reporter:  danielr|  Owner:
   Type:  Bug| Status:  new
  Milestone: |  Component:  Database layer
Version:  1.2|  (models, ORM)
 Resolution: |   Severity:  Normal
   Triage Stage:  Accepted   |   Keywords:
Needs documentation:  0  |  Has patch:  1
Patch needs improvement:  0  |Needs tests:  0
 |  Easy pickings:  0
-+-
Changes (by Alex):

 * easy:   => 0


Comment:

 `connections.queries` is explicitly documented as not quoting things
 correctly, here http://docs.djangoproject.com/en/dev/faq/models/#how-can-i
 -see-the-raw-sql-queries-django-is-running, I'm not sure why we'd bother
 to fix this, the patch is non-trivial (it involves running queries on
 SQLite) and adds little value IMO.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, 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] #15880: manage.py: difficult to run in background (and crashes when input isn't a terminal)

[Django]

#15880: manage.py: difficult to run in background (and crashes when input isn't 
a
terminal)
+
 Reporter:  dstndstn@…  |  Owner:  nobody
 Type:  Bug | Status:  new
Milestone:  |  Component:  Core (Management commands)
  Version:  1.3 |   Severity:  Normal
 Keywords:  |   Triage Stage:  Unreviewed
Has patch:  0   |  Easy pickings:  0
+
 This is with Django 1.3, and seems to be different than previous releases.

 When I try to run manage.py in the background   (python manage.py >
 django.log 2>&1 &)  the process stalls.

 When I try to pipe /dev/null to stdin it crashes as shown below.

 thanks!

 {{{
 # python manage.py --version
 1.3

 # python manage.py runserver < /dev/null
 Validating models...

 Traceback (most recent call last):
   File "manage.py", line 11, in 
 execute_manager(settings)
   File
 "/usr/local/django-1.3/lib/python/django/core/management/__init__.py",
 line 438, in execute_manager
 utility.execute()
   File
 "/usr/local/django-1.3/lib/python/django/core/management/__init__.py",
 line 379, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "/usr/local/django-1.3/lib/python/django/core/management/base.py",
 line 191, in run_from_argv
 self.execute(*args, **options.__dict__)
   File "/usr/local/django-1.3/lib/python/django/core/management/base.py",
 line 220, in execute
 output = self.handle(*args, **options)
   File
 
"/usr/local/django-1.3/lib/python/django/core/management/commands/runserver.py",
 line 67, in handle
 self.run(*args, **options)
   File
 
"/usr/local/django-1.3/lib/python/django/core/management/commands/runserver.py",
 line 76, in run
 0 errors found
 autoreload.main(self.inner_run, args, options)
   File "/usr/local/django-1.3/lib/python/django/utils/autoreload.py", line
 131, in main
 Django version 1.3, using settings 'astrometry_gsoc_challenge.settings'
 Development server is running at http://**/
 Quit the server with CONTROL-C.
 reloader(main_func, args, kwargs)
   File "/usr/local/django-1.3/lib/python/django/utils/autoreload.py", line
 104, in python_reloader
 reloader_thread()
   File "/usr/local/django-1.3/lib/python/django/utils/autoreload.py", line
 83, in reloader_thread
 ensure_echo_on()
   File "/usr/local/django-1.3/lib/python/django/utils/autoreload.py", line
 77, in ensure_echo_on
 attr_list = termios.tcgetattr(fd)
 termios.error: (25, 'Inappropriate ioctl for device')
 }}}

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

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

Re: [Django] #15866: get_model() and get_models() can return models that are not in INSTALLED_APPS

[Django]

#15866: get_model() and get_models() can return models that are not in
INSTALLED_APPS
-+-
   Reporter:  carljm |  Owner:  carljm
   Type:  Bug| Status:  closed
  Milestone: |  Component:  Database layer
Version: |  (models, ORM)
 Resolution:  fixed  |   Severity:  Normal
   Triage Stage:  Accepted   |   Keywords:
Needs documentation:  0  |  Has patch:  1
Patch needs improvement:  0  |Needs tests:  0
 |  Easy pickings:  0
-+-

Comment (by carljm):

 Replying to [comment:5 jezdez]:
 > This should really have been added to the app-loading branch, not trunk.

 I don't mind porting this fix to app-loading branch, but fixing it in
 trunk resolved a problematic regression (#15850) which prevented reusable
 app authors from running their tests against trunk. I wouldn't want to
 delay that fix until app-loading lands, though if having this in trunk is
 a serious problem we could temporarily use a hackier workaround to resolve
 #15850.

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

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

Re: [Django] #15783: Class FileProxyMixin has invalid attribute definition

[Django]

#15783: Class FileProxyMixin has invalid attribute definition
-+-
   Reporter:  sebzur |  Owner:  nobody
   Type:  Bug| Status:  closed
  Milestone: |  Component:  File
Version:  1.3|  uploads/storage
 Resolution:  invalid|   Severity:  Normal
   Triage Stage: |   Keywords:
  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+-

Comment (by sebzur):

 OKay - now I see it! This comment helps me a little.  You're right the
 when You're looking on this with hasattr, there's no 'fileno', and
 everything is **perfectly okay**.

 My 'fault' was, that I was looking on this firstly with `dir`, which
 simply listed 'fileno' as attr and than I was trying to use it. I was also
 looking into the code, where I also saw 'fileno' implemented.

 So I thing it should be left as it is... but there's still a tiny bit of
 hesitation in me when I'm thinking abut it...

 (fileno behaviour is like taken from the quantum mechanics: You know that
 it's not there only if You really try to touch it.) :D

 Anyway - thanks for the 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] #15878: Bad Link In Module Index

[Django]

#15878: Bad Link In Module Index
+---
   Reporter:  Shane@…   |  Owner:  nobody
   Type:  Bug   | Status:  new
  Milestone:|  Component:  Documentation
Version:  1.3   |   Severity:  Normal
 Resolution:|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  1
+---

Comment (by jacob):

 It's probably a typo in `ref/contrib/admin/` itself -- the index is
 listing all Sphinx directives, so somewhere there's a "adm" link 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.

Re: [Django] #15877: Exception:ModelForm has no model class specified

[Django]

#15877: Exception:ModelForm has no model class specified
---+--
   Reporter:  theaspect@…  |  Owner:  nobody
   Type:  Bug  | Status:  reopened
  Milestone:   |  Component:  Forms
Version:  1.3  |   Severity:  Normal
 Resolution:   |   Keywords:
   Triage Stage:  Accepted |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
---+--
Changes (by jacob):

 * stage:  Unreviewed => Accepted


Comment:

 Verified. `ModelForm.__init__` should raise the `ValueError` in all cases.

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

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

Re: [Django] #11283: latest() doesn't clear previous ordering

[Django]

#11283: latest() doesn't clear previous ordering
-+-
   Reporter:  benmoran   |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Database layer
Version: |  (models, ORM)
 Resolution: |   Severity:  Normal
   Triage Stage:  Ready for  |   Keywords:
  checkin|  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+-
Changes (by julien):

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


Comment:

 Thank you for the patch. I've just added a reference to this ticket number
 in the test's comment for posterity.

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

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

Re: [Django] #15783: Class FileProxyMixin has invalid attribute definition

[Django]

#15783: Class FileProxyMixin has invalid attribute definition
-+-
   Reporter:  sebzur |  Owner:  nobody
   Type:  Bug| Status:  closed
  Milestone: |  Component:  File
Version:  1.3|  uploads/storage
 Resolution:  invalid|   Severity:  Normal
   Triage Stage: |   Keywords:
  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+-

Comment (by jonash):

 From the runtime's point of view (`hasattr`/`getattr`), it doesn't have a
 `fileno` attribute.
 {{{>>> class Foo(object):
 ...   @property
 ...   def fileno(self):
 ... raise AttributeError
 ...
 >>> hasattr(Foo(), 'fileno')
 False}}}

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

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

Re: [Django] #15783: Class FileProxyMixin has invalid attribute definition

[Django]

#15783: Class FileProxyMixin has invalid attribute definition
-+-
   Reporter:  sebzur |  Owner:  nobody
   Type:  Bug| Status:  closed
  Milestone: |  Component:  File
Version:  1.3|  uploads/storage
 Resolution:  invalid|   Severity:  Normal
   Triage Stage: |   Keywords:
  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+-

Comment (by sebzur):

 OK, I understand that... but the case is: `FileProxyMixin` defines
 `fileno` property, which proxies to `self.file.fileno` .. which does not
 exist.

 The fact that `self.file.fileno` does not exist (when file is e.g.
 InMemomyUploadedFile instance) is of course valid with respect to Python
 docs, but.. when I'm using an object (an instance of FileProxyMixin
 subclass) that is reporting (i.e. with dir) that **it has fileno
 attribute**, shouldn't it have it?

 I found the current FileProxyMixin definition unclear. IMHO it confuses
 programmer, who has to know, that despite the existence of the attribute,
 he can not use it.

 One can of course say, that this is somehow similar case to the case of
 abstract method raising `NonImplementedError`  being at the same time the
 existing attribute of the class, but while the Python docs states that the
 method **should not be provided** in fact **it is** (at least as a
 'reference' to `AttributeError`).

 This is just to comment what worries me here. :D Maybe `FileProxyMixin`
 should introspect `self.file` to see if it provides `fileno` before
 putting it as a proxy attr?

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

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

Re: [Django] #15783: Class FileProxyMixin has invalid attribute definition

[Django]

#15783: Class FileProxyMixin has invalid attribute definition
-+-
   Reporter:  sebzur |  Owner:  nobody
   Type:  Bug| Status:  closed
  Milestone: |  Component:  File
Version:  1.3|  uploads/storage
 Resolution:  invalid|   Severity:  Normal
   Triage Stage: |   Keywords:
  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+-
Changes (by jonash):

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


Comment:

 From the Python documentation:

 file.fileno()
 [...]
 File-like objects which do not have a real file descriptor should
 *not* provide
 this method!

 That's exactly what Django does: Raising an ``AttributeError`` for file-
 likes that have no ``fileno``.

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

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

Re: [Django] #15819: Admin searches should use distinct, if query involves joins

[Django]

#15819: Admin searches should use distinct, if query involves joins
-+-
   Reporter:  Adam   |  Owner:  ryankask
  Kochanowski | Status:  new
   Type:  Bug|  Component:  contrib.admin
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage: |Needs tests:  0
  Unreviewed |  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-

Comment (by ryankask):

 I've added an alternative patch that removes some of the mock request
 boilerplate in the tests. I'm not sure if that's okay because it isn't
 important for the patch but cuts down on unnecessary code.

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

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

Re: [Django] #15792: databrowse attempting to create urls out of non-models

[Django]

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

Comment (by aaugustin):

 I hit that bug myself some time ago and solved it with a different patch
 (attached).

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

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

Re: [Django] #15792: databrowse attempting to create urls out of non-models

[Django]

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

 * needs_docs:   => 0
 * needs_better_patch:   => 0
 * needs_tests:   => 1
 * easy:   => 0
 * 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] #15793: Filebased email backend should save emails using the ".eml" standard extension

[Django]

#15793: Filebased email backend should save emails using the ".eml" standard
extension
-+-
   Reporter:  Kronuz |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |  Component:  Core (Mail)
  Milestone: |   Severity:  Normal
Version: |   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage:  Ready for  |Needs tests:  0
  checkin|  Easy pickings:  1
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by aaugustin):

 * easy:  0 => 1
 * stage:  Accepted => Ready for checkin


Comment:

 Patch is trivial and the change makes sense.

 There is no standard for file extensions; .eml is certainly more
 appropriate than .log for an email.

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

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

Re: [Django] #15793: Filebased email backend should save emails using the ".eml" standard extension

[Django]

#15793: Filebased email backend should save emails using the ".eml" standard
extension
-+-
   Reporter:  Kronuz |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |  Component:  Core (Mail)
  Milestone: |   Severity:  Normal
Version: |   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
-+-
Changes (by aaugustin):

 * easy:   => 0
 * 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] #15782: Runserver/runfcgi/startup with MySQL is unlike any other database

[Django]

#15782: Runserver/runfcgi/startup with MySQL is unlike any other database
-+-
   Reporter:  toofishes  |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Database layer
Version:  1.3|  (models, ORM)
 Resolution: |   Severity:  Normal
   Triage Stage:  Design |   Keywords:
  decision needed|  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+-
Changes (by aaugustin):

 * needs_better_patch:   => 0
 * stage:  Unreviewed => Design decision needed
 * needs_tests:   => 0
 * easy:   => 0
 * needs_docs:   => 0


Comment:

 See #9431 which has a lengthy discussion of why and how the checks are
 performed.

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

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

Re: [Django] #15798: "spaceless" filter does not not honor tag formatting

[Django]

#15798: "spaceless" filter does not not honor  tag formatting
-+-
   Reporter:  dfcode |  Owner:  nobody
   Type: | Status:  closed
  Cleanup/optimization   |  Component:  Template system
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:  spaceless,html,pre
 Resolution:  wontfix|  Has patch:  0
   Triage Stage: |Needs tests:  0
  Unreviewed |  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by aaugustin):

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


Comment:

 Currently the {% spaceless %} tag does what is documented: it removes all
 spaces.

 #8123 discusses customizing its behavior for certain tags (inline vs.
 block); it was rejected by two core developers. The bottom line is that if
 you do not want to remove all spaces, you just shouldn't use {% spaceless
 %}.

 In my opinion, the behavior is intentional, so I will close the ticket as
 wontfix.

 PS1 : your idea was briefly mentioned here:
 http://code.djangoproject.com/ticket/3532#comment:10 but not discussed
 further.

 PS2 : for the record, here is the history of the {% spaceless %} tag:
 - introduced with #1067, really spaceless
 - changed with #1227, collapses several whitespace characters to a space
 - changed back with #3532, really spaceless again after a discussion on
 the mailing-list: http://www.mail-archive.com/django-
 develop...@googlegroups.com/msg09235.html

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

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

Re: [Django] #15786: Wrong SQL for OneToOneField with exclude() using F() parameter

[Django]

#15786: Wrong SQL for OneToOneField with exclude() using F() parameter
-+-
   Reporter:  gerdemb|  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Database layer
Version:  1.3|  (models, ORM)
 Resolution: |   Severity:  Normal
   Triage Stage:  Accepted   |   Keywords:
Needs documentation:  0  |  Has patch:  0
Patch needs improvement:  0  |Needs tests:  0
 |  Easy pickings:  0
-+-
Changes (by jonash):

 * needs_docs:   => 0
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * easy:   => 0
 * 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] #15801: Logging docs: Incorrect external link for dictConfig

[Django]

#15801: Logging docs: Incorrect external link for dictConfig
-+-
   Reporter:  David  |  Owner:  nobody
  Niergarth    | Status:  new
   Type:  Bug|  Component:  Documentation
  Milestone: |   Severity:  Normal
Version:  1.2|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
-+-
Changes (by jonash):

 * has_patch:  0 => 1
 * easy:   => 0
 * 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] #15774: UnicodeDecodeError with makemessages

[Django]

#15774: UnicodeDecodeError with makemessages
-+-
   Reporter:  deschler   |  Owner:  nobody
   Type:  Bug| Status:  closed
  Milestone: |  Component:
Version:  1.3|  Internationalization
 Resolution:  duplicate  |   Severity:  Normal
   Triage Stage: |   Keywords:
  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
-+-
Changes (by jonash):

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


Comment:

 Duplicate of #15848

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

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

Re: [Django] #15819: Admin searches should use distinct, if query involves joins

[Django]

#15819: Admin searches should use distinct, if query involves joins
-+-
   Reporter:  Adam   |  Owner:  ryankask
  Kochanowski | Status:  new
   Type:  Bug|  Component:  contrib.admin
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage: |Needs tests:  0
  Unreviewed |  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by ryankask):

 * has_patch:  0 => 1


Comment:

 I've added an initial patch. I've also discovered that the problem exists
 for `list_filters` and the patch reflects thats. Since the same check to
 use `distinct()` was used in two places, I've factored that out into a
 function:

 {{{#!python
 def field_needs_distinct(field):
 if ((hasattr(field, 'rel') and
  isinstance(field.rel, models.ManyToManyRel)) or
 (isinstance(field, models.related.RelatedObject) and
  not field.field.unique)):
 return True
 return False
 }}}

 Distinct isn't called unconditionally: only if it is a ManyToMany
 relationship or some other kind of relationship where the key has
 `unique=False`.

 The only other piece of code I'm unsure about is
 
http://code.djangoproject.com/browser/django/trunk/django/contrib/admin/views/main.py#L238.
 Should `select_related()` be called for other types of relationships? For
 example, this case where a `ForeignKey` has `unique=False`.

 I don't know if this is an acceptable test for the condition so any
 feedback would be great. I'd also like feedback on the style as it's my
 first 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] #15879: multipart/form-data filename="" not handled as file

[Django]

#15879: multipart/form-data filename="" not handled as file
-+--
 Reporter:  j@…  |  Owner:  nobody
 Type:  Bug  | Status:  new
Milestone:   |  Component:  File uploads/storage
  Version:  1.3  |   Severity:  Normal
 Keywords:   |   Triage Stage:  Unreviewed
Has patch:  0|  Easy pickings:  0
-+--
 Django does not parse file uploads with empty filename as file objects in
 multipart/form-data requests.
 This happens currently if you try to upload a Blob in Firefox 4
 (https://bugzilla.mozilla.org/show_bug.cgi?id=649150)
 Firefox sends this:
 {{{
 Content-Disposition: form-data; name="fieldname"; filename=""
 Content-Type: content/type
 DATA
 }}}

 Reading the related RFCs there is no mention that filename="" is not
 allowed and the existence of the filename parameter should be enough to
 treat it as a file.
 looking at django/http/multipartparser.py
 165ff
 {{{
 file_name = disposition.get('filename')
 if not file_name:
 continue
 }}}
 this would need to set a default filename instead of bailing out
 (i.e. if file_name == '': file_name = 'data.bin)

 590:
 {{{
 if params.get('filename'):
 }}}
 this would need to check
 {{{
 if 'filename' in params:
 }}}

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

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

Re: [Django] #15878: Bad Link In Module Index

[Django]

#15878: Bad Link In Module Index
+---
   Reporter:  Shane@…   |  Owner:  nobody
   Type:  Bug   | Status:  new
  Milestone:|  Component:  Documentation
Version:  1.3   |   Severity:  Normal
 Resolution:|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  1
+---
Changes (by julien):

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


Comment:

 Yes, I'm unsure why this is occurring though.

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

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

Re: [Django] #11639: Can't remove prepopulated fields from fieldset in ModelAdmin

[Django]

#11639: Can't remove prepopulated fields from fieldset in ModelAdmin
-+-
   Reporter: |  Owner:  nobody
  leanmeandonothingmachine   | Status:  new
   Type:  New|  Component:  contrib.admin
  feature|   Severity:  Normal
  Milestone:  1.4|   Keywords:  sprintnov13
Version:  1.3-beta   |  Has patch:  1
 Resolution: |Needs tests:  0
   Triage Stage:  Ready for  |  Easy pickings:  0
  checkin|
Needs documentation:  0  |
Patch needs improvement:  0  |
-+-
Changes (by defaultwombat):

 * easy:   => 0


Comment:

 This is definitly a fix for #13618 too.

 Additionally it solves a problem when trying to manually fix the #13618
 issue by changeing the prepopulated_fields e.g. in the change_view.
 As this is a dictionary shared over all instances of the Adminmodel, after
 altering it you lost the prepopulating feature until server refresh.

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

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

Re: [Django] #13629: Admin Changelist: add app-model_name class to tag

[Django]

#13629: Admin Changelist: add app-model_name class to  tag
---+---
   Reporter:  naos |  Owner:  nobody
   Type:  New feature  | Status:  new
  Milestone:   |  Component:  contrib.admin
Version:  1.2  |   Severity:  Normal
 Resolution:   |   Keywords:
   Triage Stage:  Accepted |  Has patch:  1
Needs documentation:  0|Needs tests:  1
Patch needs improvement:  1|  Easy pickings:  1
---+---

Comment (by julien):

 Scrap my comment about `opts.object_name.lower`, which is fine to use
 here. I'd still like to see this new feature applied to all relevant admin
 templates though.

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

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

[Django]

#15878: Bad Link In Module Index
-+
 Reporter:  Shane@…  |  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:  1
-+
 Hello,

 In the [http://docs.djangoproject.com/en/1.3/py-modindex/ Module Index]
 there is a link called django.contrib.admin  which goes to
 http://docs.djangoproject.com/en/1.3/ref/contrib/adm/ rather than
 http://docs.djangoproject.com/en/1.3/ref/contrib/admin/

 Hope that helps,

 Shane Hudson

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

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

Re: [Django] #5833: Custom FilterSpecs

[Django]

#5833: Custom FilterSpecs
-+-
   Reporter: |  Owner:  jkocherhans
  Honza_Kral | Status:  assigned
   Type:  New|  Component:  contrib.admin
  feature|   Severity:  Normal
  Milestone: |   Keywords:  nfa-someday
Version:  SVN|  list_filter filterspec nfa-
 Resolution: |  changelist ep2008
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  1  |  Easy pickings:  0
-+-
Changes (by julien):

 * needs_better_patch:  0 => 1
 * easy:   => 0


Comment:

 Thanks for reviewing the patch!

 Replying to [comment:121 fas]:
 > - get_query_set should have no request parameter. It is passed in the
 __init__, you can set self.request there to be available for all the
 methods of the filter. has_output, title, ... could all depend on request.
 It is arbitrary that only get_query_set gets passed the request,
 especially if it can be accessed with self.request.

 I would prefer passing the request as a parameter for the sake of being
 explicit. This would also be more consistent with the way things work in
 other public APIs in Django, for example in `ModelAdmin`.

 > - there is no reason why _choices() should have an underscore (as
 introduced in the latest patch). It is not a private method and intended
 to be overridden in inheriting filters.

 The two main reasons I've added an underscore is because I haven't come up
 with a clean and simple API for `FieldListFilter` yet and also to avoid
 the developer accidentally overriding it instead of the `get_choices()`
 method which is part of the suggested new public API. If we're to remove
 the underscore then I'd like at least to find a more distinct name for it.

 > - I think the whole used_params and query_parameter_name thing is too
 restricting. Who says I use only one parameter?
 > The better implementation is to provide get_value with the parameter key
 and a default value, like this:
 >
 > {{{
 > def get_value(self, name, default):
 > return self.params.get(name, default)
 > }}}
 >
 > You would then usually do something like this:
 >
 > {{{
 > class MyCustomFilter(FilterSpec):
 > ALL = 'all'
 > MY_VALUE1 = 'some-param-value'
 > MY_VALUE2 = 'some-other-param-value'
 > # ...
 > DEFAULT_VALUE = MY_VALUE1
 >
 > def __init__(self, ...):
 > super(...)...
 > self.arg = 'my-parameter-key'
 > self.value = self.get_value(self.arg, self.DEFAULT_VALUE)
 >
 > def get_query_set(self, qs):
 > if self.value == self.ALL:
 > return 
 > if self.value == self.MY_VALUE1:
 > return ...
 >
 >
 > }}}
 >
 > The get_query_set method should be called no matter what is in the
 parameters (as there should be no query_parameter_name in the first
 place).
 >
 > - When applying the get_query_set method, if it returns None, it should
 not be used. The problem of having to check if to call the method based on
 request parameters disappears, as do custom checks in the method.

 This all seems interesting. Could you elaborate on how the developer would
 specify the choices/options available in the filter?

 Your approach seems valid but it still feels quite complex. I have been
 trying to come up with a very simple and easy API to cover most use cases.
 I believe that in most use cases one would just need one parameter. This
 is why I originally called the class `SimpleFilterSpec` (and in a later
 patch `SimpleListFilter`). But Jacob didn't like the split between
 `SimpleListFilter` and `FieldListFilter` (see his comment in
 http://groups.google.com/group/django-
 developers/browse_thread/thread/ec7c4124e7317145). I tend to agree with
 Jacob in that this split didn't seem ideal, but I also tend to agree with
 you that the current implementation of `ListFilter` is a bit too
 restrictive. Currently my preference would be to reintroduce
 `SimpleListFilter` to offer this dead-simple (yet restrictive) approach,
 and to modify `ListFilterBase` to accommodate for a less restrictive API
 (and also let `FieldListFilter` use that API to validate that it works).

 I'll continue thinking this through, but please feel free to provide any
 other criticisms or insights.

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

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

Re: [Django] #15866: get_model() and get_models() can return models that are not in INSTALLED_APPS

[Django]

#15866: get_model() and get_models() can return models that are not in
INSTALLED_APPS
-+-
   Reporter:  carljm |  Owner:  carljm
   Type:  Bug| Status:  closed
  Milestone: |  Component:  Database layer
Version: |  (models, ORM)
 Resolution:  fixed  |   Severity:  Normal
   Triage Stage:  Accepted   |   Keywords:
Needs documentation:  0  |  Has patch:  1
Patch needs improvement:  0  |Needs tests:  0
 |  Easy pickings:  0
-+-
Changes (by jezdez):

 * easy:   => 0


Comment:

 This should really have been added to the app-loading branch, not trunk.

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

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

Re: [Django] #15813: STATES_NORMALIZED dict for India does not include all states

[Django]

#15813: STATES_NORMALIZED dict for India does not include all states
-+-
   Reporter:  jsdalton   |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |  Component:  contrib.localflavor
  Milestone:  1.4|   Severity:  Normal
Version:  SVN|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  1  |
-+-
Changes (by julien):

 * needs_better_patch:  0 => 1
 * easy:   => 0


Comment:

 Thanks a lot for your patch. Everything looks great but the tests still
 look a bit thin. The tests should be made more thorough by checking that
 *all* the values return the expected outcome. Testing some cases where the
 form field is invalid would also be useful. This would prevent regressions
 caused, for example, by typos inserted in the `STATES_NORMALIZED` or
 `STATE_CHOICES` contants in the future.

 You can find lots of inspiration in the existing tests for other local
 flavors in source:django/trunk/tests/regressiontests/forms/localflavor/

 I'll review your patch again if you can re-post it with more comprehensive
 tests. Thanks!

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

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

Re: [Django] #15877: Exception:ModelForm has no model class specified

[Django]

#15877: Exception:ModelForm has no model class specified
---+--
   Reporter:  theaspect@…  |  Owner:  nobody
   Type:  Bug  | Status:  reopened
  Milestone:   |  Component:  Forms
Version:  1.3  |   Severity:  Normal
 Resolution:   |   Keywords:
   Triage Stage:  Unreviewed   |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
---+--
Changes (by anonymous):

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


Comment:

 it's pretty clear
 {{{
 class SomeModel(models.Model):
 ...

 class MyForm(forms.ModelForm):
 class Meta:
 pass

 f = MyForm() #raises exception (ModelForm has no model class specified.)
 f = MyForm(instance=SomeModel) #don't but expected too
 }}}

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

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

Re: [Django] #15819: Admin searches should use distinct, if query involves joins

[Django]

#15819: Admin searches should use distinct, if query involves joins
-+-
   Reporter:  Adam   |  Owner:  ryankask
  Kochanowski | Status:  new
   Type:  Bug|  Component:  contrib.admin
  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  |
-+-
Changes (by ryankask):

 * status:  reopened => new
 * owner:  aip@… => ryankask
 * easy:   => 0


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

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

Re: [Django] #13659: Made the request accessible in callables used in ModelAdmin.list_display [PATCH]

[Django]

#13659: Made the request accessible in callables used in ModelAdmin.list_display
[PATCH]
---+---
   Reporter:  sebastian_noack  |  Owner:  nobody
   Type:  New feature  | Status:  new
  Milestone:   |  Component:  contrib.admin
Version:  1.2  |   Severity:  Normal
 Resolution:   |   Keywords:
   Triage Stage:  Accepted |  Has patch:  1
Needs documentation:  1|Needs tests:  0
Patch needs improvement:  1|  Easy pickings:  0
---+---
Changes (by julien):

 * needs_better_patch:  0 => 1
 * easy:   => 0


Comment:

 I think there's a problem with this patch. The `request` parameter in
 `lookup_field` could be `None`, which would happen when called from
 `AdminReadonlyField.contents()`. This means that the callable may receive
 `None` in some cases, which is a shame. The callable should always receive
 the `HTTPRequest` object.

 Also, I think it would make more sense (and be more consistent with the
 way `ModelAdmin`'s methods work) if the request was provided as the first
 argument, e.g.:
 {{{
 def my_function(request, ...):
 ...
 }}}
 or:
 {{{
 def my_method(self, request, ...):
 ...
 }}}
 And finally, I'd prefer the function attribute to be called
 `takes_request`, for consistency with `takes_context` in the
 `inclusion_tag`.

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

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

Re: [Django] #15877: Exception:ModelForm has no model class specified

[Django]

#15877: Exception:ModelForm has no model class specified
---+
   Reporter:  theaspect@…  |  Owner:  nobody
   Type:  Bug  | Status:  closed
  Milestone:   |  Component:  Forms
Version:  1.3  |   Severity:  Normal
 Resolution:  needsinfo|   Keywords:
   Triage Stage:  Unreviewed   |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
---+
Changes (by akaariai):

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


Comment:

 I am afraid that there is not enough information about the problem to
 verify this as a bug. Giving concrete sample of the problem would help.
 That is, could you write Python code which would show the problem?

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

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

Re: [Django] #13629: Admin Changelist: add app-model_name class to tag

[Django]

#13629: Admin Changelist: add app-model_name class to  tag
---+---
   Reporter:  naos |  Owner:  nobody
   Type:  New feature  | Status:  new
  Milestone:   |  Component:  contrib.admin
Version:  1.2  |   Severity:  Normal
 Resolution:   |   Keywords:
   Triage Stage:  Accepted |  Has patch:  1
Needs documentation:  0|Needs tests:  1
Patch needs improvement:  1|  Easy pickings:  1
---+---
Changes (by julien):

 * needs_better_patch:  0 => 1
 * easy:   => 1


Comment:

 This is a good idea but while we're at it let's do it in every admin
 template, not just the change list. Also, using `opts.module_name` is
 preferable over `opts.object_name.lower`.

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

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