Re: [Django] #25621: AlterField to ForeignKey reverse migration doesn't drop the constraint

[Django]

#25621: AlterField to ForeignKey reverse migration doesn't drop the constraint
+--
 Reporter:  mgedmin |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  1.8
 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 mgedmin):

 MySQL (unfortunately).

 The actual project where I stumbled upon this is open source:
 
https://github.com/ManoSeimas/manoseimas.lt/blob/master/manoseimas/mps_v2/migrations/0029_link_suggestion_to_committeeresolution.py

 I'll try to provide a minimal example.

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

Re: [Django] #15130: Model.validate_unique method doesn't take in account multi-db

[Django]

#15130: Model.validate_unique method doesn't take in account multi-db
-+-
 Reporter:  t2y  |Owner:
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  multi-db | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by akaariai):

 Yes, that would be a step in the right direction. But using the write
 router is just a guess. There is an explicit way to tell which database to
 use when saving, so there should also be an explicit way to tell Django
 which database to use when validating.

 The solution I see as the right one is:
 {{{
   1) Use explicitly given database for validation
   2) Use write router's database for validation
   3) Use the default database for validation
 }}}

 And currently, if I'm not mistake, we have this:
 {{{
   1) Use read router's database for validation
   2) Use the default database for validation
 (here 2 is actually implemented by the router for reading)
 }}}

 So, just changing Django to use write router instead of read router as
 done in the attached patch would be an improvement, but not a complete
 solution.

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

Re: [Django] #25623: Django always returns a white page along with 400 on latin encoded URLs.

[Django]

#25623: Django always returns a white page along with 400 on latin encoded URLs.
---+
 Reporter:  shredding  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  HTTP handling  |  Version:  1.8
 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 DheerendraRathor):

 In the part mentioned by OP,

 {{{
 def get_path_info(environ):
 """
 Returns the HTTP request's PATH_INFO as a unicode string.
 """
 path_info = get_bytes_from_wsgi(environ, 'PATH_INFO', '/')

 return path_info.decode(UTF_8)
 }}}

 I changed `UTF-8 ` to `ISO_8859_1` in my local Django installation and
 then it was correctly throwing 404 instead of 400.

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

Re: [Django] #25629: Some GIS functions don't check the number of arguments

[Django]

#25629: Some GIS functions don't check the number of arguments
-+-
 Reporter:  claudep  |Owner:  sir-
 Type:   |  sigurd
  Cleanup/optimization   |   Status:  assigned
Component:  GIS  |  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 sir-sigurd):

 PR -- https://github.com/django/django/pull/5499

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

Re: [Django] #25629: Some GIS functions don't check the number of arguments

[Django]

#25629: Some GIS functions don't check the number of arguments
-+-
 Reporter:  claudep  |Owner:  sir-
 Type:   |  sigurd
  Cleanup/optimization   |   Status:  assigned
Component:  GIS  |  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 sir-sigurd):

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

Re: [Django] #25417: Add a system check for an invalid default on a model field

[Django]

#25417: Add a system check for an invalid default on a model field
-+-
 Reporter:  avorio   |Owner:  charettes
 Type:  New feature  |   Status:  closed
Component:  Core (System |  Version:  master
  checks)|
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  decimal, | Triage Stage:  Ready for
  InvalidOperation, migrations   |  checkin
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by timgraham):

 See #25628 for another issue in case this check is revisited.

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

Re: [Django] #25628: SystemCheckError states "Invalid 'default' value" when no max_length on CharField is specified.

[Django]

#25628: SystemCheckError states "Invalid 'default' value" when no max_length on
CharField is specified.
-+-
 Reporter:  zelo |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.9b1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 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 timgraham):

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


Comment:

 The "Invalid 'default'" feature was reverted in #25417.

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

Re: [Django] #25627: Django is swallowing ImportErrors in migrations for modules containing the string 'south'

[Django]

#25627: Django is swallowing ImportErrors in migrations for modules containing 
the
string 'south'
---+--
 Reporter:  gavinwahl  |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Migrations |  Version:  1.9a1
 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 timgraham):

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


Comment:

 That error message was added in #25618 but I guess reverting it won't fix
 the issue either. I think this issue affects 1.8 and 1.7 too (silently
 putting apps with such errors in `unmigrated_apps` before #25618), but
 perhaps we could backport c4af8eb366be45420e13a400cc1dcc8fab91c1ad to 1.9.
 I expect South is probably obsoleted by Django 1.9 too but I didn't want
 to backport a non-release blocker at this point without a better
 justification.

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

Re: [Django] #15130: Model.validate_unique method doesn't take in account multi-db

[Django]

#15130: Model.validate_unique method doesn't take in account multi-db
-+-
 Reporter:  t2y  |Owner:
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  multi-db | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by timgraham):

 Did you see the solution proposed in attachment:15130.2.diff? That seems
 on the right track to me. I don't see why the programmer should have to
 specify the database when we already have database routers to figure out
 where the model will 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/061.365a730321c4969ff75c25f558da1965%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #25629: Some GIS functions don't check the number of arguments

[Django]

#25629: Some GIS functions don't check the number of arguments
+
   Reporter:  claudep   |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  GIS   |Version:  master
   Severity:  Normal|   Keywords:
   Triage Stage:  Accepted  |  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 GIS functions using their parent (GeoFunc) default `__init__` don't check
 that the number of passed arguments is correct (e.g. Area). This should be
 improved, because currently, the result is a ProgrammingError when hitting
 the backend instead of a TypeError.

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

Re: [Django] #20846: Increase contrib.auth's User.username length

[Django]

#20846: Increase contrib.auth's User.username length
--+
 Reporter:  ivoras@…  |Owner:  nobody
 Type:  New feature   |   Status:  new
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 timgraham):

 * needs_better_patch:  1 => 0


Comment:

 [https://github.com/django/django/pull/5497 Updated 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/074.3cfb4b68243331808ecf1e8095026251%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #25628: SystemCheckError states "Invalid 'default' value" when no max_length on CharField is specified.

[Django]

#25628: SystemCheckError states "Invalid 'default' value" when no max_length on
CharField is specified.
--+
 Reporter:  zelo  |  Owner:  nobody
 Type:  Bug   | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.9b1
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 Using django 1.9b1 i got this message during execution of makemigrations
 command:
 {{{
 SystemCheckError: System check identified some issues:

 ERRORS:
 resources.Resource.test: (fields.E008) Invalid 'default' value: Ensure
 this value has at most %(limit_value)d characters (it has %(show_value)d).
 resources.Resource.test: (fields.E120) CharFields must define a
 'max_length' attribute.
 }}}

 With this code:
 {{{
 test = models.CharField(
 choices=(
 ('foo','bar'),
 ),
 default='foo',
 )
 }}}

 Adding max_length resolves both errors.

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

[Django] #25627: Django is swallowing ImportErrors in migrations for modules containing the string 'south'

[Django]

#25627: Django is swallowing ImportErrors in migrations for modules containing 
the
string 'south'
---+
 Reporter:  gavinwahl  |  Owner:  nobody
 Type:  Uncategorized  | Status:  new
Component:  Migrations |Version:  1.9a1
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 If I put `from mymodule import north, east, west, south,
 xxxdoesntexistxxx` in an initial migration, Django tells me:

 {{{
 django.db.migrations.exceptions.BadMigrationError: Migrated app 'foo'
 contains South migrations. Make sure all numbered South migrations are
 deleted prior to creating Django migrations.
 }}}

 I should get an ImportError so I can debug the problem.

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

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

Re: [Django] #25328: Add LiveServerTestCase that runs an HTTPS server

[Django]

#25328: Add LiveServerTestCase that runs an HTTPS server
---+
 Reporter:  jgoclawski |Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  Testing framework  |  Version:  master
 Severity:  Normal |   Resolution:  wontfix
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  0  |UI/UX:  0
---+
Changes (by timgraham):

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


Comment:

 Closing as there doesn't seem to be interest in this at this time. We can
 reopen if your third-party package sees widespread adoption. 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/068.92f4e84e6e238a6ce7e91fd9fd2a0aef%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #21489: Expose FormSet on the django.forms package.

[Django]

#21489: Expose FormSet on the django.forms package.
-+-
 Reporter:  loic84   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 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 Tim Graham ):

 In [changeset:"42f254674243928a563364389906a00303cc9a56" 42f25467]:
 {{{
 #!CommitTicketReference repository=""
 revision="42f254674243928a563364389906a00303cc9a56"
 [1.8.x] Fixed #21516 -- Updated imports paths for some formset
 functions/classes.

 Since refs #21489, FormSet classes and factories are exposed on the
 django.forms package.

 Backport of 455034d4df048010de4ae0a9a2392b70d1463c61 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/064.d3854b42082be332d1f48b38929cccd2%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #21516: Update the import path for the FormSet classes and factories in documentation.

[Django]

#21516: Update the import path for the FormSet classes and factories in
documentation.
--+
 Reporter:  loic84|Owner:  bxm156
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  1 |UI/UX:  0
--+

Comment (by Tim Graham ):

 In [changeset:"44f177b5cdab82ffefa81abd3e9c2a13aaab256f" 44f177b5]:
 {{{
 #!CommitTicketReference repository=""
 revision="44f177b5cdab82ffefa81abd3e9c2a13aaab256f"
 [1.9.x] Fixed #21516 -- Updated imports paths for some formset
 functions/classes.

 Since refs #21489, FormSet classes and factories are exposed on the
 django.forms package.

 Backport of 455034d4df048010de4ae0a9a2392b70d1463c61 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/064.d1d601be89c0579cb9a4bb41a0ba0629%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #21489: Expose FormSet on the django.forms package.

[Django]

#21489: Expose FormSet on the django.forms package.
-+-
 Reporter:  loic84   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 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 Tim Graham ):

 In [changeset:"44f177b5cdab82ffefa81abd3e9c2a13aaab256f" 44f177b5]:
 {{{
 #!CommitTicketReference repository=""
 revision="44f177b5cdab82ffefa81abd3e9c2a13aaab256f"
 [1.9.x] Fixed #21516 -- Updated imports paths for some formset
 functions/classes.

 Since refs #21489, FormSet classes and factories are exposed on the
 django.forms package.

 Backport of 455034d4df048010de4ae0a9a2392b70d1463c61 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/064.f547cde27ad134dc01414139b385e71e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #21516: Update the import path for the FormSet classes and factories in documentation.

[Django]

#21516: Update the import path for the FormSet classes and factories in
documentation.
--+
 Reporter:  loic84|Owner:  bxm156
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  1 |UI/UX:  0
--+

Comment (by Tim Graham ):

 In [changeset:"42f254674243928a563364389906a00303cc9a56" 42f25467]:
 {{{
 #!CommitTicketReference repository=""
 revision="42f254674243928a563364389906a00303cc9a56"
 [1.8.x] Fixed #21516 -- Updated imports paths for some formset
 functions/classes.

 Since refs #21489, FormSet classes and factories are exposed on the
 django.forms package.

 Backport of 455034d4df048010de4ae0a9a2392b70d1463c61 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/064.23df6bd87d5bc88b372bfbb4c6821ea3%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #21489: Expose FormSet on the django.forms package.

[Django]

#21489: Expose FormSet on the django.forms package.
-+-
 Reporter:  loic84   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 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 Tim Graham ):

 In [changeset:"455034d4df048010de4ae0a9a2392b70d1463c61" 455034d4]:
 {{{
 #!CommitTicketReference repository=""
 revision="455034d4df048010de4ae0a9a2392b70d1463c61"
 Fixed #21516 -- Updated imports paths for some formset functions/classes.

 Since refs #21489, FormSet classes and factories are exposed on the
 django.forms package.
 }}}

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

Re: [Django] #21516: Update the import path for the FormSet classes and factories in documentation.

[Django]

#21516: Update the import path for the FormSet classes and factories in
documentation.
--+
 Reporter:  loic84|Owner:  bxm156
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  1 |UI/UX:  0
--+
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"455034d4df048010de4ae0a9a2392b70d1463c61" 455034d4]:
 {{{
 #!CommitTicketReference repository=""
 revision="455034d4df048010de4ae0a9a2392b70d1463c61"
 Fixed #21516 -- Updated imports paths for some formset functions/classes.

 Since refs #21489, FormSet classes and factories are exposed on the
 django.forms package.
 }}}

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

Re: [Django] #25626: Storing big strings with special chars fails when using PostgreSQL with SQL_ASCII encoding

[Django]

#25626: Storing big strings with special chars fails when using PostgreSQL with
SQL_ASCII encoding
-+-
 Reporter:  JoseTomasTocino  |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 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 timgraham):

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


Comment:

 [https://docs.djangoproject.com/en/1.8/ref/databases/#encoding As
 documented], "Django assumes that all databases use UTF-8 encoding. Using
 other encodings may result in unexpected behavior such as “value too long”
 errors from your database for data that is valid in Django."

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

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

[Django] #25626: Storing big strings with special chars fails when using PostgreSQL with SQL_ASCII encoding

[Django]

#25626: Storing big strings with special chars fails when using PostgreSQL with
SQL_ASCII encoding
--+
 Reporter:  JoseTomasTocino   |  Owner:  nobody
 Type:  Uncategorized | Status:  new
Component:  Database layer (models, ORM)  |Version:  1.8
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 If a project uses a PostgreSQL database with SQL_ASCII encoding, a model
 with a CharField may raise a {{{DataError: value too long}}} error when
 storing strings with special characters.

 Supposing a simple model like this:

 {{{
 #!python
 class TestModel(models.Model):
 title = models.CharField(max_length=5)
 }}}

 And a PostgreSQL database called `testing` with SQL_ASCII encoding, that
 can be created using:
 {{{
 #!sql
 CREATE DATABASE testing WITH TEMPLATE = template0 ENCODING = 'SQL_ASCII';
 }}}

 If you try to add an instance of the model with a title with special
 characters it fails, even being under the length limit:

 {{{
 #!python
 TestModel.objects.create(title="ñññ")
 }}}

 {{{
 #!pytb
 Traceback (most recent call last):
   File "", line 1, in 
   File "/home/vagrant/ENV/local/lib/python2.7/site-
 packages/django/db/models/manager.py", line 127, in manager_method
 return getattr(self.get_queryset(), name)(*args, **kwargs)
   File "/home/vagrant/ENV/local/lib/python2.7/site-
 packages/django/db/models/query.py", line 348, in create
 obj.save(force_insert=True, using=self.db)
   File "/home/vagrant/ENV/local/lib/python2.7/site-
 packages/django/db/models/base.py", line 734, in save
 force_update=force_update, update_fields=update_fields)
   File "/home/vagrant/ENV/local/lib/python2.7/site-
 packages/django/db/models/base.py", line 762, in save_base
 updated = self._save_table(raw, cls, force_insert, force_update,
 using, update_fields)
   File "/home/vagrant/ENV/local/lib/python2.7/site-
 packages/django/db/models/base.py", line 846, in _save_table
 result = self._do_insert(cls._base_manager, using, fields, update_pk,
 raw)
   File "/home/vagrant/ENV/local/lib/python2.7/site-
 packages/django/db/models/base.py", line 885, in _do_insert
 using=using, raw=raw)
   File "/home/vagrant/ENV/local/lib/python2.7/site-
 packages/django/db/models/manager.py", line 127, in manager_method
 return getattr(self.get_queryset(), name)(*args, **kwargs)
   File "/home/vagrant/ENV/local/lib/python2.7/site-
 packages/django/db/models/query.py", line 920, in _insert
 return query.get_compiler(using=using).execute_sql(return_id)
   File "/home/vagrant/ENV/local/lib/python2.7/site-
 packages/django/db/models/sql/compiler.py", line 974, in execute_sql
 cursor.execute(sql, params)
   File "/home/vagrant/ENV/local/lib/python2.7/site-
 packages/django/db/backends/utils.py", line 79, in execute
 return super(CursorDebugWrapper, self).execute(sql, params)
   File "/home/vagrant/ENV/local/lib/python2.7/site-
 packages/django/db/backends/utils.py", line 64, in execute
 return self.cursor.execute(sql, params)
   File "/home/vagrant/ENV/local/lib/python2.7/site-
 packages/django/db/utils.py", line 97, in __exit__
 six.reraise(dj_exc_type, dj_exc_value, traceback)
   File "/home/vagrant/ENV/local/lib/python2.7/site-
 packages/django/db/backends/utils.py", line 64, in execute
 return self.cursor.execute(sql, params)
 DataError: value too long for type character varying(5)
 }}}

 This is particularly relevant in the admin app, where the {{{LogEntry}}}
 model has a {{{object_repr}}} field with `max_length=200` that's prone to
 fail whenever a user does something on a model with a potentially big
 `repr` string (which is exactly how I came across this bug).

 IMHO this has to do with how non-ascii characters are represented in a
 ASCII database.

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

Re: [Django] #25622: InlineAdmin raises 'GenericRel' object has no attribute 'get_related_field'

[Django]

#25622: InlineAdmin raises 'GenericRel' object has no attribute 
'get_related_field'
---+-
 Reporter:  johnraz|Owner:  charettes
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  1.8
 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 charettes):

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


Comment:

 Managed to reproduced with simplified models, thanks. Here's a
 [https://github.com/django/django/pull/5496 PR] you can test.

 I guess we should backport this since it's a bug in a new feature.

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

Re: [Django] #25622: InlineAdmin raises 'GenericRel' object has no attribute 'get_related_field'

[Django]

#25622: InlineAdmin raises 'GenericRel' object has no attribute 
'get_related_field'
---+--
 Reporter:  johnraz|Owner:  charettes
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  1.8
 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 charettes):

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


Comment:

 Will look into this soon.

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

Re: [Django] #25622: InlineAdmin raises 'GenericRel' object has no attribute 'get_related_field'

[Django]

#25622: InlineAdmin raises 'GenericRel' object has no attribute 
'get_related_field'
---+--
 Reporter:  johnraz|Owner:  charettes
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  Version:  1.8
 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
---+--

Comment (by johnraz):

 Yes you are absolutely right.
 I do have a `GenericRelation` setup like this (in addition to the previous
 example):

 {{{
 # models.py

 class AbstractModelX(models.Model):
 model_a_gen_rel = GenericRelation(SortedDocument)
 class Meta:
 abstract=True

 class ModelD(AbstractModelX):
 pass

 class ModelE(AbstractModelX):
 pass
 }}}

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

Re: [Django] #21516: Update the import path for the FormSet classes and factories in documentation.

[Django]

#21516: Update the import path for the FormSet classes and factories in
documentation.
--+
 Reporter:  loic84|Owner:  bxm156
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  1 |UI/UX:  0
--+

Comment (by bxm156):

 I have updated my changes to reflect timgraham's feedback.

 https://github.com/django/django/pull/5492

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

Re: [Django] #25621: AlterField to ForeignKey reverse migration doesn't drop the constraint

[Django]

#25621: AlterField to ForeignKey reverse migration doesn't drop the constraint
+--
 Reporter:  mgedmin |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  1.8
 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 timgraham):

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


Comment:

 What database are you using? Could you provide a complete minimal project
 that reproduces 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/065.471b02fc564a278d51727a762be0d7fd%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25625: Old version of pip reports SyntaxError with Django 1.9+ (was: Invalid Syntax Error.)

[Django]

#25625: Old version of pip reports SyntaxError with Django 1.9+
-+--
 Reporter:  un33k|Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Core (Other) |  Version:  1.9b1
 Severity:  Release blocker  |   Resolution:  duplicate
 Keywords:  Syntax   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by timgraham):

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


Comment:

 Duplicate of #25584

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

[Django] #25625: Invalid Syntax Error.

[Django]

#25625: Invalid Syntax Error.
-+
 Reporter:  un33k|  Owner:  nobody
 Type:  Uncategorized| Status:  new
Component:  Core (Other) |Version:  1.9b1
 Severity:  Release blocker  |   Keywords:  Syntax
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 There is a syntax error in the following file during installation.
 Installation completes though.

 django/django/conf/app_template/models.py", line 1
 {{ unicode_literals }}from django.db import models
 SyntaxError: invalid syntax

 Successfully installed django
 Cleaning up...

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

Re: [Django] #25625: Invalid Syntax Error.

[Django]

#25625: Invalid Syntax Error.
-+--
 Reporter:  un33k|Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Core (Other) |  Version:  1.9b1
 Severity:  Release blocker  |   Resolution:
 Keywords:  Syntax   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by un33k):

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


Comment:

 Installation was attempted on:

 Python 3.4.1 (default, Nov 19 2014, 22:20:47)
 [GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.54)] on darwin
 Type "help", "copyright", "credits" or "license" for more information.

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

Re: [Django] #25625: Invalid Syntax Error.

[Django]

#25625: Invalid Syntax Error.
-+
 Reporter:  un33k|  Owner:  nobody
 Type:  Uncategorized| Status:  new
Component:  Core (Other) |Version:  1.9b1
 Severity:  Release blocker  | Resolution:
 Keywords:  Syntax   |   Triage Stage:  Unreviewed
Has patch:  0|  Easy pickings:  0
UI/UX:  0|
-+
Changes (by un33k):

 * Attachment "error-log.txt" 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/063.4d33bb6c2939525ce50cc1eb1146eabf%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #21516: Update the import path for the FormSet classes and factories in documentation.

[Django]

#21516: Update the import path for the FormSet classes and factories in
documentation.
--+
 Reporter:  loic84|Owner:  bxm156
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  1 |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.eccc50ac3006c2311ae7c3c524466c96%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25622: InlineAdmin raises 'GenericRel' object has no attribute 'get_related_field'

[Django]

#25622: InlineAdmin raises 'GenericRel' object has no attribute 
'get_related_field'
---+--
 Reporter:  johnraz|Owner:  charettes
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  Version:  1.8
 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
---+--

Comment (by charettes):

 Do you have a `django.contrib.contenttypes.fields.GenericRelation` defined
 somewhere?

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

Re: [Django] #25622: InlineAdmin raises 'GenericRel' object has no attribute 'get_related_field'

[Django]

#25622: InlineAdmin raises 'GenericRel' object has no attribute 
'get_related_field'
---+--
 Reporter:  johnraz|Owner:  charettes
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  Version:  1.8
 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 charettes):

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


Comment:

 Hi johnraz,

 This looks like a legitimate traceback but I cannot reproduce with your
 provided setup against `1.8.x` and `master`.

 Can you confirm [https://github.com/charettes/django-
 ticketing/tree/master/ticket_25622 I didn't miss something]?

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

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

Re: [Django] #25623: Django always returns a white page along with 400 on latin encoded URLs.

[Django]

#25623: Django always returns a white page along with 400 on latin encoded URLs.
---+
 Reporter:  shredding  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  HTTP handling  |  Version:  1.8
 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 timgraham):

 * component:  Core (URLs) => HTTP handling
 * 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/067.048a0413f1af907d6199152c89a41a2b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25624: Autoreload fails if jinja2.ModuleLoader used

[Django]

#25624: Autoreload fails if jinja2.ModuleLoader used
-+-
 Reporter:  svartalf |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Utilities|  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:  autoreload, jinja2,  | Triage Stage:  Accepted
  ModuleLoader   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

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


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

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

Re: [Django] #25600: Template `if` tag behavior change with 1.8, OneToOneField, RelatedObjectDoesNotExist is True?

[Django]

#25600: Template `if` tag behavior change with 1.8, OneToOneField,
RelatedObjectDoesNotExist is True?
-+
 Reporter:  syphar   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Template system  |  Version:  1.8
 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 timgraham):

 The `RelatedObjectDoesNotExist` exception is a subclass of
 `AttributeError` -- that's why it's hitting that logic added in the commit
 noted in the previous comment. We end up checking `{% if
  %}` which passes for a non-empty `string_if_invalid`.
 I'm not sure we should add special handling of `RelatedObjectDoesNotExist`
 in the template engine to restore the old behavior (and I'm not sure how
 to since `RelatedObjectDoesNotExist` is a dynamically generated exception
 based on the related descriptors).

 I think the usage of `string_if_invalid` is somewhat
 unreliable/unpredictable anyway and therefore discouraged but I'm not too
 sure as I haven't used it myself.

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

[Django] #25624: Autoreload fails if jinja2.ModuleLoader used

[Django]

#25624: Autoreload fails if jinja2.ModuleLoader used
+--
 Reporter:  svartalf|  Owner:  nobody
 Type:  Bug | Status:  new
Component:  Utilities   |Version:  1.8
 Severity:  Normal  |   Keywords:  autoreload, jinja2, ModuleLoader
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+--
 It happens because `jinja2.ModuleLoader` injects a weakref to a fake
 module into a sys.modules:
 
https://github.com/mitsuhiko/jinja2/blob/f6b654de615de61a9ca79e7ccecf7b4a8bf90ec0/jinja2/loaders.py#L439-L449

 So, because weakref is not a hashable object, autoreload fails.

 {{{
 Traceback (most recent call last):
   File "bug/manage.py", line 10, in 
 execute_from_command_line(sys.argv)
   File "/home/svartalf/projects/dj-module-loader-
 bug/.env/local/lib/python2.7/site-
 packages/django/core/management/__init__.py", line 351, in
 execute_from_command_line
 utility.execute()
   File "/home/svartalf/projects/dj-module-loader-
 bug/.env/local/lib/python2.7/site-
 packages/django/core/management/__init__.py", line 343, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "/home/svartalf/projects/dj-module-loader-
 bug/.env/local/lib/python2.7/site-
 packages/django/core/management/base.py", line 394, in run_from_argv
 self.execute(*args, **cmd_options)
   File "/home/svartalf/projects/dj-module-loader-
 bug/.env/local/lib/python2.7/site-
 packages/django/core/management/commands/runserver.py", line 49, in
 execute
 super(Command, self).execute(*args, **options)
   File "/home/svartalf/projects/dj-module-loader-
 bug/.env/local/lib/python2.7/site-
 packages/django/core/management/base.py", line 445, in execute
 output = self.handle(*args, **options)
   File "/home/svartalf/projects/dj-module-loader-
 bug/.env/local/lib/python2.7/site-
 packages/django/core/management/commands/runserver.py", line 88, in handle
 self.run(**options)
   File "/home/svartalf/projects/dj-module-loader-
 bug/.env/local/lib/python2.7/site-
 packages/django/core/management/commands/runserver.py", line 97, in run
 autoreload.main(self.inner_run, None, options)
   File "/home/svartalf/projects/dj-module-loader-
 bug/.env/local/lib/python2.7/site-packages/django/utils/autoreload.py",
 line 336, in main
 reloader(wrapped_main_func, args, kwargs)
   File "/home/svartalf/projects/dj-module-loader-
 bug/.env/local/lib/python2.7/site-packages/django/utils/autoreload.py",
 line 302, in python_reloader
 reloader_thread()
   File "/home/svartalf/projects/dj-module-loader-
 bug/.env/local/lib/python2.7/site-packages/django/utils/autoreload.py",
 line 278, in reloader_thread
 change = fn()
   File "/home/svartalf/projects/dj-module-loader-
 bug/.env/local/lib/python2.7/site-packages/django/utils/autoreload.py",
 line 207, in code_changed
 for filename in gen_filenames():
   File "/home/svartalf/projects/dj-module-loader-
 bug/.env/local/lib/python2.7/site-packages/django/utils/autoreload.py",
 line 94, in gen_filenames
 module_values = set(sys.modules.values())
 TypeError: unhashable type: 'weakproxy'
 }}}

 I had reproduced this bug with a clean project and following environment:
 {{{
 Python 2.7.6

 $ pip freeze
 Django==1.8.5
 Jinja2==2.7.3
 MarkupSafe==0.23
 argparse==1.2.1
 wsgiref==0.1.2
 }}}

 Template settings:
 {{{
 template_loader = jinja2.ModuleLoader('compiled_templates')
 TEMPLATES = [
 {
 'BACKEND': 'django.template.backends.jinja2.Jinja2',
 'DIRS': [os.path.join(BASE_DIR, 'templates')],
 'APP_DIRS': True,
 'OPTIONS': {
 'loader': template_loader,
 },
 },
 ]
 }}}

 P.S. Not sure if it is an "Utilities" or a "Template system" component.

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

Re: [Django] #25623: Django always returns a white page along with 400 on latin encoded URLs.

[Django]

#25623: Django always returns a white page along with 400 on latin encoded URLs.
-+--
 Reporter:  shredding|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (URLs)  |  Version:  1.8
 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 shredding):

 For what it's worth:

 Pyramid raises a 500 (http://www.pylonsproject.org/Raumh%F6he.htm)  (error
 code: URLDecodeError: 'utf8' codec can't decode byte 0xf6 in position 11:
 invalid start byte (urldispatch.py, line 86)

 Flask handles it correctly.

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

[Django] #25623: Django always returns a white page along with 400 on latin encoded URLs.

[Django]

#25623: Django always returns a white page along with 400 on latin encoded URLs.
-+
 Reporter:  shredding|  Owner:  nobody
 Type:  Bug  | Status:  new
Component:  Core (URLs)  |Version:  1.8
 Severity:  Normal   |   Keywords:
 Triage Stage:  Unreviewed   |  Has patch:  0
Easy pickings:  0|  UI/UX:  0
-+
 Given a URL like /Raumh%F6he.htm served with gunicorn and waitress (maybe
 others as well), django raises a UnicodeDecodeError here:

 https://github.com/django/django/blob/master/django/core/handlers/wsgi.py#L200

 ... which ends up in serving a white page with a 400 (sample:
 https://www.djangoproject.com/Raumh%F6he.htm)

 This does not happen with the built in runserver command, because it
 double encodes the query, as far as I understand:

 
https://github.com/django/django/blob/master/django/core/servers/basehttp.py#L154-L157

 Gunicorn on the other hand is explicitly casting to latin:

 https://github.com/benoitc/gunicorn/blob/master/gunicorn/_compat.py#L82

 ... which leads to the error as django is explicitly expecting utf-8.

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

Re: [Django] #25623: Django always returns a white page along with 400 on latin encoded URLs.

[Django]

#25623: Django always returns a white page along with 400 on latin encoded URLs.
-+--
 Reporter:  shredding|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (URLs)  |  Version:  1.8
 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 shredding):

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


Old description:

> Given a URL like /Raumh%F6he.htm served with gunicorn and waitress (maybe
> others as well), django raises a UnicodeDecodeError here:
>
> https://github.com/django/django/blob/master/django/core/handlers/wsgi.py#L200
>
> ... which ends up in serving a white page with a 400 (sample:
> https://www.djangoproject.com/Raumh%F6he.htm)
>
> This does not happen with the built in runserver command, because it
> double encodes the query, as far as I understand:
>
> https://github.com/django/django/blob/master/django/core/servers/basehttp.py#L154-L157
>
> Gunicorn on the other hand is explicitly casting to latin:
>
> https://github.com/benoitc/gunicorn/blob/master/gunicorn/_compat.py#L82
>
> ... which leads to the error as django is explicitly expecting utf-8.

New description:

 Given a URL like /Raumh%F6he served with gunicorn and waitress (maybe
 others as well), django raises a UnicodeDecodeError here:

 https://github.com/django/django/blob/master/django/core/handlers/wsgi.py#L200

 ... which ends up in serving a white page with a 400 (sample:
 https://www.djangoproject.com/Raumh%F6he)

 This does not happen with the built in runserver command, because it
 double encodes the query, as far as I understand:

 
https://github.com/django/django/blob/master/django/core/servers/basehttp.py#L154-L157

 Gunicorn on the other hand is explicitly casting to latin:

 https://github.com/benoitc/gunicorn/blob/master/gunicorn/_compat.py#L82

 ... which leads to the error as django is explicitly expecting utf-8.

--

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

Re: [Django] #25622: InlineAdmin raises 'GenericRel' object has no attribute 'get_related_field'

[Django]

#25622: InlineAdmin raises 'GenericRel' object has no attribute 
'get_related_field'
---+--
 Reporter:  johnraz|Owner:  charettes
 Type:  Bug|   Status:  assigned
Component:  contrib.admin  |  Version:  1.8
 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 charettes):

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

Re: [Django] #25588: Add spatial lookups to RasterField

[Django]

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

Comment (by Claude Paroz ):

 In [changeset:"48548d1a473a40adeaf292b63857efdd00a034be" 48548d1]:
 {{{
 #!CommitTicketReference repository=""
 revision="48548d1a473a40adeaf292b63857efdd00a034be"
 Refs #25588 -- Added the srid property to GDALRaster

 Geometry objects have an srid property, so this addition makes the raster
 api
 more similar to the geometries api.
 }}}

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

Re: [Django] #25618: Django migration system breaks with unhelpful error message if south migrations accidentally retained

[Django]

#25618: Django migration system breaks with unhelpful error message if south
migrations accidentally retained
---+
 Reporter:  ryuusenshi |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Migrations |  Version:  1.7
 Severity:  Normal |   Resolution:  fixed
 Keywords:  migrations, south  | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+

Comment (by Tim Graham ):

 In [changeset:"e5ab75d2fda8ef2617bc13074206e66c980ca51f" e5ab75d2]:
 {{{
 #!CommitTicketReference repository=""
 revision="e5ab75d2fda8ef2617bc13074206e66c980ca51f"
 Refs #25618 -- Forwardported 1.8.6 release note.

 Forwardport of 65bff161ffab1310719bdee495d1e9b35f838c31 from stable/1.8.x
 }}}

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

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

Re: [Django] #25618: Django migration system breaks with unhelpful error message if south migrations accidentally retained

[Django]

#25618: Django migration system breaks with unhelpful error message if south
migrations accidentally retained
---+
 Reporter:  ryuusenshi |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Migrations |  Version:  1.7
 Severity:  Normal |   Resolution:  fixed
 Keywords:  migrations, south  | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"65bff161ffab1310719bdee495d1e9b35f838c31" 65bff16]:
 {{{
 #!CommitTicketReference repository=""
 revision="65bff161ffab1310719bdee495d1e9b35f838c31"
 [1.8.x] Fixed #25618 -- Added a helpful error message when Django & south
 migrations exist in the same directory.
 }}}

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

Re: [Django] #25618: Django migration system breaks with unhelpful error message if south migrations accidentally retained

[Django]

#25618: Django migration system breaks with unhelpful error message if south
migrations accidentally retained
---+
 Reporter:  ryuusenshi |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Migrations |  Version:  1.7
 Severity:  Normal |   Resolution:  fixed
 Keywords:  migrations, south  | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+

Comment (by Tim Graham ):

 In [changeset:"774a893d0bf3433571a94cd27883fab61010440a" 774a893]:
 {{{
 #!CommitTicketReference repository=""
 revision="774a893d0bf3433571a94cd27883fab61010440a"
 [1.9.x] Fixed #25618 -- Added a helpful error message when Django & south
 migrations exist in the same directory.

 Forwardport of 65bff161ffab1310719bdee495d1e9b35f838c31 from stable/1.8.x
 }}}

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

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

Re: [Django] #25605: GeoDjango DB functions doesn't really work with expressions

[Django]

#25605: GeoDjango DB functions doesn't really work with expressions
+--
 Reporter:  sir-sigurd  |Owner:  sir-sigurd
 Type:  Bug |   Status:  assigned
Component:  GIS |  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 sir-sigurd):

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

Re: [Django] #25620: URLValidator regex does not trigger on consecutive periods

[Django]

#25620: URLValidator regex does not trigger on consecutive periods
--+
 Reporter:  sully90h  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Core (Other)  |  Version:  1.8
 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 timgraham):

 * has_patch:  0 => 1


Comment:

 Could you submit the patch as 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/066.3c41391938466ad37bf17f92ee1ba190%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25618: Django migration system breaks with unhelpful error message if south migrations accidentally retained

[Django]

#25618: Django migration system breaks with unhelpful error message if south
migrations accidentally retained
---+
 Reporter:  ryuusenshi |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Migrations |  Version:  1.7
 Severity:  Normal |   Resolution:
 Keywords:  migrations, south  | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+

Comment (by Tim Graham ):

 In [changeset:"c4af8eb366be45420e13a400cc1dcc8fab91c1ad" c4af8eb]:
 {{{
 #!CommitTicketReference repository=""
 revision="c4af8eb366be45420e13a400cc1dcc8fab91c1ad"
 Refs #25618 -- Removed detection of south migrations in loader.

 It doesn't seem relevant for anyone upgrading to Django 1.10
 and beyond.
 }}}

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

[Django] #25622: InlineAdmin raises 'GenericRel' object has no attribute 'get_related_field'

[Django]

#25622: InlineAdmin raises 'GenericRel' object has no attribute 
'get_related_field'
---+
 Reporter:  johnraz|  Owner:  nobody
 Type:  Bug| Status:  new
Component:  contrib.admin  |Version:  1.8
 Severity:  Normal |   Keywords:
 Triage Stage:  Unreviewed |  Has patch:  0
Easy pickings:  0  |  UI/UX:  0
---+
 I have the following setup (simplified for the sake of clarity)

 {{{
 # models.py
 class ModelA(models.Model):
 content_type = models.ForeignKey(ContentType)
 object_id = models.PositiveIntegerField()
 content_object = GenericForeignKey('content_type', 'object_id')
 uuid = models.UUIDField(default=uuid.uuid4, unique=True,
 db_index=True)

 class ModelB(models.Model):
 model_a_fk = models.ForeignKey('ModelA', to_field='uuid')
 model_c_fk = models.ForeignKey('ModelC')

 class ModelC(models.Model):
 ... # nothing fancy
 }}}


 {{{
 #admin.py
 class ModelAAdmin(admin.ModelAdmin):
  #nothing fancy

 class InlineModelB(admin.TabularInline):
  model=ModelB
  raw_id_fields=('model_a_fk', 'model_c_fk')

 class ModelBAdmin(admin.ModelAdmin):
  raw_id_fields=('model_a_fk', 'model_c_fk')

 class ModelCAdmin(admin.ModelAdmin):
  inlines=(InlineModelB,)
 }}}

 Now, when going to the `ModelCAdmin` view, triggering the search pop-up
 for `ModelB.model_a_fk` field, I will get the following traceback:


 {{{
   File "/usr/local/lib/python2.7/dist-
 packages/django/core/handlers/base.py", line 132, in get_response
 response = wrapped_callback(request, *callback_args,
 **callback_kwargs)
   File "/usr/local/lib/python2.7/dist-
 packages/django/contrib/admin/options.py", line 616, in wrapper
 return self.admin_site.admin_view(view)(*args, **kwargs)
   File "/usr/local/lib/python2.7/dist-
 packages/django/utils/decorators.py", line 110, in _wrapped_view
 response = view_func(request, *args, **kwargs)
   File "/usr/local/lib/python2.7/dist-
 packages/django/views/decorators/cache.py", line 57, in _wrapped_view_func
 response = view_func(request, *args, **kwargs)
   File "/usr/local/lib/python2.7/dist-
 packages/django/contrib/admin/sites.py", line 233, in inner
 return view(request, *args, **kwargs)
   File "/usr/local/lib/python2.7/dist-
 packages/django/utils/decorators.py", line 34, in _wrapper
 return bound_func(*args, **kwargs)
   File "/usr/local/lib/python2.7/dist-
 packages/django/utils/decorators.py", line 110, in _wrapped_view
 response = view_func(request, *args, **kwargs)
   File "/usr/local/lib/python2.7/dist-
 packages/django/utils/decorators.py", line 30, in bound_func
 return func.__get__(self, type(self))(*args2, **kwargs2)
   File "/usr/local/lib/python2.7/dist-
 packages/django/contrib/admin/options.py", line 1548, in changelist_view
 self.list_max_show_all, self.list_editable, self)
   File "/usr/local/lib/python2.7/dist-
 packages/django/contrib/admin/views/main.py", line 67, in __init__
 if to_field and not model_admin.to_field_allowed(request, to_field):
   File "/usr/local/lib/python2.7/dist-
 packages/django/contrib/admin/options.py", line 489, in to_field_allowed
 related_object.field.rel.get_related_field() == field):
 AttributeError: 'GenericRel' object has no attribute 'get_related_field'
 }}}

 Triggering the search pop-up for `ModelB.model_c_fk` works just fine.

 It looks like https://code.djangoproject.com/ticket/23616 but in a
 different place.

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

Re: [Django] #25619: Since Django ~1.6.4 the dev runserver uses http_version 1.0, before it was 1.1

[Django]

#25619: Since Django ~1.6.4 the dev runserver uses http_version 1.0, before it 
was
1.1
---+
 Reporter:  gabn88 |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  HTTP handling  |  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 claudep):

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


Comment:

 Looks like that change would be required:
 {{{
 #!patch
 diff --git a/django/core/servers/basehttp.py
 b/django/core/servers/basehttp.py
 index 4e2f8dd..1e0f0c2 100644
 --- a/django/core/servers/basehttp.py
 +++ b/django/core/servers/basehttp.py
 @@ -86,6 +86,7 @@ class WSGIServer(simple_server.WSGIServer, object):

  # Inheriting from object required on Python 2.
  class ServerHandler(simple_server.ServerHandler, object):
 +http_version = "1.1"
  def handle_error(self):
  # Ignore broken pipe errors, otherwise pass on
  if not is_broken_pipe_error():
 }}}

 However, I didn't find the possible faulty commit.

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

[Django] #25621: AlterField to ForeignKey reverse migration doesn't drop the constraint

[Django]

#25621: AlterField to ForeignKey reverse migration doesn't drop the constraint
+
 Reporter:  mgedmin |  Owner:  nobody
 Type:  Bug | Status:  new
Component:  Migrations  |Version:  1.8
 Severity:  Normal  |   Keywords:
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+
 I'm changing a data model that had a
 {{{
 source_id = CharField()
 }}}
 field to a
 {{{
 source_resolution = ForeignKey(CommitteeResolution, db_column='source_id',
 to_field='source_id')
 }}}
 so that my database schema remains the same, but now the column is a
 foreign key reference to another table.

 I've adjusted the migrations file manually to avoid dropping/re-creating
 columns.  The migration looks like this now:
 {{{
 operations = [
 migrations.AlterField(
 model_name='suggestion',
 name='source_id',
 field=models.ForeignKey(db_column=b'source_id',
 to_field=b'source_id', to='mps_v2.CommitteeResolution'),
 preserve_default=False,
 ),
 migrations.RenameField(
 model_name='suggestion',
 old_name='source_id',
 new_name='source_resolution',
 ),
 migrations.AlterUniqueTogether(
 name='suggestion',
 unique_together=set([('source_resolution', 'source_index')]),
 ),
 ]
 }}}

 The forward migration is exactly as I expect it to be:

 {{{
 $ django-admin sqlmigrate mps_v2 0029
 BEGIN;
 ALTER TABLE `mps_v2_suggestion` ADD CONSTRAINT
 `D58bb2cf0b1407c8c24fa06b0cc34f38` FOREIGN KEY (`source_id`) REFERENCES
 `mps_v2_committeeresolution` (`source_id`);

 COMMIT;
 }}}

 I expect the reverse migration to drop the constraint.

 It doesn't:

 {{{
 $ django-admin sqlmigrate mps_v2 0029 --backwards
 }}}

 (there's no output).

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

Re: [Django] #25619: Since Django ~1.6.4 the dev runserver uses http_version 1.0, before it was 1.1

[Django]

#25619: Since Django ~1.6.4 the dev runserver uses http_version 1.0, before it 
was
1.1
---+--
 Reporter:  gabn88 |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  HTTP handling  |  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 claudep):

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


Comment:

 Oh, sorry, I didn't pay attention to the `runserver` part...

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

Re: [Django] #25619: Since Django ~1.6.4 the dev runserver uses http_version 1.0, before it was 1.1

[Django]

#25619: Since Django ~1.6.4 the dev runserver uses http_version 1.0, before it 
was
1.1
---+--
 Reporter:  gabn88 |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  HTTP handling  |  Version:  1.7
 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 claudep):

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


Comment:

 I cannot confirm this, I've checked with one of my site with Django 1.8
 and the response was `HTTP/1.1 200 OK`.
 By the way, this is probably controlled by the Web server, not Django.

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

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

Re: [Django] #25620: URLValidator regex does not trigger on consecutive periods

[Django]

#25620: URLValidator regex does not trigger on consecutive periods
--+
 Reporter:  sully90h  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Core (Other)  |  Version:  1.8
 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 DheerendraRathor):

 * Attachment "0001-Fixed-25620-Changed-to-in-domain-name-regex.patch"
 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/066.416f977dda7abcca0714372b4235c0b7%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.