Re: [Django] #16010: Support Origin header checking in the CSRF middleware

[Django]

#16010: Support Origin header checking in the CSRF middleware
-+
 Reporter:  davidben |Owner:
 Type:  New feature  |   Status:  new
Component:  CSRF |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+
Changes (by auvipy):

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


Comment:

 New/Core contributors should look after this. I'm working on other parts
 of django, so better let others work on this whoever gave the ability and
 interest to work with security

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

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

Re: [Django] #25773: deprecate `MultiPolygon.cascaded_union` in favor of `GEOSGeometry.unary_union`

[Django]

#25773: deprecate `MultiPolygon.cascaded_union` in favor of
`GEOSGeometry.unary_union`
-+-
 Reporter:  sir-sigurd   |Owner:  sir-
 Type:   |  sigurd
  Cleanup/optimization   |   Status:  assigned
Component:  GIS  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by claudep):

 * stage:  Unreviewed => Accepted


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

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

Re: [Django] #10403: provide declarative syntax to define FormSets - including ModelFormSet and InlineFormSet

[Django]

#10403: provide declarative syntax to define FormSets - including ModelFormSet 
and
InlineFormSet
-+-
 Reporter:  Koen Biermans|Owner:  auvipy
    |
 Type:  New feature  |   Status:  assigned
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  formset  | Triage Stage:  Accepted
  modelformset inlineformset |
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by auvipy):

 Replying to [comment:10 timgraham]:
 > I don't know that deprecating the factory functions (at least
 immediately) is a good idea. This could cause a lot of annoying churn for
 large projects.

 Then I should keep them [factory function/s] for this patch in WIP

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

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

Re: [Django] #25774: Refactor of datetime expressions and better, official support for right-hand-side date part extraction

[Django]

#25774: Refactor of datetime expressions and better, official support for right-
hand-side date part extraction
-+-
 Reporter:  ryuusenshi   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
  db,expressions,date,time,extract,transform|  Unreviewed
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by ryuusenshi):

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


Old description:

> As previously stated in [https://code.djangoproject.com/ticket/25556 this
> ticket] and [https://groups.google.com/forum/#!topic/django-
> developers/GU8OrPUMjrc this thread], I have begun work on the following:
>
>- making the so called datetime transforms (currently residing in
> `django.db.models.lookups`) part of the officially supported ORM API as
> part of the db expressions,
>- making these transforms easily usable on the right hand side of
> lookups / Q objects
> [[BR]]
>

> To this effect, I propose the following:
>  - replace module `django.db.models.expressions` with a package of
> the same name
>  - add module `django.db.models.expressions.datetimes`
>  - rename `XTransform` to `XExtract` and move them from
> `django.db.models.lookups` to `django.db.models.lookups` to
> `django.db.models.expressions.datetimes`
>  - change `YearLookup` and `YearComparisonLookup` to allow for
> functions on the right hand side
> - extensive testing of these db expressions
> - adding this to the release notes
> - any other change that might support this
>
> [[BR]]
>
> I'm also adding a [PR] with some of these already implemented. What
> remains to be done is:
> - replace references `XTransform` type classes in
> `django.db.models.lookups` with `XExtract` classes from
> `django.db.models.expressions.datetimes`
> - replace these references anywhere else in the project (I've noticed
> there are some in the tests, for instance)
>
> [[BR]]
>
> With the API in the [PR] it becomes possible to do the following lookup:
>

> {{{
> from django.db.models.expressions.datetimes import DateExtract
>
> Person.objects.filter(birth_date__year=DateExtract('job__start_date',
> lookup_name='year'))
> }}}
>
> which is equivalent to:
>

> {{{
> from django.db.models.expressions.datetimes import YearExtract
>
> Person.objects.filter(birth_date__year=YearExtract('job__start_date'))
> }}}
>

> Additionally, @jarshwah suggested that these should maybe be named:
> `ExtractX` instead of `XExtract`.

New description:

 As previously stated in [https://code.djangoproject.com/ticket/25556 this
 ticket] and [https://groups.google.com/forum/#!topic/django-
 developers/GU8OrPUMjrc this thread], I have begun work on the following:

- making the so called datetime transforms (currently residing in
 `django.db.models.lookups`) part of the officially supported ORM API as
 part of the db expressions,
- making these transforms easily usable on the right hand side of
 lookups / Q objects
 [[BR]]


 To this effect, I propose the following:
  - replace module `django.db.models.expressions` with a package of the
 same name
  - add module `django.db.models.expressions.datetimes`
  - rename `XTransform` to `XExtract` and move them from
 `django.db.models.lookups` to `django.db.models.lookups` to
 `django.db.models.expressions.datetimes`
  - change `YearLookup` and `YearComparisonLookup` to allow for
 functions on the right hand side
 - extensive testing of these db expressions
 - adding this to the release notes
 - any other change that might support this

 [[BR]]

 I'm also adding a [https://github.com/django/django/pull/5683 PR] with
 some of these already implemented. What remains to be done is:
 - replace references `XTransform` type classes in
 `django.db.models.lookups` with `XExtract` classes from
 `django.db.models.expressions.datetimes`
 - replace these references anywhere else in the project (I've noticed
 there are some in the tests, for instance)

 [[BR]]

 With the API in the [https://github.com/django/django/pull/5683 PR] it
 becomes possible to do the following lookup:


 {{{
 from django.db.models.expressions.datetimes import DateExtract

 Person.objects.filter(birth_date__year=DateExtract('job__start_date',
 lookup_name='year'))
 }}}

 which is equivalent to:


 {{{
 from django.db.models.expressions.datetimes import YearExtract

 

[Django] #25774: Refactor of datetime expressions and better, official support for right-hand-side date part extraction

[Django]

#25774: Refactor of datetime expressions and better, official support for right-
hand-side date part extraction
-+-
 Reporter:  ryuusenshi   |  Owner:  nobody
 Type:  New feature  | Status:  new
Component:  Database layer   |Version:  master
  (models, ORM)  |   Keywords:
 Severity:  Normal   |  
db,expressions,date,time,extract,transform
 Triage Stage:  Unreviewed   |  Has patch:  1
Easy pickings:  0|  UI/UX:  0
-+-
 As previously stated in [https://code.djangoproject.com/ticket/25556 this
 ticket] and [https://groups.google.com/forum/#!topic/django-
 developers/GU8OrPUMjrc this thread], I have begun work on the following:

- making the so called datetime transforms (currently residing in
 `django.db.models.lookups`) part of the officially supported ORM API as
 part of the db expressions,
- making these transforms easily usable on the right hand side of
 lookups / Q objects
 [[BR]]


 To this effect, I propose the following:
  - replace module `django.db.models.expressions` with a package of the
 same name
  - add module `django.db.models.expressions.datetimes`
  - rename `XTransform` to `XExtract` and move them from
 `django.db.models.lookups` to `django.db.models.lookups` to
 `django.db.models.expressions.datetimes`
  - change `YearLookup` and `YearComparisonLookup` to allow for
 functions on the right hand side
 - extensive testing of these db expressions
 - adding this to the release notes
 - any other change that might support this

 [[BR]]

 I'm also adding a [PR] with some of these already implemented. What
 remains to be done is:
 - replace references `XTransform` type classes in
 `django.db.models.lookups` with `XExtract` classes from
 `django.db.models.expressions.datetimes`
 - replace these references anywhere else in the project (I've noticed
 there are some in the tests, for instance)

 [[BR]]

 With the API in the [PR] it becomes possible to do the following lookup:


 {{{
 from django.db.models.expressions.datetimes import DateExtract

 Person.objects.filter(birth_date__year=DateExtract('job__start_date',
 lookup_name='year'))
 }}}

 which is equivalent to:


 {{{
 from django.db.models.expressions.datetimes import YearExtract

 Person.objects.filter(birth_date__year=YearExtract('job__start_date'))
 }}}


 Additionally, @jarshwah suggested that these should maybe be named:
 `ExtractX` instead of `XExtract`.

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

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

[Django] #25773: deprecate `MultiPolygon.cascaded_union` in favor of `GEOSGeometry.unary_union`

[Django]

#25773: deprecate `MultiPolygon.cascaded_union` in favor of
`GEOSGeometry.unary_union`
--+
 Reporter:  sir-sigurd|  Owner:  nobody
 Type:  Cleanup/optimization  | Status:  new
Component:  GIS   |Version:  master
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+
 GEOS 3.3 deprecates `GEOSUnionCascaded` in favor of `GEOSUnaryUnion` so
 similar changes should be done for Django.

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

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

Re: [Django] #25773: deprecate `MultiPolygon.cascaded_union` in favor of `GEOSGeometry.unary_union`

[Django]

#25773: deprecate `MultiPolygon.cascaded_union` in favor of
`GEOSGeometry.unary_union`
-+-
 Reporter:  sir-sigurd   |Owner:  sir-
 Type:   |  sigurd
  Cleanup/optimization   |   Status:  assigned
Component:  GIS  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by sir-sigurd):

 * status:  new => assigned
 * needs_better_patch:   => 0
 * owner:  nobody => sir-sigurd
 * needs_tests:   => 0
 * needs_docs:   => 0


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

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

Re: [Django] #25617: Disallow usernames that differ only in case in UserCreationForm

[Django]

#25617: Disallow usernames that differ only in case in UserCreationForm
--+
 Reporter:  timgraham |Owner:  nmundar
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  contrib.auth  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+
Changes (by timgraham):

 * needs_better_patch:  0 => 1


Comment:

 There's a test failure.

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

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

Re: [Django] #22810: full_result_count optimization is wrong in the presence of custom ListFilters

[Django]

#22810: full_result_count optimization is wrong in the presence of custom
ListFilters
---+
 Reporter:  gwahl@…|Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  Version:  1.6
 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:"5fa7b592b3f43282823045954c61a1f9a4b31a7f" 5fa7b59]:
 {{{
 #!CommitTicketReference repository=""
 revision="5fa7b592b3f43282823045954c61a1f9a4b31a7f"
 Fixed #22810 -- Corrected admin changelist count for list filters that
 filter by default.
 }}}

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

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

Re: [Django] #25549: auth_user_password_change URL is undocumented

[Django]

#25549: auth_user_password_change URL is undocumented
-+-
 Reporter:  googol7  |Owner:  darkryder
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  1.8
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"ad167502f36f2547718aee290d4d11bf7a26ff82" ad16750]:
 {{{
 #!CommitTicketReference repository=""
 revision="ad167502f36f2547718aee290d4d11bf7a26ff82"
 Fixed #25549 -- Documented auth_user_password_change URL.
 }}}

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

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

Re: [Django] #25549: auth_user_password_change URL is undocumented

[Django]

#25549: auth_user_password_change URL is undocumented
-+-
 Reporter:  googol7  |Owner:  darkryder
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  1.8
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"b6545468eebdee12ee58aeb4871aa91c62220542" b654546]:
 {{{
 #!CommitTicketReference repository=""
 revision="b6545468eebdee12ee58aeb4871aa91c62220542"
 [1.9.x] Fixed #25549 -- Documented auth_user_password_change URL.

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

Re: [Django] #25549: auth_user_password_change URL is undocumented

[Django]

#25549: auth_user_password_change URL is undocumented
-+-
 Reporter:  googol7  |Owner:  darkryder
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  1.8
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"95eca4f508eb99d26ce812629afe0f6c60488134" 95eca4f]:
 {{{
 #!CommitTicketReference repository=""
 revision="95eca4f508eb99d26ce812629afe0f6c60488134"
 [1.8.x] Fixed #25549 -- Documented auth_user_password_change URL.

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

Re: [Django] #25677: compilemessages throws an exception and does not report msgformat errors correctly

[Django]

#25677: compilemessages throws an exception and does not report msgformat errors
correctly
-+-
 Reporter:  gavinwahl|Owner:
 Type:  Bug  |   Status:  new
Component:   |  Version:  master
  Internationalization   |
 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 timgraham):

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

Re: [Django] #25654: add support for `GEOSUnaryUnion` that was added to geos 3.3

[Django]

#25654: add support for `GEOSUnaryUnion` that was added to geos 3.3
-+--
 Reporter:  sir-sigurd   |Owner:  sir-sigurd
 Type:  New feature  |   Status:  closed
Component:  GIS  |  Version:  1.8
 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:"034dfbfc057b6090f9f2589731b8f58a70e4f885" 034dfbfc]:
 {{{
 #!CommitTicketReference repository=""
 revision="034dfbfc057b6090f9f2589731b8f58a70e4f885"
 Fixed #25654 -- Added the GEOSGeometry.unary_union property.
 }}}

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

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

Re: [Django] #25722: add support for `GEOSCovers`

[Django]

#25722: add support for `GEOSCovers`
-+--
 Reporter:  sir-sigurd   |Owner:  sir-sigurd
 Type:  New feature  |   Status:  assigned
Component:  GIS  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+--
Changes (by timgraham):

 * needs_better_patch:  0 => 1


Comment:

 Left some minor comments for improvement.

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

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

Re: [Django] #25663: `LinearRing` and `LineString` don't check number of points during instantiation

[Django]

#25663: `LinearRing` and `LineString` don't check number of points during
instantiation
-+-
 Reporter:  sir-sigurd   |Owner:  sir-
 Type:   |  sigurd
  Cleanup/optimization   |   Status:  closed
Component:  GIS  |  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:  assigned => closed
 * resolution:   => fixed


Comment:

 In [changeset:"1e35dd1a053b620f065101c02069c8e142ebf8ec" 1e35dd1]:
 {{{
 #!CommitTicketReference repository=""
 revision="1e35dd1a053b620f065101c02069c8e142ebf8ec"
 Fixed #25663 -- Added checking of the number of points for LinearRing and
 LineString.
 }}}

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

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

Re: [Django] #25768: Cast Variable, and provide multiplication

[Django]

#25768: Cast Variable, and provide multiplication
+--
 Reporter:  BenLiyanage |Owner:  nobody
 Type:  Uncategorized   |   Status:  closed
Component:  Uncategorized   |  Version:  1.8
 Severity:  Normal  |   Resolution:  invalid
 Keywords:  QuerySet.extra  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Changes (by BenLiyanage):

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


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

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

Re: [Django] #25768: Cast Variable, and provide multiplication

[Django]

#25768: Cast Variable, and provide multiplication
+--
 Reporter:  BenLiyanage |Owner:  nobody
 Type:  Uncategorized   |   Status:  new
Component:  Uncategorized   |  Version:  1.8
 Severity:  Normal  |   Resolution:
 Keywords:  QuerySet.extra  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--

Comment (by BenLiyanage):

 Yea I actually I found most of this stuff a couple hours later.  I was
 able to reproduce this functionality with F, Case, When, Value, and Q.

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

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

Re: [Django] #25551: makemigrations when adding a ForeignKey to a newly created model along with a unique_together constraint must create fields before the unique_together constraint

[Django]

#25551: makemigrations when adding a ForeignKey to a newly created model along 
with
a unique_together constraint must create fields before the unique_together
constraint
+---
 Reporter:  mssnlayam   |Owner:  avojnovicDk
 Type:  Bug |   Status:  assigned
Component:  Migrations  |  Version:  1.8
 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 timgraham):

 * needs_better_patch:  0 => 1


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

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

Re: [Django] #25734: Nodata value not excluded when computing GDALBand min/max values

[Django]

#25734: Nodata value not excluded when computing GDALBand min/max values
-+-
 Reporter:  yellowcap|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  GIS  |  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:  raster gdal gis  | 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 timgraham):

 * stage:  Accepted => Ready for checkin


Comment:

 I'm not sure it's a critical fix that needs to be backported (however, I'm
 not a GIS user). See our [https://docs.djangoproject.com/en/dev/internals
 /release-process/#supported-versions Supported Versions policy].

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

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

Re: [Django] #16084: makemessages command doesn't respect LOCALE_PATHS setting

[Django]

#16084: makemessages command doesn't respect LOCALE_PATHS setting
-+-
 Reporter:  heylinus |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:   |  Version:  1.4
  Internationalization   |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by claudep):

 It's probably not intentional. We would need to find some heuristics to
 detect if dirname is a 'locale' directory containing translations or any
 other sort of 'locale'-named directory. Please open a new ticket for this
 issue.

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

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

Re: [Django] #25665: deprecate public getters/setters for properties of `GEOSGeometry` and its subclasses

[Django]

#25665: deprecate public getters/setters for properties of `GEOSGeometry` and 
its
subclasses
-+-
 Reporter:  sir-sigurd   |Owner:  sir-
 Type:   |  sigurd
  Cleanup/optimization   |   Status:  closed
Component:  GIS  |  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 Tim Graham ):

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


Comment:

 In [changeset:"7a452c5ce295679307bd81dd9b5f37b3cf762acf" 7a452c5]:
 {{{
 #!CommitTicketReference repository=""
 revision="7a452c5ce295679307bd81dd9b5f37b3cf762acf"
 Fixed #25665 -- Deprecated getter/setter of Point.tuple.
 }}}

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

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

Re: [Django] #25665: deprecate public getters/setters for properties of `GEOSGeometry` and its subclasses

[Django]

#25665: deprecate public getters/setters for properties of `GEOSGeometry` and 
its
subclasses
-+-
 Reporter:  sir-sigurd   |Owner:  sir-
 Type:   |  sigurd
  Cleanup/optimization   |   Status:  assigned
Component:  GIS  |  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
-+-

Comment (by Tim Graham ):

 In [changeset:"7803f429a4d435623cb7b91dd324d3aadad87380" 7803f42]:
 {{{
 #!CommitTicketReference repository=""
 revision="7803f429a4d435623cb7b91dd324d3aadad87380"
 Refs #25665 -- Deprecated getters/setters of Point coordinate properties.
 }}}

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

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

Re: [Django] #25772: ArrayField: incorrent len lookup

[Django]

#25772: ArrayField: incorrent len lookup
--+--
 Reporter:  mrAdm |Owner:
 Type:  Bug   |   Status:  new
Component:  contrib.postgres  |  Version:  1.8
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by mrAdm):

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


Old description:

> Models:
> {{{
> NullableIntegerArrayModel.objects.create(field=[])
> NullableIntegerArrayModel.objects.create(field=[1])
> NullableIntegerArrayModel.objects.create(field=[2, 3])
> NullableIntegerArrayModel.objects.create(field=[20, 30, 40])
> NullableIntegerArrayModel.objects.create(field=None)
> }}}
>
> Queries:
> {{{
> NullableIntegerArrayModel.objects.filter(field__len=0)
> # return: empty queryset
> NullableIntegerArrayModel.objects.filter(field__len__lt=2)
> # return only one model (field=[1])
> }}}
>
> Reason:
> PostgreSQL function array_length(ARRAY[]::int4[], 1) return null if array
> empty.
>
> The solution is to use a function PostgreSQL: COALESCE ().
> {{{
> SELECT * FROM ... WHERE COALESCE(array_length("field", 1), 0)=0
> }}}

New description:

 Models:
 {{{
 NullableIntegerArrayModel.objects.create(field=[])
 NullableIntegerArrayModel.objects.create(field=[1])
 NullableIntegerArrayModel.objects.create(field=[2, 3])
 NullableIntegerArrayModel.objects.create(field=[20, 30, 40])
 }}}

 Queries:
 {{{
 NullableIntegerArrayModel.objects.filter(field__len=0)
 # return: empty queryset
 NullableIntegerArrayModel.objects.filter(field__len__lt=2)
 # return only one model (field=[1])
 }}}

 Reason:
 PostgreSQL function array_length(ARRAY[]::int4[], 1) return null if array
 empty.

 The solution is to use a function PostgreSQL: COALESCE ().
 {{{
 SELECT * FROM ... WHERE COALESCE(array_length("field", 1), 0)=0
 }}}

--

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

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

[Django] #25772: ArrayField: incorrent len lookup

[Django]

#25772: ArrayField: incorrent len lookup
--+-
 Reporter:  mrAdm |  Owner:
 Type:  Bug   | Status:  new
Component:  contrib.postgres  |Version:  1.8
 Severity:  Normal|   Keywords:
 Triage Stage:  Unreviewed|  Has patch:  0
Easy pickings:  0 |  UI/UX:  0
--+-
 Models:
 {{{
 NullableIntegerArrayModel.objects.create(field=[])
 NullableIntegerArrayModel.objects.create(field=[1])
 NullableIntegerArrayModel.objects.create(field=[2, 3])
 NullableIntegerArrayModel.objects.create(field=[20, 30, 40])
 NullableIntegerArrayModel.objects.create(field=None)
 }}}

 Queries:
 {{{
 NullableIntegerArrayModel.objects.filter(field__len=0)
 # return: empty queryset
 NullableIntegerArrayModel.objects.filter(field__len__lt=2)
 # return only one model (field=[1])
 }}}

 Reason:
 PostgreSQL function array_length(ARRAY[]::int4[], 1) return null if array
 empty.

 The solution is to use a function PostgreSQL: COALESCE ().
 {{{
 SELECT * FROM ... WHERE COALESCE(array_length("field", 1), 0)=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/048.2c6573eaf52e82f15627d9ffdb74fba8%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25665: deprecate public getters/setters for properties of `GEOSGeometry` and its subclasses

[Django]

#25665: deprecate public getters/setters for properties of `GEOSGeometry` and 
its
subclasses
-+-
 Reporter:  sir-sigurd   |Owner:  sir-
 Type:   |  sigurd
  Cleanup/optimization   |   Status:  assigned
Component:  GIS  |  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 timgraham):

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

Re: [Django] #25665: deprecate public getters/setters for properties of `GEOSGeometry` and its subclasses

[Django]

#25665: deprecate public getters/setters for properties of `GEOSGeometry` and 
its
subclasses
-+-
 Reporter:  sir-sigurd   |Owner:  sir-
 Type:   |  sigurd
  Cleanup/optimization   |   Status:  assigned
Component:  GIS  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"b7177cc2a422a0183c8f2d56eceb6b9323c6f959" b7177cc]:
 {{{
 #!CommitTicketReference repository=""
 revision="b7177cc2a422a0183c8f2d56eceb6b9323c6f959"
 Refs #25665 -- Deprecated getter/setter of GEOSGeometry.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/068.6b6e86e72f5aa050328e6285cdead023%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #25526: Document how to output color from custom management commands

[Django]

#25526: Document how to output color from custom management commands
--+
 Reporter:  bmispelon |Owner:  elenaoat
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  1 |UI/UX:  0
--+

Comment (by Tim Graham ):

 In [changeset:"e7da99abd41b483c8991581628d442296698b2bf" e7da99a]:
 {{{
 #!CommitTicketReference repository=""
 revision="e7da99abd41b483c8991581628d442296698b2bf"
 [1.8.x] Refs #25526 -- Documented some missing termcolors.

 Backport of 5f7f3b46853c958789361a7defda8ca3c3c2be53 from master
 }}}

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

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

Re: [Django] #25526: Document how to output color from custom management commands

[Django]

#25526: Document how to output color from custom management commands
--+
 Reporter:  bmispelon |Owner:  elenaoat
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  1 |UI/UX:  0
--+

Comment (by Tim Graham ):

 In [changeset:"5f7f3b46853c958789361a7defda8ca3c3c2be53" 5f7f3b46]:
 {{{
 #!CommitTicketReference repository=""
 revision="5f7f3b46853c958789361a7defda8ca3c3c2be53"
 Refs #25526 -- Documented some missing termcolors.
 }}}

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

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

Re: [Django] #25526: Document how to output color from custom management commands

[Django]

#25526: Document how to output color from custom management commands
--+
 Reporter:  bmispelon |Owner:  elenaoat
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  1 |UI/UX:  0
--+

Comment (by Tim Graham ):

 In [changeset:"e7c86871052b4bfb62a2fcc67ccd4fe441057463" e7c86871]:
 {{{
 #!CommitTicketReference repository=""
 revision="e7c86871052b4bfb62a2fcc67ccd4fe441057463"
 [1.9.x] Refs #25526 -- Documented some missing termcolors.

 Backport of 5f7f3b46853c958789361a7defda8ca3c3c2be53 from master
 }}}

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

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

Re: [Django] #10403: provide declarative syntax to define FormSets - including ModelFormSet and InlineFormSet

[Django]

#10403: provide declarative syntax to define FormSets - including ModelFormSet 
and
InlineFormSet
-+-
 Reporter:  Koen Biermans|Owner:  auvipy
    |
 Type:  New feature  |   Status:  assigned
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  formset  | Triage Stage:  Accepted
  modelformset inlineformset |
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by timgraham):

 I don't know that deprecating the factory functions (at least immediately)
 is a good idea. This could cause a lot of annoying churn for large
 projects.

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

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

Re: [Django] #25771: Serialization of natural foreign key in migration scripts does not work

[Django]

#25771: Serialization of natural foreign key in migration scripts does not work
-+-
 Reporter:  bowensong|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Uncategorized|  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:  database migration   | Triage Stage:
  serialization  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

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


Comment:

 I think this is expected behavior because the `natural_key()` method isn't
 available in migrations. Per
 [https://docs.djangoproject.com/en/dev/topics/migrations/#historical-
 models the docs], "Because it’s impossible to serialize arbitrary Python
 code, these historical models will not have any custom methods that you
 have defined."

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

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

[Django] #25771: Serialization of natural foreign key in migration scripts does not work

[Django]

#25771: Serialization of natural foreign key in migration scripts does not work
+--
 Reporter:  bowensong   |  Owner:  nobody
 Type:  Bug | Status:  new
Component:  |Version:  1.8
  Uncategorized |
 Severity:  Normal  |   Keywords:  database migration serialization
 Triage Stage:  Unreviewed  |  Has patch:  0
Easy pickings:  0   |  UI/UX:  0
+--
 The `serializers.serialize(..., use_natural_foreign_keys=True)` is not
 working in migration scripts, the `ManyToManyField` always have the value
 of the `pk` instead of the `natural_key`

 An example to reproduce this bug:

 models.py
 {{{
 # -*- coding: utf-8 -*-
 from django.db import models


 class Student(models.Model):
 student_id = models.CharField(max_length=10, unique=True)
 name = models.CharField(max_length=30)

 def __unicode__(self):
 return self.name

 def natural_key(self):
 return self.student_id


 class Teacher(models.Model):
 name = models.CharField(max_length=30)
 students = models.ManyToManyField(Student)

 def __unicode__(self):
 return self.name
 }}}


 migrations/0002_example.py
 {{{
 # -*- coding: utf-8 -*-
 from __future__ import unicode_literals

 from django.db import migrations, models
 from django.core import serializers


 def example(apps, schema_editor):
 Teacher = apps.get_model("mytest", "Teacher")
 json_data = serializers.serialize('json', Teacher.objects.all(),
 use_natural_foreign_keys=True)
 print json_data


 class Migration(migrations.Migration):

 dependencies = [
 ('mytest', '0001_initial'),
 ]

 operations = [
 migrations.RunPython(example,
 reverse_code=migrations.RunPython.noop)
 ]
 }}}

 I applied the initial migration, and inserted some data into those tables.

 The dumpdata command output is:
 {{{
 $ python manage.py dumpdata mytest --natural-foreign
 [{"fields": {"student_id": "1234567890", "name": "Alice"}, "model":
 "mytest.student", "pk": 1}, {"fields": {"student_id": "9876543210",
 "name": "Bob"}, "model": "mytest.student", "pk": 2}, {"fields":
 {"students": ["1234567890", "9876543210"], "name": "Petter"}, "model":
 "mytest.teacher", "pk": 1}]
 }}}

 When running the migrate command, output is:
 {{{
 $ python manage.py migrate mytest 0002
 Operations to perform:
   Target specific migration: 0002_example, from mytest
 Running migrations:
   Rendering model states... DONE
   Applying mytest.0002_example...[{"fields": {"students": [1, 2], "name":
 "Petter"}, "model": "mytest.teacher", "pk": 1}]
  OK
 }}}

 Expected output is:
 {{{
 $ python manage.py migrate mytest 0002
 Operations to perform:
   Target specific migration: 0002_example, from mytest
 Running migrations:
   Rendering model states... DONE
   Applying mytest.0002_example...[{"fields": {"students": ["1234567890",
 "9876543210"], "name": "Petter"}, "model": "mytest.teacher", "pk": 1}]
  OK
 }}}

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

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

Re: [Django] #25665: deprecate public getters/setters for properties of `GEOSGeometry` and its subclasses

[Django]

#25665: deprecate public getters/setters for properties of `GEOSGeometry` and 
its
subclasses
-+-
 Reporter:  sir-sigurd   |Owner:  sir-
 Type:   |  sigurd
  Cleanup/optimization   |   Status:  assigned
Component:  GIS  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by sir-sigurd):

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

Re: [Django] #25644: Setting a cookie after deletion should not keep 1970 as expiry date

[Django]

#25644: Setting a cookie after deletion should not keep 1970 as expiry date
---+---
 Reporter:  rollokb|Owner:  raphaelmerx
 Type:  Bug|   Status:  closed
Component:  HTTP handling  |  Version:  1.8
 Severity:  Normal |   Resolution:  fixed
 Keywords:  cookies http   | 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:"0a19f8d4fc864de481eac1b76c799ffd6ced4e91" 0a19f8d]:
 {{{
 #!CommitTicketReference repository=""
 revision="0a19f8d4fc864de481eac1b76c799ffd6ced4e91"
 Fixed #25644 -- Fixed reset cookie expiry date bug.

 Setting a cookie with the same name as a previously deleted cookie
 would set its expiry date to 'Thu, 01-Jan-1970 00:00:00 GMT'.
 }}}

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

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

Re: [Django] #21523: Models DateField to_python method no longer supports mock dates.

[Django]

#21523: Models DateField to_python method no longer supports mock dates.
-+-
 Reporter:  hugo@…   |Owner:
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  1.6
  (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 auvipy):

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


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

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

Re: [Django] #25665: deprecate public getters/setters for properties of `GEOSGeometry` and its subclasses

[Django]

#25665: deprecate public getters/setters for properties of `GEOSGeometry` and 
its
subclasses
-+-
 Reporter:  sir-sigurd   |Owner:  sir-
 Type:   |  sigurd
  Cleanup/optimization   |   Status:  assigned
Component:  GIS  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by timgraham):

 * needs_better_patch:  0 => 1


Comment:

 Left comments for improvement.

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

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

Re: [Django] #16084: makemessages command doesn't respect LOCALE_PATHS setting

[Django]

#16084: makemessages command doesn't respect LOCALE_PATHS setting
-+-
 Reporter:  heylinus |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:   |  Version:  1.4
  Internationalization   |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by termopetteri):

 Hello, commenting an old fixed ticket.

 If an app has 'locale' named folder under its static folder
 (/app_name/static/app_name/locale/foobar.js), makemessages does not pick
 the files in that folder (here foobar.js). Is that intentional?

 Here's the relevant code:
 
https://github.com/django/django/blob/master/django/core/management/commands/makemessages.py#L413

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

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

Re: [Django] #10403: provide declarative syntax to define FormSets - including ModelFormSet and InlineFormSet

[Django]

#10403: provide declarative syntax to define FormSets - including ModelFormSet 
and
InlineFormSet
-+-
 Reporter:  Koen Biermans|Owner:  auvipy
    |
 Type:  New feature  |   Status:  assigned
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  formset  | Triage Stage:  Accepted
  modelformset inlineformset |
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by auvipy):

 Replying to [comment:4 bpeschier]:
 > Ok, so I missed this one O:)
 >
 > I disagree with the implementation in the patch, no !MetaClass is needed
 and just simple additions to the class definitions to make it work, maybe
 with the exception of !InlineFormSet. Will attach a patch later on.

 I saw your patch, and willing to implement it cleanly against master
 branch with a pull request.

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

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