Re: [Django] #27563: Move "Apply limit_choices_to" code from BaseModelForm to fields_for_model()

[Django]

#27563: Move "Apply limit_choices_to" code from BaseModelForm to 
fields_for_model()
-+-
 Reporter:  Jon Dufresne |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:
 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 Claude Paroz):

 * stage:  Unreviewed => Ready for checkin


Comment:

 Looks good!

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

Re: [Django] #27561: Add Oracle support for binary "or" operator

[Django]

#27561: Add Oracle support for binary "or" operator
-+-
 Reporter:  felixxm  |Owner:  felixxm
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 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 felixxm):

 * has_patch:  0 => 1


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

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

Re: [Django] #27563: Move "Apply limit_choices_to" code from BaseModelForm to fields_for_model()

[Django]

#27563: Move "Apply limit_choices_to" code from BaseModelForm to 
fields_for_model()
-+-
 Reporter:  Jon Dufresne |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Forms|  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 Jon Dufresne):

 * has_patch:  0 => 1


Comment:

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

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

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

[Django] #27563: Move "Apply limit_choices_to" code from BaseModelForm to fields_for_model()

[Django]

#27563: Move "Apply limit_choices_to" code from BaseModelForm to 
fields_for_model()
+
   Reporter:  Jon Dufresne  |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Forms |Version:  master
   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 |
+
 I frequently use `fields_for_model()` to generate form fields dynamically
 on a model form. The form may have different fields based on the request,
 system settings,  or other input. Using `fields_for_model()` is very
 convenient to build these dynamic fields. For the most part, it is built
 consistently had the field originally been defined on `Meta.fields`.

 One shortfall I noticed, `limit_choices_to` is not applied to form field
 querysets the way it typically is for `ModelForm`s. To make the
 `fields_for_model()` function more convenient and consistent with fields
 generated by `ModelForm`, I'd like to suggest moving the "Apply
 limit_choices_to" code from `BaseModelForm` to `fields_for_model()`.

 Currently here:
 
https://github.com/django/django/blob/3507d4e773aa9ff2336e7230ba231c4ba6eb568f/django/forms/models.py#L294-L300

 Suggested location:
 
https://github.com/django/django/blob/3507d4e773aa9ff2336e7230ba231c4ba6eb568f/django/forms/models.py#L172-L173

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

Re: [Django] #27562: Django using uuid as primary key, receive AttributeError during createsuperuser(NOT AN ISSUE) (was: Django using uuid as primary key, receive AttributeError during createsuperuser

[Django]

#27562: Django using uuid as primary key, receive AttributeError during
createsuperuser(NOT AN ISSUE)
-+-
 Reporter:  Sean, Liu Diansheng  |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  Uncategorized|  Version:  1.10
 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 Sean, Liu Diansheng):

 * status:  new => closed
 * resolution:   => invalid
 * type:  Bug => Uncategorized


Comment:

 I restarted mysql, delete all migrations and databases, the issue is gone.
 It is not a bug.

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

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

Re: [Django] #27562: Django using uuid as primary key, receive AttributeError during createsuperuser

[Django]

#27562: Django using uuid as primary key, receive AttributeError during
createsuperuser
-+-
 Reporter:  Sean, Liu Diansheng  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Uncategorized|  Version:  1.10
 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
-+-
Description changed by Sean, Liu Diansheng:

Old description:

> I am using uuid as the primary key for my CustomerUser model which is to
> override the default django user. I got an AttributeError when trying to
> run `./manage.py createsuperuser`
>
> Here is my model.
> `
> class CustomUser(AbstractUser):
> id = models.UUIDField(primary_key=True, default=uuid.uuid4,
> editable=False)
> user_type = models.CharField(max_length=1, choices=TYPE_USER,
> default='U')
> is_deleted = models.BooleanField(_('deleted'), default=False)
> `
> Software version: django version 1.10.2 and python version 2.7.10
>
> And this is the exception
>
> `
> value = uuid.UUID(value)
>   File
> "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/uuid.py",
> line 131, in __init__
> hex = hex.replace('urn:', '').replace('uuid:', '')
> AttributeError: 'long' object has no attribute 'replace'
> `

New description:

 I am using '''uuid as the primary key''' for my ''CustomerUser model''
 which is to override the default django user. I got an AttributeError when
 trying to run `./manage.py createsuperuser`

 Here is my model.
 {{{
 class CustomUser(AbstractUser):
 id = models.UUIDField(primary_key=True, default=uuid.uuid4,
 editable=False)
 user_type = models.CharField(max_length=1, choices=TYPE_USER,
 default='U')
 is_deleted = models.BooleanField(_('deleted'), default=False)
 }}}
 Software version: django version 1.10.2 and python version 2.7.10

 And this is the exception

 {{{
 value = uuid.UUID(value)
   File
 
"/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/uuid.py",
 line 131, in __init__
 hex = hex.replace('urn:', '').replace('uuid:', '')
 AttributeError: 'long' object has no attribute 'replace'
 }}}

--

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

[Django] #27562: Django using uuid as primary key, receive AttributeError during createsuperuser

[Django]

#27562: Django using uuid as primary key, receive AttributeError during
createsuperuser
-+
   Reporter:  diansheng  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Uncategorized  |Version:  1.10
   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  |
-+
 I am using uuid as the primary key for my CustomerUser model which is to
 override the default django user. I got an AttributeError when trying to
 run `./manage.py createsuperuser`

 Here is my model.
 `
 class CustomUser(AbstractUser):
 id = models.UUIDField(primary_key=True, default=uuid.uuid4,
 editable=False)
 user_type = models.CharField(max_length=1, choices=TYPE_USER,
 default='U')
 is_deleted = models.BooleanField(_('deleted'), default=False)
 `
 Software version: django version 1.10.2 and python version 2.7.10

 And this is the exception

 `
 value = uuid.UUID(value)
   File
 
"/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/uuid.py",
 line 131, in __init__
 hex = hex.replace('urn:', '').replace('uuid:', '')
 AttributeError: 'long' object has no attribute 'replace'
 `

--
Ticket URL: 
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.7046483d3de59efe4cccb7b3a7e8e7da%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:  Tetsuya Morimoto |Owner:  (none)
 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 Simon Charette):

 Replying to [comment:19 Michel Perez]:
 > Is this already fixed?, I'm still having this problem using
 Django==1.10.3 and Python 3.5

 This has not been fixed yet.

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

Re: [Django] #25753: Cache formats retrieved from django settings in formats.get_format

[Django]

#25753: Cache formats retrieved from django settings in formats.get_format
--+
 Reporter:  Jaap Roes |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Utilities |  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 Claude Paroz):

 * needs_better_patch:  1 => 0


Comment:

 New [https://github.com/django/django/pull/7649 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/063.bc467c3059813139110cfb12dbfe1e4e%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:  Tetsuya Morimoto |Owner:  (none)
 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 Michel Perez):

 Is this already fixed?, I'm still having this problem using Django==1.10.3
 and Python 3.5

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

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

Re: [Django] #27561: Add Oracle support for binary "or" operator

[Django]

#27561: Add Oracle support for binary "or" operator
-+-
 Reporter:  felixxm  |Owner:  felixxm
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 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 felixxm):

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

[Django] #27561: Add Oracle support for binary "or" operator

[Django]

#27561: Add Oracle support for binary "or" operator
-+-
   Reporter:  felixxm|  Owner:  felixxm
   Type:  New| Status:  assigned
  feature|
  Component:  Database   |Version:  master
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-


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

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

Re: [Django] #25874: allow GEOSGeometry to read SRID from GeoJSON input

[Django]

#25874: allow GEOSGeometry to read SRID from GeoJSON input
-+-
 Reporter:  Sergey Fedoseev  |Owner:  Sergey
 |  Fedoseev
 Type:  New feature  |   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 Claude Paroz):

 * version:  1.9 => master


Comment:

 The GeoJSON format has been recently standardized in RFC 7946. In that
 standard, the use of the WGS84 coordinate system is mandatory.

 Quoting [https://tools.ietf.org/html/rfc7946#section-4 RFC 7946]:
 {{{
 4.  Coordinate Reference System

The coordinate reference system for all GeoJSON coordinates is a
geographic coordinate reference system, using the World Geodetic
System 1984 (WGS 84) [WGS84] datum, with longitude and latitude units
of decimal degrees.  This is equivalent to the coordinate reference
system identified by the Open Geospatial Consortium (OGC) URN
urn:ogc:def:crs:OGC::CRS84.  An OPTIONAL third-position element SHALL
be the height in meters above or below the WGS 84 reference
ellipsoid.  In the absence of elevation values, applications
sensitive to height or depth SHOULD interpret positions as being at
local ground or sea level.

Note: the use of alternative coordinate reference systems was
specified in [GJ2008], but it has been removed from this version of
the specification because the use of different coordinate reference
systems -- especially in the manner specified in [GJ2008] -- has
proven to have interoperability issues.  In general, GeoJSON
processing software is not expected to have access to coordinate
reference system databases or to have network access to coordinate
reference system transformation parameters.  However, where all
involved parties have a prior arrangement, alternative coordinate
reference systems can be used without risk of data being
misinterpreted.
 }}}

 Therefore, I suggest to won't fix this ticket. Any comment?

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

Re: [Django] #27119: full_clean() called too many times during formset validation

[Django]

#27119: full_clean() called too many times during formset validation
-+-
 Reporter:  Claude Paroz |Owner:  Karol
 Type:   |  Sztajerwald
  Cleanup/optimization   |   Status:  closed
Component:  Forms|  Version:  master
 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 GitHub ):

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


Comment:

 In [changeset:"d49551bc261666fad753b0f55f1150467190e3f7" d49551bc]:
 {{{
 #!CommitTicketReference repository=""
 revision="d49551bc261666fad753b0f55f1150467190e3f7"
 Fixed #27119 -- Cached BaseFormSet.management_form property

 Thanks Tim Graham for the review.
 }}}

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

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

Re: [Django] #27025: Python 3.6 compatibility

[Django]

#27025: Python 3.6 compatibility
--+
 Reporter:  Tim Graham|Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Tim Graham):

 Thanks, the relevant commit in cpython is
 https://hg.python.org/cpython/rev/feb1ae9d5381.

 I'm not sure if Django or cpython is at fault.

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

Re: [Django] #27558: Setting db_index=False on existing ForeignKey causes constraint to be recreated on MySQL

[Django]

#27558: Setting db_index=False on existing ForeignKey causes constraint to be
recreated on MySQL
-+-
 Reporter:  Ed Morley|Owner:  Ed Morley
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  db-indexes, mysql| Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"dd2e4d7b5d6f24f33c2805b0bfb97a08e27b2125" dd2e4d7b]:
 {{{
 #!CommitTicketReference repository=""
 revision="dd2e4d7b5d6f24f33c2805b0bfb97a08e27b2125"
 Refs #27558 -- Added test for no index on InnoDB ForeignKey.

 The refactor in 3f76d1402dac9c2993d588f996dc1c331edbc9a7 fixed the
 creation
 of redundant indexes.

 Forwardport of 82ce55dbbe2d96e8b5d1fcb4a1d52b73e08e7929 from stable/1.10.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/066.2db40eb50a75a8dd86969ed50a99737e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27558: Setting db_index=False on existing ForeignKey causes constraint to be recreated on MySQL

[Django]

#27558: Setting db_index=False on existing ForeignKey causes constraint to be
recreated on MySQL
-+-
 Reporter:  Ed Morley|Owner:  Ed Morley
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  db-indexes, mysql| Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"82ce55dbbe2d96e8b5d1fcb4a1d52b73e08e7929" 82ce55d]:
 {{{
 #!CommitTicketReference repository=""
 revision="82ce55dbbe2d96e8b5d1fcb4a1d52b73e08e7929"
 [1.10.x] Fixed #27558 -- Prevented redundant index on InnoDB ForeignKey.

 The MySQL backend overrides _field_should_be_indexed() so that it skips
 index creation for ForeignKeys when using InnoDB.
 }}}

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

[Django] #27560: Formset.save for model with foreign key to concrete base model

[Django]

#27560: Formset.save for model with foreign key to concrete base model
-+-
   Reporter:  Lorenzo|  Owner:  nobody
  Peña   |
   Type: | Status:  new
  Uncategorized  |
  Component:  Forms  |Version:  1.9
   Severity:  Normal |   Keywords:  formset
 |  inline_formset
   Triage Stage: |  inline_formsetfactory
  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 {{{
 class A(models.Model):
   pass

 class B(A):
   pass

 class C(models.Model):
   some_model = models.ForeignKey(SomeModel)
   a_link = models.ForeignKey(A)
 }}}

 I'm using an inlineformset_factory where the parent model is SomeModel and
 the child model is C.
 When calling formset.save() I'm getting an error from
 django/forms/models.py (line 910)

 {{{
 910:   pk_value = getattr(self.instance, self.fk.remote_field.field_name)
 911:   setattr(obj, self.fk.get_attname(), getattr(pk_value, 'pk',
 pk_value))
 }}}

 The getattr call fails

 if I wrap both lines in: if hasattr(self.instance,
 self.fk.remote_field.field_name):
 it works good.

 Not sure if the condition is the way to fix the bug or it's just
 preventing the original cause from happening.

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

Re: [Django] #27025: Python 3.6 compatibility

[Django]

#27025: Python 3.6 compatibility
--+
 Reporter:  Tim Graham|Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Anthony King):

 py3.6 breaks calling `super()` (in the python3 style) inside Models with:
 `RuntimeError: super(): empty __class__ cell`

 This is also present on 1.8 and 1.10

 {{{
 class ModelToBreak(models.Model):
 def save(self, *args, **kwargs):
 return super().save(*args, **kwargs)
 }}}

 {{{#!python
 >>> m = ModelToBreak()
 >>> m.save()
 Traceback (most recent call last):
   File "/home/cybo/work/3.6-test/testing/d/tests.py", line 9, in
 test_empty_class_fail
 m.save()
   File "/home/cybo/work/3.6-test/testing/d/models.py", line 5, in save
 return super().save(*args, **kwargs)
 RuntimeError: super(): empty __class__ cell
 }}}

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

Re: [Django] #26760: Delete nonexistent migrations from django_migrations table

[Django]

#26760: Delete nonexistent migrations from django_migrations table
-+-
 Reporter:  Jarek Glowacki   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  django_migrations| Triage Stage:  Accepted
  squash migrations  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Ryan Kaskel):

 * cc: dev@… (added)


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

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

Re: [Django] #27542: Client.force_login() shouldn't use authentication backends without a get_user() method

[Django]

#27542: Client.force_login() shouldn't use authentication backends without a
get_user() method
--+
 Reporter:  Tom   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Testing framework |  Version:  master
 Severity:  Normal|   Resolution:  fixed
 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 Tim Graham ):

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


Comment:

 In [changeset:"47744a0a4ed0b9e2d3f52de65abcf6cef9a14e31" 47744a0a]:
 {{{
 #!CommitTicketReference repository=""
 revision="47744a0a4ed0b9e2d3f52de65abcf6cef9a14e31"
 Fixed #27542 -- Made Client.force_login() skip auth backends without
 get_user().
 }}}

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

Re: [Django] #27416: ModelFormSet with queryset accepts invalid POST data for outer models and create unexpected empty data.

[Django]

#27416: ModelFormSet with queryset accepts invalid POST data for outer models 
and
create unexpected empty data.
-+-
 Reporter:  Hiroki Kiyohara  |Owner:  Hiroki
 |  Kiyohara
 Type:  Bug  |   Status:  assigned
Component:  Forms|  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:  formset,modelform| 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 Tim Graham):

 * stage:  Accepted => Ready for checkin


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

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

Re: [Django] #27558: Setting db_index=False on existing ForeignKey causes constraint to be recreated on MySQL

[Django]

#27558: Setting db_index=False on existing ForeignKey causes constraint to be
recreated on MySQL
-+-
 Reporter:  Ed Morley|Owner:  Ed Morley
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  db-indexes, mysql| Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Ed Morley):

 * status:  new => assigned
 * owner:  nobody => Ed Morley


Comment:

 I have a reduced testcase for master + 1.10.x branch, and a 1 liner to fix
 the issue on 1.10.x.
 Will clean up soon and open PRs.

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

Re: [Django] #27505: Error messages customization and internationalization in Paginator class

[Django]

#27505: Error messages customization and internationalization in Paginator class
-+-
 Reporter:  Anton Bazhanov   |Owner:  Anton
 Type:   |  Bazhanov
  Cleanup/optimization   |   Status:  assigned
Component:  Core (Other) |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

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


Comment:

 Strings are now marked for translation. Easing customization of error
 messages to be done separately.

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

Re: [Django] #27505: Error messages customization and internationalization in Paginator class

[Django]

#27505: Error messages customization and internationalization in Paginator class
-+-
 Reporter:  Anton Bazhanov   |Owner:  Anton
 Type:   |  Bazhanov
  Cleanup/optimization   |   Status:  assigned
Component:  Core (Other) |  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 Tim Graham ):

 In [changeset:"e690eb405f09a9e58b9d95ae98991352602635d6" e690eb40]:
 {{{
 #!CommitTicketReference repository=""
 revision="e690eb405f09a9e58b9d95ae98991352602635d6"
 Refs #27505 -- Made Paginator's exception messsages translatable.
 }}}

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

Re: [Django] #27546: Replace hardcoded class names in __repr__-methods

[Django]

#27546: Replace hardcoded class names in __repr__-methods
-+-
 Reporter:  Mads Jensen  |Owner:  Adiyat
 Type:   |  Mubarak
  Cleanup/optimization   |   Status:  closed
Component:  Core (Other) |  Version:  1.10
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"48826aa541f3a043690b90aa96f3fc07b7bc9fa9" 48826aa]:
 {{{
 #!CommitTicketReference repository=""
 revision="48826aa541f3a043690b90aa96f3fc07b7bc9fa9"
 Fixed #27546 -- Removed hardcoded class names in __repr__() methods.
 }}}

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

Re: [Django] #27546: Replace hardcoded class names in __repr__-methods

[Django]

#27546: Replace hardcoded class names in __repr__-methods
-+-
 Reporter:  Mads Jensen  |Owner:  Adiyat
 Type:   |  Mubarak
  Cleanup/optimization   |   Status:  assigned
Component:  Core (Other) |  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"794b7d803359c7d510910361f4d92429b43d0e79" 794b7d80]:
 {{{
 #!CommitTicketReference repository=""
 revision="794b7d803359c7d510910361f4d92429b43d0e79"
 Refs #27546 -- Tested some __repr__() methods.
 }}}

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

Re: [Django] #27559: Admin changelist turns GET QueryDict into dict which may lose parameters (was: Admin changelist turns QueryDict into dict)

[Django]

#27559: Admin changelist turns GET QueryDict into dict which may lose parameters
--+
 Reporter:  Jonas von Poser   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  contrib.admin |  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 Tim Graham):

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


Comment:

 Sounds reasonable, if it can be done in a backwards-compatible way.

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

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

Re: [Django] #27088: GEOSGeometry should accept Python 2.7 memoryview

[Django]

#27088: GEOSGeometry should accept Python 2.7 memoryview
+--
 Reporter:  Carl Meyer  |Owner:  Michał Ociepka
 Type:  Bug |   Status:  closed
Component:  GIS |  Version:  1.10
 Severity:  Normal  |   Resolution:  wontfix
 Keywords:  py2 | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  1
Easy pickings:  0   |UI/UX:  0
+--
Changes (by Tim Graham):

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


Comment:

 From the person who worked on the pull request, "There is not elegant way
 to solve this issue. If Django drops support to python 3 it is pointless
 to continue."

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

Re: [Django] #27538: Value of JSONField is being re-encoded to string even though being already encoded

[Django]

#27538: Value of JSONField is being re-encoded to string even though being 
already
encoded
--+--
 Reporter:  Petar Aleksic |Owner:  (none)
 Type:  Bug   |   Status:  closed
Component:  contrib.postgres  |  Version:  1.10
 Severity:  Normal|   Resolution:  worksforme
 Keywords:  JSONField | Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--

Comment (by Petar Aleksic):

 I didn't manage to reproduce the bug with the test or in a fresh django
 project.

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

[Django] #27559: Admin changelist turns QueryDict into dict

[Django]

#27559: Admin changelist turns QueryDict into dict
-+
   Reporter:  Jonas  |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  contrib.admin  |Version:  master
   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  |
-+
 We implemented a custom SimpleListFilter for the admin which presents the
 choices as a list of checkboxes. Pressing "submit" sends the list to the
 backend for filtering.

 Unfortunately, this doesn't really work well and it took us a while to
 find out why: the `ChangeList` view turns `request.GET` (a `QueryDict`)
 
[https://github.com/django/django/blob/master/django/contrib/admin/views/main.py#L67
 into a dict].

 This means, a query string in the form of `?q=123=1=2` simply
 loses all state values except the last one. It still works in principle
 but as soon as you e.g. click on a column heading to re-sort, the link
 only shows the last value instead of all of them.

 I checked the git log and traced this re-casting back to the
 
"[https://github.com/django/django/commit/9dda4abee1225db7a7b195b84c915fdd141a7260
 #diff-ea7d8c684e252f3dad6aa458df7d3070R109 NEW ADMIN MERGE]" in 2005. It
 was probably done to be able to manipulate the parameters but seems to be
 a very lossy operation for this purpose.

 Shouldn't `self.params` rather be kept as a `QueryDict`? We'll get started
 on a pull request if there's interest.

 ([https://groups.google.com/forum/#!topic/django-developers/dxEAq8_DSeM
 Asked on django-developers])

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