Re: [Django] #11776: HTML class for non-field errors

[Django]

#11776: HTML class for non-field errors
-+-
 Reporter:  Daniel Pope   |Owner:
 Type:  New feature  |  NickPresta
Component:  Forms|   Status:  assigned
 Severity:  Normal   |  Version:  1.1
 Keywords:   |   Resolution:
Has patch:  0| Triage Stage:  Accepted
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by NickPresta):

 Initial attempt at https://github.com/NickPresta/django/pull/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 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/095.ef2801279c98e8c0b80ecc94eec16eab%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #11776: HTML class for non-field errors

[Django]

#11776: HTML class for non-field errors
-+-
 Reporter:  Daniel Pope   |Owner:
 Type:  New feature  |  NickPresta
Component:  Forms|   Status:  assigned
 Severity:  Normal   |  Version:  1.1
 Keywords:   |   Resolution:
Has patch:  0| Triage Stage:  Accepted
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by NickPresta):

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


-- 
Ticket URL: 
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/095.994033c24b56cc255f6802ff9082db9d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22438: Slow INNER JOIN in MySQL can be fixed in Django ORM, but should it?

[Django]

#22438: Slow INNER JOIN in MySQL can be fixed in Django ORM, but should it?
-+-
 Reporter:  frol |Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:  mysql, orm, slow |  Unreviewed
  query, join|  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by frol):

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


Comment:

 I've tried completely replace INNER JOIN with STRAIGHT_JOIN and run tests.
 There were some fails, but only because those tests tried to search 'INNER
 JOIN' string in queries. Execution time of testing without changes was 561
 and after I changed INNER JOIN to STRAIGHT_JOIN, overall execution time
 was 574. It might be just random fluctuation, but also a regression.

 Thus I'm going to create separate project on github with 'enchanced' MySQL
 backend and ask people to try 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/062.f5ce2dc12fecbf4e4fd40992b2b8783f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #14030: Use F() objects in aggregates(), annotates() and values()

[Django]

#14030: Use F() objects in aggregates(), annotates() and values()
-+-
 Reporter:  delfick  |Owner:  smeatonj
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:  aggregate, annotate  |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by smeatonj):

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


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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.60f31d421d122f8aa3778c790a40fee7%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22440: Incorrect Behavior of ConditionalGetMiddleware

[Django]

#22440: Incorrect Behavior of ConditionalGetMiddleware
---+--
 Reporter:  mlavin |Owner:  mlavin
 Type:  Uncategorized  |   Status:  new
Component:  HTTP handling  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by mlavin):

 * has_patch:  0 => 1


Comment:

 Added PR https://github.com/django/django/pull/2555

-- 
Ticket URL: 
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.70c3926c646fd418065a9dcd313c805f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22395: Deleting a model and fields that relate to it results in ValueError: Related model '.' cannot be resolved

[Django]

#22395: Deleting a model and fields that relate to it results in ValueError:
Related model '.' cannot be resolved
+--
 Reporter:  melinath|Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  1.7-beta-1
 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
+--

Comment (by melinath):

 I'm technically running 1.7.X, not the 1.7b1 tag. So it could be a newly-
 introduced bug. I'll test.

 The project I'm using is https://github.com/littleweaver/django-brambling
 - but I never committed the broken version. Worked around by deleting,
 then recreating the broken fields (since we're still in alpha and hadn't
 put any data in there yet.)

 I'll pull the latest 1.7.X and see if it's been fixed.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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.452ccd5502b8e5205391e02379bf50ce%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22397: Issues removing M2M field with explicit through model

[Django]

#22397: Issues removing M2M field with explicit through model
-+
 Reporter:  melinath |Owner:  andrewsg
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  master
 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
-+

Comment (by melinath):

 So to clarify, you'll make sure that the M2M fields get removed first, not
 that the migration fails to compute?

-- 
Ticket URL: 
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.190c8547f1503d21f84d5c87bc8eb2d6%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22261: Wrong Permalink for flatpages

[Django]

#22261: Wrong Permalink for flatpages
---+
 Reporter:  allo@… |Owner:  edanm
 Type:  Bug|   Status:  assigned
Component:  contrib.flatpages  |  Version:  1.6
 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 edanm):

 * has_patch:  0 => 1


Comment:

 I just sent a pull request for a fix for this:
 https://github.com/django/django/pull/2554

 This solves all the cases I can think of for including flatpages and
 running get_absolute_url() on them.

 By the way, not sure if this is relevant, but:
 When I was writing the tests for this, I noticed that all the flatpages
 tests include the flatpages url without a slash, e.g.:
 url(r'^flatpage_root', include('django.contrib.flatpages.urls')), (Note
 lack of '/' after flatpage_root).

 This is different than how the documentation recommends including the
 flatpages, and doesn't make much sense. Not sure what the purpose of this
 is.

-- 
Ticket URL: 
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/070.828aae0eadc0033cad2fadc7c0f795c1%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:  judy2k
 Type:  Cleanup/optimization  |   Status:  assigned
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
--+
Description changed by julien:

Old description:

> There's quite a lot of unit tests that have been rewritten 1:1 from
> doctests. These tests tend to verify all aspects of a certain feature at
> once, they modify the state of the database throughout the whole test and
> by the end of the test no one really knows what the database state is
> supposed to be.
>
> For example,
> `modeltests.generic_relations.GenericRelationsTests.test_generic_relations`
> walks through most of the features supported by `GenericForeignKeys`, it
> is 130 lines long and in case the last assertion fails, you'll have to
> spend ridiculous amounts of time figuring out what happened.
>
> A likely incomplete list of similar tests:[[BR]]
> `modeltests.basic.ModelTest.test_lookup`[[BR]]
> `modeltests.basic.ModelTest.test_object_creation`[[BR]]
> ~~modeltests.custom_columns.CustomColumnsTests.test_db_column~~[[BR]]
> `modeltests.custom_managers.CustomManagerTests.test_manager`[[BR]]
> `modeltests.custom_pk.CustomPKTests.test_custom_pk`[[BR]]
> `modeltests.defer.DeferTests.test_defer`[[BR]]
> `modeltests.expressions.ExpressionsTests.test_filter`[[BR]]
> `modeltests.field_subclassing.CustomField.test_custom_field`[[BR]]
> `modeltests.files.FileStorageTests.test_files`[[BR]]
> `modeltests.get_or_create.GetOrCreateTests.test_get_or_create`[[BR]]
> ~~modeltests.m2m_recursive.RecursiveM2MTests.test_recursive_m2m~~[[BR]]
> `modeltests.m2m_signals.ManyToManySignalsTest`[[BR]]
> `modeltests.m2m_through.M2mThroughTests`[[BR]]
> `modeltests.model_formsets.ModelFormsetTests`[[BR]]
> `modeltests.model_forms.OldFormForXTests.test_with_data` (This one has
> more than 500 lines!)[[BR]]
> `modeltests.model_inheritance.ModelInheritanceTests`[[BR]]
> `modeltests.model_package.ModelPackageTests.test_model_packages`[[BR]]
> `modeltests.order_with_respect_to.OrderWithRespectToTests.test_basic`[[BR]]
> `modeltests.signals.SignalTests.test_basic`
>
> I only went through modeltests/*/tests.py; I might have overlooked a few
> tests.
>
> This ticket is meant to track all of them; each time a test is updated,
> we can strike it out in the list above and once there is no item left, we
> can close this. The point is to make the test suite help developers as
> much as possible.

New description:

 There's quite a lot of unit tests that have been rewritten 1:1 from
 doctests. These tests tend to verify all aspects of a certain feature at
 once, they modify the state of the database throughout the whole test and
 by the end of the test no one really knows what the database state is
 supposed to be.

 For example,
 `modeltests.generic_relations.GenericRelationsTests.test_generic_relations`
 walks through most of the features supported by `GenericForeignKeys`, it
 is 130 lines long and in case the last assertion fails, you'll have to
 spend ridiculous amounts of time figuring out what happened.

 A likely incomplete list of similar tests:[[BR]]
 `modeltests.basic.ModelTest.test_lookup`[[BR]]
 `modeltests.basic.ModelTest.test_object_creation`[[BR]]
 ~~modeltests.custom_columns.CustomColumnsTests.test_db_column~~[[BR]]
 `modeltests.custom_managers.CustomManagerTests.test_manager`[[BR]]
 `modeltests.custom_pk.CustomPKTests.test_custom_pk`[[BR]]
 `modeltests.defer.DeferTests.test_defer`[[BR]]
 `modeltests.expressions.ExpressionsTests.test_filter`[[BR]]
 `modeltests.field_subclassing.CustomField.test_custom_field`[[BR]]
 `modeltests.files.FileStorageTests.test_files`[[BR]]
 ~~modeltests.get_or_create.GetOrCreateTests.test_get_or_create~~[[BR]]
 ~~modeltests.m2m_recursive.RecursiveM2MTests.test_recursive_m2m~~[[BR]]
 `modeltests.m2m_signals.ManyToManySignalsTest`[[BR]]
 `modeltests.m2m_through.M2mThroughTests`[[BR]]
 `modeltests.model_formsets.ModelFormsetTests`[[BR]]
 `modeltests.model_forms.OldFormForXTests.test_with_data` (This one has
 more than 500 lines!)[[BR]]
 `modeltests.model_inheritance.ModelInheritanceTests`[[BR]]
 `modeltests.model_package.ModelPackageTests.test_model_packages`[[BR]]
 `modeltests.order_with_respect_to.OrderWithRespectToTests.test_basic`[[BR]]
 `modeltests.signals.SignalTests.test_basic`

 I only went through modeltests/*/tests.py; I might have overlooked a few
 tests.

 This ticket is 

Re: [Django] #22353: CachedStaticFilesMixin lags in updating hashed names of other static files referenced in CSS

[Django]

#22353: CachedStaticFilesMixin lags in updating hashed names of other static 
files
referenced in CSS
-+-
 Reporter:  woodlee  |Owner:  frog32
 Type:  Bug  |   Status:  assigned
Component:  contrib.staticfiles  |  Version:  1.6
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
Has patch:  0|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by frog32):

 * easy:  1 => 0


Comment:

 I am removing the easy pickings because there are more complex problems
 involved in this ticket. We need to make sure that in this case the image
 is always post-processed before the css file that is referring to it. This
 also applies to css files including other css files.

-- 
Ticket URL: 
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.8e381fdd3647a51386ab684339588a4f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[django/django] 9b29a5: Refs #18586 - Refactored model get_or_create test.

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 9b29a551e4a6a2bc50ade95b0ccce1d3633f85da
  
https://github.com/django/django/commit/9b29a551e4a6a2bc50ade95b0ccce1d3633f85da
  Author: Liav Koren 
  Date:   2014-04-14 (Mon, 14 Apr 2014)

  Changed paths:
M tests/get_or_create/tests.py

  Log Message:
  ---
  Refs #18586 - Refactored model get_or_create test.

Refactored get_or_create test into several smaller test functions across two
different test classes. Also converted the comments over to docstrings.


  Commit: 401be8a2062c359f7acea6b0ace30e96b8f30574
  
https://github.com/django/django/commit/401be8a2062c359f7acea6b0ace30e96b8f30574
  Author: Julien Phalip 
  Date:   2014-04-14 (Mon, 14 Apr 2014)

  Changed paths:
M tests/get_or_create/tests.py

  Log Message:
  ---
  Merge pull request #2553 from liavkoren-vmfarms/ticket_18586

Ticket 18586


Compare: https://github.com/django/django/compare/0bcc92c69177...401be8a2062c

-- 
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/534c5fc625f19_214f1463d4470610%40hookshot-fe2-cp1-prd.iad.github.net.mail.
For more options, visit https://groups.google.com/d/optout.

[django/django] a195ec: [1.7.x] Improve migrations/schema docs

[GitHub]

  Branch: refs/heads/stable/1.7.x
  Home:   https://github.com/django/django
  Commit: a195ec847e44e8ec6f688dfed55b37eb8ec144cf
  
https://github.com/django/django/commit/a195ec847e44e8ec6f688dfed55b37eb8ec144cf
  Author: Andrew Godwin 
  Date:   2014-04-14 (Mon, 14 Apr 2014)

  Changed paths:
M docs/ref/django-admin.txt
M docs/ref/migration-operations.txt
M docs/ref/schema-editor.txt
M docs/topics/migrations.txt

  Log Message:
  ---
  [1.7.x] Improve migrations/schema docs


-- 
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/534c5cc9b33a2_12e4fcfd3c937c7%40hookshot-fe2-cp1-prd.iad.github.net.mail.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22353: CachedStaticFilesMixin lags in updating hashed names of other static files referenced in CSS

[Django]

#22353: CachedStaticFilesMixin lags in updating hashed names of other static 
files
referenced in CSS
-+-
 Reporter:  woodlee  |Owner:  frog32
 Type:  Bug  |   Status:  assigned
Component:  contrib.staticfiles  |  Version:  1.6
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
Has patch:  0|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  1|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by frog32):

 * owner:  nobody => frog32
 * needs_better_patch:   => 0
 * status:  new => assigned
 * 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 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.920cd40cd9f60718e9fb737bc9535d45%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22436: migrations fail on custom upload_to on ImageField

[Django]

#22436: migrations fail on custom upload_to on ImageField
-+-
 Reporter:  David Binetti|Owner:
     |  chriscauley
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:
 Severity:  Normal   |  1.7-beta-1
 Keywords:   |   Resolution:
Has patch:  0| Triage Stage:  Accepted
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by chriscauley):

 The migration sterilizer previously was using the `__name__` of the
 function and the module, which is not the full import path if the function
 is a method of a class.

 {{{
 ...
 else:
 module = value.__module__
 return"%s.%s" % (module, six.get_qualname(value)),
 set(["import %s" % module])
 # formerly
 # return"%s.%s" % (module, value.__name__), set(["import
 %s" % module])
 }}}

 `six.get_qualname(func)` is a new function that returns
 `func.__qualname__` for python 3.X and fakes it for 2.X (sort of). It
 relies on `func.im_class`, which isn't always available in python 2.X:

 {{{
 def upload1(instance,self):
 return 'photos/{0}/dropbox{1}'.format(instance.account.id, filename)
 class NotAModel:
 def upload2(instance,self):
 return 'photos/{0}/dropbox{1}'.format(instance.account.id,
 filename)
 class Subclass:
 def upload3(instance,self):
 return 'photos/{0}/dropbox{1}'.format(instance.account.id,
 filename)

 class MyModel(models.Model):
 def upload4(instance,self):
 return 'photos/{0}/dropbox{1}'.format(instance.account.id,
 filename)
 photo_1 = models.ImageField(upload_to=upload1)
 photo_2 = models.ImageField(upload_to=NotAModel.upload2)
 photo_3 = models.ImageField(upload_to=NotAModel.Subclass.upload3)
 photo_4 = models.ImageField(upload_to=upload4)
 }}}

 Here `photo_1` and `photo_2` will work in Python 2 and 3 (with the
 modifications on the branch mentioned below). `photo_3` can't be
 serialized in 2.X because there's no way to access `NotAModel` from
 `Subclass`. `photo_4` can't be serialized because `upload_to` is passed in
 the unbound function `upload4` which doesn't have the attribute
 `im_class`.

 But this all kind of unnecessary because migrations don't actually need
 `upload_to`. Additionally, if you rename `upload_to` it will cause past
 migrations to break. The best way out I can see is to set the
 `upload_to="IN_MIGRATIONS"` in the migrations file and modify the
 FileField to ignore upload_to when in migrations. If anyone is interested,
 here is a link to the changes listed above and `six.get_qualname`:

 
https://github.com/chriscauley/django/commit/2a6f27451f9cfe2f76f92a8806b2939dc46ce2a5

-- 
Ticket URL: 
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/092.1f18dd674bf1909c7baca84ce8c0deaa%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22229: Invalid data can cause InlineFormSet.is_valid to throw ValueError

[Django]

#9: Invalid data can cause InlineFormSet.is_valid to throw ValueError
---+-
 Reporter:  anonymous  |Owner:  jrothenbuhler
 Type:  Bug|   Status:  assigned
Component:  Forms  |  Version:  1.6
 Severity:  Normal |   Resolution:
 Keywords:  InlineFormSet  | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+-
Changes (by jrothenbuhler):

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


-- 
Ticket URL: 
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.74319241593352712c834d5a2affced3%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22414: Persistent connections not closed by LiveServerTestCase, preventing dropping test databases

[Django]

#22414: Persistent connections not closed by LiveServerTestCase, preventing
dropping test databases
---+
 Reporter:  Koterpillar|Owner:
 Type:  Bug|   Status:  new
Component:  Testing framework  |  Version:  1.6
 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 jrothenbuhler):

 * owner:  jrothenbuhler =>
 * status:  assigned => new


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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/069.5677ecbd5a4715bf6fed8d9252405edc%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #18773: Enable optional logging of invalid variable lookups

[Django]

#18773: Enable optional logging of invalid variable lookups
-+-
 Reporter:  wrigley  |Owner:
 Type:  New feature  |  CarolineSimpson
Component:  Template system  |   Status:  assigned
 Severity:  Normal   |  Version:  1.4
 Keywords:   |   Resolution:
Has patch:  1| Triage Stage:  Accepted
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by CarolineSimpson):

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


Comment:

 I've submitted a pull request for this issue:
 https://github.com/django/django/pull/2552

 Added a new logger, and log when there is an exception in the resolve
 function.  The logger uses the null handler by default.

-- 
Ticket URL: 
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.92b0eb148f10b95b490fd0ced4ef9393%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #18763: Shortcut to get users by permission

[Django]

#18763: Shortcut to get users by permission
--+
 Reporter:  shelldweller  |Owner:  Osmose
 Type:  New feature   |   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:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Osmose):

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


Comment:

 Added a pull request for this issue:
 https://github.com/django/django/pull/2551

-- 
Ticket URL: 
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/070.043e11658e15bb50baa5817c698a64f0%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22235: pip can install from tarballs as well

[Django]

#22235: pip can install from tarballs as well
--+
 Reporter:  omer.drow@…   |Owner:  gregloy
 Type:  Cleanup/optimization  |   Status:  closed
Component:  *.djangoproject.com   |  Version:
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  1 |UI/UX:  0
--+
Changes (by gregloy):

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


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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/077.cd72a1603879cfd3074c78a10c4e4f45%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22356: unique_together fails when referencing columns from base and child class

[Django]

#22356: unique_together fails when referencing columns from base and child class
-+-
 Reporter:  claus|Owner:  frog32
 Type:  Bug  |   Status:  closed
Component:  Core (System |  Version:
  checks)|  1.7-beta-1
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  1|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by Simon Charette ):

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


Comment:

 In [changeset:"0bcc92c6917738caa2f08ec16d26fad62974fb47"]:
 {{{
 #!CommitTicketReference repository=""
 revision="0bcc92c6917738caa2f08ec16d26fad62974fb47"
 Fixed #22356 -- Added a check to make sure unique_together fields are
 local.
 }}}

-- 
Ticket URL: 
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/063.86fe8210fc8119d326b230a9301cefeb%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[django/django] 0bcc92: Fixed #22356 -- Added a check to make sure unique_...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 0bcc92c6917738caa2f08ec16d26fad62974fb47
  
https://github.com/django/django/commit/0bcc92c6917738caa2f08ec16d26fad62974fb47
  Author: Marc Egli 
  Date:   2014-04-14 (Mon, 14 Apr 2014)

  Changed paths:
M django/db/models/base.py
M docs/ref/checks.txt
M tests/invalid_models_tests/test_models.py

  Log Message:
  ---
  Fixed #22356 -- Added a check to make sure unique_together fields are local.


-- 
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/534c4eb131662_69db827d3c6851f%40hookshot-fe1-cp1-prd.iad.github.net.mail.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22439: LiveServerTestCase handles error messages inconsistently

[Django]

#22439: LiveServerTestCase handles error messages inconsistently
--+
 Reporter:  jmbowman  |Owner:  jmbowman
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Testing framework |  Version:  1.6
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  1
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by julien):

 * needs_docs:  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/066.3229f9de981a56218b58936823b86f6d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22436: migrations fail on custom upload_to on ImageField

[Django]

#22436: migrations fail on custom upload_to on ImageField
-+-
 Reporter:  David Binetti|Owner:
     |  chriscauley
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:
 Severity:  Normal   |  1.7-beta-1
 Keywords:   |   Resolution:
Has patch:  0| Triage Stage:  Accepted
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-

Comment (by chriscauley):

 Your specific problem can be easily fixed by moving the upload_thumb
 method outside of the Photo class. Unless call Photo.upload_thumb anywhere
 there's no difference between the two. There's nothing wrong with how you
 did it before, but there's no way to implement migrations with as you had
 it (except manually typing qualname for Photo.upload_to like you did).
 I'll expand on this in a second comment, but for now here's your solution.

 {{{
 def upload_thumb(instance, filename):
 return 'photos/{0}/dropbox{1}'.format(instance.account.id, filename)

 class Photo(models.Model):

 account = models.ForeignKey(Account)

 ...

 thumbnail = models.ImageField(upload_to=upload_thumb, null=True)
 }}}

-- 
Ticket URL: 
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/092.151880ea243255843e1a85f2b3881786%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22414: Persistent connections not closed by LiveServerTestCase, preventing dropping test databases

[Django]

#22414: Persistent connections not closed by LiveServerTestCase, preventing
dropping test databases
-+-
 Reporter:  Koterpillar  |Owner:
 Type:  Bug  |  jrothenbuhler
Component:  Testing framework|   Status:  assigned
 Severity:  Normal   |  Version:  1.6
 Keywords:   |   Resolution:
Has patch:  1| Triage Stage:  Accepted
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by jrothenbuhler):

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


-- 
Ticket URL: 
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/069.01abadc359079c3a3409342be4320aae%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22440: Incorrect Behavior of ConditionalGetMiddleware

[Django]

#22440: Incorrect Behavior of ConditionalGetMiddleware
---+--
 Reporter:  mlavin |Owner:  mlavin
 Type:  Uncategorized  |   Status:  new
Component:  HTTP handling  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by mlavin):

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


Comment:

 Same check for the status code is needed for the If-Modified-Since:

 > If the request would normally result in anything other than a 200 (OK)
 status, or if the passed If-Modified-Since date is invalid, the response
 is exactly the same as for a normal GET. A date which is later than the
 server's current time is invalid.

-- 
Ticket URL: 
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.cf7996ca07ab4a615df17d8b0927fffc%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22439: LiveServerTestCase handles error messages inconsistently

[Django]

#22439: LiveServerTestCase handles error messages inconsistently
-+-
 Reporter:  jmbowman |Owner:  jmbowman
 Type:   |   Status:  assigned
  Cleanup/optimization   |  Version:  1.6
Component:  Testing framework|   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by jmbowman):

 * has_patch:  0 => 1


Comment:

 Proposed fix is in https://github.com/jmbowman/django/tree/ticket_22439
 (now looking into possible unit tests for 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/066.bb88fc591b5ebf3791bfa42e4415fe2b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #22440: Incorrect Behavior of ConditionalGetMiddleware

[Django]

#22440: Incorrect Behavior of ConditionalGetMiddleware
---+
 Reporter:  mlavin |  Owner:  mlavin
 Type:  Uncategorized  | Status:  new
Component:  HTTP handling  |Version:  master
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 There is an edge case where the {{{ConditionalGetMiddleware}}} violates
 RFC 2616 in particular
 http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.26

 > If the request would, without the If-None-Match header field, result in
 anything other than a 2xx or 304 status, then the If-None-Match header
 MUST be ignored.

 The middleware currently does not check the original response status code
 before the If-None-Match. This is correctly handled by the
 {{{CommmonMiddleware}}} which has a similar check. This was pointed out in
 #12789 which tried to fix/address a related but seperate problem with how
 the ETag is actually generated. #17834 currently tracks problems with the
 generation of the ETag and this issue only tracks the problem with
 {{{ConditionalGetMiddleware}}} using the ETag however it may have been
 generated

-- 
Ticket URL: 
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.eba8a52c1e2f64686400fd12563ee600%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22434: Ordering is cleared in Subqueries with limits

[Django]

#22434: Ordering is cleared in Subqueries with limits
-+-
 Reporter:  maciej.pawlisz@… |Owner:
 Type:  Bug  |  justhamade
Component:  Database layer   |   Status:  assigned
  (models, ORM)  |  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 charettes):

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


Comment:

 Left comments on the 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/083.5ba8cca5c469efff2aab981a11746ae3%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:  judy2k
 Type:  Cleanup/optimization  |   Status:  assigned
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 bsilverberg):

 I am going to start working on modeltests.basic.ModelTest.test_lookup

-- 
Ticket URL: 
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.ac1b4970e4af6068266b12bfb86c63cf%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22439: LiveServerTestCase handles error messages inconsistently

[Django]

#22439: LiveServerTestCase handles error messages inconsistently
-+-
 Reporter:  jmbowman |Owner:  jmbowman
 Type:   |   Status:  assigned
  Cleanup/optimization   |  Version:  1.6
Component:  Testing framework|   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
-+-
Changes (by jmbowman):

 * status:  new => assigned
 * needs_better_patch:   => 0
 * owner:  nobody => jmbowman
 * 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 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.5935713741ae40c42ec099ab062a2e0b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #22439: LiveServerTestCase handles error messages inconsistently

[Django]

#22439: LiveServerTestCase handles error messages inconsistently
--+
 Reporter:  jmbowman  |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Testing framework |Version:  1.6
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 There are a few different ways that messages can be output when running
 LiveServerTestCase, and they aren't currently handled consistently:

 * Messages that are created via the logging module are handled normally
 with the exception of console output, which is typically captured by the
 test runner and shown only for failures.  This is usually what is desired.

 * Request status messages are normally sent to stdout by Django's
 WSGIRequestHandler, but QuietWSGIRequestHandler doesn't output them at all
 to avoid interfering with the test runner output.  This makes the
 information unavailable when debugging test failures.

 * PEP 333 (WSGI) suggests sending error messages to the wsgi.errors
 stream, which even for QuietWSGIRequestHandler is currently stderr.  These
 can interfere with the test runner output.

 * Some less serious errors instead get sent to
 socketserver.BaseServer.handle_error() (inherited by WSGIServer), which
 since at least Python 2.7 has sent different parts of the output directly
 to stdout and stderr (there's a comment in the CPython source pointing out
 that this is less than ideal).  Errors like "[Errno 32] Broken pipe"
 (which sometimes happens when a browser cancels a request before it
 finishes) can end up here and really clutter the test output.

 None of this should go to stderr or stdout when running a
 LiveServerTestCase, and most (maybe all) of it should be available via the
 configured logging handlers (probably via the "django.request" logger).

-- 
Ticket URL: 
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.93c54c8b4665dcd5fbbfe3336c96c715%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22434: Ordering is cleared in Subqueries with limits

[Django]

#22434: Ordering is cleared in Subqueries with limits
-+-
 Reporter:  maciej.pawlisz@… |Owner:
 Type:  Bug  |  justhamade
Component:  Database layer   |   Status:  assigned
  (models, ORM)  |  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 justhamade):

 * version:  1.6 => master
 * stage:  Unreviewed => Accepted


Comment:

 Wrote test and fix in pull request
 https://github.com/django/django/pull/2550

-- 
Ticket URL: 
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/083.1e55fa4ab4aedd9f78b107dd0ca3c8bc%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22342: Changing a model to an abstract model caused "ValueError: Related model 'app.Model' cannot be resolved"

[Django]

#22342: Changing a model to an abstract model caused "ValueError: Related model
'app.Model' cannot be resolved"
+--
 Reporter:  blueyed |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  Migrations  |  Version:  master
 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 bmispelon):

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


Comment:

 Hi,

 I can't seem to be able to reproduce this.

 I've tried creating a (non-abstract) model, running `makemigrations` and
 `migrate`, then changing the model to have `abstract=True` and running
 `makemigrations` and `migrate` again.

 When I do that, I don't get the error you mention.

 Could you provide us with the models you used (or better yet, a simplified
 version that still reproduces the issue)?

 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 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.e39fa604b068b5ea6b969c7eec054188%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[django/django] 17c188: Fixed #22369 -- Added count parameter to assertTem...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 17c18844561431aabed89c3bd48de951db7d13ab
  
https://github.com/django/django/commit/17c18844561431aabed89c3bd48de951db7d13ab
  Author: Jacob R. Rothenbuhler 
  Date:   2014-04-14 (Mon, 14 Apr 2014)

  Changed paths:
M django/test/testcases.py
M docs/releases/1.8.txt
M docs/topics/testing/tools.txt
M tests/test_client_regress/tests.py
M tests/test_client_regress/urls.py
M tests/test_client_regress/views.py

  Log Message:
  ---
  Fixed #22369 -- Added count parameter to assertTemplateUsed


-- 
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/534c3d649f01a_10c7a85d40635f6%40hookshot-fe2-cp1-prd.iad.github.net.mail.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22369: Add ability to assert number of times a template is used for assertTemplateUsed

[Django]

#22369: Add ability to assert number of times a template is used for
assertTemplateUsed
-+-
 Reporter:  anonymous|Owner:
 Type:  New feature  |  jrothenbuhler
Component:  Testing framework|   Status:  closed
 Severity:  Normal   |  Version:  master
 Keywords:  assert, testing  |   Resolution:  fixed
Has patch:  1| Triage Stage:  Accepted
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  1
 |UI/UX:  0
-+-
Changes (by Simon Charette ):

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


Comment:

 In [changeset:"17c18844561431aabed89c3bd48de951db7d13ab"]:
 {{{
 #!CommitTicketReference repository=""
 revision="17c18844561431aabed89c3bd48de951db7d13ab"
 Fixed #22369 -- Added count parameter to assertTemplateUsed
 }}}

-- 
Ticket URL: 
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.6b867102c3ebbbfc735455bffaf54e58%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22261: Wrong Permalink for flatpages

[Django]

#22261: Wrong Permalink for flatpages
---+
 Reporter:  allo@… |Owner:  edanm
 Type:  Bug|   Status:  assigned
Component:  contrib.flatpages  |  Version:  1.6
 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 edanm):

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


-- 
Ticket URL: 
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/070.16487000449013f2d259a63bf537e213%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:  judy2k
 Type:  Cleanup/optimization  |   Status:  assigned
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 Liav3000):

 Hi. I just created https://github.com/liavkoren-
 vmfarms/djangoDev/tree/ticket_18586 which refactors
 modeltests.get_or_create.GetOrCreateTests.test_get_or_create into smaller
 units and changes comments over to docstrings. I'd be happy to continue
 crunching through the tests in this ticket if everything is okay with that
 first set of changes.

 Thanks, Liav.

-- 
Ticket URL: 
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.5f927a44192b78b6aeb6283ea336aaec%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:  judy2k
 Type:  Cleanup/optimization  |   Status:  assigned
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
--+
Description changed by julien:

Old description:

> There's quite a lot of unit tests that have been rewritten 1:1 from
> doctests. These tests tend to verify all aspects of a certain feature at
> once, they modify the state of the database throughout the whole test and
> by the end of the test no one really knows what the database state is
> supposed to be.
>
> For example,
> `modeltests.generic_relations.GenericRelationsTests.test_generic_relations`
> walks through most of the features supported by `GenericForeignKeys`, it
> is 130 lines long and in case the last assertion fails, you'll have to
> spend ridiculous amounts of time figuring out what happened.
>
> A likely incomplete list of similar tests:[[BR]]
> `modeltests.basic.ModelTest.test_lookup`[[BR]]
> `modeltests.basic.ModelTest.test_object_creation`[[BR]]
> ~~modeltests.custom_columns.CustomColumnsTests.test_db_column~~[[BR]]
> `modeltests.custom_managers.CustomManagerTests.test_manager`[[BR]]
> `modeltests.custom_pk.CustomPKTests.test_custom_pk`[[BR]]
> `modeltests.defer.DeferTests.test_defer`[[BR]]
> `modeltests.expressions.ExpressionsTests.test_filter`[[BR]]
> `modeltests.field_subclassing.CustomField.test_custom_field`[[BR]]
> `modeltests.files.FileStorageTests.test_files`[[BR]]
> `modeltests.get_or_create.GetOrCreateTests.test_get_or_create`[[BR]]
> `modeltests.m2m_recursive.RecursiveM2MTests.test_recursive_m2m`[[BR]]
> `modeltests.m2m_signals.ManyToManySignalsTest`[[BR]]
> `modeltests.m2m_through.M2mThroughTests`[[BR]]
> `modeltests.model_formsets.ModelFormsetTests`[[BR]]
> `modeltests.model_forms.OldFormForXTests.test_with_data` (This one has
> more than 500 lines!)[[BR]]
> `modeltests.model_inheritance.ModelInheritanceTests`[[BR]]
> `modeltests.model_package.ModelPackageTests.test_model_packages`[[BR]]
> `modeltests.order_with_respect_to.OrderWithRespectToTests.test_basic`[[BR]]
> `modeltests.signals.SignalTests.test_basic`
>
> I only went through modeltests/*/tests.py; I might have overlooked a few
> tests.
>
> This ticket is meant to track all of them; each time a test is updated,
> we can strike it out in the list above and once there is no item left, we
> can close this. The point is to make the test suite help developers as
> much as possible.

New description:

 There's quite a lot of unit tests that have been rewritten 1:1 from
 doctests. These tests tend to verify all aspects of a certain feature at
 once, they modify the state of the database throughout the whole test and
 by the end of the test no one really knows what the database state is
 supposed to be.

 For example,
 `modeltests.generic_relations.GenericRelationsTests.test_generic_relations`
 walks through most of the features supported by `GenericForeignKeys`, it
 is 130 lines long and in case the last assertion fails, you'll have to
 spend ridiculous amounts of time figuring out what happened.

 A likely incomplete list of similar tests:[[BR]]
 `modeltests.basic.ModelTest.test_lookup`[[BR]]
 `modeltests.basic.ModelTest.test_object_creation`[[BR]]
 ~~modeltests.custom_columns.CustomColumnsTests.test_db_column~~[[BR]]
 `modeltests.custom_managers.CustomManagerTests.test_manager`[[BR]]
 `modeltests.custom_pk.CustomPKTests.test_custom_pk`[[BR]]
 `modeltests.defer.DeferTests.test_defer`[[BR]]
 `modeltests.expressions.ExpressionsTests.test_filter`[[BR]]
 `modeltests.field_subclassing.CustomField.test_custom_field`[[BR]]
 `modeltests.files.FileStorageTests.test_files`[[BR]]
 `modeltests.get_or_create.GetOrCreateTests.test_get_or_create`[[BR]]
 ~~modeltests.m2m_recursive.RecursiveM2MTests.test_recursive_m2m~~[[BR]]
 `modeltests.m2m_signals.ManyToManySignalsTest`[[BR]]
 `modeltests.m2m_through.M2mThroughTests`[[BR]]
 `modeltests.model_formsets.ModelFormsetTests`[[BR]]
 `modeltests.model_forms.OldFormForXTests.test_with_data` (This one has
 more than 500 lines!)[[BR]]
 `modeltests.model_inheritance.ModelInheritanceTests`[[BR]]
 `modeltests.model_package.ModelPackageTests.test_model_packages`[[BR]]
 `modeltests.order_with_respect_to.OrderWithRespectToTests.test_basic`[[BR]]
 `modeltests.signals.SignalTests.test_basic`

 I only went through modeltests/*/tests.py; I might have overlooked a few
 tests.

 This ticket is 

Re: [Django] #22369: Add ability to assert number of times a template is used for assertTemplateUsed

[Django]

#22369: Add ability to assert number of times a template is used for
assertTemplateUsed
-+-
 Reporter:  anonymous|Owner:
 Type:  New feature  |  jrothenbuhler
Component:  Testing framework|   Status:  assigned
 Severity:  Normal   |  Version:  master
 Keywords:  assert, testing  |   Resolution:
Has patch:  1| Triage Stage:  Accepted
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  1
 |UI/UX:  0
-+-
Changes (by charettes):

 * needs_better_patch:  0 => 1


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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.4072449b6e878fcd8c4929811c876b5a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22235: pip can install from tarballs as well

[Django]

#22235: pip can install from tarballs as well
--+
 Reporter:  omer.drow@…   |Owner:  gregloy
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  *.djangoproject.com   |  Version:
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  1 |UI/UX:  0
--+
Changes (by bmispelon):

 * needs_better_patch:  0 => 1


Comment:

 As noted in the pull request, you also need to modify the settings to
 activate the request context processor so that the request object is
 available in the context.

 I would also suggest that we only keep install instructions with pip and
 get rid of the `tar xvzf ...` ones (both for stable and preview versions).

-- 
Ticket URL: 
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/077.a0cff3c2bb877bd60b653ca18479c004%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22369: Add ability to assert number of times a template is used for assertTemplateUsed

[Django]

#22369: Add ability to assert number of times a template is used for
assertTemplateUsed
-+-
 Reporter:  anonymous|Owner:
 Type:  New feature  |  jrothenbuhler
Component:  Testing framework|   Status:  assigned
 Severity:  Normal   |  Version:  master
 Keywords:  assert, testing  |   Resolution:
Has patch:  1| Triage Stage:  Accepted
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by jrothenbuhler):

 * has_patch:  0 => 1


Comment:

 Pull request: https://github.com/django/django/pull/2549

-- 
Ticket URL: 
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.5886ba95d60de766e5f9a077cc22ec6a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22436: migrations fail on custom upload_to on ImageField

[Django]

#22436: migrations fail on custom upload_to on ImageField
-+-
 Reporter:  David Binetti|Owner:
     |  chriscauley
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:
 Severity:  Normal   |  1.7-beta-1
 Keywords:   |   Resolution:
Has patch:  0| Triage Stage:  Accepted
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by chriscauley):

 * owner:  charettes => chriscauley


-- 
Ticket URL: 
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/092.49a9f064d49e6ff9a6ebf0a2e68d17ab%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22434: Ordering is cleared in Subqueries with limits

[Django]

#22434: Ordering is cleared in Subqueries with limits
-+-
 Reporter:  maciej.pawlisz@… |Owner:
 Type:  Bug  |  justhamade
Component:  Database layer   |   Status:  assigned
  (models, ORM)  |  Version:  1.6
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
Has patch:  0|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by justhamade):

 * owner:  nobody => justhamade
 * needs_docs:   => 0
 * status:  new => assigned
 * needs_tests:   => 0
 * needs_better_patch:   => 0


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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/083.83294771d22fe6c57da46d2d902cc81b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22436: migrations fail on custom upload_to on ImageField

[Django]

#22436: migrations fail on custom upload_to on ImageField
-+-
 Reporter:  David Binetti|Owner:  charettes
     |   Status:  assigned
 Type:  Bug  |  Version:
Component:  Migrations   |  1.7-beta-1
 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 charettes):

 * status:  new => assigned
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * owner:  nobody => charettes
 * needs_docs:   => 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 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/092.06d3d6fad47d4b0e23d7075a8118fc15%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22356: unique_together fails when referencing columns from base and child class

[Django]

#22356: unique_together fails when referencing columns from base and child class
-+-
 Reporter:  claus|Owner:  frog32
 Type:  Bug  |   Status:  assigned
Component:  Core (System |  Version:
  checks)|  1.7-beta-1
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
Has patch:  1|  checkin
  Needs tests:  1|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by andrewsg):

 * 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 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/063.fdd2d637622674ee1e3339f7dc1057e7%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22395: Deleting a model and fields that relate to it results in ValueError: Related model '.' cannot be resolved

[Django]

#22395: Deleting a model and fields that relate to it results in ValueError:
Related model '.' cannot be resolved
+--
 Reporter:  melinath|Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  1.7-beta-1
 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
+--

Comment (by andrewsg):

 This looks potentially related to the root cause of #22397 and it's
 possible my work on that bug will affect this one.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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.98d2ebd4e2594dd13c5787279080ec8a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22356: unique_together fails when referencing columns from base and child class

[Django]

#22356: unique_together fails when referencing columns from base and child class
-+-
 Reporter:  claus|Owner:  frog32
 Type:  Bug  |   Status:  assigned
Component:  Core (System |  Version:
  checks)|  1.7-beta-1
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
Has patch:  1|  Unreviewed
  Needs tests:  1|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by frog32):

 * has_patch:  0 => 1
 * stage:  Accepted => Unreviewed


Comment:

 Pull request: https://github.com/django/django/pull/2548

-- 
Ticket URL: 
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/063.d6336de3461bc38c214e93d42bc901d7%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22435: Adding a ManyToManyField and running makemigrations prompts for a default

[Django]

#22435: Adding a ManyToManyField and running makemigrations prompts for a 
default
+
 Reporter:  andrewsg|Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  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 charettes):

 * needs_better_patch:   => 0
 * component:  Uncategorized => Migrations
 * needs_tests:   => 0
 * needs_docs:   => 0
 * type:  Uncategorized => Bug
 * stage:  Unreviewed => Accepted


Comment:

 Could reproduce using master.

 I'm unsure how we should solve this. It would be great if we could avoid
 special casing `ManyToManyField` here.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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.4f5abf1cf0043c1e382847b264f7d262%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22397: Issues removing M2M field with explicit through model

[Django]

#22397: Issues removing M2M field with explicit through model
-+
 Reporter:  melinath |Owner:  andrewsg
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  master
 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
-+

Comment (by andrewsg):

 The problem with the AttributeError seems to actually be a problem with
 allowing the removal of a model that has M2M fields pointing to it at all,
 so I'm going to focus on putting checks in to make sure that doesn't
 happen, and also to make sure makemigrations does the right thing in that
 case.

 The problem with the KeyError appears to only affect sqlite and has a
 straightforward fix.

-- 
Ticket URL: 
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.0234840571d839fe1c5531632655eb0a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #14136: Show how to specify schemas for Oracle databases

[Django]

#14136: Show how to specify schemas for Oracle databases
-+-
 Reporter:  pfctdayelise |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Documentation|  Version:  1.2
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  databases oracle | Triage Stage:
  easy   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by mike.henken@…):

 * ui_ux:   => 0
 * type:   => Uncategorized
 * severity:   => Normal
 * easy:   => 0


Comment:

 Please add to documentation. I too spent quite some time looking for this.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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/070.893c74e71338e7f3a8c79580b9f7a2a6%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22046: unhelpful queryset handling for model formsets with data

[Django]

#22046: unhelpful queryset handling for model formsets with data
+
 Reporter:  Jim Bailey  |Owner:  hershbergien
 Type:  Bug |   Status:  assigned
Component:  Forms   |  Version:  1.6
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  1   |  Needs documentation:  0
  Needs tests:  1   |  Patch needs improvement:  1
Easy pickings:  0   |UI/UX:  0
+
Changes (by hershbergien):

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


Comment:

 The pull request does not address the second problem described in this
 ticket. The pull request needs more work and testing. See the attached
 test, which reproduces the second problem as described.

 {{{
 def test_model_formset_with_paginated_form_data(self):
 # saving a formset that contains a subset of the view queryset
 should
 # not overwrite existing data with different pks.
 # see #22046

 Author.objects.create(pk=1, name='a')
 Author.objects.create(pk=2, name='c')
 Author.objects.create(pk=3, name='e')
 Author.objects.create(pk=4, name='g')

 data = {
 'form-TOTAL_FORMS': 2,
 'form-INITIAL_FORMS': 2,
 'form-MAX_NUM_FORMS': 2,
 'form-0-id': '3',
 'form-0-name': 'c',
 'form-1-id': '4',
 'form-1-name': 'g',
 }

 FormSet = modelformset_factory(Author, fields=('name', ))
 formset = FormSet(data=data,
 queryset=Author.objects.order_by('name'))

 # adding another author before saving the form exposes the issue
 Author.objects.create(pk=5, name='b')

 formset.save()

 # expect only one author named `c'
 self.assertEqual(1, Author.objects.filter(name='c').count())
 }}}

-- 
Ticket URL: 
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.69567837cdcf4e8a02b102a31e74f0b9%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #9894: Give the FileField 'upload_to' callable access to an UploadedFile's contents.

[Django]

#9894: Give the FileField 'upload_to' callable access to an UploadedFile's
contents.
-+-
 Reporter:  Pyth |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  File |  Version:  1.0
  uploads/storage|   Resolution:  wontfix
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  feature upload_to|  Needs documentation:  1
  FileField  |  Patch needs improvement:  1
Has patch:  0|UI/UX:  0
  Needs tests:  1|
Easy pickings:  0|
-+-

Comment (by mlavin):

 To be clear the main problem with catching the {{{TypeError}}} is that
 it's such a broad error and there isn't a clean way to inspect the
 exception to know which function caused it. That is you can't know if the
 problem was {{{generate_filename}}} or another function internal to the
 callback.

-- 
Ticket URL: 
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.2a4909c6f242151647c5fbd58953069b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #9894: Give the FileField 'upload_to' callable access to an UploadedFile's contents.

[Django]

#9894: Give the FileField 'upload_to' callable access to an UploadedFile's
contents.
-+-
 Reporter:  Pyth |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  File |  Version:  1.0
  uploads/storage|   Resolution:  wontfix
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  feature upload_to|  Needs documentation:  1
  FileField  |  Patch needs improvement:  1
Has patch:  0|UI/UX:  0
  Needs tests:  1|
Easy pickings:  0|
-+-
Changes (by mlavin):

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


Comment:

 Spoke with julienphalip and others at the PyCon 2014 sprints and the
 consensus was that this is a reasonable but rare use case. However, doing
 this in a backwards compatible when changing the number of expected
 arguments for {{{upload_to}}} is messy and difficult. One way would be to
 change {{{FieldFile.save}}} to call {{{self.field.generate_filename}}}
 with the extra content argument, catch the {{{TypeError}}} which would be
 raised if the {{{upload_to}}} doesn't take the arg and then raise a
 deprecation and call it again with only the {{{instance}}} and
 {{{filename}}} args.

 {{{
 def save(self, name, content, save=True):
 try:
 name = self.field.generate_filename(self.instance, name,
 content)
 except TypeError:
 # Include deprecation warning about content arg
 name = self.field.generate_filename(self.instance, name)
 }}}

 The problem with this is the possibiliy that something inside the
 {{{upload_to}}} raises a {{{TypeError}}} and it is masked during this
 deprecation cycle leading to difficult to debug problems. Another
 possibility would be to use {{{inspect.getargspec}}} but that type of
 inspection can be prone to error.

 Doing this type of name change based on the content is possible with the
 current code/API. If you don't need the model instance then the storage
 {{{save}}} gets the content and the name generated by the field. If you do
 need the instance and the content then you can subclass both
 {{{FieldFile}}} and {{{FileField}}} to make {{{FieldFile.save}}} and
 {{{FileField.generate_filename}}} compatible with passing the content as
 an additional argument. While both of these directions require much more
 work, this use case seems small enough and somewhat custom enough to merit
 it. Overall the amount of work required to add this new argument doesn't
 appear to be worth the savings for the few that might need it.

 Marking this as wontfix. If someone really wants this new argument and can
 make a compelling argument for a simple way to maintain backwards
 compatibility that should be raised on django-developers
 http://groups.google.com/group/django-developers/ Otherwise you can try
 one of the work-arounds described above.

-- 
Ticket URL: 
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.35eb8ec66d7e704bbe38aa740e831b91%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #21548: Add the ability to limit file extensions for ImageField and FileField

[Django]

#21548: Add the ability to limit file extensions for ImageField and FileField
-+
 Reporter:  timo |Owner:  jfilipe
 Type:  New feature  |   Status:  assigned
Component:  Forms|  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 jfilipe):

 * 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 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.a7d2f6b1138256f991f35045f7573734%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #21548: Add the ability to limit file extensions for ImageField and FileField

[Django]

#21548: Add the ability to limit file extensions for ImageField and FileField
-+
 Reporter:  timo |Owner:  jfilipe
 Type:  New feature  |   Status:  assigned
Component:  Forms|  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
-+

Comment (by jfilipe):

 I have a work in progress PR here:
 https://github.com/jfilipe/django/pull/2

 Wanted to get some feedback on the approach before I added some docs.

-- 
Ticket URL: 
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.a79edfdd59de08ff8f5fcc3859ed1ea8%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #21548: Add the ability to limit file extensions for ImageField and FileField

[Django]

#21548: Add the ability to limit file extensions for ImageField and FileField
-+
 Reporter:  timo |Owner:  jfilipe
 Type:  New feature  |   Status:  assigned
Component:  Forms|  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 jfilipe):

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


-- 
Ticket URL: 
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.b84091198ebb55c2cedf26f29e6265a5%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #21765: Contexts cannot be compared for equality.

[Django]

#21765: Contexts cannot be compared for equality.
-+-
 Reporter:  Keryn Knight |Owner:  onjin
   |   Status:  closed
 Type:  New feature  |  Version:  master
Component:  Template system  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by leotin):

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


Comment:

 It seems like the reported issue is finally fixed after the update by
 8274fa60f88607eb0e81908f049c391455956dd8.

-- 
Ticket URL: 
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/095.8e994ce7603d5953c409b4e83f6852ce%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22437: mimetype

[Django]

#22437: mimetype
---+--
 Reporter:  anonymous  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Uncategorized  |  Version:  1.7-beta-1
 Severity:  Normal |   Resolution:  invalid
 Keywords:  mimetupe   | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by claudep):

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


Comment:

 This is probably due to mimetype being content_type on more recent Django
 versions. But please, do not use this tracker as a help channel.

-- 
Ticket URL: 
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.c506fda194098f281613b737ada476b0%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #22438: Slow INNER JOIN in MySQL can be fixed in Django ORM, but should it?

[Django]

#22438: Slow INNER JOIN in MySQL can be fixed in Django ORM, but should it?
-+-
 Reporter:  frol |  Owner:  nobody
 Type:  Uncategorized| Status:  new
Component:  Database layer   |Version:  master
  (models, ORM)  |   Keywords:  mysql, orm, slow query,
 Severity:  Normal   |  join
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+-
 There is the bug in MySQL INNER JOIN optimization, but it can be fixed in
 Django ORM by replacing INNER JOIN with STRAIGHT_JOIN. In short, ordered
 inner join selections take 3+ seconds, where if replace INNER JOIN with
 STRAIGHT_JOIN, we get result in 0.001.

 Here are steps to reproduce:
 1) We need a model with ForeignKey:
 {{{
 from django.conf import settings
 from django.db import models

 class Child(models.Model):
 name = models.CharField("Name", max_length=255)
 owner = models.ForeignKey(settings.AUTH_USER_MODEL)
 }}}

 2) Initialize data:
 {{{
 from random import choice
 from django.contrib.auth import get_user_model
 from qq.models import *

 User = get_user_model()
 users = User.objects.all()
 Child.objects.bulk_create(Child(name='child_%d' % i, owner=choice(users))
 for i in xrange(40))
 }}}

 3) Query data with join (the bug appears only if order by is applied):
 {{{
 Child.objects.all().order_by('-id').select_related('owner')[:2]
 }}}
 The resulting query would be:
 {{{
  {u'sql': u'SELECT `qq_child`.`id`, `qq_child`.`name`,
 `qq_child`.`other_field`, `qq_child`.`owner_id`,
 `auth_user`.`id`, `auth_user`.`password`, `auth_user`.`last_login`,
 `auth_user`.`is_superuser`,
 `auth_user`.`username`, `auth_user`.`first_name`, `auth_user`.`last_name`,
 `auth_user`.`email`,
 `auth_user`.`is_staff`, `auth_user`.`is_active`, `auth_user`.`date_joined`
 FROM `qq_child`
 INNER JOIN `auth_user` ON ( `qq_child`.`owner_id` = `auth_user`.`id` )
 ORDER BY `qq_child`.`id` ASC
 LIMIT 2',
   u'time': u'4.608'},
 }}}

 (MySQL caches result until you update the table so the next time it would
 take 0.001, but not in production if your table updates frequently)

 If I replace INNER JOIN with STRAIGHT_JOIN:
 {{{
 list(Child.objects.raw(
 Child.objects.all().order_by('-id').select_related('owner')[:2]\
 .query.sql_with_params()[0].replace('INNER JOIN', 'STRAIGHT_JOIN')
 ))
 }}}

 I get this result:
 {{{
  {u'sql': u'SELECT `qq_child`.`id`, `qq_child`.`name`,
 `qq_child`.`other_field`, `qq_child`.`owner_id`,
 `auth_user`.`id`, `auth_user`.`password`, `auth_user`.`last_login`,
 `auth_user`.`is_superuser`,
 `auth_user`.`username`, `auth_user`.`first_name`, `auth_user`.`last_name`,
 `auth_user`.`email`,
 `auth_user`.`is_staff`, `auth_user`.`is_active`, `auth_user`.`date_joined`
 FROM `qq_child`
 STRAIGHT_JOIN `auth_user` ON ( `qq_child`.`owner_id` = `auth_user`.`id` )
 ORDER BY `qq_child`.`id` DESC
 LIMIT 2',
   u'time': u'0.001'}]
 }}}

 '''4.6 seconds vs 0.001. Really?'''

 '''Solutions:'''
 1) SQLAlchemy implemented .with_prefix() method for query:
 http://stackoverflow.com/a/16743228
 2) Replace INNER JOIN for MySQL backend with STRAIGHT_JOIN, but it might
 be not a good idea. I will investigate this today.

 '''Wrong attempts to fix this:'''
 Since select_related is used in django admin change_list if you ask for
 related fields in columns, devs try to override it with .raw() -
 http://stackoverflow.com/a/15978732/1178806 (I answered in comments why it
 doesn't 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/047.fb4a41896834fa58bf28eba502eefc05%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #18523: Add getvalue to HttpResponse

[Django]

#18523: Add getvalue to HttpResponse
---+
 Reporter:  claudep|Owner:  Osmose
 Type:  New feature|   Status:  assigned
Component:  HTTP handling  |  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 Osmose):

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


Comment:

 I submitted a PR with the changes mentioned in comment:3 here:
 https://github.com/django/django/pull/2545

-- 
Ticket URL: 
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.f90b3ce6fd762973e62d32251301ca19%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #21158: Set an implicit wait for selenium.

[Django]

#21158: Set an implicit wait for selenium.
-+-
 Reporter:  apollo13 |Owner:
 Type:   |  bsilverberg
  Cleanup/optimization   |   Status:  assigned
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
-+-

Comment (by bsilverberg):

 Thanks jmbowman. That certainly can be an issue. I ran the current test
 suite and it doesn't seem to suffer from this issue. In the suites that we
 use at work we do have a default implicit wait set up, and then we use
 helper methods when we want to check that an element is not present which
 switch off the implicit wait.

 I think the approach used here is appropriate for the current test suite,
 but it is something to be careful about in the future, if this approach is
 adopted.

-- 
Ticket URL: 
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.c63c57257e00f3de846f6fb91855b557%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22220: reverse() documentation

[Django]

#0: reverse() documentation
-+-
 Reporter:  EvilDMP  |Owner:
 Type:   |  bendavis78
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  1.6
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by bendavis78):

 * has_patch:  0 => 1


Comment:

 Here's my take on this: https://github.com/django/django/pull/2544

-- 
Ticket URL: 
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.5394d1c7532b0f3ae3a61ef45b40fdec%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[django/django] 09af48: Improve migrations/schema docs

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/django/django
  Commit: 09af48c70fb5cc652ea109487015472e9ef984df
  
https://github.com/django/django/commit/09af48c70fb5cc652ea109487015472e9ef984df
  Author: Andrew Godwin 
  Date:   2014-04-14 (Mon, 14 Apr 2014)

  Changed paths:
M docs/ref/django-admin.txt
M docs/ref/migration-operations.txt
M docs/ref/schema-editor.txt
M docs/topics/migrations.txt

  Log Message:
  ---
  Improve migrations/schema docs


-- 
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/534c15c41089f_68318d3d44161f4%40hookshot-fe1-cp1-prd.iad.github.net.mail.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #21158: Set an implicit wait for selenium.

[Django]

#21158: Set an implicit wait for selenium.
-+-
 Reporter:  apollo13 |Owner:
 Type:   |  bsilverberg
  Cleanup/optimization   |   Status:  assigned
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
-+-

Comment (by jmbowman):

 I'd advise a little caution on this approach.  I've worked on projects
 which have assertions that just want to verify that an element is not on
 the page.  If every such assertion takes 10 seconds of redundantly
 verifying that the element is still not on the page, that can make the
 tests take a lot longer to run.  It's a pain to correctly do it
 consistently, but I've had better results fixing tests with implicit
 timing dependencies to wait explicitly when 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 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.d3b957d9b0a05387d0b52478b6f936c5%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #21549: Fixture loading should fail with a BIG LOUD EXCEPTION when the file is not found

[Django]

#21549: Fixture loading should fail with a BIG LOUD EXCEPTION when the file is 
not
found
-+-
 Reporter:  mpasternak   |Owner:  bugZPDX
 Type:  Bug  |   Status:  assigned
Component:  Core (Management |  Version:  master
  commands)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by bugZPDX):

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


Comment:

 The loaddata function in find_fixtures via load_label warns properly,
 however something in the interactive command is masking the error. I will
 continue investigating the issue.

-- 
Ticket URL: 
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.3570587c253b8f559eaff6f7d5b5acd3%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #22437: mimetype

[Django]

#22437: mimetype
---+
 Reporter:  anonymous  |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  Uncategorized  |Version:  1.7-beta-1
 Severity:  Normal |   Keywords:  mimetupe
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 TypeError at /warehouse_report/buch/
 __init__() got an unexpected keyword argument 'mimetype'
 Request Method: POST
 Request URL:http://127.0.0.1:8000/warehouse_report/buch/
 Django Version: 1.7b1
 Exception Type: TypeError
 Exception Value:
 __init__() got an unexpected keyword argument 'mimetype'
 Exception Location: /usr/local/lib/python2.7/dist-
 packages/Django-1.7b1-py2.7.egg/django/http/response.py in __init__, line
 320
 Python Executable:  /usr/bin/python
 Python Version: 2.7.5
 Python Path:
 ['/home/ski/Development/DJ17/potolok',
  '/usr/local/lib/python2.7/dist-packages/Django-1.7b1-py2.7.egg',
  '/usr/lib/python2.7',
  '/usr/lib/python2.7/plat-x86_64-linux-gnu',
  '/usr/lib/python2.7/lib-tk',
  '/usr/lib/python2.7/lib-old',
  '/usr/lib/python2.7/lib-dynload',
  '/usr/local/lib/python2.7/dist-packages',
  '/usr/lib/python2.7/dist-packages',
  '/usr/lib/python2.7/dist-packages/PILcompat',
  '/usr/lib/python2.7/dist-packages/gtk-2.0',
  '/usr/lib/pymodules/python2.7',
  '/usr/lib/python2.7/dist-packages/ubuntu-sso-client',
  '/usr/lib/python2.7/dist-packages/wx-2.8-gtk2-unicode']
 Server time:Пнд, 14 Апр 2014 19:45:46 +0300

-- 
Ticket URL: 
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/052.dad5a980116d22aeb858c96a290a694b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #21158: Set an implicit wait for selenium.

[Django]

#21158: Set an implicit wait for selenium.
-+-
 Reporter:  apollo13 |Owner:
 Type:   |  bsilverberg
  Cleanup/optimization   |   Status:  assigned
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 bsilverberg):

 * 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 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.6d208f4b4d7d9f44671f70cd4ad907fe%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #21158: Set an implicit wait for selenium.

[Django]

#21158: Set an implicit wait for selenium.
-+-
 Reporter:  apollo13 |Owner:
 Type:   |  bsilverberg
  Cleanup/optimization   |   Status:  assigned
Component:  Testing framework|  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
-+-

Comment (by bsilverberg):

 I have opened pull request https://github.com/django/django/pull/2543 for
 this. This is my first django pull request so any advice/feedback would be
 appreciated.

-- 
Ticket URL: 
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.4df30d4c66d4a03fdd5e2569e93d160a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22397: Issues removing M2M field with explicit through model

[Django]

#22397: Issues removing M2M field with explicit through model
-+
 Reporter:  melinath |Owner:  andrewsg
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  master
 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 andrewsg):

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


Comment:

 Going to take a crack at this at the PyCon 2014 sprints.

-- 
Ticket URL: 
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.d215f517271b333dbfb1acc0da6b9468%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #22436: migrations fail on custom upload_to on ImageField

[Django]

#22436: migrations fail on custom upload_to on ImageField
+
 Reporter:  David Binetti   |  Owner:  nobody
 Type:  Bug | Status:  new
Component:  Migrations  |Version:  1.7-beta-1
 Severity:  Normal  |   Keywords:
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+
 One of my models has an ImageField with a dynamically created upload_to:

 {{{
 class Photo(models.Model):


 account = models.ForeignKey(Account)

 ...

 def upload_thumb(instance, filename):
 return 'photos/{0}/dropbox{1}'.format(instance.account.id,
 filename)

 thumbnail = models.ImageField(upload_to=upload_thumb, null=True)
 }}}

 When I run makemigrations it produces the following (without error):

 {{{
 # encoding: utf8
 from django.db import models, migrations
 import apps.dinadesa.models


 class Migration(migrations.Migration):

 dependencies = [
 ('dinadesa', '0006_auto_20140414_0836'),
 ]

 operations = [
 migrations.AlterField(
 model_name='photo',
 name='thumbnail',
 field=models.ImageField(null=True,
 upload_to=apps.dinadesa.models.upload_thumb),
 ),
 ]
 }}}

 (I keep my apps in an `apps` directory in the project root, in case that
 matters.)

 When I try to run the migration, I get:

 {{{
 (dinadesa)$ django-admin migrate
 Traceback (most recent call last):
   File "/Users/dbinetti/.virtualenvs/dinadesa/bin/django-admin", line 11,
 in 
 sys.exit(execute_from_command_line())
   File "/Users/dbinetti/.virtualenvs/dinadesa/lib/python2.7/site-
 packages/django/core/management/__init__.py", line 427, in
 execute_from_command_line
 utility.execute()
   File "/Users/dbinetti/.virtualenvs/dinadesa/lib/python2.7/site-
 packages/django/core/management/__init__.py", line 419, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "/Users/dbinetti/.virtualenvs/dinadesa/lib/python2.7/site-
 packages/django/core/management/base.py", line 288, in run_from_argv
 self.execute(*args, **options.__dict__)
   File "/Users/dbinetti/.virtualenvs/dinadesa/lib/python2.7/site-
 packages/django/core/management/base.py", line 337, in execute
 output = self.handle(*args, **options)
   File "/Users/dbinetti/.virtualenvs/dinadesa/lib/python2.7/site-
 packages/django/core/management/commands/migrate.py", line 62, in handle
 executor = MigrationExecutor(connection,
 self.migration_progress_callback)
   File "/Users/dbinetti/.virtualenvs/dinadesa/lib/python2.7/site-
 packages/django/db/migrations/executor.py", line 14, in __init__
 self.loader = MigrationLoader(self.connection)
   File "/Users/dbinetti/.virtualenvs/dinadesa/lib/python2.7/site-
 packages/django/db/migrations/loader.py", line 48, in __init__
 self.build_graph()
   File "/Users/dbinetti/.virtualenvs/dinadesa/lib/python2.7/site-
 packages/django/db/migrations/loader.py", line 145, in build_graph
 self.load_disk()
   File "/Users/dbinetti/.virtualenvs/dinadesa/lib/python2.7/site-
 packages/django/db/migrations/loader.py", line 103, in load_disk
 migration_module = import_module("%s.%s" % (module_name,
 migration_name))
   File
 
"/usr/local/Cellar/python/2.7.6/Frameworks/Python.framework/Versions/2.7/lib/python2.7/importlib/__init__.py",
 line 37, in import_module
 __import__(name)
   File
 
"/Users/dbinetti/Repos/dinadesa/project/apps/dinadesa/migrations/0007_auto_20140414_0850.py",
 line 6, in 
 class Migration(migrations.Migration):
   File
 
"/Users/dbinetti/Repos/dinadesa/project/apps/dinadesa/migrations/0007_auto_20140414_0850.py",
 line 16, in Migration
 field=models.ImageField(null=True,
 upload_to=apps.dinadesa.models.upload_thumb),
 AttributeError: 'module' object has no attribute 'upload_thumb'
 }}}

 Which I can work around by changing the `field` line in my migration to:

 {{{
 field=models.ImageField(null=True,
 upload_to=apps.dinadesa.models.Photo.upload_thumb),   # Note the addition
 of the `Photo` model in the path.
 }}}

 Then, the `migrate` command works fine.

 BUT if I then try to run another migration it detects the altered field,
 and I have to do it all again.

 I hope this is sufficient information.  It is my first bug report and I'm
 not certain how to create a test case, but it is 100% reproduce-able on my
 system.

 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 unsubscribe from this group and stop receiving emails from it, send an email 
to 

Re: [Django] #22395: Deleting a model and fields that relate to it results in ValueError: Related model '.' cannot be resolved

[Django]

#22395: Deleting a model and fields that relate to it results in ValueError:
Related model '.' cannot be resolved
+--
 Reporter:  melinath|Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  1.7-beta-1
 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
+--

Comment (by ofirov):

 I couldn't reproduce the bug. Not on stable (f004374) and not on the 1.7b1
 tag. I tried the following:
 https://github.com/Ofir-Purple/django/tree/testing-22395
 https://github.com/Ofir-Purple/django/tree/testing-22395-on-1.7b1

 And tried to create a project with 2 related fields. I made sure that the
 migration's operations were: First delete the model, then the related
 fields; But to no avail. The migrations worked fine.

 Do you have a link to a full project that reproduced the bug?

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To 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.2d596ce9b006a1a71e15b09dac52300a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #22435: Adding a ManyToManyField and running makemigrations prompts for a default

[Django]

#22435: Adding a ManyToManyField and running makemigrations prompts for a 
default
---+
 Reporter:  andrewsg   |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  master
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 Adding a ManyToManyField to an existing model prompts the user as so:

 {{{
 You are trying to add a non-nullable field 'authors' to post without a
 default;
 we can't do that (the database needs something to populate existing rows).
 Please select a fix:
  1) Provide a one-off default now (will be set on all existing rows)
  2) Quit, and let me add a default in models.py
 Select an option:
 }}}

 Since there is no way to specify a default for an M2M field in the
 interactive process, this makes it impossible to add M2M fields.

 The workaround is to cancel and add `null=True` to the field definition.
 But `null=True` does not apply to `ManyToManyField`, so this should be
 unnecessary.

-- 
Ticket URL: 
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.61039779e1d53b171e49c311cb6849d1%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22378: \d in urls examples in documentation is missleading.

[Django]

#22378: \d in urls examples in documentation is missleading.
-+-
 Reporter:  tomwys   |Owner:
 Type:   |  chriscauley
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  1.6
 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 chriscauley):

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


-- 
Ticket URL: 
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.0c7b3b7689e34d6d29de4ab895b6da5c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #20916: Provide a "simple_login" feature for the test client

[Django]

#20916: Provide a "simple_login" feature for the test client
---+
 Reporter:  mjtamlyn   |Owner:  alasdair
 Type:  New feature|   Status:  assigned
Component:  Testing framework  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords:  auth   | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  1
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+

Comment (by jfilipe):

 I've tried a different approach where a new authentication backend is
 added when setting up the test environment.

 The changes are here:
 https://github.com/jfilipe/django/compare/django:master...simple-login

 If you guys like this approach I can add some docs.

-- 
Ticket URL: 
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.e49e25d5e5728890956ca58227320d48%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #21158: Set an implicit wait for selenium.

[Django]

#21158: Set an implicit wait for selenium.
-+-
 Reporter:  apollo13 |Owner:
 Type:   |  bsilverberg
  Cleanup/optimization   |   Status:  assigned
Component:  Testing framework|  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 bsilverberg):

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


-- 
Ticket URL: 
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.78636af6c161ecb53931f5a71b100ff6%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22220: reverse() documentation

[Django]

#0: reverse() documentation
-+-
 Reporter:  EvilDMP  |Owner:
 Type:   |  bendavis78
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  1.6
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by bendavis78):

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


-- 
Ticket URL: 
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.e97099630507475e83752a14724a84c6%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22373: Django Migrations keeps detecting changes to FileField using custom storage

[Django]

#22373: Django Migrations keeps detecting changes to FileField using custom 
storage
-+-
 Reporter:  Matthias Pronk   |Owner:
   |   Status:  new
 Type:  Bug  |  Version:  master
Component:  Migrations   |   Resolution:
 Severity:  Release blocker  | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by bmispelon):

 * severity:  Normal => Release blocker
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * version:  1.7-beta-1 => master
 * needs_docs:   => 0
 * stage:  Unreviewed => Accepted


Comment:

 Hi,

 It seems that the autodetector is comparing the instances of the storage
 class instead of their deconstructed versions.

 Since the storage class doesn't implement `__eq__`, this means that the
 autodetector wrongly assumes you're using a new object and therefore
 create a new migration.

 Not sure what the best course of action is, but this is definitely a bug
 (I'll also mark it as a release blocker).

 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 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/091.5a2376f2f4a06277a801d583e23c93c0%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22369: Add ability to assert number of times a template is used for assertTemplateUsed

[Django]

#22369: Add ability to assert number of times a template is used for
assertTemplateUsed
-+-
 Reporter:  anonymous|Owner:
 Type:  New feature  |  jrothenbuhler
Component:  Testing framework|   Status:  assigned
 Severity:  Normal   |  Version:  master
 Keywords:  assert, testing  |   Resolution:
Has patch:  0| Triage Stage:  Accepted
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by jrothenbuhler):

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


-- 
Ticket URL: 
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.2d9af12d7ec6eae9ededdfb5cb8355b4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22046: unhelpful queryset handling for model formsets with data

[Django]

#22046: unhelpful queryset handling for model formsets with data
+
 Reporter:  Jim Bailey  |Owner:  hershbergien
 Type:  Bug |   Status:  assigned
Component:  Forms   |  Version:  1.6
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  1   |UI/UX:  0
+
Changes (by hershbergien):

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


-- 
Ticket URL: 
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.ebf3ea4e765f5836e95b17cb3362acb4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22379: Escaping needed during lazy reversing of non-ascii URLs

[Django]

#22379: Escaping needed during lazy reversing of non-ascii URLs
-+--
 Reporter:  jnns |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (URLs)  |  Version:  1.6
 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 bmispelon):

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


Comment:

 Hi,

 I can't seem to be able to reproduce this:

 {{{#!python

 # urls.py

 ...
 url(r'^é/$', view=..., name='foo')
 ...


 >>> print(reverse('foo'))
 /%C3%A9/
 >>> print(reverse_lazy('foo'))
 /%C3%A9/
 }}}

 Can you provide more information as to how you can trigger that error?

 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 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.eb78aaf2a2fd8bdb4d5d801e31e95371%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22356: unique_together fails when referencing columns from base and child class

[Django]

#22356: unique_together fails when referencing columns from base and child class
-+-
 Reporter:  claus|Owner:  frog32
 Type:  Bug  |   Status:  assigned
Component:  Core (System |  Version:
  checks)|  1.7-beta-1
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by frog32):

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


-- 
Ticket URL: 
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/063.19782d51124f44410517c6d482053cb2%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22235: pip can install from tarballs as well

[Django]

#22235: pip can install from tarballs as well
--+
 Reporter:  omer.drow@…   |Owner:  gregloy
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  *.djangoproject.com   |  Version:
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by gregloy):

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


-- 
Ticket URL: 
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/077.3397c4796902cede10f03c2b1f46c200%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22433: Django

[Django]

#22433: Django
---+--
 Reporter:  carol  |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Uncategorized  |  Version:  1.6
 Severity:  Normal |   Resolution:  invalid
 Keywords:  django | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by alasdair):

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


Comment:

 Looks like this was created by mistake. Closing as invalid.

-- 
Ticket URL: 
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/063.a15a38a8b01a6bf97c1ac8067fc6322f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #22434: Ordering is cleared in Subqueries with limits

[Django]

#22434: Ordering is cleared in Subqueries with limits
--+
 Reporter:  maciej.pawlisz@…  |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.6
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 This can lead to unexpected and unpredictable results. In my case I had a
 method on ModelManager that returned custom query. I was interested only
 in the most recent result:
 {{{
 In [76]: pr = Program.objects.get_all_for_user(98,True)
 In [77]: print pr[:1].query
 SELECT "training_program"."id", "training_program"."name",
 "training_program"."d
 escription", "training_program"."created", "training_program"."modified",
 "train
 ing_program"."created_by_id", "training_program"."status" FROM
 "training_program
 " INNER JOIN "training_programuser" ON ( "training_program"."id" =
 "training_pro
 gramuser"."program_id" ) WHERE ("training_program"."status" = published
 AND "tr
 aining_programuser"."user_id" IN (98) AND
 "training_programuser"."available_sinc
 e" <= 2014-04-11 08:40:19.68 ) ORDER BY
 "training_programuser"."user_id" DES
 C, "training_programuser"."available_since" DESC LIMIT 1
 }}}
 The resulting query is as expected. Unfortunately when using this query in
 another query produces sql which does not give results as expected:

 {{{
 In [78]: print Session.objects.filter(programs__in=pr[:1]).query
 SELECT "training_session"."id", "training_session"."name",
 "training_session"."d
 escription", "training_session"."created", "training_session"."modified",
 "train
 ing_session"."created_by_id", "training_session"."areas" FROM
 "training_session"
  INNER JOIN "training_program_sessions" ON ( "training_session"."id" =
 "training
 _program_sessions"."session_id" ) WHERE
 "training_program_sessions"."program_id"
  IN (SELECT "training_program"."id" FROM "training_program" INNER JOIN
 "training
 _programuser" ON ( "training_program"."id" =
 "training_programuser"."program_id"
  ) WHERE ("training_program"."status" = published  AND
 "training_programuser"."u
 ser_id" IN (98) AND "training_programuser"."available_since" <= 2014-04-10
 13:48
 :57.228000 ) LIMIT 1)
 }}}
 There is no ORDER BY clause in sql, so the resulting Program is different
 then the one in previous example.
 Quick fix that worked for me was changing line 408 in
 django/db/modelse/sql/where.py, to:


 {{{
 if query.low_mark == 0 and query.high_mark is None:
 query.clear_ordering(True)
 }}}

-- 
Ticket URL: 
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.601995467e6d378cd74144df7bb0bb39%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #11154: Inconsistency with permissions for proxy models

[Django]

#11154: Inconsistency with permissions for proxy models
-+-
 Reporter:  etianen  |Owner:  charettes
 Type:  Bug  |   Status:  assigned
Component:  contrib.auth |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  proxy contenttype| Triage Stage:  Accepted
  permission |  Needs documentation:  1
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by guettli):

 * cc: hv@… (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/065.e0639b2e7df77ebe984369dadffa3538%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22433: Django

[Django]

#22433: Django
---+--
 Reporter:  carol  |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Uncategorized  |  Version:  1.6
 Severity:  Normal |   Resolution:  invalid
 Keywords:  django | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by erikr):

 * status:  new => closed
 * needs_better_patch:   => 0
 * resolution:   => invalid
 * 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 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/063.94aa5b7c636727f4bc2253e17823d1f1%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #22433: Django

[Django]

#22433: Django
---+
 Reporter:  carol  |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Uncategorized  |Version:  1.6
 Severity:  Normal |   Keywords:  django
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 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/048.7bdfa2d770cb9249540c3bcf824925cf%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22431: TestCase swallows IntegrityError when creating object with invalid foreign key

[Django]

#22431: TestCase swallows IntegrityError when creating object with invalid 
foreign
key
-+-
 Reporter:  cjerdonek|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.6
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
  TestCase,IntegrityError,TransactionTestCase,ForeignKey|  Needs 
documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by cjerdonek):

 It looks like PostgreSQL at least
 [http://www.postgresql.org/docs/9.1/static/sql-set-constraints.html
 provides the ability] to check constraints immediately (at least for
 "UNIQUE, PRIMARY KEY, REFERENCES (foreign key), and EXCLUDE constraints").
 The option can be enabled on a per-transaction basis by calling `SET
 CONSTRAINTS` within the transaction.  So maybe `TestCase` can be
 configured to call this during test initialization after starting the
 transaction.

-- 
Ticket URL: 
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.04cebea470d9bbf8b5759a2e2ebe4907%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22431: TestCase swallows IntegrityError when creating object with invalid foreign key

[Django]

#22431: TestCase swallows IntegrityError when creating object with invalid 
foreign
key
-+-
 Reporter:  cjerdonek|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.6
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
  TestCase,IntegrityError,TransactionTestCase,ForeignKey|  Needs 
documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by cjerdonek):

 I wonder if there is a way to force or simulate such a check to be done
 earlier in the process.  For example, after such a call to `save()`, if I
 were to access the property corresponding to such a field within that same
 test, I would get a `DoesNotExist` exception.  So the information is
 there.

 If there is no practical fix, it would be good if the documentation also
 gave a work-around or two.  I don't have enough experience with the issue
 though to know what would be useful beyond avoiding `TestCase` altogether
 in those situations.

-- 
Ticket URL: 
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.c6b0d95929b8882a1e3f7c64a4accc83%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22432: Switching model on an M2M field results in a broken db (no change to the automatic through table)

[Django]

#22432: Switching model on an M2M field results in a broken db (no change to the
automatic through table)
-+--
 Reporter:  melinath |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  1.7-beta-1
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by melinath):

 * cc: stephen.r.burrows@… (added)
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 This seems pretty severe, with potential for data loss/unexpected crashes,
 so I marked it as a release blocker. Apologies if I shouldn't have.

-- 
Ticket URL: 
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.ff09b308772b4cb98b86a7aafb8bb33d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #22432: Switching model on an M2M field results in a broken db (no change to the automatic through table)

[Django]

#22432: Switching model on an M2M field results in a broken db (no change to the
automatic through table)
-+
 Reporter:  melinath |  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  Migrations   |Version:  1.7-beta-1
 Severity:  Release blocker  |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 I had a field that looked like this:

 {{{
 class EventPerson(models.Model)
 person_prefer = models.ManyToManyField('self')
 }}}

 But that was wrong (copy-paste mistake) so I switched it to this:

 {{{
 class EventPerson(models.Model):
 person_prefer = models.ManyToManyField(Person)
 }}}

 Then I ran makemigrations and migrate. And now I'm getting database errors
 because the auto-generated through table still looks like this:

 {{{
 CREATE TABLE "brambling_eventperson_person_prefer"
 ("id" integer NOT NULL PRIMARY KEY AUTOINCREMENT,
  "from_eventperson_id" integer NOT NULL REFERENCES "brambling_eventperson"
 ("id"),
  "to_eventperson_id" integer NOT NULL REFERENCES "brambling_eventperson"
 ("id"),
 UNIQUE ("from_eventperson_id", "to_eventperson_id"));
 }}}

 ... and I have no easy way to recover.

-- 
Ticket URL: 
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.944279f08707ee48f9cf1563b146ad62%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22431: TestCase swallows IntegrityError when creating object with invalid foreign key

[Django]

#22431: TestCase swallows IntegrityError when creating object with invalid 
foreign
key
-+-
 Reporter:  cjerdonek|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.6
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:
 Keywords:   |  Unreviewed
  TestCase,IntegrityError,TransactionTestCase,ForeignKey|  Needs 
documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by aaugustin):

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


Comment:

 Databases defer foreign key checks until the end of the current
 transaction. Since `TestCase` runs its tests in a transaction that is
 eventually rolled back, indeed, the foreign key check is skipped. I don't
 think we can fix that limitation, but we can document 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.080d4ba1b312d448fd5568b320896d5d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22428: Model docstring not parsed in model detail

[Django]

#22428: Model docstring not parsed in model detail
---+-
 Reporter:  axel_amigo |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  contrib.admindocs  |  Version:  1.6
 Severity:  Normal |   Resolution:  duplicate
 Keywords:  helpers, models| Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+-
Changes (by aaugustin):

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


Comment:

 Duplicate of #5405.

-- 
Ticket URL: 
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.af277967d7367bc72d497d3f7f633fe2%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #5405: Support restructured text in model docstrings

[Django]

#5405: Support restructured text in model docstrings
-+-
 Reporter:  mattmcc  |Owner:  gokmen
 Type:  New feature  |   Status:  assigned
Component:  contrib.admindocs|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  nfa-someday  | Triage Stage:  Accepted
  sprint2013 |  Needs documentation:  1
Has patch:  1|  Patch needs improvement:  1
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by aaugustin):

 #22428 was a duplicate with 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 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.1d2ebc0f6dde590e6358cb4e13a56292%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #22416: Migrate can't create ManyToManyField for Model wigrated in the same run

[Django]

#22416: Migrate can't create ManyToManyField for Model wigrated in the same run
-+-
 Reporter:  roughdesignapps@…|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:
Component:  Migrations   |  1.7-alpha-2
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
Has patch:  0|  Unreviewed
  Needs tests:  0|  Needs documentation:  0
Easy pickings:  0|  Patch needs improvement:  0
 |UI/UX:  0
-+-
Changes (by melinath):

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


Comment:

 The django_content_type bug sounds like a duplicate of #22411.

-- 
Ticket URL: 
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/083.135c35bbeb144ae0ee6dc661838f0ffa%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.