[Django] #16442: step not passed to get_form when using NamedUrls

[Django]

#16442: step not passed to get_form when using NamedUrls
-+
 Reporter:  guillaume@…  |  Owner:  nobody
 Type:  Bug  | Status:  new
Milestone:  1.4  |  Component:  Forms
  Version:  SVN  |   Severity:  Normal
 Keywords:   |   Triage Stage:  Unreviewed
Has patch:  0|  Easy pickings:  1
UI/UX:  0|
-+
 Hi,

 I have noticed in the code of NamedUrlWizardView that you don't pass the
 step name to get_form.

 I think it should pass it as else the only we have to know what step we
 are in is to use self.steps.current, which can bring some bugs. For
 example in my use case for the same step I need to customize get_form and
 get_form_initial. But in my get_form_initial I need to use get_form with
 data parameter to retrieve a previous form data to generate my new form.
 If I use self.steps.current it would bring a recursive loop.

 Here is a piece of code that show the problem:

 {{{#!python
 class wizard(SessionWizardView, NamedUrlSessionWizardView):

 def _calc_attributes(self):
 sale_form = self.get_form(step=self.STEP_PRODUCT,
 data=self.storage.data['step_data'][self.STEP_PRODUCT])
 sale = sale_form.save(commit=False)
 self.common_attributes =
 CommonAttribute.objects.filter(for_type=sale.type)

 def get_form_initial(self, step):
 if step == self.steps.current
 self._calc_attributes()
 initials = []
 # add stuff in initials
 return initials
 return super(SaleWizard, self).get_form_initial(step)

 def get_form(self, step=None, data=None, files=None):
 if step == self.steps.current:
 self._calc_attributes()
 formset = inlineformset_factory(Sale, ProductStock,
 can_delete=True,
  extra=self.attributes_len,
  formset=BaseStockFormSet)
 kwargs = self.get_form_kwargs(step)
 kwargs.update({
 'data': data,
 'files': files,
 'prefix': self.get_form_prefix(step,
 self.form_list[step]),
 'initial': self.get_form_initial(step),
 })
 return formset(**kwargs)
 return super(SaleWizard, self).get_form(step, data, files)

 }}}


 Would be great if it could be fixed!

 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] #16441: Tutorial step1: Enable the project

[Django]

#16441: Tutorial step1: Enable the project
-+-
   Reporter: |  Owner:  nobody
  cesare.montresor@… | Status:  closed
   Type:  New|  Component:  Documentation
  feature|   Severity:  Normal
  Milestone: |   Keywords:
Version:  1.2|  Has patch:  0
 Resolution:  invalid|Needs tests:  0
   Triage Stage: |  Easy pickings:  0
  Unreviewed |
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by russellm):

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


Comment:

 I'm not sure why you think this is needed, but it isn't. Tutorial 3 covers
 the definition of URL patterns; Tutorial 1 doesn't require any
 modifications to the URL patterns in order to work, and adding a pattern
 for 'mysite.urls' when your project is called 'mysite' is a recipe for
 disaster later on (mysite.urls should be your top level URL patterns, so
 you shouldn't need to include it *anywhere*).

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

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

[Django]

#16441: Tutorial step1: Enable the project
+---
 Reporter:  cesare.montresor@…  |  Owner:  nobody
 Type:  New feature | Status:  new
Milestone:  |  Component:  Documentation
  Version:  1.2 |   Severity:  Normal
 Keywords:  |   Triage Stage:  Unreviewed
Has patch:  0   |  Easy pickings:  0
UI/UX:  0   |
+---
 It's about django-nonrel for appengine, I don't know if this applies to
 all the cases.

 I got trouble in following this documentation because for me was missing a
 step, that I have fixed it by guessing.
 For my experience, would be nice to add at the end of the paragraph
 [https://docs.djangoproject.com/en/1.2/intro/tutorial01/#creating-a-project
 Creating a project] the instructions to alter the main urls.py to route
 the requests into the project "mysite"


 ...
 Make sure that your /urls.py contains a row that look like this:

 {{{

  (r'^mysite/', include('mysite.urls')),

 }}}

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

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

Re: [Django] #16440: Internationalization pluralization docs small mistake

[Django]

#16440: Internationalization pluralization docs small mistake
-+-
   Reporter:  Bradley|  Owner:  nobody
  Ayers | Status:  new
   Type:  Bug|  Component:  Documentation
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage:  Ready for  |Needs tests:  0
  checkin|  Easy pickings:  1
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by julien):

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


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

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

Re: [Django] #16437: Outdated comment

[Django]

#16437: Outdated comment
-+-
   Reporter:  jonash |  Owner:  teraom
   Type: | Status:  assigned
  Cleanup/optimization   |  Component:  Testing framework
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:  minor
 Resolution: |  Has patch:  1
   Triage Stage:  Ready for  |Needs tests:  0
  checkin|  Easy pickings:  1
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by julien):

 * 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] #16438: class Meta spacing in django.contrib.admin Code Guidelines

[Django]

#16438: class Meta spacing in django.contrib.admin Code Guidelines
-+-
   Reporter: |  Owner:  nobody
  philipkimmey   | Status:  new
   Type: |  Component:  contrib.admin
  Cleanup/optimization   |   Severity:  Normal
  Milestone: |   Keywords:
Version:  SVN|  Has patch:  1
 Resolution: |Needs tests:  0
   Triage Stage:  Accepted   |  Easy pickings:  1
Needs documentation:  0  |
Patch needs improvement:  1  |
  UI/UX:  0  |
-+-
Changes (by melinath):

 * needs_better_patch:  0 => 1
 * version:  1.3 => SVN
 * stage:  Unreviewed => Accepted


Comment:

 The patch should be from the root of the django source code - i.e. it
 should be django/contrib/admin/models.py, not contrib/admin/models.py.

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

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

[Django] #16440: Internationalization pluralization docs small mistake

[Django]

#16440: Internationalization pluralization docs small mistake
-+-
 Reporter:  Bradley Ayers   |  Owner:  nobody
 Type:  Bug  | Status:  new
Milestone:   |  Component:
  Version:  1.3  |  Documentation
 Keywords:   |   Severity:  Normal
Has patch:  1|   Triage Stage:  Unreviewed
UI/UX:  0|  Easy pickings:  1
-+-
 
https://docs.djangoproject.com/en/1.3/topics/i18n/internationalization/#pluralization

 I think it should say "different from one", rather than "different from
 zero".

 {{{
 'object' for the singular and 'objects' for all the cases where count is
 different from zero, irrespective of its value.)
 }}}

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

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

Re: [Django] #16437: Outdated comment

[Django]

#16437: Outdated comment
-+-
   Reporter:  jonash |  Owner:  teraom
   Type: | Status:  assigned
  Cleanup/optimization   |  Component:  Testing framework
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:  minor
 Resolution: |  Has patch:  1
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  1
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by teraom):

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


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

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

[Django] #16439: select_related does not work with nullable fields

[Django]

#16439: select_related does not work with nullable fields
-+--
 Reporter:  dloewenherz  |  Owner:  nobody
 Type:  Bug  | Status:  new
Milestone:   |  Component:  Database layer (models, ORM)
  Version:  1.3  |   Severity:  Normal
 Keywords:  db   |   Triage Stage:  Unreviewed
Has patch:  0|  Easy pickings:  0
UI/UX:  0|
-+--
 Say I have the following model:


 {{{
 class Book(models.Model):
   owner = models.ForeignKey(Owner, related_name='books')
 }}}


 `Book.objects.select_related()` will pull in all owner data. HOWEVER, when
 the owner field is nullable, no joins occur.

 {{{
 class Book(models.Model):
 owner = models.ForeignKey(Owner, null=True, blank=True,
 related_name='books')
 }}}

 Running a join in my database involving a nullable field works exactly as
 would one on a non-nullable field, so I can't really see a good reason for
 this to happen.

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

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

Re: [Django] #8892: ForeignKey relation not saved as expected

[Django]

#8892: ForeignKey relation not saved as expected
-+-
   Reporter:  julien |  Owner:  blacklwhite
   Type:  Bug| Status:  reopened
  Milestone: |  Component:  Database layer
Version:  1.0|  (models, ORM)
 Resolution: |   Severity:  Normal
   Triage Stage:  Accepted   |   Keywords:
Needs documentation:  0  |  Has patch:  1
Patch needs improvement:  0  |Needs tests:  0
  UI/UX:  0  |  Easy pickings:  0
-+-
Changes (by blacklwhite):

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


Comment:

 Thank you for your feedback. Your hint made it much more simpler to find
 the correct piece of code to bugfix it. And - as you said - it fits
 formerly as a two liner into the existing code :-)

 The patch will now raise an error and results in the following behaviour:

 {{{
 >>> a = ModelA(name="a")
 >>> b = ModelB(name="b")
 >>> a.b = b
 ValueError: Cannot assign "": "ModelB.b" must have
 a primary key.
 }}}
 It does the same the reversed scenario.
 {{{
 >>> a = ModelA(name="a")
 >>> b = ModelB(name="b")
 >>> b.a_set.add(a)
 }}}

 Is the error message ok or would it be better to append "You have to save
  before assignment." or something like that?
 Are the both tests in the right class / method?
 What about compatibility to people using a workaround like follows; don't
 considering about that?
 {{{
 >>> a = ModelA(name="a")
 >>> b = ModelB(name="b")
 >>> a.b = b
 >>> print a.b.name
 >>> b.save()
 >>> a.b_id = a.b.id
 >>> a.save()
 }}}

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

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

Re: [Django] #10899: easier manipulation of sessions by test client

[Django]

#10899: easier manipulation of sessions by test client
---+---
   Reporter:  tallfred |  Owner:  nobody
   Type:  New feature  | Status:  reopened
  Milestone:   |  Component:  Testing framework
Version:  SVN  |   Severity:  Normal
 Resolution:   |   Keywords:
   Triage Stage:  Accepted |  Has patch:  1
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+---

Comment (by prestontimmons):

 I added an updated patch against r16527. It needs a second set of eyes to
 review it and verify it covers 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] #15496: "Content-Transfer-Encoding: base64" not honored when uploading files

[Django]

#15496: "Content-Transfer-Encoding: base64" not honored when uploading files
-+-
   Reporter:  gene@… |  Owner:  nobody
   Type:  Bug| Status:  closed
  Milestone: |  Component:  HTTP handling
Version:  SVN|   Severity:  Normal
 Resolution:  needsinfo  |   Keywords:  base64 file upload
   Triage Stage:  Ready for  |  Has patch:  1
  checkin|Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-

Comment (by anonymous):

 Thanks for looking into it.  One of these days I'll get back to it and
 repeat my test.  The above is my actual POST data... it should be easy
 enough for me to repeat the test when I get a free hour.  (Ha! A free
 hour!)  Thank you again for double-checking the patch.

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

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

Re: [Django] #16438: class Meta spacing in django.contrib.admin Code Guidelines

[Django]

#16438: class Meta spacing in django.contrib.admin Code Guidelines
-+-
   Reporter: |  Owner:  nobody
  philipkimmey   | Status:  new
   Type: |  Component:  contrib.admin
  Cleanup/optimization   |   Severity:  Normal
  Milestone: |   Keywords:
Version:  1.3|  Has patch:  1
 Resolution: |Needs tests:  0
   Triage Stage: |  Easy pickings:  1
  Unreviewed |
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by BernhardEssl):

 * needs_better_patch:   => 0
 * type:  Uncategorized => Cleanup/optimization
 * component:  Uncategorized => contrib.admin
 * 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.

[Django] #16438: class Meta spacing in django.contrib.admin Code Guidelines

[Django]

#16438: class Meta spacing in django.contrib.admin Code Guidelines
---+---
 Reporter:  philipkimmey   |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Milestone: |  Component:  Uncategorized
  Version:  1.3|   Severity:  Normal
 Keywords: |   Triage Stage:  Unreviewed
Has patch:  1  |  Easy pickings:  1
UI/UX:  0  |
---+---
 This is trivial almost to the point of being pedantic, but the class Meta
 should be separated from the field declarations by a blank line.

 I've attached a patch.

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

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

Re: [Django] #16437: Outdated comment

[Django]

#16437: Outdated comment
-+-
   Reporter:  jonash |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |  Component:  Testing framework
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:  minor
 Resolution: |  Has patch:  0
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  1
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by aaugustin):

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


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

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

[Django] #16437: Outdated comment

[Django]

#16437: Outdated comment
--+---
 Reporter:  jonash|  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Milestone:|  Component:  Testing framework
  Version:  1.3   |   Severity:  Normal
 Keywords:  minor |   Triage Stage:  Unreviewed
Has patch:  0 |  Easy pickings:  0
UI/UX:  0 |
--+---
 
https://code.djangoproject.com/browser/django/trunk/django/test/testcases.py#L547
 I guess that's from Python 2.4 times.

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

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

Re: [Django] #12794: Interaction between sessions and django.views.i18n.set_language causes caching errors

[Django]

#12794: Interaction between sessions and django.views.i18n.set_language causes
caching errors
-+-
   Reporter: |  Owner:  nobody
  alessandro.gudio+bugzilla@…| Status:  new
   Type:  Bug|  Component:
  Milestone: |  Internationalization
Version:  1.1|   Severity:  Normal
 Resolution: |   Keywords:  cache i18n
   Triage Stage:  Accepted   |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
Changes (by pennersr):

 * has_patch:  0 => 1
 * ui_ux:   => 0


Comment:

 I have attached a patch that stops Django from storing the language in the
 session.

 A decision is needed on whether support for storing the language in the
 session is to be completely dropped, or whether it is to be made
 configurable via settings. For now, the old behaviour has been put below
 an "if False:" so that it can be easily reinstantiated.

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

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

Re: [Django] #16088: Multi-database tests fail in ContentType

[Django]

#16088: Multi-database tests fail in ContentType
-+-
   Reporter:  def@…  |  Owner:  nobody
   Type:  Bug| Status:  closed
  Milestone: |  Component:  Database layer
Version:  1.2|  (models, ORM)
 Resolution:  needsinfo  |   Severity:  Normal
   Triage Stage: |   Keywords:  ContentType
  Unreviewed |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
Changes (by aaugustin):

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


Comment:

 If someone can provide a way to reproduce this on 1.3, please reopen the
 ticket.

 Only critical fixes are backported to the 1.2 branch, and this problem is
 certainly not critical.

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

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

Re: [Django] #16418: Class based generic DetailView tries to access non-existant _meta field when get_object has been modified to return a ModelForm

[Django]

#16418: Class based generic DetailView tries to access non-existant _meta field
when get_object has been modified to return a ModelForm
-+-
   Reporter:  kd4ttc |  Owner:  kd4ttc
   Type:  Bug| Status:  new
  Milestone: |  Component:  Generic views
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:  genericviews
   Triage Stage:  Accepted   |  modelform
Needs documentation:  0  |  Has patch:  0
Patch needs improvement:  0  |Needs tests:  0
  UI/UX:  0  |  Easy pickings:  0
-+-
Changes (by aaugustin):

 * stage:  Unreviewed => Accepted


Comment:

 Based on the evidence provided in the original report, I'd say this
 attempt to check if `self.object` is a model is incorrect:
 {{{
 if hasattr(self.object, '_meta'):
 }}}
 It should be replaced by something along these lines:
 {{{
 from django.db import models
 if isinstance(self.object, models.Model)
 }}}

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

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

[noreply]

Author: ramiro
Date: 2011-07-08 07:22:36 -0700 (Fri, 08 Jul 2011)
New Revision: 16527

Modified:
   django/trunk/tests/regressiontests/admin_views/fixtures/admin-views-books.xml
Log:
Fixed typos in admin_views tests XML fixtures.

Modified: 
django/trunk/tests/regressiontests/admin_views/fixtures/admin-views-books.xml
===
--- 
django/trunk/tests/regressiontests/admin_views/fixtures/admin-views-books.xml   
2011-07-08 12:07:54 UTC (rev 16526)
+++ 
django/trunk/tests/regressiontests/admin_views/fixtures/admin-views-books.xml   
2011-07-08 14:22:36 UTC (rev 16527)
@@ -8,38 +8,38 @@
   
   
 Promo 1
-1
+1
   
   
 Promo 2
-2
+2
   
   
 Chapter 1
 [ insert contents here ]
-1
+1
   
   
 Chapter 2
 [ insert contents here ]
-1
+1
   
   
 Chapter 1
 [ insert contents here ]
-2
+2
   
   
 Chapter 2
 [ insert contents here ]
-2
+2
   
   
 ChapterXtra1 1
-1
+1
   
   
 ChapterXtra1 2
-3
+3
   
 

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

Re: [Django] #16367: Exceptions thrown by middleware.process_response don't get to middleware.process_exception

[Django]

#16367: Exceptions thrown by middleware.process_response don't get to
middleware.process_exception
-+-
   Reporter:  bob84123   |  Owner:  nobody
   Type:  New| Status:  new
  feature|  Component:  Core (Other)
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:
 Resolution: |  Has patch:  1
   Triage Stage:  Design |Needs tests:  1
  decision needed|  Easy pickings:  0
Needs documentation:  1  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by aaugustin):

 * needs_better_patch:   => 0
 * component:  HTTP handling => Core (Other)
 * needs_tests:   => 1
 * needs_docs:   => 1
 * type:  Bug => New feature
 * stage:  Unreviewed => Design decision needed


Comment:

 Exception middleware currently works as advertised.

 https://docs.djangoproject.com/en/dev/topics/http/middleware/#process-
 exception:
 > Django calls process_exception() when a view raises an exception.

 You're proposing to change its behavior, so that it will also be called if
 an exception happens in a middleware. This requires a decision by a core
 developer.

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

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

Re: [Django] #16374: ExceptionReporter may re-evaluate error-causing queryset, leading to a later DatabaseError that masks the original one

[Django]

#16374: ExceptionReporter may re-evaluate error-causing queryset, leading to a
later DatabaseError that masks the original one
-+-
   Reporter:  aaron  |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Core (Other)
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:  ExceptionReporter
   Triage Stage:  Accepted   |  DatabaseError current transaction
Needs documentation:  0  |  aborted error queryset
Patch needs improvement:  0  |  Has patch:  0
  UI/UX:  0  |Needs tests:  0
 |  Easy pickings:  0
-+-

Comment (by lukeplant):

 For the DB-level switch, it should throw some exception. The hard part is
 find the right point to do it.

 So I think for now, your 'safe_repr' idea is the best one. Perhaps even
 `__safe_repr__`, to avoid accidental conflicts, and to make it obviously
 similar to `__repr__`. The exception handling will call this method,
 perhaps via a new `saferepr` function that encapsulates the checking for
 `__safe_repr__` attribute. We can avoid isinstance checks entirely this
 way.

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

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

Re: [Django] #8892: ForeignKey relation not saved as expected

[Django]

#8892: ForeignKey relation not saved as expected
-+-
   Reporter:  julien |  Owner:  blacklwhite
   Type:  Bug| Status:  reopened
  Milestone: |  Component:  Database layer
Version:  1.0|  (models, ORM)
 Resolution: |   Severity:  Normal
   Triage Stage:  Accepted   |   Keywords:
Needs documentation:  0  |  Has patch:  1
Patch needs improvement:  1  |Needs tests:  1
  UI/UX:  0  |  Easy pickings:  0
-+-
Changes (by lukeplant):

 * needs_better_patch:  0 => 1


Comment:

 @blacklwhite:

 Thanks for having a go at this. I think this patch is the wrong approach,
 however. It is unnecessarily complicated, and changes the semantics of
 saving an object in some significant ways, by adding a new point where the
 object's fields are set from the related object.

 We want a smaller fix, which only changes existing behaviour for the case
 when a developer has made a mistake - as in the example above. We already
 have checking at the point of assignment, such as checking that the object
 is of the right type, which is in `SingleRelatedObjectDescriptor`, and
 that's where the new check should be made. It should be a two liner.

 Of course, this also needs tests.

 On a point of style, you should use % interpolation for building up
 strings.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email 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  |
  UI/UX:  0  |
-+-
Changes (by bkonkle):

 * cc: brandon.konkle@… (added)
 * ui_ux:   => 0


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

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

Re: [Django] #12890: extra() tables included twice do not generate aliases

[Django]

#12890: extra() tables included twice do not generate aliases
-+-
   Reporter:  semenov|  Owner:  daveycrockett
   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:  1
Patch needs improvement:  0  |Needs tests:  1
  UI/UX:  0  |  Easy pickings:  0
-+-
Changes (by anonymous):

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


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

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

Re: [Django] #12890: extra() tables included twice do not generate aliases

[Django]

#12890: extra() tables included twice do not generate aliases
-+-
   Reporter:  semenov|  Owner:  daveycrockett
   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:  1  |Needs tests:  1
  UI/UX:  0  |  Easy pickings:  0
-+-
Changes (by anonymous):

 * has_patch:  1 => 0


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

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

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

[Django]

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

Comment (by jsdalton):

 Okay, made some additional changes tonight:

 * Added support for PostgreSQL and Oracle. With these additions, all
 backends support a check_constraints() method to verify foreign keys. Note
 that Oracle *has not* been tested because I don't have it. Also note that
 simply doing SET CONSTRAINTS ALL IMMEDIATE for postrgresql caused some
 issues. Mainly, I think these were due to the fact that we catch errors
 and continue our business running tests. So I added a finally block to
 ensure that the constraint check gets reset back to deferred after we're
 done checking it.
 * I also reworked the API. Since 1.4 supports Python 2.5 and up we can
 safely use context managers, and this API makes a ton more sense as a
 context manager. In particular, it does a much better job of ensuring
 constraint checks are re-enabled if an exception occurs while they are
 turned off. I also reworked a few other areas and streamlined others so
 that everything works together more seamlessly across all backends.

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

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

Re: [Django] #16433: Missing 'help_text' in admin form when showing the back reference for a OneToOne field.

[Django]

#16433: Missing 'help_text' in admin form when showing the back reference for a
OneToOne field.
+---
   Reporter:  chris@…   |  Owner:  nobody
   Type:  Bug   | Status:  new
  Milestone:|  Component:  contrib.admin
Version:  SVN   |   Severity:  Normal
 Resolution:|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+---
Changes (by aaugustin):

 * 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] #16436: `annotate()` + `select_related()` + `only()` = `ValueError: invalid literal for int() with base 10`

[Django]

#16436: `annotate()` + `select_related()` + `only()` = `ValueError: invalid 
literal
for int() with base 10`
-+-
   Reporter:  mrmachine  |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone:  1.4|  Component:  ORM aggregation
Version:  SVN|   Severity:  Normal
 Resolution: |   Keywords:  annotate
   Triage Stage:  Accepted   |  select_related only defer
Needs documentation:  0  |  ValueError empty list
Patch needs improvement:  1  |  Has patch:  1
  UI/UX:  0  |Needs tests:  0
 |  Easy pickings:  0
-+-
Changes (by aaugustin):

 * stage:  Unreviewed => Accepted


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

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

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

[noreply]

Author: lukeplant
Date: 2011-07-08 05:07:54 -0700 (Fri, 08 Jul 2011)
New Revision: 16526

Modified:
   django/trunk/django/http/__init__.py
   django/trunk/tests/regressiontests/httpwrappers/tests.py
Log:
Fixed bug with our SimpleCookie regarding load/custom Morsel, and simplified 
implementation

Modified: django/trunk/django/http/__init__.py
===
--- django/trunk/django/http/__init__.py2011-07-08 09:39:56 UTC (rev 
16525)
+++ django/trunk/django/http/__init__.py2011-07-08 12:07:54 UTC (rev 
16526)
@@ -54,18 +54,10 @@
 if "httponly" in self:
 output += "; httponly"
 return output
+else:
+Morsel = Cookie.Morsel
 
 class SimpleCookie(Cookie.SimpleCookie):
-if not _morsel_supports_httponly:
-def __set(self, key, real_value, coded_value):
-M = self.get(key, Morsel())
-M.set(key, real_value, coded_value)
-dict.__setitem__(self, key, M)
-
-def __setitem__(self, key, value):
-rval, cval = self.value_encode(value)
-self.__set(key, rval, cval)
-
 if not _cookie_encodes_correctly:
 def value_encode(self, val):
 # Some browsers do not support quoted-string from RFC 2109,
@@ -91,19 +83,20 @@
 
 return val, encoded
 
-if not _cookie_allows_colon_in_names:
+if not _cookie_allows_colon_in_names or not _morsel_supports_httponly:
 def load(self, rawdata):
 self.bad_cookies = set()
 super(SimpleCookie, self).load(rawdata)
 for key in self.bad_cookies:
 del self[key]
 
-_strict_set = Cookie.BaseCookie._BaseCookie__set
-
 # override private __set() method:
+# (needed for using our Morsel, and for laxness with CookieError
 def _BaseCookie__set(self, key, real_value, coded_value):
 try:
-self._strict_set(key, real_value, coded_value)
+M = self.get(key, Morsel())
+M.set(key, real_value, coded_value)
+dict.__setitem__(self, key, M)
 except Cookie.CookieError:
 self.bad_cookies.add(key)
 dict.__setitem__(self, key, Cookie.Morsel())

Modified: django/trunk/tests/regressiontests/httpwrappers/tests.py
===
--- django/trunk/tests/regressiontests/httpwrappers/tests.py2011-07-08 
09:39:56 UTC (rev 16525)
+++ django/trunk/tests/regressiontests/httpwrappers/tests.py2011-07-08 
12:07:54 UTC (rev 16526)
@@ -291,3 +291,13 @@
 Test that a repeated non-standard name doesn't affect all cookies. 
Ticket #15852
 """
 self.assertTrue('good_cookie' in parse_cookie('a,=b; a,=c; 
good_cookie=yes').keys())
+
+def test_httponly_after_load(self):
+"""
+Test that we can use httponly attribute on cookies that we load
+"""
+c = SimpleCookie()
+c.load("name=val")
+c['name']['httponly'] = True
+self.assertTrue(c['name']['httponly'])
+

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

Re: [Django] #8892: ForeignKey relation not saved as expected

[Django]

#8892: ForeignKey relation not saved as expected
-+-
   Reporter:  julien |  Owner:  blacklwhite
   Type:  Bug| Status:  reopened
  Milestone: |  Component:  Database layer
Version:  1.0|  (models, ORM)
 Resolution: |   Severity:  Normal
   Triage Stage:  Accepted   |   Keywords:
Needs documentation:  0  |  Has patch:  1
Patch needs improvement:  0  |Needs tests:  1
  UI/UX:  0  |  Easy pickings:  0
-+-

Comment (by blacklwhite):

 Sorry, I misinterpreted the guideline chart.

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

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

Re: [Django] #16436: `annotate()` + `select_related()` + `only()` = `ValueError: invalid literal for int() with base 10`

[Django]

#16436: `annotate()` + `select_related()` + `only()` = `ValueError: invalid 
literal
for int() with base 10`
-+-
   Reporter:  mrmachine  |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone:  1.4|  Component:  ORM aggregation
Version:  SVN|   Severity:  Normal
 Resolution: |   Keywords:  annotate
   Triage Stage: |  select_related only defer
  Unreviewed |  ValueError empty list
Needs documentation:  0  |  Has patch:  1
Patch needs improvement:  1  |Needs tests:  0
  UI/UX:  0  |  Easy pickings:  0
-+-
Changes (by mrmachine):

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

[Django] #16436: `annotate()` + `select_related()` + `only()` = `ValueError: invalid literal for int() with base 10`

[Django]

#16436: `annotate()` + `select_related()` + `only()` = `ValueError: invalid 
literal
for int() with base 10`
-+-
 Reporter:  mrmachine|  Owner:  nobody
 Type:  Bug  | Status:  new
Milestone:  1.4  |  Component:  ORM
  Version:  SVN  |  aggregation
 Keywords:  annotate select_related only defer   |   Severity:  Normal
  ValueError empty list  |   Triage Stage:
Has patch:  0|  Unreviewed
UI/UX:  0|  Easy pickings:  0
-+-
 With some combinations of models and arguments to `annotate()`,
 `select_related()` and `only()`, I get `ValueError: invalid literal for
 int() with base 10`.

 I think that
 
[https://code.djangoproject.com/browser/django/trunk/django/db/models/sql/compiler.py#L720
 SQLCompiler.results_iter()] is not taking the deferred fields into account
 when calculating the `aggregate_start` offset.

 To create a test, I started with a large number of models each with a
 large number of fields, taken from an app that we have in production, and
 pared it down by trial and error to as simple a form as I could and still
 reproduce the error.

 As I did this (choosing models and fields to remove at random) the
 behaviour changed from raising a `ValueError`, to yielding no items when
 consuming the queryset (but with `.count()` still returning a positive
 number), to apparently working as expected.

 This is probably related to (or the same issue) that was reported in the
 comments of #11890.

 I had a crack at calculating the correct `aggregate_start` by looking at
 the `deferred_loading` attribute and the `q.get_loaded_field_names()`
 method on the `Query` object, but didn't have any luck.

 I've put the test in it's own module,
 `defer_annotate_select_related_only`, just because it seems like such an
 obscure edge-case and I didn't want the other models and tests in
 `defer_regress` to have any influence.

 Hopefully if someone can figure out how and why this is happening, we can
 integrate a more concise test into `defer_regress`.

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

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

Re: [Django] #16350: Small admin CSS issue: messagelist items should be capitalized to work well in other languages

[Django]

#16350: Small admin CSS issue: messagelist items should be capitalized to work 
well
in other languages
-+-
   Reporter:  semente|  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  contrib.admin
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:  css, admin, pt-br
   Triage Stage:  Design |  Has patch:  1
  decision needed|Needs tests:  0
Needs documentation:  0  |  Easy pickings:  1
Patch needs improvement:  0  |
  UI/UX:  1  |
-+-

Comment (by BernhardEssl):

 Sorry, but I don't think that's a real problem. Why not use in your model
 the Meta class with ''verbose_name''?

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

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

[Changeset] r16525 - django/trunk/django/contrib/staticfiles/management/commands

[noreply]

Author: Alex
Date: 2011-07-08 02:39:56 -0700 (Fri, 08 Jul 2011)
New Revision: 16525

Modified:
   django/trunk/django/contrib/staticfiles/management/commands/collectstatic.py
Log:
Explicitly close a file in the collectstatic management command.

Modified: 
django/trunk/django/contrib/staticfiles/management/commands/collectstatic.py
===
--- 
django/trunk/django/contrib/staticfiles/management/commands/collectstatic.py
2011-07-08 00:39:59 UTC (rev 16524)
+++ 
django/trunk/django/contrib/staticfiles/management/commands/collectstatic.py
2011-07-08 09:39:56 UTC (rev 16525)
@@ -1,3 +1,5 @@
+from __future__ import with_statement
+
 import os
 import sys
 from optparse import make_option
@@ -9,6 +11,7 @@
 
 from django.contrib.staticfiles import finders
 
+
 class Command(NoArgsCommand):
 """
 Command that allows to copy or symlink media files from different
@@ -236,7 +239,7 @@
 os.makedirs(os.path.dirname(full_path))
 except OSError:
 pass
-source_file = source_storage.open(path)
-self.storage.save(prefixed_path, source_file)
+with source_storage.open(path) as source_file:
+self.storage.save(prefixed_path, source_file)
 if not prefixed_path in self.copied_files:
 self.copied_files.append(prefixed_path)

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

Re: [Django] #16431: Redirects ignore query strings should be made optional.

[Django]

#16431: Redirects ignore query strings should be made optional.
---+---
   Reporter:  cnobile  |  Owner:  nobody
   Type:  New feature  | Status:  closed
  Milestone:   |  Component:  contrib.redirects
Version:  1.3  |   Severity:  Normal
 Resolution:  worksforme   |   Keywords:
   Triage Stage:  Unreviewed   |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+---
Changes (by aaugustin):

 * status:  new => closed
 * needs_better_patch:   => 0
 * component:  Core (Other) => contrib.redirects
 * needs_tests:   => 0
 * needs_docs:   => 0
 * resolution:   => worksforme


Comment:

 Since the query string is included in the original URL (see #14153) when
 searching for a redirect, can't you just add the query string to the
 target URL?

 Please reopen if I missed something.

 #9966 is related.

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

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

Re: [Django] #16374: ExceptionReporter may re-evaluate error-causing queryset, leading to a later DatabaseError that masks the original one

[Django]

#16374: ExceptionReporter may re-evaluate error-causing queryset, leading to a
later DatabaseError that masks the original one
-+-
   Reporter:  aaron  |  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Core (Other)
Version:  1.3|   Severity:  Normal
 Resolution: |   Keywords:  ExceptionReporter
   Triage Stage:  Accepted   |  DatabaseError current transaction
Needs documentation:  0  |  aborted error queryset
Patch needs improvement:  0  |  Has patch:  0
  UI/UX:  0  |Needs tests:  0
 |  Easy pickings:  0
-+-

Comment (by aaron):

 What about adding a method to {{{QuerySet}}}?  Something like
 {{{QuerySet.safe_repr()}}}, which acts the way I described above, and then
 we can do an {{{isinstance}}} check and call that method instead of
 pprint.  That way if this issue comes up in other places there will be a
 clear way to fix it, and anyone modifying {{{QuerySet}}} will be aware
 that this use case exists.

 Monkey patching always has the issue that it's hard to notice when
 changing the original code.

 For the DB don't-do-anything mode idea, what would the behaviour be?
 Return empty results, or raise an exception?  Raising a special exception
 would be nice, perhaps, because the template code could catch it and
 display a clear message.

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

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

Re: [Django] #16432: MultipleObjectMixin should handle pagination prior to get_context_data

[Django]

#16432: MultipleObjectMixin should handle pagination prior to get_context_data
-+-
   Reporter: |  Owner:  nobody
  AndrewIngram   | Status:  new
   Type:  New|  Component:  Generic views
  feature|   Severity:  Normal
  Milestone: |   Keywords:
Version:  1.3|  Has patch:  0
 Resolution: |Needs tests:  0
   Triage Stage:  Design |  Easy pickings:  0
  decision needed|
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by aaugustin):

 * needs_better_patch:   => 0
 * needs_docs:   => 0
 * needs_tests:   => 0
 * 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] #16371: model fieldname as css class in admin edit view

[Django]

#16371: model fieldname as css class in admin edit view
-+-
   Reporter: |  Owner:  nobody
  thomasbilk | Status:  new
   Type:  Bug|  Component:  contrib.admin
  Milestone: |   Severity:  Normal
Version:  1.3|   Keywords:  css class admin
 Resolution: |  Has patch:  1
   Triage Stage:  Design |Needs tests:  0
  decision needed|  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  1  |
  UI/UX:  0  |
-+-

Comment (by thomasbilk):

 I have attached a screenshot showing the problem. I have a field on my
 model
 named `button` and there is a css class in the admin that conflicts with
 that
 so that the field row in the admin gets styled like a button.

 [[Image(class-button.jpg)]]


 I would suggest to add an option for prefixing this css class so that this
 fix
 will not break anything:

 {{{
 class SomeModelAdmin(admin.ModelAdmin):
 css_prefix = 'form-row-field-'
 }}}

 Unfortunately I could not figure out how to accomplish that, hence the
 noob patch.

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

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

Re: [Django] #16435: Configurable hidden settings in debug mode

[Django]

#16435: Configurable hidden settings in debug mode
-+-
   Reporter: |  Owner:  nobody
  munderwood@…   | Status:  new
   Type:  New|  Component:  Core (Other)
  feature|   Severity:  Normal
  Milestone: |   Keywords:  settings.py
Version:  1.3|  Has patch:  0
 Resolution: |Needs tests:  0
   Triage Stage:  Design |  Easy pickings:  0
  decision needed|
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-

Comment (by anonymous):

 I think something along those lines would be appropriate

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

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

Re: [Django] #16434: doc patch "widgets.extras" => "extras.widgets"

[Django]

#16434: doc patch "widgets.extras" => "extras.widgets"
-+-
   Reporter:  rfk|  Owner:  nobody
   Type:  Bug| Status:  new
  Milestone: |  Component:  Documentation
Version:  SVN|   Severity:  Normal
 Resolution: |   Keywords:
   Triage Stage:  Ready for  |  Has patch:  1
  checkin|Needs tests:  0
Needs documentation:  0  |  Easy pickings:  1
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by aaugustin):

 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * easy:  0 => 1
 * needs_docs:   => 0
 * type:  Uncategorized => Bug
 * stage:  Unreviewed => Ready for checkin


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

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

Re: [Django] #16435: Configurable hidden settings in debug mode

[Django]

#16435: Configurable hidden settings in debug mode
-+-
   Reporter: |  Owner:  nobody
  munderwood@…   | Status:  new
   Type:  New|  Component:  Core (Other)
  feature|   Severity:  Normal
  Milestone: |   Keywords:  settings.py
Version:  1.3|  Has patch:  0
 Resolution: |Needs tests:  0
   Triage Stage:  Design |  Easy pickings:  0
  decision needed|
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
Changes (by julien):

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


Comment:

 This is currently controlled by the `HIDDEN_SETTINGS` variable in
 source:django/trunk/django/views/debug.py#L18 as described in
 https://docs.djangoproject.com/en/dev/ref/settings/#debug and introduced
 in [1242].

 However, there is no easy way for the developer to override this value.
 Perhaps a new global settings should be added.

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

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