Re: [Django] #23714: `date` filter raises an exception for naive datetimes during DST change

[Django]

#23714: `date` filter raises an exception for naive datetimes during DST change
-+-
 Reporter:  mbertheau|Owner:  aaugustin
 Type:  Bug  |   Status:  assigned
Component:  Template system  |  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:  timezone | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by aaugustin):

 * owner:  tricoder42 => aaugustin


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

Re: [Django] #23714: `date` filter raises an exception for naive datetimes during DST change

[Django]

#23714: `date` filter raises an exception for naive datetimes during DST change
-+--
 Reporter:  mbertheau|Owner:  tricoder42
 Type:  Bug  |   Status:  assigned
Component:  Template system  |  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:  timezone | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+--
Changes (by tricoder42):

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


Comment:

 After discussion on PR, we're waiting for approval from @aaugustin:
 Naive datetimes returns empty string for any timezone-related format
 specifiers (for the whole year). This is backward-incompatible change
 which will be mentioned in 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/067.f5503c20f215fa3021fdf0771c14e380%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23873: Trying to import GIS without GEOS installed leads to obscure error message

[Django]

#23873: Trying to import GIS without GEOS installed leads to obscure error 
message
--+
 Reporter:  carljm|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  GIS   |  Version:  1.7
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Carl Meyer ):

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


Comment:

 In [changeset:"d2bcb0598058dd93eac94bdbb7dd2565cff0abea"]:
 {{{
 #!CommitTicketReference repository=""
 revision="d2bcb0598058dd93eac94bdbb7dd2565cff0abea"
 Fixed #23873 -- Improved GIS error message when GEOS is not installed.

 Thanks Claude for writing the patch.
 }}}

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

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

Re: [Django] #23682: Stronger redirect loop detection in the test client

[Django]

#23682: Stronger redirect loop detection in the test client
---+
 Reporter:  wrwrwr |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Testing framework  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  1
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+

Comment (by wrwrwr):

 Thanks again; rebased, undid the unnecessary reordering. added docs on the
 new exception and a point to the 1.8 release notes.

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

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

Re: [Django] #23873: Trying to import GIS without GEOS installed leads to obscure error message

[Django]

#23873: Trying to import GIS without GEOS installed leads to obscure error 
message
--+
 Reporter:  carljm|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  GIS   |  Version:  1.7
 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 carljm):

 Created a pull request (https://github.com/django/django/pull/3581) just
 to get CI verification that this doesn't break anything.

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

Re: [Django] #23410: Backward migrations change overall state rather than reverting single migration

[Django]

#23410: Backward migrations change overall state rather than reverting single
migration
-+-
 Reporter:  Markush2010  |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Migrations   |  Version:  1.7
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Carl Meyer ):

 In [changeset:"03e8c182888e27c7609cbc7705a46ab7b7107f12"]:
 {{{
 #!CommitTicketReference repository=""
 revision="03e8c182888e27c7609cbc7705a46ab7b7107f12"
 [1.7.x] Fixed #23410 -- Avoided unnecessary rollbacks in related apps when
 migrating backwards.

 Backport of ab2819aa7b09d36d9ff24830a9825aa52b87fdb4 from master.
 }}}

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

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

Re: [Django] #23410: Backward migrations change overall state rather than reverting single migration

[Django]

#23410: Backward migrations change overall state rather than reverting single
migration
-+-
 Reporter:  Markush2010  |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Migrations   |  Version:  1.7
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carl Meyer ):

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


Comment:

 In [changeset:"ab2819aa7b09d36d9ff24830a9825aa52b87fdb4"]:
 {{{
 #!CommitTicketReference repository=""
 revision="ab2819aa7b09d36d9ff24830a9825aa52b87fdb4"
 Fixed #23410 -- Avoided unnecessary rollbacks in related apps when
 migrating backwards.
 }}}

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

Re: [Django] #21794: No warning should be raised when defining an abstract model with no app_label

[Django]

#21794: No warning should be raised when defining an abstract model with no
app_label
-+-
 Reporter:  charettes|Owner:  aaugustin
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  master
Component:  Database layer   |   Resolution:  fixed
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:  app-loading  |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by Carl Meyer ):

 In [changeset:"ac359dc7710ed8c62b6f058fe5a0ecfd6ce27602"]:
 {{{
 #!CommitTicketReference repository=""
 revision="ac359dc7710ed8c62b6f058fe5a0ecfd6ce27602"
 [1.7.x] Fixed #21794 -- Removed deprecation warning for abstract models
 outside an app.

 Backport of e7b9a58b081299b30f807d5c66f7a5d1940efe4c from master.
 }}}

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

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

Re: [Django] #21794: No warning should be raised when defining an abstract model with no app_label

[Django]

#21794: No warning should be raised when defining an abstract model with no
app_label
-+-
 Reporter:  charettes|Owner:  aaugustin
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  master
Component:  Database layer   |   Resolution:  fixed
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:  app-loading  |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by Carl Meyer ):

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


Comment:

 In [changeset:"e7b9a58b081299b30f807d5c66f7a5d1940efe4c"]:
 {{{
 #!CommitTicketReference repository=""
 revision="e7b9a58b081299b30f807d5c66f7a5d1940efe4c"
 Fixed #21794 -- Removed deprecation warning for abstract models outside an
 app.
 }}}

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

[Django] #23874: Admin Interface: Unique constraint in gis.db.models raises Integrity Error instead of the unique error message

[Django]

#23874: Admin Interface: Unique constraint in gis.db.models raises Integrity 
Error
instead of the unique error message
-+-
 Reporter:   |  Owner:  nobody
  raratiru   | Status:  new
 Type:   |Version:  1.7
  Uncategorized  |   Keywords:  IntegrityError, Unique Constraint,
Component:  GIS  |  Admin
 Severity:  Normal   |  Has patch:  0
 Triage Stage:   |  UI/UX:  0
  Unreviewed |
Easy pickings:  0|
-+-
 models.py
 {{{
 from django.contrib.gis.db import models as geomodels

 class GeoUnique(geomodels.Model):
 geo_point = geomodels.PointField(
 unique=True,
 srid=4326
 )
 geoobjects = geomodels.GeoManager()
 }}}


 In the admin interface, if the same PointField is entered twice, an
 IntegrityError rises with a 40x Bad Request, while in any other of the
 django.db.models if the unique constraint is "on" and "activated" a
 friendly message notifies the user that the model instance cannot be
 saved.

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

Re: [Django] #21794: No warning should be raised when defining an abstract model with no app_label

[Django]

#21794: No warning should be raised when defining an abstract model with no
app_label
-+-
 Reporter:  charettes|Owner:  aaugustin
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:  app-loading  |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by aaugustin):

 Yes, let's just remove the warning for abstract models and hope that
 doesn't break too much code when we release 1.9.

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

Re: [Django] #23872: Squashmigration tests dependent on current working directory

[Django]

#23872: Squashmigration tests dependent on current working directory
-+-
 Reporter:  carljm   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.6
  (models, ORM)  |   Resolution:  fixed
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by Carl Meyer ):

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


Comment:

 In [changeset:"47b7f601eeb93bd7a91f87b77da658212f2f2314"]:
 {{{
 #!CommitTicketReference repository=""
 revision="47b7f601eeb93bd7a91f87b77da658212f2f2314"
 Fixed #23872 -- Removed sensitivity of migrations tests to CWD.
 }}}

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

Re: [Django] #23873: Trying to import GIS without GEOS installed leads to obscure error message

[Django]

#23873: Trying to import GIS without GEOS installed leads to obscure error 
message
--+
 Reporter:  carljm|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  GIS   |  Version:  1.7
 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 carljm):

 Yep, that looks pretty reasonable to me.

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

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

Re: [Django] #21794: No warning should be raised when defining an abstract model with no app_label

[Django]

#21794: No warning should be raised when defining an abstract model with no
app_label
-+-
 Reporter:  charettes|Owner:  aaugustin
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:  app-loading  |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by carljm):

 Even though there is a behavior change here (from setting `app_label` to
 something probably-bogus, to setting it to `None`), it is a change that
 quite likely won't affect anybody. And I don't think we should raise
 pending-deprecation warnings that don't have a straightforward update path
 to get rid of them.

 I would say this is like any other minor backwards-incompatible change to
 a semi-internal detail (which is arguably a bugfix anyway, as the
 currently-set value is bogus): we should just do it (that is, leave
 `app_label` as `None` for abstract models that aren't in an installed app
 and don't have it set explicitly), note it in the release notes, and be
 done.

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

Re: [Django] #23873: Trying to import GIS without GEOS installed leads to obscure error message

[Django]

#23873: Trying to import GIS without GEOS installed leads to obscure error 
message
--+
 Reporter:  carljm|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  GIS   |  Version:  1.7
 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 claudep):

 * type:  Bug => Cleanup/optimization
 * stage:  Unreviewed => Accepted


Comment:

 Maybe something like that:
 {{{
 #!diff
 diff --git a/django/contrib/gis/db/models/__init__.py
 b/django/contrib/gis/db/models/__init__.py
 index 835e907..9be4a18 100644
 --- a/django/contrib/gis/db/models/__init__.py
 +++ b/django/contrib/gis/db/models/__init__.py
 @@ -1,6 +1,15 @@
 +from django.core.exceptions import ImproperlyConfigured
 +
  # Want to get everything from the 'normal' models package.
  from django.db.models import *  # NOQA

 +from django.contrib.gis.geos import HAS_GEOS
 +
 +if not HAS_GEOS:
 +raise ImproperlyConfigured(
 +"GEOS is required and has not been detected. Are you sure it is
 installed? "
 +"See also
 https://docs.djangoproject.com/en/stable/ref/contrib/gis/install/geolibs/";)
 +
  # Geographic aggregate functions
  from django.contrib.gis.db.models.aggregates import *  # NOQA
 }}}

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

Re: [Django] #23748: inspectdb should introspect autofield

[Django]

#23748: inspectdb should introspect autofield
-+-
 Reporter:  paulcdejean  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  1.7
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:  inspectdb|  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by claudep):

 * has_patch:  0 => 1
 * stage:  Someday/Maybe => Accepted


Comment:

 PR for MySQL and PostgreSQL: https://github.com/django/django/pull/3579

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

[Django] #23873: Trying to import GIS without GEOS installed leads to obscure error message

[Django]

#23873: Trying to import GIS without GEOS installed leads to obscure error 
message
--+
   Reporter:  carljm  |  Owner:  nobody
   Type:  Bug | Status:  new
  Component:  GIS |Version:  1.7
   Severity:  Normal  |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+
 The error message is "cannot import name GEOSException."

 Given that we already calculate a `HAS_GEOS` variable, it would not be
 hard to issue a clearer message.

 Here is an example of a new user being led quite a ways down a rabbit-hole
 by the confusing message:
 https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg
 /django-users/W3IBOBTQMyU/3F8xBVMAwsYJ

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

Re: [Django] #23872: Squashmigration tests dependent on current working directory

[Django]

#23872: Squashmigration tests dependent on current working directory
-+-
 Reporter:  carljm   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.6
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  1|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-
Changes (by carljm):

 * has_patch:  0 => 1


Comment:

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

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

Re: [Django] #21163: MySQL backend: when settings.DEBUG is True, and the model instance's creation leads to a query that triggers a warning, the transaction stays uncommitted.

[Django]

#21163: MySQL backend: when settings.DEBUG is True, and  the model instance's
creation leads to a query that triggers a warning, the transaction stays
uncommitted.
-+-
 Reporter:  anonymous|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.5
  (models, ORM)  |   Resolution:  duplicate
 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 timgraham):

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


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

Re: [Django] #23871: MySQL database backend shouldn't promote warnings to exceptions in DEBUG mode

[Django]

#23871: MySQL database backend shouldn't promote warnings to exceptions in DEBUG
mode
-+-
 Reporter:  timgraham|Owner:  timgraham
 Type:   |   Status:  closed
  Cleanup/optimization   |  Version:  master
Component:  Database layer   |   Resolution:  fixed
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"5bcd292098b4de7bb03ef778e24d9e2f433d0dae"]:
 {{{
 #!CommitTicketReference repository=""
 revision="5bcd292098b4de7bb03ef778e24d9e2f433d0dae"
 Fixed #23871 -- Removed promotion of MySQL warnings to errors in DEBUG
 mode.
 }}}

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

[Django] #23872: Squashmigration tests dependent on current working directory

[Django]

#23872: Squashmigration tests dependent on current working directory
-+-
   Reporter:  carljm |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Database   |Version:  1.6
  layer (models, ORM)|   Keywords:
   Severity:  Normal |  Has patch:  0
   Triage Stage:  Accepted   |Needs tests:  0
Needs documentation:  0  |  Easy pickings:  0
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
 The tests for the squashmigrations command added in
 d18810131995dac63f9d89b0beaeadfc935130aa error when run with CWD something
 other than the `tests/` dir.

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

Re: [Django] #23850: Test failure in migrations tests

[Django]

#23850: Test failure in migrations tests
+--
 Reporter:  jphalip |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  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
+--

Comment (by carljm):

 Tried running just those two tests, using the command you gave in the last
 comment; still no failures 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/065.5ba19864b12ba448073fc3afb207f430%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23844: Use topological sort for migration operation dependency resolution

[Django]

#23844: Use topological sort for migration operation dependency resolution
-+-
 Reporter:  patrys   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  Migrations   |   Resolution:
 Severity:  Normal   | Triage Stage:  Ready for
 Keywords:   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

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


Comment:

 I left some cosmetic comments and Carl says it needs to be rebased to
 apply cleanly and commits squashed.

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

Re: [Django] #21163: MySQL backend: when settings.DEBUG is True, and the model instance's creation leads to a query that triggers a warning, the transaction stays uncommitted.

[Django]

#21163: MySQL backend: when settings.DEBUG is True, and  the model instance's
creation leads to a query that triggers a warning, the transaction stays
uncommitted.
-+-
 Reporter:  anonymous|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.5
  (models, ORM)  |   Resolution:
 Severity:  Normal   | Triage Stage:  Accepted
 Keywords:   |  Needs documentation:  0
Has patch:  0|  Patch needs improvement:  0
  Needs tests:  0|UI/UX:  0
Easy pickings:  0|
-+-

Comment (by iljamaas):

 Will be fixed by ticket #23871

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

Re: [Django] #23871: MySQL database backend shouldn't promote warnings to exceptions in DEBUG mode

[Django]

#23871: MySQL database backend shouldn't promote warnings to exceptions in DEBUG
mode
-+-
 Reporter:  timgraham|Owner:  timgraham
 Type:   |   Status:  new
  Cleanup/optimization   |  Version:  master
Component:  Database layer   |   Resolution:
  (models, ORM)  | Triage Stage:  Accepted
 Severity:  Normal   |  Needs documentation:  0
 Keywords:   |  Patch needs improvement:  0
Has patch:  1|UI/UX:  0
  Needs tests:  0|
Easy pickings:  0|
-+-

Comment (by iljamaas):

 Will fix #21163 too

 Thanx for removing

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

Re: [Django] #23778: Running tests outside the test runner needs clarification

[Django]

#23778: Running tests outside the test runner needs clarification
--+
 Reporter:  Starou|Owner:  Starou
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Documentation |  Version:  1.7
 Severity:  Normal|   Resolution:
 Keywords:  tests run_tests   | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+
Changes (by timgraham):

 * needs_better_patch:  0 => 1


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

[Django] #23871: MySQL database backend shouldn't promote warnings to exceptions in DEBUG mode

[Django]

#23871: MySQL database backend shouldn't promote warnings to exceptions in DEBUG
mode
-+-
   Reporter:  timgraham  |  Owner:  timgraham
   Type: | Status:  new
  Cleanup/optimization   |Version:  master
  Component:  Database   |   Keywords:
  layer (models, ORM)|  Has patch:  1
   Severity:  Normal |Needs tests:  0
   Triage Stage:  Accepted   |  Easy pickings:  0
Needs documentation:  0  |
Patch needs improvement:  0  |
  UI/UX:  0  |
-+-
 Quoting Aymeric in the [https://groups.google.com/d/topic/django-
 developers/FwMI7_qcXHU/discussion django-developers] thread:

 - there's absolutely no reason to be more strict in development than in
 production
 - promoting warnings to exceptions in production would be subtly
 backwards-incompatible
 - you can enable this behavior in the MySQL configuration e.g. by enabling
 Strict SQL Mode

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

Re: [Django] #15053: Make templates more reusable by Improving template loading algorithm to avoid extending infinite recursion

[Django]

#15053: Make templates more reusable by Improving template loading algorithm to
avoid extending infinite recursion
-+
 Reporter:  pmartin  |Owner:  unaizalakain
 Type:  New feature  |   Status:  assigned
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+

Comment (by prestontimmons):

 I'm waiting for Aymeric's work, now. Once the template system is
 refactored as a library it will simplify the peripheral changes in this
 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.8173fc1e730c4243500e5a65abb77f6a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23682: Stronger redirect loop detection in the test client

[Django]

#23682: Stronger redirect loop detection in the test client
---+
 Reporter:  wrwrwr |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Testing framework  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  1
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+
Changes (by prestontimmons):

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


Comment:

 Thanks for adding the pull request. I left a few comments on 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/064.8d2b83d51b676f8f0c798c019915bdd6%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23865: Document raising a `ValidationError` with a dictionary

[Django]

#23865: Document raising a `ValidationError` with a dictionary
---+--
 Reporter:  alasdairnicol  |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Documentation  |  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
---+--

Comment (by carljm):

 Pull request is at https://github.com/django/django/pull/3573

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

Re: [Django] #23780: Easy to use natural keys from a tuple on meta

[Django]

#23780: Easy to use natural keys from a tuple on meta
-+-
 Reporter:  scrummyin|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Core |  Version:  master
  (Serialization)|   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 scrummyin):

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


Comment:

 Sorry, I just realized I broke some other tests. After I broke them and
 took another look at them, I think I didn't break them, but there were
 already messed up. I have adjusted those tests for what I think is the
 proper use case. I believe in their original form the serializer output
 the models in the wrong order. I reorder the data in the test and got it
 to work. When I looked at the new order I realized that the new order
 reflected the decencies correctly. A membership had fk's to person and
 group and it should have come after those two objects. This is correctly
 reflected in the revised tests.  With this git commit
 
https://github.com/scrummyin/django/commit/ce6d437c72de478c681a934509a186cb242f84f7.

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

Re: [Django] #23714: `date` filter raises an exception for naive datetimes during DST change

[Django]

#23714: `date` filter raises an exception for naive datetimes during DST change
-+--
 Reporter:  mbertheau|Owner:  tricoder42
 Type:  Bug  |   Status:  assigned
Component:  Template system  |  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:  timezone | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by tricoder42):

 Replying to [comment:16 carljm]:
 > I'm not seeing a link to a pull request anywhere in this thread.

 It's in the ticket's header (https://github.com/django/django/pull/3576)

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

Re: [Django] #23714: `date` filter raises an exception for naive datetimes during DST change

[Django]

#23714: `date` filter raises an exception for naive datetimes during DST change
-+--
 Reporter:  mbertheau|Owner:  tricoder42
 Type:  Bug  |   Status:  assigned
Component:  Template system  |  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:  timezone | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by carljm):

 I'm not seeing a link to a pull request anywhere in this thread.

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

Re: [Django] #23714: `date` filter raises an exception for naive datetimes during DST change

[Django]

#23714: `date` filter raises an exception for naive datetimes during DST change
-+--
 Reporter:  mbertheau|Owner:  tricoder42
 Type:  Bug  |   Status:  assigned
Component:  Template system  |  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:  timezone | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by tricoder42):

 * has_patch:  0 => 1


Comment:

 I've updated the pull request, fixed also other `TimeFormat` formats.

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

[Django] #23870: Sliced QuerySets in ModelChoiceField

[Django]

#23870: Sliced QuerySets in ModelChoiceField
-+-
 Reporter:  cameel   |  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  Forms|Version:  1.6
 Severity:  Normal   |   Keywords:  modelchoicefield limit queryset
 Triage Stage:   |  slicing
  Unreviewed |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+-
 == The issue ==

 `ModelChoiceField` raises an exception if its `queryset` is a query that
 has been sliced (i.e. resolves to a SQL `SELECT` with `LIMIT`). The
 failure occurs only after form submission - during validation - so it's
 not obvious to the user if it's unsupported or if he's just using it
 incorrectly.

 This should either be fixed or documented as an unsupported use case. In
 the latter case the error should appear earlier (in field constructor?)
 and the message should tell the user explicitly that it's not supported.

 == Example ==

 Let's say you have a model called Book:

 {{{#!python
 class Book(models.Model):
 rating = models.IntegerField()
 }}}

 You want to create a form that lets user select one of the top rated
 books. So you try:

 {{{#!python
 class BookForm(forms.Form):
 book = forms.ModelChoiceField(queryset =
 Book.objects.order_by('-rating')[:100])
 }}}

 It appears to work - the form can be rendered and you can choose one of a
 hundered top-rated books. But when you submit, you get the following
 error:

 {{{
 AssertionError: Cannot filter a query once a slice has been taken.
 }}}

 The error is caused by
 
[[https://github.com/django/django/blob/bfb11b95626f39e2f5e18d97d7761c6f93dcc1a9/django/forms/models.py#L1195-L1203|`ModelChoiceField.to_python()`]]
 validating the existence of the selected item by calling `get()` on the
 queryset:

 {{{#!python
 value = self.queryset.get(**{key: value})
 }}}

 And this is not supported for sliced querysets as the error above states.

 == Workarounds ==

 To work around the problem one can make the sliced query a subquery:

 {{{#!python
 class BookForm(forms.Form):
 book = forms.ModelChoiceField(queryset = Book.objects.filter(pk__in =
 Book.objects.order_by('-rating')[:100].values_list('pk')))
 }}}

 On my machine this is about 4 times slower than a simple query with
 `LIMIT` (see the discussion thread linked below) but seems to work without
 any adverse effects.

 One nice feature of this workaround is that the outer query can have
 different ordering than the one used for slicing which might be useful in
 some cases. E.g. select top rated books but sort them by title.

 I think that it would be a good idea to mention this workaround in
 
[[https://docs.djangoproject.com/en/dev/ref/forms/fields/#django.forms.ModelChoiceField.queryset|the
 docs]].

 == Discussion ==

 Here's the discussion thread regarding the issue on django-developers
 mailing list: [[https://groups.google.com/forum/#!topic/django-
 developers/ELqU2xt_Qo0|Why doesn't ModelChoiceField.queryset support
 slicing?]]

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

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

[Django]

#23857: "Save as new" breaks when related inlines are marked to be deleted
---+--
 Reporter:  amarandon  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  1.7
 Severity:  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 jonathanmorgan):

 * cc: jonathan.morgan.007@… (added)
 * needs_better_patch:   => 0
 * needs_tests:   => 0
 * needs_docs:   => 0


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

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

Re: [Django] #22248: Model renaming doesn't work backwards

[Django]

#22248: Model renaming doesn't work backwards
--+
 Reporter:  andrewgodwin  |Owner:  andrewgodwin
 Type:  Bug   |   Status:  closed
Component:  Migrations|  Version:  master
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  1
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Tim Graham ):

 In [changeset:"50434aebe2d3307263ca55f6dd9fa7ace2f87d8f"]:
 {{{
 #!CommitTicketReference repository=""
 revision="50434aebe2d3307263ca55f6dd9fa7ace2f87d8f"
 [1.7.x] Fixed #22248 -- Made RenameModel reversible

 Backport of cf7a2a000e from master
 }}}

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

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

Re: [Django] #22248: Model renaming doesn't work backwards

[Django]

#22248: Model renaming doesn't work backwards
--+
 Reporter:  andrewgodwin  |Owner:  andrewgodwin
 Type:  Bug   |   Status:  closed
Component:  Migrations|  Version:  master
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  1
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Stratos Moros ):

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


Comment:

 In [changeset:"cf7a2a000e16b86dd721a021f1a2001529d8d707"]:
 {{{
 #!CommitTicketReference repository=""
 revision="cf7a2a000e16b86dd721a021f1a2001529d8d707"
 Fixed #22248 -- Made RenameModel reversible
 }}}

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

Re: [Django] #23865: Document raising a `ValidationError` with a dictionary

[Django]

#23865: Document raising a `ValidationError` with a dictionary
---+--
 Reporter:  alasdairnicol  |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Documentation  |  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 alasdairnicol):

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


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

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

Re: [Django] #23714: `date` filter raises an exception for naive datetimes during DST change

[Django]

#23714: `date` filter raises an exception for naive datetimes during DST change
-+--
 Reporter:  mbertheau|Owner:  tricoder42
 Type:  Bug  |   Status:  assigned
Component:  Template system  |  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:  timezone | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by tricoder42):

 Just to be precise: The problem occurs only for '''naive''' datetime
 during '''DST''' change. For other cases the timezone functions/formats
 works fine even for naive datetimes.

 And yes, we should fix all other formats as well. I'll do it later.

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

Re: [Django] #23714: `date` filter raises an exception for naive datetimes during DST change

[Django]

#23714: `date` filter raises an exception for naive datetimes during DST change
-+--
 Reporter:  mbertheau|Owner:  tricoder42
 Type:  Bug  |   Status:  assigned
Component:  Template system  |  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:  timezone | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by mbertheau):

 I'm not aware of all the circumstances that TimeFormat is given a naive
 datetime - with that caveat I think showing a warning, similar to what
 tricoder42 suggested, whenever TimeFormat gets a naive datetime. The
 warning could be similar to the datetime model field warning.

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

Re: [Django] #23714: `date` filter raises an exception for naive datetimes during DST change

[Django]

#23714: `date` filter raises an exception for naive datetimes during DST change
-+--
 Reporter:  mbertheau|Owner:  tricoder42
 Type:  Bug  |   Status:  assigned
Component:  Template system  |  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:  timezone | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by mbertheau):

 Reading the code more closely, I'm convinced, that the correct fix is to
 change TimeFormat.Z to return an empty string if given a naive datetime.
 This is in line with python's strftime, which exhibits the same behaviour.

 If you agree, then the scope of this is actually bigger: TimeFormat
 shouldn't make up a timezone for anything, if given a naive datetime. This
 then concerns TimeFormat.e, TimeFormat.O, TimeFormat.T, TimeFormat.Z and
 DateFormat.I.

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

Re: [Django] #23741: [System Check for migrations] Check presence of all foreign keys

[Django]

#23741: [System Check for migrations] Check presence of all foreign keys
--+
 Reporter:  notsqrt   |Owner:  notsqrt
 Type:  New feature   |   Status:  assigned
Component:  Core (System checks)  |  Version:  1.7
 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 notsqrt):

 Is django-developers a better place for discussion than comments in a pull
 request ?

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

Re: [Django] #23714: `date` filter raises an exception for naive datetimes during DST change

[Django]

#23714: `date` filter raises an exception for naive datetimes during DST change
-+--
 Reporter:  mbertheau|Owner:  tricoder42
 Type:  Bug  |   Status:  assigned
Component:  Template system  |  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:  timezone | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by tricoder42):

 Alright, I simplified the solution a little bit. Added explanation into
 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/067.6cd8d210c426df33c61220e88a44b0bd%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23741: [System Check for migrations] Check presence of all foreign keys

[Django]

#23741: [System Check for migrations] Check presence of all foreign keys
--+
 Reporter:  notsqrt   |Owner:  notsqrt
 Type:  New feature   |   Status:  assigned
Component:  Core (System checks)  |  Version:  1.7
 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 notsqrt):

 * owner:  nobody => notsqrt
 * 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/065.8de6f3ccd04e1867cb83fc2bf0f366a7%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23741: [System Check for migrations] Check presence of all foreign keys

[Django]

#23741: [System Check for migrations] Check presence of all foreign keys
--+
 Reporter:  notsqrt   |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Core (System checks)  |  Version:  1.7
 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 notsqrt):

 Regarding the settings, that's what I did with a local PostgreSQL DB.
 I was also wondering how Django does this in their CI platform.

 The tricky parts are:

  * I have a migrated model, I can check the DB constraints
  * I have a new/modified model, the checks must be partial or skipped, but
 how to detect this lightly ?
  * I am testing the check themselves : if I use a model that does not live
 in an app, it won't be present in the DB; otherwise I have to create an
 app with models and migrations for my tests, and this seems to be avoid if
 possible in django test suite.

 I was about to open a pull request, with these questions, so it can be
 seen by more people, to get more feedback.
 Is it a good idea ?

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

[Django] #23869: `get_deleted_objects` doesn't use `has_delete_permission`

[Django]

#23869: `get_deleted_objects` doesn't use `has_delete_permission`
---+
 Reporter:  andreage   |  Owner:  nobody
 Type:  Bug| Status:  new
Component:  contrib.admin  |Version:  1.7
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 Considering `get_deleted_objects` in `django.contrib.admin.utils`, it
 checks for deleting permission using `user.has_perm(p)`, bypassing the
 `ModelAdmin` method `has_delete_permission` assigned to the class for the
 `Model` to be deleted.

 
https://github.com/django/django/blob/stable/1.7.x/django/contrib/admin/utils.py#L141

 Therefore, even in a senario where

 {{{
 def has_delete_permission(self, request, obj=None):
 return True
 }}}

 the user is not able to delete the object, if he doesn't have the
 permission explicitly assigned for the class by an auth backend.

 A tentative idea would be to replace

 `if not user.has_perm(p):`

 with

 `if admin_site._registry[obj.__class__].has_delete_permission(request,
 obj)`

 There are though two problems:
  - `request` is not defined
  - what about `ForeignKey` objects that ought to be deleted but they exist
 in the admin panel only as `Inlines`? That is, they don't have their own
 `ModelAdmin` class 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/051.8f9cb44f0cf6b5cecdd25d79d8efe670%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #23714: `date` filter raises an exception for naive datetimes during DST change

[Django]

#23714: `date` filter raises an exception for naive datetimes during DST change
-+--
 Reporter:  mbertheau|Owner:  tricoder42
 Type:  Bug  |   Status:  assigned
Component:  Template system  |  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:  timezone | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by tricoder42):

 I understand that usually templates handle exceptions silently, printing
 nothing on error. I just don't like the idea that for one hour a year, the
 template won't display datetime at all (for naive datetimes). Yes, we're
 making a decision instead of users, but they won't know about this issue,
 since it's occurrence is so rare. This isn't a common scenario which is
 easily tested.

 Maybe at least show warning so user can see in logs what happened and why?

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

Re: [Django] #23714: `date` filter raises an exception for naive datetimes during DST change

[Django]

#23714: `date` filter raises an exception for naive datetimes during DST change
-+--
 Reporter:  mbertheau|Owner:  tricoder42
 Type:  Bug  |   Status:  assigned
Component:  Template system  |  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:  timezone | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by aaugustin):

 Replying to [comment:8 mbertheau]:
 > Instead the template code should handle AmbiguousTimeError and silently
 return an empty string.

 Yes, that is the correct fix (or at least the fix consistent with how
 Django handles ambiguous datetimes in general).

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

Re: [Django] #23778: Running tests outside the test runner needs clarification

[Django]

#23778: Running tests outside the test runner needs clarification
--+
 Reporter:  Starou|Owner:  Starou
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Documentation |  Version:  1.7
 Severity:  Normal|   Resolution:
 Keywords:  tests run_tests   | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Starou):

 [https://github.com/django/django/pull/3485/files PR] updated with a more
 elaborated example as suggested by @carljm too.

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

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

Re: [Django] #23741: [System Check for migrations] Check presence of all foreign keys

[Django]

#23741: [System Check for migrations] Check presence of all foreign keys
--+
 Reporter:  notsqrt   |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Core (System checks)  |  Version:  1.7
 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 timgraham):

 You can read about how to test using a different database in
 [https://docs.djangoproject.com/en/dev/internals/contributing/writing-code
 /unit-tests/#using-another-settings-module Using another settings module].

 I thought implementing this might be tricky, and I'm not really sure I
 have a good answer for your other questions.

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

Re: [Django] #23714: `date` filter raises an exception for naive datetimes during DST change

[Django]

#23714: `date` filter raises an exception for naive datetimes during DST change
-+--
 Reporter:  mbertheau|Owner:  tricoder42
 Type:  Bug  |   Status:  assigned
Component:  Template system  |  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:  timezone | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by mbertheau):

 I think handling AmbiguousTimeError in dateformat essentially means we're
 making a business logic decision on behalf of the implementor that we
 shouldn't make for him - his business logic might dictate a different
 decision.

 Instead the template code should handle AmbiguousTimeError and silently
 return an empty string.

 Kudos for fixing the root issue where a naive datetime was put in the
 context :) This part can surely be commit separately, because it solves
 the first problem that the technical 500 page doesn't work during DST
 change.

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

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

Re: [Django] #23714: `date` filter raises an exception for naive datetimes during DST change

[Django]

#23714: `date` filter raises an exception for naive datetimes during DST change
-+--
 Reporter:  mbertheau|Owner:  tricoder42
 Type:  Bug  |   Status:  assigned
Component:  Template system  |  Version:  1.7
 Severity:  Normal   |   Resolution:
 Keywords:  timezone | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by tricoder42):

 * owner:  nobody => tricoder42
 * status:  new => assigned
 * needs_tests:  0 => 1


Comment:

 Tests are still missings. Should be simple though.

 I don't like the fix, but can't figure out anything better. As mentioned
 in PR: The except block catching all exceptions is ugly, but I can't rely
 on pytz library, which is optional, and therefore I can't catch
 pytz.exceptions.AmbiguousTimeError exception.

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

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

[Django] #23868: dumpdata options documentation isn't correctly formatted for some options

[Django]

#23868: dumpdata options documentation isn't correctly formatted for some 
options
--+
 Reporter:  kezabelle |  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  Documentation |Version:  master
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 Specifically, [https://docs.djangoproject.com/en/dev/ref/django-admin
 /#dumpdata-app-label-app-label-app-label-model dumpdata ] gives `--format`, `--pks`, `--indent` etc their own
 headings, but `--exclude` and `--database` are formatted in such a way
 that they look like addendums to the `--indent` documentation.

 Also, `--pks` lacks a demonstrative example that `--format` and `--indent`
 provide (eg: `` or whatever). I'd suggest that example
 argument formats should also be given to `--exclude` and `--database`, if
 hoisted to headings.

 An argument could be made that because both are common options (documented
 under common options) they needn't even be covered here, I suppose, though
 given `dumpdata` exports unmanaged models (which it may not be able to)
 I'd say the `--exclude` is pertinent. If hoisting to their own headings is
 undesirable because they're already headings elsewhere, the paragraphs
 should probably be moved to the preamble which includes explaining `--all`
 as prose.

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

Re: [Django] #23866: Broken link on 403 forbidden "CSRF token missing or incorrect." page

[Django]

#23866: Broken link on 403 forbidden "CSRF token missing or incorrect." page
-+
 Reporter:  nikolas  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Documentation|  Version:  1.7
 Severity:  Release blocker  |   Resolution:
 Keywords:  csrf | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+

Comment (by claudep):

 Ritgh, we'll need something a bit more elaborate, something like `if
 'alpha' in django.VERSION or 'beta' in django.VERSION: ver = 'stable';
 else: ver = get_major_version`.

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