Re: [Django] #15619: Logout link should be protected

[Django]

#15619: Logout link should be protected
--+--
 Reporter:  void  |Owner:  ashchristopher
 Type:  Bug   |   Status:  assigned
Component:  contrib.auth  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+--

Comment (by collinanderson):

 https://groups.google.com/d/topic/django-developers/MmFzCq8oB5I/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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/062.47ed3a32f3c21c287dce62f7b0f81578%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23822: Serialize model managers in migrations

[Django]

#23822: Serialize model managers in migrations
-+
 Reporter:  MarkusH  |Owner:  MarkusH
 Type:  New feature  |   Status:  new
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by MarkusH):

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


Comment:

 I finally had some time to write some docs and tests. Here's the pull
 request: https://github.com/django/django/pull/3687

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.37db4e45a389f9620cf0ee5c38d3dd30%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23943: Audit tests decorated with unittest.expectedFailure

[Django]

#23943: Audit tests decorated with unittest.expectedFailure
--+
 Reporter:  timgraham |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Core (Other)  |  Version:  master
 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 diegoguimaraes):

 * cc: diegaogs@… (added)


Comment:

 While crossing references on those tests with the @expectedFailure
 decorator, this one seems that do not passes the audit
 `tests/generic_views/test_edit.py`:
 {{{
 @expectedFailure
 def test_update_put(self):
 a = Author.objects.create(
 name='Randall Munroe',
 slug='randall-munroe',
 )
 res = self.client.get('/edit/author/%d/update/' % a.pk)
 self.assertEqual(res.status_code, 200)
 self.assertTemplateUsed(res, 'generic_views/author_form.html')

 res = self.client.put('/edit/author/%d/update/' % a.pk,
 {'name': 'Randall Munroe (author of xkcd)',
 'slug': 'randall-munroe'})
 # Here is the expected failure. PUT data are not processed in any
 special
 # way by django. So the request will equal to a POST without data,
 hence
 # the form will be invalid and redisplayed with errors (status
 code 200).
 # See also #12635
 self.assertEqual(res.status_code, 302)
 self.assertRedirects(res, 'http://testserver/list/authors/')
 self.assertQuerysetEqual(Author.objects.all(), [''])

 }}}
 This test is related to ticket #12635 marked as wontfix, and according to
 the last comment on that, Using PUT and DELETE as HTTP methods for the
 form element is no longer supported (http://www.w3.org/TR/2010/WD-
 html5-diff-20101019/#changes-2010-06-24).

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.efbc8f0d7a3d5f65aae30d96fb57e2e2%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23960: HTTP standard no longer requires the Location header to be an absolute URI

[Django]

#23960: HTTP standard no longer requires the Location header to be an absolute 
URI
-+-
 Reporter:  carljm   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.7
Component:  HTTP handling|   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by carljm):

 If we were going to continue to provide support for this in Django, it
 seems like a built-in middleware would make more sense than a dedicated
 setting.

 But are there really good enough reasons to be doing this server-side that
 there needs to be built-in support in Django?

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.b84d18338333d860540ac459af2b7f51%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23960: HTTP standard no longer requires the Location header to be an absolute URI

[Django]

#23960: HTTP standard no longer requires the Location header to be an absolute 
URI
-+-
 Reporter:  carljm   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  1.7
Component:  HTTP handling|   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by timgraham):

 This was discussed on IRC I think, and Matt Robenolt
 [https://github.com/mattrobenolt/django/compare/relative drafted a patch]
 using a setting to control the behavior -- not sure the justification for
 doing that over just dropping it as you've proposed.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.49bf71eae5be647f5ca5678d7d05a463%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #23960: HTTP standard no longer requires the Location header to be an absolute URI

[Django]

#23960: HTTP standard no longer requires the Location header to be an absolute 
URI
+
   Reporter:  carljm|  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  HTTP handling |Version:  1.7
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 RFC 2616 required the `Location` header (in redirect responses) to be an
 absolute URI. In Django, we have `django.http.utils.fix_location_header()`
 to unconditionally ensure this.

 RFC 2616 has now been superseded by RFC 7231, which allows relative URIs
 in `Location` (recognizing the actual practice of user agents, almost all
 of which support them): http://tools.ietf.org/html/rfc7231#section-7.1.2

 We should remove `django.http.utils.fix_location_header()`.

 Since user agents almost universally allow relative `Location` (I'm not
 aware of any that don't), I don't believe this change requires a
 deprecation path, but it should of course be noted in the release notes.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/049.b572df4dc2584ec88ee257fd85a23358%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #10414: select_related ignores unrecognized fields

[Django]

#10414: select_related ignores unrecognized fields
-+-
 Reporter:  trebor74hr   |Owner:  nip3o
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  select_related   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by nip3o):

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


Comment:

 The patch is updated with tests for the mentioned cases. I have never
 worked with generic relations previously, but I hope that I managed to
 implement the tests as intended 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.fc80ca41e9b19a9d46aeadb8a42db629%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23886: Accessing obsolete documentation page throws an exception

[Django]

#23886: Accessing obsolete documentation page throws an exception
-+-
 Reporter:  timgraham|Owner:
 Type:  Bug  |  olasitarska
Component:  *.djangoproject.com  |   Status:  closed
 Severity:  Normal   |  Version:
 Keywords:   |   Resolution:  fixed
Has patch:  1| Triage Stage:  Accepted
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by timgraham):

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


Comment:

 As I was reviewing the PR and code, I realized this is because the
 `docbuilds` directory on the server contains a checkout for 1.2, but the
 docs build doesn't work. After deleting that directory, the docs for 1.2
 404 as expected. The checkout won't be recreated because the
 `DocumentRelease` for 1.2 has been deleted. So I think we can resolve this
 without any code changes.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.2b824ed26088fe3071c19bd2ec94917d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23958: Rewrite filter tests as unit tests

[Django]

#23958: Rewrite filter tests as unit tests
--+
 Reporter:  prestontimmons|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Testing framework |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by prestontimmons):

 * needs_better_patch:  1 => 0


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/072.65a7f476aa3dd79182e33909f910d385%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23954: migrations doesnt create {text|varchar}_pattern_ops for postgres indexes

[Django]

#23954: migrations doesnt create {text|varchar}_pattern_ops for postgres indexes
-+-
 Reporter:  adityagupta104   |Owner:  claudep
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  1.7
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  postgres indexes | Triage Stage:  Accepted
  pattern_ops|  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by Claude Paroz ):

 In [changeset:"6ba960266a14756dbf6365029d46bd157bd2b155"]:
 {{{
 #!CommitTicketReference repository=""
 revision="6ba960266a14756dbf6365029d46bd157bd2b155"
 [1.7.x] Fixed #23954 -- Added special text/varchar PostgreSQL indexes in
 migrations

 Thanks adityagupta104 for the report and Tim Graham for the review.
 Backport of 8d7a48027e from master.
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/072.eaa8ac09ac1480453edb1091568b2140%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23954: migrations doesnt create {text|varchar}_pattern_ops for postgres indexes

[Django]

#23954: migrations doesnt create {text|varchar}_pattern_ops for postgres indexes
-+-
 Reporter:  adityagupta104   |Owner:  claudep
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  1.7
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  postgres indexes | Triage Stage:  Accepted
  pattern_ops|  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by Claude Paroz ):

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


Comment:

 In [changeset:"8d7a48027ef6848f693f57ae442a1b0ace0ebcdc"]:
 {{{
 #!CommitTicketReference repository=""
 revision="8d7a48027ef6848f693f57ae442a1b0ace0ebcdc"
 Fixed #23954 -- Added special text/varchar PostgreSQL indexes in
 migrations

 Thanks adityagupta104 for the report and Tim Graham for the review.
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/072.fab65932e4888315445b5cc862edfd4e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23957: Start a deprecation path toward requiring session verification

[Django]

#23957: Start a deprecation path toward requiring session verification
-+-
 Reporter:  timgraham|Owner:  timgraham
 Type:   |   Status:  assigned
  Cleanup/optimization   |  Version:  master
Component:  contrib.auth |   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 timgraham):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/3686 PR]

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.ef04fac3f5627505a86c412748461b81%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #5986: Easy way to customize ordering of fields on forms that use inheritance

[Django]

#5986: Easy way to customize ordering of fields on forms that use inheritance
-+-
 Reporter:  emes |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  field order weight   | Triage Stage:  Accepted
  form newforms  |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by tanner):

 I have revised my PR to make it fully backwards-compatible.

 The field_order attribute/argument is used to rearrange existing fields.

 If a key of an existing field is missing in the list, the field is
 appended to the fields in the original order.
 This way new fields in subclasses are just added (as before) if the
 subclass does not override field_order.

 If a key in field_order refers to a non-existing field, it is simply
 ignored.
 This make is possible to remove a field in a subclass by overriding it
 with None, without overriding field_order.
 Again, this won't break existing subclasses.

 If you do not define Form.field_order or set it None, the default order is
 kept.

 There are now three ways to set the field order:

 1. set the class variable as default for all instances

 2. pass field_order as argument when instantiating a Form, e.g., when
 calling the parent constructor

 3. use the order_fields() method to rearrange the field order of an
 instance, e.g., in a subclass constructor after some extra fields have
 been 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/062.fff24afc55d134f4e5bb7d6938e428a1%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23954: migrations doesnt create {text|varchar}_pattern_ops for postgres indexes

[Django]

#23954: migrations doesnt create {text|varchar}_pattern_ops for postgres indexes
-+-
 Reporter:  adityagupta104   |Owner:  claudep
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  1.7
 Severity:  Release blocker  |   Resolution:
 Keywords:  postgres indexes | Triage Stage:  Accepted
  pattern_ops|  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by claudep):

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


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/072.2de9febcd999a2d185ff4d7ef91aabab%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #18586: Rewrite unit tests migrated from doctests

[Django]

#18586: Rewrite unit tests migrated from doctests
-+-
 Reporter:  konk |Owner:
 Type:   |  ChillarAnand
  Cleanup/optimization   |   Status:  new
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  unit tests   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"7daf00679d2848fdb6f5618009817b56486fce1b"]:
 {{{
 #!CommitTicketReference repository=""
 revision="7daf00679d2848fdb6f5618009817b56486fce1b"
 Refs #18586 -- Split up order_with_respect_to tests
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.9cc581cde650751dd0d72b3ab0ca765c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23920: MySQL: migrate TextField() to TextField(blank=True) fails

[Django]

#23920: MySQL: migrate TextField() to TextField(blank=True) fails
-+-
 Reporter:  wkornewald   |Owner:  timgraham
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  1.7
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"d57124433f0d0f2bf61ea4e14962f3b663ab20c7"]:
 {{{
 #!CommitTicketReference repository=""
 revision="d57124433f0d0f2bf61ea4e14962f3b663ab20c7"
 [1.7.x] Fixed #23920 -- Fixed MySQL crash when adding blank=True to
 TextField.

 Thanks wkornewald for the report and Markus Holtermann for review.

 Backport of 765fa36d57d08d0568438f6fd74521e7a56abb61 from master
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.99601fb602dd18401ff7c78607cbb6a5%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23920: MySQL: migrate TextField() to TextField(blank=True) fails

[Django]

#23920: MySQL: migrate TextField() to TextField(blank=True) fails
-+-
 Reporter:  wkornewald   |Owner:  timgraham
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  1.7
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"765fa36d57d08d0568438f6fd74521e7a56abb61"]:
 {{{
 #!CommitTicketReference repository=""
 revision="765fa36d57d08d0568438f6fd74521e7a56abb61"
 Fixed #23920 -- Fixed MySQL crash when adding blank=True to TextField.

 Thanks wkornewald for the report and Markus Holtermann for review.
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.bb1df25bad1a82a582470da9a0a467c1%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23804: Add a RasterField to GeoDjango

[Django]

#23804: Add a RasterField to GeoDjango
-+-
 Reporter:  yellowcap|Owner:  yellowcap
 Type:  New feature  |   Status:  assigned
Component:  GIS  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  raster gdal  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by yellowcap):

 The RasterField is still very minimalistic, here are some thoughts of what
 is missing/could be improved:

 - Integration with different db backends. Currently the raster IO is
 tailored towrards PostGIS. The value passed to the db is the output of the
 `wkb` property of the GDALRaster, which converts between PostGIS WKB and
 GDALRaster. This seems to work in the test-databases. The db_type is fixed
 to `'raster'`, which is also PostGIS specific.

 - A deeper integration with the GeometryField would be beneficial. For
 instance the SRID property could be shared in a master class. But this is
 currently integrated into GeometryField directly. So integrating the two
 would probably require a GeoField master class or so.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.be891843eb54653564fe22071c30ca98%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23804: Add a RasterField to GeoDjango

[Django]

#23804: Add a RasterField to GeoDjango
-+-
 Reporter:  yellowcap|Owner:  yellowcap
 Type:  New feature  |   Status:  assigned
Component:  GIS  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  raster gdal  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by yellowcap):

 I branched off master and started integrating the raster files into the
 structure with the new driver. I followed your suggestions above. The new
 branch is this one:

 https://github.com/geodesign/django/tree/raster/django/contrib/gis/gdal

 - Moved all tests into gdal.tests folder
 - Separated constants from utils functions
 - Moved RasterField into `django.contrib.gis.db.models.fields` module

 Most of the changes are file-rearangements.

 The raster field can leverage some of the features around the
 GeometryFields, but here some of the code that can be re-used is named
 Geometry* for instance the GeometryProxy and the `geom_type` property.
 Both are related to lazy-instanciation of field target instances (Rasters
 or Geometries).

 See:

 
https://github.com/geodesign/django/blob/raster/django/contrib/gis/db/models/fields.py#L356
 
https://github.com/geodesign/django/blob/raster/django/contrib/gis/db/models/fields.py#L390

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.a847d47aefdc346de1f61e4510d16fbd%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23920: MySQL: migrate TextField() to TextField(blank=True) fails

[Django]

#23920: MySQL: migrate TextField() to TextField(blank=True) fails
-+-
 Reporter:  wkornewald   |Owner:  timgraham
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  1.7
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by MarkusH):

 * cc: info+coding@… (added)
 * 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.b6acb9a8010b108246d6018544bd82d9%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23435: GFK should be indexed

[Django]

#23435: GFK should be indexed
-+-
 Reporter:  aaugustin|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by charettes):

 The `('object_id_abstract', 'content_object_abstract')` index should only
 be added to `BasePerson` indexes and not `Person` ones.

 In this case you can solely rely on `opts.local_fields` to make sure both
 `ct_field` and `fk_field` are local in order to add the index.

 If one of the fields is not local (it belongs to a concrete parent) then
 the index shouldn't be created.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.97d187baa5b13fb8e52e3c5c1450d221%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #10405: quoted class names in foreign key definition causes 'str' object has no attribute '_default_manager'

[Django]

#10405: quoted class names in foreign key definition causes 'str' object has no
attribute '_default_manager'
-+-
 Reporter:  danbrwn  |Owner:  mitsuhiko
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:
  (models, ORM)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:   |  checkin
  foreign,key,quoted,dceu2011|  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by Gwildor):

 For anyone else who ran into this: for me this occurred because I had a
 form import in my main `urls.py` file, to pass a form to a built in view
 by Django. That `forms.py` file had a ModelForm and the model it was
 associated with had a foreign key using a string for the model (because of
 earlier import errors). This didn't happen on 1.4, but it occurred when I
 upgraded Django to 1.5.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.40ecfbd56b22d912fe853d3be169b5f1%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23954: migrations doesnt create {text|varchar}_pattern_ops for postgres indexes

[Django]

#23954: migrations doesnt create {text|varchar}_pattern_ops for postgres indexes
-+-
 Reporter:  adityagupta104   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.7
 Severity:  Release blocker  |   Resolution:
 Keywords:  postgres indexes | Triage Stage:  Accepted
  pattern_ops|  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by timgraham):

 Claude has done some work in moving more `DatabaseCreation` functionality
 to the schema editor in [https://github.com/django/django/pull/3220 PR
 3220]. I've asked if he might be able to create a patch that would be
 appropriate for backporting based on that work.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/072.dba635f30107a073eec2908ac5b43c0c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23920: MySQL: migrate TextField() to TextField(blank=True) fails

[Django]

#23920: MySQL: migrate TextField() to TextField(blank=True) fails
-+-
 Reporter:  wkornewald   |Owner:  timgraham
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  1.7
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/3683 PR]

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.1bec9e6b77867c79bc43641507041628%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23920: MySQL: migrate TextField() to TextField(blank=True) fails

[Django]

#23920: MySQL: migrate TextField() to TextField(blank=True) fails
-+-
 Reporter:  wkornewald   |Owner:  timgraham
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  1.7
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

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


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.21d7bc610ecf6068fa7392ec4e788cc1%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23857: "Save as new" breaks when related inlines are marked to be deleted

[Django]

#23857: "Save as new" breaks when related inlines are marked to be deleted
-+
 Reporter:  amarandon|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  1.7
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by timgraham):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/3682 PR]

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.13c5b8feb06e66b896a9a69d28f5d256%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23911: support buffers as file-upload in the test client

[Django]

#23911: support buffers as file-upload in the test client
-+-
 Reporter:  tanner   |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"018d110ef547acb71b0526d0ff934e1e476244e4"]:
 {{{
 #!CommitTicketReference repository=""
 revision="018d110ef547acb71b0526d0ff934e1e476244e4"
 Fixed #23911 -- Added support for buffer file uploads in the test client
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.fecfb717bd66ac296fa48ae3d767cf02%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23958: Rewrite filter tests as unit tests

[Django]

#23958: Rewrite filter tests as unit tests
--+
 Reporter:  prestontimmons|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Testing framework |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+
Changes (by timgraham):

 * needs_better_patch:  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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/072.e24b985352619e1f21dc9c9f9d186b70%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23911: support buffers as file-upload in the test client

[Django]

#23911: support buffers as file-upload in the test client
-+-
 Reporter:  tanner   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by timgraham):

 * 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.9b091a963dde874cd931d670b8c744ce%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23435: GFK should be indexed

[Django]

#23435: GFK should be indexed
-+-
 Reporter:  aaugustin|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  0|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by alexanderad):

 I've started looking at this ticket, and first tricky thing I caught
 (using {{{contrubute_to_class}}}) is following scenario (taken from
 model_meta tests):
 (in short: is there a simple way to distinguish abstract field from multi-
 table inherited?)
 {{{
 #!python
 class AbstractPerson(models.Model):
 ...
 # GFK fields
 content_type_abstract = models.ForeignKey(ContentType,
 related_name='+')
 object_id_abstract = models.PositiveIntegerField()
 content_object_abstract = GenericForeignKey('content_type_abstract',
 'object_id_abstract')

 class Meta:
 abstract = True
 }}}
 This one is easy, here we need:
 {{{
 index_together = (('object_id_abstract', 'content_object_abstract'),)
 }}}

 

 {{{
 #!python
 class BasePerson(AbstractPerson):
 ...
 # GFK fields
 content_type_base = models.ForeignKey(ContentType, related_name='+')
 object_id_base = models.PositiveIntegerField()
 content_object_base = GenericForeignKey('content_type_base',
 'object_id_base')
 }}}

 This one is easy too, at this point we need:
 {{{
 index_together = (
 ('object_id_abstract', 'content_object_abstract'),
 ('content_type_base', 'object_id_base')
 )
 }}}

 

 But then I stuck:
 {{{
 #!python
 class Person(BasePerson):
 ...
 # GFK fields
 content_type_concrete = models.ForeignKey(ContentType,
 related_name='+')
 object_id_concrete = models.PositiveIntegerField()
 content_object_concrete = GenericForeignKey('content_type_concrete',
 'object_id_concrete')
 }}}

 At this point in {{{contribute_to_class}}} we are going to add two more
 fields to index from {{{Person}}}, this is OK. But we have also inherited
 from {{{BasePerson}}} + abstract from {{{ AbstractPerson}}}. All those
 fields belong to {{{BasePerson}}}, but we need to take from there only
 abstract ones, so that for {{{Person}}} we have:
 {{{
 index_together = (
 ('object_id_abstract', 'content_object_abstract'),
 ('content_type_concrete', 'object_id_concrete')
 )
 }}}

 We can't add to index BasePerson fields since those live in different
 table. But we still need ones from AbstractPerson.
 Probably I'm terribly wrong, but for this case I can't see obvious way to
 tell which inherited fields came from Abstract model and which from Base
 one.

 {{{
 ipdb> cls
 
 ipdb> [x.name for x in cls._meta.local_fields]
 ['baseperson_ptr', 'data_inherited', 'fk_inherited',
 'data_not_concrete_inherited', 'content_type_concrete',
 'object_id_concrete']

 ipdb> [x.name for x in cls._meta.fields]
 ['id', 'data_abstract', 'fk_abstract', 'data_not_concrete_abstract',
 'content_type_abstract', 'object_id_abstract', 'data_base', 'fk_base',
 'data_not_concrete_base', 'content_type_base', 'object_id_base',
 'baseperson_ptr', 'data_inherited', 'fk_inherited',
 'data_not_concrete_inherited', 'content_type_concrete',
 'object_id_concrete']

 ipdb> cls._meta.get_field('object_id_base').model # << this one is from
 base, we need to omit it
 
 ipdb> cls._meta.get_field('object_id_abstract').model # <<< this one is
 from abstract, we need it
 
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.9bfc83cb2e7d7b990398773d24a67381%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #18586: Rewrite unit tests migrated from doctests

[Django]

#18586: Rewrite unit tests migrated from doctests
-+-
 Reporter:  konk |Owner:
 Type:   |  ChillarAnand
  Cleanup/optimization   |   Status:  new
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  unit tests   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by berkerpeksag):

 [https://github.com/django/django/pull/3638 PR #3638] LGTM. (I added a
 couple of minor comments on GitHub)

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.686c5060775f49170921dc45231c214f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23956: makemigrations creates broken initial migration for models with multiple inheritance

[Django]

#23956: makemigrations creates broken initial migration for models with multiple
inheritance
-+-
 Reporter:  gagarski |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:  migrations   | Triage Stage:
  inheritance|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by gagarski:

Old description:

> Hello.
> I am trying to create models that use multiple inheritance and then use
> django migrations mechanism to migrate. But I have some problems with it.
>
> I have created simplest example to reproduce.
>
>  = Steps to reproduce =
>
> 1. Create a `migrationstest` django app with following `models.py`:
>
> {{{
> from django.db import models
>

> class A(models.Model):
> a_id = models.AutoField(primary_key=True)
>

> class B(models.Model):
> b_id = models.AutoField(primary_key=True)
>

> class C(A, B):
> pass
>

> class D(A, B):
> pass
>

> class E(A, B):
> pass
>
> }}}
> 2. run './manage.py makemigrations migrationstest'
> 3. run './manage.py migrate migrationstest'
>
>  = Expected results =
>
> Fine migration
>
>  = Actual results =
> Exception is thrown while running 'migrate':
> {{{
> Traceback (most recent call last):
>   File "./manage.py", line 10, in 
> execute_from_command_line(sys.argv)
>   File "/home/gagarski/polyana-web/environment/lib/python3.4/site-
> packages/django/core/management/__init__.py", line 385, in
> execute_from_command_line
> utility.execute()
>   File "/home/gagarski/polyana-web/environment/lib/python3.4/site-
> packages/django/core/management/__init__.py", line 377, in execute
> self.fetch_command(subcommand).run_from_argv(self.argv)
>   File "/home/gagarski/polyana-web/environment/lib/python3.4/site-
> packages/django/core/management/base.py", line 288, in run_from_argv
> self.execute(*args, **options.__dict__)
>   File "/home/gagarski/polyana-web/environment/lib/python3.4/site-
> packages/django/core/management/base.py", line 338, in execute
> output = self.handle(*args, **options)
>   File "/home/gagarski/polyana-web/environment/lib/python3.4/site-
> packages/django/core/management/commands/migrate.py", line 160, in handle
> executor.migrate(targets, plan, fake=options.get("fake", False))
>   File "/home/gagarski/polyana-web/environment/lib/python3.4/site-
> packages/django/db/migrations/executor.py", line 63, in migrate
> self.apply_migration(migration, fake=fake)
>   File "/home/gagarski/polyana-web/environment/lib/python3.4/site-
> packages/django/db/migrations/executor.py", line 97, in apply_migration
> migration.apply(project_state, schema_editor)
>   File "/home/gagarski/polyana-web/environment/lib/python3.4/site-
> packages/django/db/migrations/migration.py", line 107, in apply
> operation.database_forwards(self.app_label, schema_editor,
> project_state, new_state)
>   File "/home/gagarski/polyana-web/environment/lib/python3.4/site-
> packages/django/db/migrations/operations/fields.py", line 37, in
> database_forwards
> field,
>   File "/home/gagarski/polyana-web/environment/lib/python3.4/site-
> packages/django/db/backends/schema.py", line 390, in add_field
> self.execute(sql, params)
>   File "/home/gagarski/polyana-web/environment/lib/python3.4/site-
> packages/django/db/backends/schema.py", line 99, in execute
> cursor.execute(sql, params)
>   File "/home/gagarski/polyana-web/environment/lib/python3.4/site-
> packages/django/db/backends/utils.py", line 81, in execute
> return super(CursorDebugWrapper, self).execute(sql, params)
>   File "/home/gagarski/polyana-web/environment/lib/python3.4/site-
> packages/django/db/backends/utils.py", line 65, in execute
> return self.cursor.execute(sql, params)
>   File "/home/gagarski/polyana-web/environment/lib/python3.4/site-
> packages/django/db/utils.py", line 94, in __exit__
> six.reraise(dj_exc_type, dj_exc_value, traceback)
>   File "/home/gagarski/polyana-web/environment/lib/python3.4/site-
> packages/django/utils/six.py", line 549, in reraise
> raise value.with_traceback(tb)
>   File "/home/gagarski/polyana-web/environment/lib/python3.4/site-
> packages/django/db/backends/utils.py", line 65, in execute
> return self.cursor.execute(sql, params)
> django.db.utils.ProgrammingError: column "b_ptr_id" of relation
> "migrationstest_d" already exists
> }}}
>
>  = More details =
>
> The generated initial migration:
> {{{
> # -*- coding: utf-8 -*-
> from 

Re: [Django] #23956: makemigrations creates broken initial migration for models with multiple inheritance

[Django]

#23956: makemigrations creates broken initial migration for models with multiple
inheritance
-+-
 Reporter:  gagarski |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:  migrations   | Triage Stage:
  inheritance|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Old description:

> Hello.
> I am trying to create models that use multiple inheritance and then use
> django migrations mechanism to migrate. But I have some problems with it.
>
> I have created simplest example to reproduce.
>
>  = Steps to reproduce =
>
> 1. Create a `migrationstest` django app with following `models.py`:
>
> {{{
> from django.db import models
>

> class A(models.Model):
> a_id = models.IntegerField(primary_key=True)
>

> class B(models.Model):
> b_id = models.IntegerField(primary_key=True)
>

> class C(A, B):
> pass
>

> class D(A, B):
> pass
>

> class E(A, B):
> pass
>
> }}}
> 2. run './manage.py makemigrations migrationstest'
> 3. run './manage.py migrate migrationstest'
>
>  = Expected results =
>
> Fine migration
>
>  = Actual results =
> Exception is thrown while running 'migrate':
> {{{
> Traceback (most recent call last):
>   File "./manage.py", line 10, in 
> execute_from_command_line(sys.argv)
>   File "/home/gagarski/polyana-web/environment/lib/python3.4/site-
> packages/django/core/management/__init__.py", line 385, in
> execute_from_command_line
> utility.execute()
>   File "/home/gagarski/polyana-web/environment/lib/python3.4/site-
> packages/django/core/management/__init__.py", line 377, in execute
> self.fetch_command(subcommand).run_from_argv(self.argv)
>   File "/home/gagarski/polyana-web/environment/lib/python3.4/site-
> packages/django/core/management/base.py", line 288, in run_from_argv
> self.execute(*args, **options.__dict__)
>   File "/home/gagarski/polyana-web/environment/lib/python3.4/site-
> packages/django/core/management/base.py", line 338, in execute
> output = self.handle(*args, **options)
>   File "/home/gagarski/polyana-web/environment/lib/python3.4/site-
> packages/django/core/management/commands/migrate.py", line 160, in handle
> executor.migrate(targets, plan, fake=options.get("fake", False))
>   File "/home/gagarski/polyana-web/environment/lib/python3.4/site-
> packages/django/db/migrations/executor.py", line 63, in migrate
> self.apply_migration(migration, fake=fake)
>   File "/home/gagarski/polyana-web/environment/lib/python3.4/site-
> packages/django/db/migrations/executor.py", line 97, in apply_migration
> migration.apply(project_state, schema_editor)
>   File "/home/gagarski/polyana-web/environment/lib/python3.4/site-
> packages/django/db/migrations/migration.py", line 107, in apply
> operation.database_forwards(self.app_label, schema_editor,
> project_state, new_state)
>   File "/home/gagarski/polyana-web/environment/lib/python3.4/site-
> packages/django/db/migrations/operations/fields.py", line 37, in
> database_forwards
> field,
>   File "/home/gagarski/polyana-web/environment/lib/python3.4/site-
> packages/django/db/backends/schema.py", line 390, in add_field
> self.execute(sql, params)
>   File "/home/gagarski/polyana-web/environment/lib/python3.4/site-
> packages/django/db/backends/schema.py", line 99, in execute
> cursor.execute(sql, params)
>   File "/home/gagarski/polyana-web/environment/lib/python3.4/site-
> packages/django/db/backends/utils.py", line 81, in execute
> return super(CursorDebugWrapper, self).execute(sql, params)
>   File "/home/gagarski/polyana-web/environment/lib/python3.4/site-
> packages/django/db/backends/utils.py", line 65, in execute
> return self.cursor.execute(sql, params)
>   File "/home/gagarski/polyana-web/environment/lib/python3.4/site-
> packages/django/db/utils.py", line 94, in __exit__
> six.reraise(dj_exc_type, dj_exc_value, traceback)
>   File "/home/gagarski/polyana-web/environment/lib/python3.4/site-
> packages/django/utils/six.py", line 549, in reraise
> raise value.with_traceback(tb)
>   File "/home/gagarski/polyana-web/environment/lib/python3.4/site-
> packages/django/db/backends/utils.py", line 65, in execute
> return self.cursor.execute(sql, params)
> django.db.utils.ProgrammingError: column "b_ptr_id" of relation
> "migrationstest_d" already exists
> }}}
>
>  = More details =
>
> The generated initial migration:
> {{{
> # -*- coding: utf-8 -*-
> from __future__ import 

Re: [Django] #23911: support buffers as file-upload in the test client

[Django]

#23911: support buffers as file-upload in the test client
---+
 Reporter:  tanner |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Testing framework  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by tanner):

 * needs_better_patch:  1 => 0


Comment:

 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 unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.d4e9c3f935ddb6e4a1b560b5d13f6c4d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #23959: Systems checks run when DEBUG is False

[Django]

#23959: Systems checks run when DEBUG is False
--+
 Reporter:  IanLewis  |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Core (System checks)  |Version:  1.7
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 The System check framework documentation
 (https://docs.djangoproject.com/en/1.7/topics/checks/) states the
 following:

 "For performance reasons, the checks are not performed if DEBUG is set to
 False."

 However, checks seem to be run anyway and I get warning messages even when
 DEBUG is False. I also could not find any code in Django 1.7.2 that checks
 the DEBUG flag.

 Is this intended behavior? If so then the documentation is incorrect. If
 not, then the system check framework needs to be modified to check the
 DEBUG flag.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/051.5174c6774a3e066f8c5d78238f568235%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.