Re: [Django] #27531: Delete confirmation page overrides extrahead

[Django]

#27531: Delete confirmation page overrides extrahead
---+--
 Reporter:  elky   |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  1.10
 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 elky):

 * has_patch:  0 => 1


Comment:

 Pushed a fix here: https://github.com/django/django/pull/7608

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this 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.088991f4093ca5ef7981e404169ddc8a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27530: Referencing a function in a model field definition, and then removing that reference (and function) after running a migration raises an exception

[Django]

#27530: Referencing a function in a model field definition, and then removing 
that
reference (and function) after running a migration raises an exception
---+--
 Reporter:  Jesse  |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 Simon Charette):

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


Comment:

 This a [https://docs.djangoproject.com/en/1.10/topics/migrations
 /#historical-models documented caveat] of historical models.

 You can either can squash these migrations or copy your `upload_to`
 function definition into the migration files referencing it.

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

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

[Django] #27531: Delete confirmation page overrides extrahead

[Django]

#27531: Delete confirmation page overrides extrahead
-+
   Reporter:  elky   |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  contrib.admin  |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  |
-+
 Both `delete_confirmation.html` and `delete_selected_confirmation.html`
 templates have extrahead block which overrides any rules declared in
 custom `base_site.html`

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this 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.0ab86cce56321e18dd027d55f0b8d11b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27529: Geographic database functions with two parameters should accept expressions in one or the other arguments

[Django]

#27529: Geographic database functions with two parameters should accept 
expressions
in one or the other arguments
-+-
 Reporter:  Antoine Auberger |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  GIS  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  gis geographic   | Triage Stage:  Accepted
  queryset   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Simon Charette):

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


Comment:

 I'm not that familar with the GIS stuff but I could see queries using
 expression such as `Distance('field1', 'field2')` being useful and I can't
 see why we'd like to prevent that.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this 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.72ab13216dbefb3c7df415b394cb0d7f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #27530: Referencing a function in a model field definition, and then removing that reference (and function) after running a migration raises an exception

[Django]

#27530: Referencing a function in a model field definition, and then removing 
that
reference (and function) after running a migration raises an exception
-+
   Reporter:  Jesse  |  Owner:  nobody
   Type:  Uncategorized  | 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  |
-+
 With a FileField you can define a function for the upload_to argument. If
 you reference a function within that field, and then decide to modify the
 field later by removing the function reference (and also the function),
 the migrations will cause the server to fail to start because it can't
 find the function that was previously referenced.

 For example:

 {{{
 def destination():
   return "path"

 ...

 file = models.FileField(upload_to=destination)
 }}}

 Then later on I decide I don't need the function

 {{{
 file = models.FileField(upload_to="hardcoded path")
 }}}

 Now whenever I try to run the server locally or do a migration, I get:
 "AttributeError: 'module' object has no attribute 'destination'". The only
 meaningful workaround is to delete all migrations

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this 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.1d4aa523023bfa97b661f8e509a78df8%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27321: ignores_quoted_identifier_case broken on MySQL on OS X/Windows

[Django]

#27321: ignores_quoted_identifier_case broken on MySQL on OS X/Windows
-+-
 Reporter:  Adam Chainz  |Owner:  Adam
 |  Chainz
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  mysql, mariadb   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Adam Chainz):

 * status:  new => assigned
 * cc: me@… (added)
 * has_patch:  0 => 1
 * owner:  nobody => Adam Chainz


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this 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.96d54240427be1d29414432af16a3e3a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24370: Recommend that all new projects use a custom user model

[Django]

#24370: Recommend that all new projects use a custom user model
-+-
 Reporter:  Carl Meyer   |Owner:  Krzysztof
 Type:   |  Gogolewski
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  1.7
 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
-+-

Comment (by Tim Graham ):

 In [changeset:"9f89ca41dbf8a89031f1f29d7ed3ac4e1973018d" 9f89ca41]:
 {{{
 #!CommitTicketReference repository=""
 revision="9f89ca41dbf8a89031f1f29d7ed3ac4e1973018d"
 [1.10.x] Fixed #24370 -- Recommended starting with a custom user model.

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

Re: [Django] #24370: Recommend that all new projects use a custom user model

[Django]

#24370: Recommend that all new projects use a custom user model
-+-
 Reporter:  Carl Meyer   |Owner:  Krzysztof
 Type:   |  Gogolewski
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  1.7
 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:  assigned => closed
 * resolution:   => fixed


Comment:

 In [changeset:"d02a03d574b6623ce0d648dd676ae278d46375fb" d02a03d5]:
 {{{
 #!CommitTicketReference repository=""
 revision="d02a03d574b6623ce0d648dd676ae278d46375fb"
 Fixed #24370 -- Recommended starting with a custom user model.
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this 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.10e3dd622606dac994c5aae8f168ebe6%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):

 I have a local Jenkins running with the cpython 3.6 branch and Django
 master that I check every couple days. I don't think we'll add Python 3.6
 compatibility to older versions of Django such as 1.10 but we'll discuss
 it on the DevelopersMailingList if anyone feel it's important.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this 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.3d466e9265ca23854845048e3c35d532%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #20218: Default authorization backend returns False when queried for object level permissions

[Django]

#20218: Default authorization backend returns False when queried for object 
level
permissions
--+
 Reporter:  soren@…   |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.auth  |  Version:  1.5
 Severity:  Normal|   Resolution:
 Keywords:  auth  | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Jamie Bliss):

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

Re: [Django] #20218: Default authorization backend returns False when queried for object level permissions

[Django]

#20218: Default authorization backend returns False when queried for object 
level
permissions
--+
 Reporter:  soren@…   |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.auth  |  Version:  1.5
 Severity:  Normal|   Resolution:
 Keywords:  auth  | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Jamie Bliss):

 Replying to [ticket:20218 soren@…]:
 > Ticket #12462 suggests this is intentional, but doesn't give much of a
 rationale. It seems to me that if you don't want a user to be able to edit
 all objects of type XXX, don't give them the "app.change_XXX"?

 I think the rationale is that the current behavior handles the general
 permissions case (no object) while still falling through and allowing
 another provider to handle the object-specific case.

 The snippet to I used to work around this.

 {{{#!python
 class UseGeneralPermissions:
 """
 Permissions provider that does object-level permissions by using
 general permissions.
 """
 def has_perm(self, user_obj, perm, obj=None):
 if obj is None:
 return False
 else:
 # Retry using general permissions
 return user_obj.has_perm(perm)
 }}}

 As to how general and object-level permissions interact? That is
 completely unspecified, and there isn't a clear answer how it should be.
 1. A general given overrides an object-level ungiven, 2. A general ungiven
 overrides an object-level given. 1 still allows efficient bulk operations
 but UIs must check permissions on each object to know to display actions.
 2 allows UIs to display actions optimistically, but can prevent efficient
 bulk operations.

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

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

Re: [Django] #27529: Geographic database functions with two parameters should accept expressions in one or the other arguments

[Django]

#27529: Geographic database functions with two parameters should accept 
expressions
in one or the other arguments
-+-
 Reporter:  Antoine  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  GIS  |  Version:  1.9
 Severity:  Normal   |   Resolution:
 Keywords:  gis geographic   | Triage Stage:
  queryset   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Antoine):

 * version:  1.10 => 1.9


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

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

Re: [Django] #20218: Default authorization backend returns False when queried for object level permissions

[Django]

#20218: Default authorization backend returns False when queried for object 
level
permissions
--+
 Reporter:  soren@…   |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.auth  |  Version:  1.5
 Severity:  Normal|   Resolution:
 Keywords:  auth  | 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):

 I closed #27528 as a duplicate.

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

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

[Django] #27529: Geographic database functions with two parameters should accept expressions in one or the other arguments

[Django]

#27529: Geographic database functions with two parameters should accept 
expressions
in one or the other arguments
-+-
   Reporter:  Antoine|  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  GIS|Version:  1.10
   Severity:  Normal |   Keywords:  gis geographic
   Triage Stage: |  queryset
  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 == Context
 With the release of Django 1.9 database functions were introduced to
 simplify measurements, operations, lookups, etc. within the queryset.

 Some of the functions introduced take two arguments : `Difference`,
 `Distance`, `Intersection`, `SymDifference` and `Union`.
 The doc [#point1 (1)] states these functions "Accepts two geographic
 fields or expressions and returns the distance between them".

 == Problem
 As they all inherit from `GeoFuncWithGeoParam` [#point2 (2)], they
 actually expect `expr1` to be an expression (column or value), and `expr2`
 to be a `GEOSGeometry` object, despite stated otherwise.

 If an expression is passed as `expr2`, this error is raised :
 {{{
 In [0]: MyClass.objects.annotate(distance=Distance('field1', 'field2'))

 [...]

 ValueError: Please provide a geometry attribute with a defined SRID.
 }}}

 == Solutions
 1. Edit the doc to mention these limitations
 2. (much better) Fix the code to accept expressions in `expr2` as
 documented (and `GEOSGeometry` objects as expr1). Most of the backends
 support geographic measurements and operations between two fields, so
 there is not much to change.

 Happy to work on a patch if the bug is validated.

 [=#point1 (1)]
 https://docs.djangoproject.com/en/dev/ref/contrib/gis/functions/#distance
 [=#point2 (2)]
 
https://github.com/django/django/blob/1.9/django/contrib/gis/db/models/functions.py#L91

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this 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.4e18a0cd7a4551df029c17c2a2c864c7%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27528: No default object-level permissions provider

[Django]

#27528: No default object-level permissions provider
--+--
 Reporter:  Jamie Bliss   |Owner:  nobody
 Type:  New feature   |   Status:  closed
Component:  contrib.auth  |  Version:  1.10
 Severity:  Normal|   Resolution:  duplicate
 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 Tim Graham):

 * status:  new => closed
 * type:  Uncategorized => New feature
 * resolution:   => duplicate


Comment:

 Duplicate of #20218. There's also related discussion in #13539.

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

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

Re: [Django] #27528: No default object-level permissions provider

[Django]

#27528: No default object-level permissions provider
---+--
 Reporter:  Jamie Bliss|Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  contrib.auth   |  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
---+--
Changes (by Jamie Bliss):

 * Attachment "auth.py" added.

 Snippet implementing basic object-level permissions.

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

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

[Django] #27528: No default object-level permissions provider

[Django]

#27528: No default object-level permissions provider
-+
   Reporter:  Jamie Bliss|  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  contrib.auth   |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  |
-+
 By "object-level permission", I mean if an object was passed to
 has_perm().

 The expected default behavior would be that the object is ignored and
 general permissions are used.

 However, the current default behavior and configuration is that all
 object-level permissions are false. That is, has_perm('myapp.myperm') may
 be True, but has_perm('myapp.myperm', mymodel) is always False.

 There is no built-in method to enable object-level permissions to function
 at all in any form. I have attached the snippet I use for this.

 The biggest problem is that this misbehavior does not appear to be
 documented anywhere and there are no warnings. Diagnosing this
 misconfiguration required splunking through source code.

 In addition, this bug ripples into the ecosystem. No third-party
 applications can expect object-level permissions to function without
 additional third-party software and configuration, even in situations
 where the user does not want ACLs or other advanced permissions systems.
 That is, currently applications must choose between: 1. Using object-level
 permissions and requiring users to install additional software; 2. Using
 only general permissions and not supporting ACLs, etc without a patch; 3.
 Have an application-specific configuration option and some
 wrappers/boilerplate to toggle between using object-level and general
 permissions (which every application making this decision would need a
 copy of).

 If nothing is actually fixed, please, at the very least, document this
 weridness.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/057.34df4ddcfa35a2758cf9c1c8b76b2133%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 Andrii Soldatenko):

 just tested with last Django master
 e044026dce063ec53c16d0f755ec75eb8c84b318 and Python 3.6.0b4 works for me.

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

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

Re: [Django] #25966: Implement get_user_model() that can be used in models.py

[Django]

#25966: Implement get_user_model() that can be used in models.py
-+-
 Reporter:  Marten Kenbeek   |Owner:  Markus
 |  Holtermann
 Type:  New feature  |   Status:  assigned
Component:  contrib.auth |  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 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/062.45175ef98c43ff580b00a276929045b7%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27499: Pickling a QuerySet evaluates the querysets given to Prefetch in prefetch_related

[Django]

#27499: Pickling a QuerySet evaluates the querysets given to Prefetch in
prefetch_related
-+-
 Reporter:  Adam Chainz  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  prefetch_related | 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 ):

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


Comment:

 In [changeset:"e044026dce063ec53c16d0f755ec75eb8c84b318" e044026d]:
 {{{
 #!CommitTicketReference repository=""
 revision="e044026dce063ec53c16d0f755ec75eb8c84b318"
 Fixed #27499 -- Made Prefetches pickle without evaluating their QuerySet.
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this 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.bda4b8c2abd1cb5cd6085334494ff184%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26543: Changelist actions don't redirect after failed action resulting in possible ERR_CACHE_MISS in next steps

[Django]

#26543: Changelist actions don't redirect after failed action resulting in 
possible
ERR_CACHE_MISS in next steps
-+-
 Reporter:  Emmanuelle   |Owner:  Adonys
  Delescolle |  Alea Boffill
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  Version:  1.9
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-
Changes (by Tim Graham):

 * needs_tests:  0 => 1


Comment:

 Thanks for the patch. I haven't taken a close look but a selenium test
 would also be required. To ease comment on the patch, please send a pull
 request rather than attaching a patch to ticket. One thing I noticed from
 a quick glance is that I'm not sure if moving ``
 outside `{% if messages %}` is acceptable since that could create an empty
 `` which isn't valid HTML.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this 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.3a093e124d9d890987342f9bfb46a46a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27473: Allow using Extract() with DurationField

[Django]

#27473: Allow using Extract() with DurationField
-+-
 Reporter:  Daniel Hahler|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 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 Daniel Hahler):

 * has_patch:  0 => 1


Comment:

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

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this 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.4fb8316f739e21d2fab74d4edc869654%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26543: Changelist actions don't redirect after failed action resulting in possible ERR_CACHE_MISS in next steps

[Django]

#26543: Changelist actions don't redirect after failed action resulting in 
possible
ERR_CACHE_MISS in next steps
-+-
 Reporter:  Emmanuelle   |Owner:  Adonys
  Delescolle |  Alea Boffill
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  Version:  1.9
 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:  1
-+-
Changes (by Adonys Alea Boffill):

 * has_patch:  0 => 1


Comment:

 This problem occurs every time that Django admin return again to the page
 after a failed `POST` . In other words, every time that the validation of
 `ActionForm` is failed. To solve this situation I added the current
 validations to the `JavaScript` level, and the rest works fine.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this 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.b8a24cac181eae6340a26a17db7df415%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26543: Changelist actions don't redirect after failed action resulting in possible ERR_CACHE_MISS in next steps

[Django]

#26543: Changelist actions don't redirect after failed action resulting in 
possible
ERR_CACHE_MISS in next steps
-+-
 Reporter:  Emmanuelle   |Owner:  Adonys
  Delescolle |  Alea Boffill
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  Version:  1.9
 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:  1
-+-
Changes (by Adonys Alea Boffill):

 * Attachment "#26543.diff" added.

 Fixed changelist actions don't redirect after failed action

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this 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.26627f178444c5403a44c2ea98651738%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27358: Add a system check for FileField upload_to starting with a slash

[Django]

#27358: Add a system check for FileField upload_to starting with a slash
-+-
 Reporter:  Tim Graham   |Owner:  Henry
 Type:   |  Dang
  Cleanup/optimization   |   Status:  assigned
Component:  Core (System |  Version:  1.10
  checks)|
 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 Henry Dang):

 * owner:  Frank => Henry Dang


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this 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.9bc5aa8043f09090203b388b222e5485%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27499: Pickling a QuerySet evaluates the querysets given to Prefetch in prefetch_related

[Django]

#27499: Pickling a QuerySet evaluates the querysets given to Prefetch in
prefetch_related
-+-
 Reporter:  Adam Chainz  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  prefetch_related | 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/068.267d3785cd30ef072b89a41af24548d8%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27318: Return failed values from memcached.set_many()

[Django]

#27318: Return failed values from memcached.set_many()
-+-
 Reporter:  Florent Fourcot  |Owner:  Olivier
 Type:   |  Tabone
  Cleanup/optimization   |   Status:  assigned
Component:  Core (Cache system)  |  Version:  1.10
 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 Tim Graham):

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

Re: [Django] #27471: Make admin's list_filter choices collapsable

[Django]

#27471: Make admin's list_filter choices collapsable
-+-
 Reporter:  Greg McCoy   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  contrib.admin|  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:  filter admin | Triage Stage:  Accepted
  collaspe   |
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-
Changes (by Tim Graham):

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


Comment:

 [https://github.com/django/django/pull/7538 PR] (without tests or
 documentation updates -- some screenshots need to be updated, for
 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/067.632deb95e8c4d792a34c48a95a83801a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27222: Refresh fields that are expressions after Model.save()

[Django]

#27222: Refresh fields that are expressions after Model.save()
-+-
 Reporter:  holvianssi   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 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 Tim Graham):

 * needs_better_patch:  0 => 1


Comment:

 Simon still has concerns described on the 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/068.bc38d49820d03c863dc49d72fc16496d%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27473: Allow using Extract() with DurationField

[Django]

#27473: Allow using Extract() with DurationField
-+-
 Reporter:  Daniel Hahler|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 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 Daniel Hahler):

 Cool, working on a PR now.

 I've noticed that with SQLite, the "Extract" for a DurationField appears
 to return NULL/None always, e.g. with
 `DTModel.objects.annotate(duration_s=Extract('duration', 'second'))`.

 Should this throw some error instead?  Would that be possible in `Extract`
 already (so basically keeping the current behavior there for unsupported
 backends)?
 Or would it need some other special casing?

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this 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.c95b41d9247d3c943f0acb923d25f384%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24959: Allow using negative timedeltas in expressions on MySQL and Oracle

[Django]

#24959: Allow using negative timedeltas in expressions on MySQL and Oracle
-+-
 Reporter:  Fred Palmer  |Owner:  felixxm
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  date_interval_sql,   | Triage Stage:  Ready for
  timedelta, F, orm  |  checkin
Has patch:  1|  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:"b63d0c54b05ede2589e2b720eb0c102c02891962" b63d0c54]:
 {{{
 #!CommitTicketReference repository=""
 revision="b63d0c54b05ede2589e2b720eb0c102c02891962"
 Fixed #24959 -- Fixed queries using negative timedeltas on MySQL and
 Oracle.
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this 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.1cf1a3888c87035f44f21773c0275a66%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #24959: Allow using negative timedeltas in expressions on MySQL and Oracle (was: Allow using negative timedeltas in expressions)

[Django]

#24959: Allow using negative timedeltas in expressions on MySQL and Oracle
-+-
 Reporter:  Fred Palmer  |Owner:  felixxm
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.8
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  date_interval_sql,   | Triage Stage:  Ready for
  timedelta, F, orm  |  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/068.1f72ee5c32233a8c556712be5a6db274%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27356: admin lookup_allowed incorrectly returns False for a nested reverse OneToOneField

[Django]

#27356: admin lookup_allowed incorrectly returns False for a nested reverse
OneToOneField
---+
 Reporter:  Tobias Krönke  |Owner:  felixxm
 Type:  Bug|   Status:  assigned
Component:  contrib.admin  |  Version:  1.10
 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 Tim Graham):

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

Re: [Django] #26340: Cannot rollback to a savepoint explicitly after an IntegrityError when autocommit is disabled

[Django]

#26340: Cannot rollback to a savepoint explicitly after an IntegrityError when
autocommit is disabled
-+-
 Reporter:  Aymeric Augustin |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 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):

 A subset of the issue was fixed in
 2742901ac210361bc2c4b662870d35a1be5a142c:

 Fixed #27504 -- Allowed using the ORM after an error and rollback when
 autocommit is off.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this 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.444cbeb0dccf5fa53bcb54e129d8c389%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27504: Cannot Make ORM Queries After an Error and Rollback In Non-autocommit Mode

[Django]

#27504: Cannot Make ORM Queries After an Error and Rollback In Non-autocommit 
Mode
-+-
 Reporter:  Mark Young   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.10
  (models, ORM)  |
 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 Tim Graham ):

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


Comment:

 In [changeset:"2742901ac210361bc2c4b662870d35a1be5a142c" 2742901]:
 {{{
 #!CommitTicketReference repository=""
 revision="2742901ac210361bc2c4b662870d35a1be5a142c"
 Fixed #27504 -- Allowed using the ORM after an error and rollback when
 autocommit is off.
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this 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.be1b0ffef77371bdb3283f8aba688b63%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26677: Run i18n tests on disposable FS tree instead of source code

[Django]

#26677: Run i18n tests on disposable FS tree instead of source code
-+-
 Reporter:  Ramiro Morales   |Owner:  Ramiro
 Type:   |  Morales
  Cleanup/optimization   |   Status:  closed
Component:   |  Version:  master
  Internationalization   |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  tests isolation  | Triage Stage:  Ready for
  i18n serializemixin unit unittest  |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 The commits were backported to 1.10.x at the request of #27526.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this 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.c286d8d78aa5ed88869fa667016d6c5a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27526: test_fuzzy_compiling failing on a machine with 64 cores

[Django]

#27526: test_fuzzy_compiling failing on a machine with 64 cores
--+
 Reporter:  Raphaël Hertzog   |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  Internationalization  |  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:  0 |UI/UX:  0
--+
Changes (by Tim Graham):

 * status:  new => closed
 * resolution:   => fixed
 * severity:  Release blocker => Normal
 * stage:  Unreviewed => Accepted


Comment:

 I backported the commits you mentioned to 1.10.x in
 c1bd4679e896301dd26f0bb51d905a194eb358b7 and
 a079d5ceed0cd1282db433c69135d2e082dacf0b.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this 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.56f28486d3353a15d9e1feee349bab5f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #26677: Run i18n tests on disposable FS tree instead of source code

[Django]

#26677: Run i18n tests on disposable FS tree instead of source code
-+-
 Reporter:  Ramiro Morales   |Owner:  Ramiro
 Type:   |  Morales
  Cleanup/optimization   |   Status:  closed
Component:   |  Version:  master
  Internationalization   |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  tests isolation  | Triage Stage:  Ready for
  i18n serializemixin unit unittest  |  checkin
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:"c1bd4679e896301dd26f0bb51d905a194eb358b7" c1bd4679]:
 {{{
 #!CommitTicketReference repository=""
 revision="c1bd4679e896301dd26f0bb51d905a194eb358b7"
 [1.10.x] Fixed #26677 -- Converted some i18n tests to use disposable FS
 tree.

 This allows makemessages/compilemessages tests in `test_extraction.py`
 and `test_compilation.py` to actually run isolated from each other
 (unaffected by stray FS objects left by cleanup actions failures, debug
 sessions, etc.) and to take advantage of the parallel tests execution
 feature like most of the Django test suite.

 `test_percents.py` gets slightly refactored to not inherit from the new
 machinery which sets up every test case to copy and run under a
 temporary tree.

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

Re: [Django] #26677: Run i18n tests on disposable FS tree instead of source code

[Django]

#26677: Run i18n tests on disposable FS tree instead of source code
-+-
 Reporter:  Ramiro Morales   |Owner:  Ramiro
 Type:   |  Morales
  Cleanup/optimization   |   Status:  closed
Component:   |  Version:  master
  Internationalization   |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  tests isolation  | Triage Stage:  Ready for
  i18n serializemixin unit unittest  |  checkin
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:"a079d5ceed0cd1282db433c69135d2e082dacf0b" a079d5ce]:
 {{{
 #!CommitTicketReference repository=""
 revision="a079d5ceed0cd1282db433c69135d2e082dacf0b"
 [1.10.x] Refs #26677 -- Simplified i18n test cleanups.

 The fact that we aren't dealing with the Django source tree anymore
 allows us to drop several tearDown()/addCleanup() calls that were
 concerned with removing apiece files/dirs/symlinks created by test
 cases, as we are covered by the removal of the parent temporary tree
 anyways.

 Thanks Tim Graham for advice and review.

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

Re: [Django] #27525: Revert to previous migration automatically after failure when using MySQL backend

[Django]

#27525: Revert to previous migration automatically after failure when using 
MySQL
backend
-+-
 Reporter:  Sandy Agafonoff  |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Migrations   |  Version:  1.10
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  migrations, mysql,   | Triage Stage:
  revert |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

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


Comment:

 I agree with Shai. If you have an implementation to share, that would
 certainly help better evaluate the idea. We can reopen if the ticket if
 there's consensus on the mailing list to proceed.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this 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.af1d8e23b7b0f26f275e94cb2aeef816%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27527: How to enable login for a custom written authentication backend

[Django]

#27527: How to enable login for a custom written authentication backend
-+-
 Reporter:  Kireeti  |Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:  contrib.auth |  Version:  1.9
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  Authenticate,| Triage Stage:
  Login, Backend |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * status:  new => closed
 * resolution:   => invalid
 * severity:  Release blocker => Normal


Old description:

> Hello Django Team, Thanks for creating such powerful framework and making
> it open. For one of my projects i wanted to let users login with OTP, for
> which i am doing the verification manually. I want to use the login() to
> let the user login to his account, order products. For which i created my
> own backend to query the model with the phone number all this part until
> authenticate is working fine. but i am not able to figure out how to use
> login from here.  below is a snippet of what i created.
>
> Backend:
>
> from .models import Customer
>
> class CustomerModelBackend(object):
> def authenticate(self, phone_number=None, password=None):
> try:
> user = Customer.objects.get(phone=phone_number)
> if user is not None:
> return user
> else:
> return False
> except user.DoesNotExist:
> return False
>
> def get_user(self, phone):
> try:
> return Customer.objects.get(pk=phone)
> except Customer.DoesNotExist:
> return None
>
> Views.py
> customer_backend = CustomerModelBackend()
> customer_exist = customer_backend.authenticate(phone_number=phone)
> login(request, customer_exist)
>
> Here customer_exist is getting customer object as expected but login
> function is throwing global name not defined. importing login from
> contrib/auth is throwing backend not defined.
>
> Someone please advice what to do.
>
> Thanks.

New description:

 Hello Django Team, Thanks for creating such powerful framework and making
 it open. For one of my projects i wanted to let users login with OTP, for
 which i am doing the verification manually. I want to use the login() to
 let the user login to his account, order products. For which i created my
 own backend to query the model with the phone number all this part until
 authenticate is working fine. but i am not able to figure out how to use
 login from here.  below is a snippet of what i created.

 Backend:
 {{{
 from .models import Customer

 class CustomerModelBackend(object):
 def authenticate(self, phone_number=None, password=None):
 try:
 user = Customer.objects.get(phone=phone_number)
 if user is not None:
 return user
 else:
 return False
 except user.DoesNotExist:
 return False

 def get_user(self, phone):
 try:
 return Customer.objects.get(pk=phone)
 except Customer.DoesNotExist:
 return None
 }}}
 Views.py
 {{{
 customer_backend = CustomerModelBackend()
 customer_exist = customer_backend.authenticate(phone_number=phone)
 login(request, customer_exist)
 }}}
 Here customer_exist is getting customer object as expected but login
 function is throwing global name not defined. importing login from
 contrib/auth is throwing backend not defined.

 Someone please advice what to do.

 Thanks.

--

Comment:

 Please see TicketClosingReasons/UseSupportChannels for ways to get help
 with usage questions.

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

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

[Django] #27527: How to enable login for a custom written authentication backend

[Django]

#27527: How to enable login for a custom written authentication backend
-+-
   Reporter:  Kireeti|  Owner:  nobody
   Type: | Status:  new
  Uncategorized  |
  Component: |Version:  1.9
  contrib.auth   |
   Severity:  Release|   Keywords:  Authenticate,
  blocker|  Login, Backend
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Hello Django Team, Thanks for creating such powerful framework and making
 it open. For one of my projects i wanted to let users login with OTP, for
 which i am doing the verification manually. I want to use the login() to
 let the user login to his account, order products. For which i created my
 own backend to query the model with the phone number all this part until
 authenticate is working fine. but i am not able to figure out how to use
 login from here.  below is a snippet of what i created.

 Backend:

 from .models import Customer

 class CustomerModelBackend(object):
 def authenticate(self, phone_number=None, password=None):
 try:
 user = Customer.objects.get(phone=phone_number)
 if user is not None:
 return user
 else:
 return False
 except user.DoesNotExist:
 return False

 def get_user(self, phone):
 try:
 return Customer.objects.get(pk=phone)
 except Customer.DoesNotExist:
 return None

 Views.py
 customer_backend = CustomerModelBackend()
 customer_exist = customer_backend.authenticate(phone_number=phone)
 login(request, customer_exist)

 Here customer_exist is getting customer object as expected but login
 function is throwing global name not defined. importing login from
 contrib/auth is throwing backend not defined.

 Someone please advice what to do.

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

Re: [Django] #27477: Use QuerySet.select_for_update() in admin change form to fix race condition

[Django]

#27477: Use QuerySet.select_for_update() in admin change form to fix race 
condition
---+--
 Reporter:  Dave Hall  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  contrib.admin  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords:  admin  | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by Dave Hall):

 Yes, the same issue is also present in the class-based generic edit views.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this 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.434e9d47e3744792dc31e8fc3908e1d1%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27525: Revert to previous migration automatically after failure when using MySQL backend

[Django]

#27525: Revert to previous migration automatically after failure when using 
MySQL
backend
-+-
 Reporter:  Sandy Agafonoff  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Migrations   |  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:  migrations, mysql,   | Triage Stage:
  revert |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Shai Berger):

 * type:  Cleanup/optimization => New feature


Comment:

 Hi,

 Thanks for this suggestion. Three points come to mind:

 At a normal "meta" level: If indeed this is a niche request, perhaps it
 can be fulfilled by means of a 3rd-party app; apps can override and
 enhance Django's management commands. So you can write your own "migrate"
 command, or a "migrate_and_on_error_back" command, that will do just that.

 At the subject matter level: When a migration fails, it usually means
 something unexpected happened. In these circumstances, it is more prudent
 to stop and let a human examine the situation, rather than attempt
 automatic fixes which are, in essence, based on the assumptions that were
 broken. For this reason, I tend to think it isn't a good idea to put such
 an option into Django -- adding it would endorse a practice which, I
 suspect, is more likely to cause harm than good in the general case.

 At the highest "meta" level: If you want to open a discussion, it is
 better to do so on the DevelopersMailingList, where many more people will
 see it.

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

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

Re: [Django] #27526: test_fuzzy_compiling failing on a machine with 64 cores

[Django]

#27526: test_fuzzy_compiling failing on a machine with 64 cores
-+-
 Reporter:  Raphaël Hertzog  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:   |  Version:  1.10
  Internationalization   |
 Severity:  Release blocker  |   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 Raphaël Hertzog):

 * has_patch:  0 => 1


Comment:

 Apparently this is already fixed in master due to
 bb7bb379e8cd91a91336946829519d64e919a1d2 and
 faeeb84edfebecf5a5f40df9ef816e5f1cd457c6. I suggest that you backport
 those two.

 I have attached a patch of my own that basically did something similar to
 faeeb84edfebecf5a5f40df9ef816e5f1cd457c6.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this 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.2d0aff431eced6afa56e0f827f050da1%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27526: test_fuzzy_compiling failing on a machine with 64 cores

[Django]

#27526: test_fuzzy_compiling failing on a machine with 64 cores
-+-
 Reporter:  Raphaël Hertzog  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:   |  Version:  1.10
  Internationalization   |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Raphaël Hertzog):

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

Re: [Django] #27526: test_fuzzy_compiling failing on a machine with 64 cores

[Django]

#27526: test_fuzzy_compiling failing on a machine with 64 cores
-+-
 Reporter:  Raphaël Hertzog  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:   |  Version:  1.10
  Internationalization   |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Raphaël Hertzog):

 In fact I reproduce the above problem on each run as long as I run at
 least 4 parallel test runners with `./runtests.py --verbosity=2
 i18n.test_compilation --parallel=4`.

 But with `--parallel=1`, the problem is gone.

 In fact most of the tests in that test_compilation unit are not parallel-
 friendly as they create/remove the same set of files in setUp(). On
 multiple runs of the above commande I can randomly get other failures such
 as this one:
 {{{
 ==
 FAIL: test_multiple_locales
 (i18n.test_compilation.MultipleLocaleCompilationTests)
 --
 Traceback (most recent call last):
   File "/usr/lib/python2.7/unittest/case.py", line 329, in run
 testMethod()
   File "/home/rhertzog/deb/pkg/python-
 django/tests/i18n/test_compilation.py", line 112, in test_multiple_locales
 self.assertTrue(os.path.exists(self.MO_FILE_FR))
   File "/usr/lib/python2.7/unittest/case.py", line 422, in assertTrue
 raise self.failureException(msg)
 AssertionError: False is not true
 }}}

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

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

Re: [Django] #26920: GEOSGeometry objects compare equal despite different SRID

[Django]

#26920: GEOSGeometry objects compare equal despite different SRID
-+-
 Reporter:  Raphael Das Gupta|Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  GIS  |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  geodjango, equality  | 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 ):

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


Comment:

 In [changeset:"50613d957a853f83310a03e0f300bbf568f1f65b" 50613d95]:
 {{{
 #!CommitTicketReference repository=""
 revision="50613d957a853f83310a03e0f300bbf568f1f65b"
 Fixed #26920 -- Made GEOSGeometry equality check consider the srid
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this 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.3c8dea7c6fbf577e5f51e57638ac0550%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.