Re: [Django] #8467: For ManyToMany manager, we should convert objects being added or removed to the pk type if they are not.

[Django]

#8467: For ManyToMany manager, we should convert objects being added or removed 
to
the pk type if they are not.
-+-
 Reporter:  Wonlay   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  Duplicate entry, | Triage Stage:  Accepted
  add, remove, ManyToManyField   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"8cc711999ab839c1a93cb228b35beac4a454fafc" 8cc7119]:
 {{{
 #!CommitTicketReference repository=""
 revision="8cc711999ab839c1a93cb228b35beac4a454fafc"
 Refs #8467 -- Added test for RelatedManager.add()/remove() with an invalid
 type.
 }}}

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.a9f71eeed338426503a4a21aa2df3786%40djangoproject.com.

Re: [Django] #19544: IntegrityError during ManyToMany add() on Oracle or for user-defined through relationships.

[Django]

#19544: IntegrityError during ManyToMany add() on Oracle or for user-defined
through relationships.
-+-
 Reporter:  German M. Bravo  |Owner:  Simon
 Type:   |  Charette
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  master
  (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 Mariusz Felisiak ):

 In [changeset:"379bf1a2d41494360d86bc3cf8adc482abca5d63" 379bf1a2]:
 {{{
 #!CommitTicketReference repository=""
 revision="379bf1a2d41494360d86bc3cf8adc482abca5d63"
 Fixed #8467 -- Prevented crash when adding existent m2m relation with an
 invalid type.

 This was an issue anymore on backends that allows conflicts to be
 ignored (Refs #19544) as long the provided values were coercible to the
 expected type. However on the remaining backends that don't support
 this feature, namely Oracle, this could still result in an
 IntegrityError.

 By attempting to coerce the provided values to the expected types in
 Python beforehand we allow the existing value set intersection in
 ManyRelatedManager._get_missing_target_ids to prevent the problematic
 insertion attempts.

 Thanks Baptiste Mispelon for triaging this old ticket against the
 current state of the master branch.
 }}}

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.5506fb53e6371f4da2d2e27bfbfd0adb%40djangoproject.com.

Re: [Django] #8467: For ManyToMany manager, we should convert objects being added or removed to the pk type if they are not.

[Django]

#8467: For ManyToMany manager, we should convert objects being added or removed 
to
the pk type if they are not.
-+-
 Reporter:  Wonlay   |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  Duplicate entry, | Triage Stage:  Accepted
  add, remove, ManyToManyField   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"379bf1a2d41494360d86bc3cf8adc482abca5d63" 379bf1a2]:
 {{{
 #!CommitTicketReference repository=""
 revision="379bf1a2d41494360d86bc3cf8adc482abca5d63"
 Fixed #8467 -- Prevented crash when adding existent m2m relation with an
 invalid type.

 This was an issue anymore on backends that allows conflicts to be
 ignored (Refs #19544) as long the provided values were coercible to the
 expected type. However on the remaining backends that don't support
 this feature, namely Oracle, this could still result in an
 IntegrityError.

 By attempting to coerce the provided values to the expected types in
 Python beforehand we allow the existing value set intersection in
 ManyRelatedManager._get_missing_target_ids to prevent the problematic
 insertion attempts.

 Thanks Baptiste Mispelon for triaging this old ticket against the
 current state of the master branch.
 }}}

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.1a0349f5a4119eccca96760cff93a7ba%40djangoproject.com.

Re: [Django] #19544: IntegrityError during ManyToMany add() on Oracle or for user-defined through relationships.

[Django]

#19544: IntegrityError during ManyToMany add() on Oracle or for user-defined
through relationships.
-+-
 Reporter:  German M. Bravo  |Owner:  Simon
 Type:   |  Charette
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  master
  (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
-+-
Changes (by Andrey Fedoseev):

 * cc: Andrey Fedoseev (removed)


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.2964e4c02c6d972f81db96ea75337140%40djangoproject.com.

Re: [Django] #20941: Provide a way for CBVs to be called from instances

[Django]

#20941: Provide a way for CBVs to be called from instances
---+---
 Reporter:  Marc Tamlyn|Owner:  Marc Tamlyn
 Type:  New feature|   Status:  closed
Component:  Generic views  |  Version:  master
 Severity:  Normal |   Resolution:  duplicate
 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 Baptiste Mispelon):

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


Comment:

 #29750 introduced `View.setup()` which seems to be exactly what Marc
 proposed in his comment (with the name `setup_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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.86cb2eda4c6106ab87744a41357e055c%40djangoproject.com.

Re: [Django] #27914: makemigrations produces incorrect path for inner classes

[Django]

#27914: makemigrations produces incorrect path for inner classes
-+-
 Reporter:  Serge van den Boom   |Owner:  Hasan
 |  Ramezani
 Type:  New feature  |   Status:  new
Component:  Migrations   |  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 John Bowen):

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


Comment:

 commit 6452112640081ac8838147a8ba192c45879203d8 does not resolve this
 ticket.

 The commit patched the `EnumSerializer` with `__qualname__`, which works
 for Enum members.
 However, the `serializer_factory` is returning `TypeSerializer` for the
 Enum subclass, which is still using `__name__`

 With v3.0.x introducing models.Choices, models.IntegerChoices, using
 nested enums will become a common pattern; serializing them properly
 with `__qualname__` seems prudent.

 Here's a patch for the 3.0rc1 build
 
https://github.com/django/django/files/3879265/django_db_migrations_serializer_TypeSerializer.patch.txt

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.76ded22e687c222e2d92c5b15ced4c36%40djangoproject.com.

Re: [Django] #30916: Added support for functional constraints.

[Django]

#30916: Added support for functional constraints.
-+-
 Reporter:  Safwan Rahman|Owner:
 |  saadalsaad
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  constraint   | Triage Stage:  Accepted
  functional |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by saadalsaad):

 felixxm, since this ticket is generic for functional constraints, can we
 move case_insensitive option to a sperate ticket?

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/070.aa7680f8051457b954aa895471f2f10a%40djangoproject.com.

[Django] #31023: Filtering DatetimeField by second not working on Django 2.2.7 (it works on Django 1.10)

[Django]

#31023: Filtering DatetimeField by second not working on Django 2.2.7 (it works 
on
Django 1.10)
-+-
   Reporter:  Ismael |  Owner:  nobody
  Jerez  |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  2.2
  layer (models, ORM)|   Keywords:  query, filter,
   Severity:  Normal |  datetimefield, second
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Hi:

 I recently update Django from version 1.10 to 2.2.7.

 I have a query filtering like this:

 {{{ MyModel.objects.filter(a_datetimefield__second=4).all() }}}

 This returns me an empty QuerySet result.

 But, If I try something like this just for testing:

 {{{
 
MyModel.objects.filter(a_datetimefield__second_icontains='4').first().a_datetimefield.second
 }}}

 It returns {int} 4 !!!

 I tried this too:

 {{{ MyModel.objects.filter(a_datetimefield__second_exact=4).all() }}}

 And the results is the same (empty QuerySet instance)

 Using hour or minute works perfect, it only happens with second attribute.


 Thanks in advance,
 Ismael.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/057.bd585c8a44fb5f76502cb771e0b99fe7%40djangoproject.com.

Re: [Django] #31021: migration doesn't work on multi database environment. (was: migration doesn't work on multi database environment)

[Django]

#31021: migration doesn't work on multi database environment.
--+--
 Reporter:  haudoing  |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  contrib.auth  |  Version:  2.2
 Severity:  Normal|   Resolution:  worksforme
 Keywords:| Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by felixxm):

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


Comment:

 This migration doesn't brake anything for me. I checked with
 [https://docs.djangoproject.com/en/2.2/topics/db/multi-db/#an-example an
 example] from docs and it doesn't require a `default` DB.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.dea7e5be032e0c200a28c71065ddb7a7%40djangoproject.com.

Re: [Django] #30916: Added support for functional constraints.

[Django]

#30916: Added support for functional constraints.
-+-
 Reporter:  Safwan Rahman|Owner:
 |  saadalsaad
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  constraint   | Triage Stage:  Accepted
  functional |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by felixxm):

 saadalsaad, not really we don't want to add such specific parameters.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/070.334fd30b76b06ea45211001e63da17c0%40djangoproject.com.

Re: [Django] #27914: makemigrations produces incorrect path for inner classes

[Django]

#27914: makemigrations produces incorrect path for inner classes
-+-
 Reporter:  Serge van den Boom   |Owner:  Hasan
 |  Ramezani
 Type:  New feature  |   Status:  new
Component:  Migrations   |  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 felixxm):

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


Comment:

 Agreed, we should fix this.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.5e1aa5016f73b787bb579562b51523c5%40djangoproject.com.

Re: [Django] #27914: makemigrations produces incorrect path for inner classes

[Django]

#27914: makemigrations produces incorrect path for inner classes
-+-
 Reporter:  Serge van den Boom   |Owner:  Hasan
 |  Ramezani
 Type:  New feature  |   Status:  new
Component:  Migrations   |  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 Hasan Ramezani):

 I will create a patch a soon as possible.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.c44f6dfee97ef32ac8494c08ec1708fe%40djangoproject.com.

Re: [Django] #9762: template filter |date:"r" not valid RFC 2822 formatted when LANGUAGE_CODE different than english

[Django]

#9762: template filter |date:"r" not valid RFC 2822 formatted when LANGUAGE_CODE
different than english
--+
 Reporter:  Antonio Melé  |Owner:  kgrandis
 Type:  Bug   |   Status:  closed
Component:  Utilities |  Version:  master
 Severity:  Normal|   Resolution:  fixed
 Keywords:  date template filter  | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"8929afb8ec4bc2bfb95b66c05fc3ab39e3748d91" 8929afb]:
 {{{
 #!CommitTicketReference repository=""
 revision="8929afb8ec4bc2bfb95b66c05fc3ab39e3748d91"
 Fixed #9762 -- Made DateFormat.r() locale-independent.

 Thanks to Antonio Melé for the original report all those years ago
 and to all the contributors who helped along the way.
 }}}

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

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

Re: [Django] #26281: Improve utils.formats.date_format() error message when using time formatting with datetime.date

[Django]

#26281: Improve utils.formats.date_format() error message when using time
formatting with datetime.date
-+-
 Reporter:  Florian Eßer |Owner:  Marko
 Type:   |  Benko
  Cleanup/optimization   |   Status:  closed
Component:  Utilities|  Version:  1.9
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"76ec032712d28dd8d4b9ad425f2b330a3e9a9109" 76ec032]:
 {{{
 #!CommitTicketReference repository=""
 revision="76ec032712d28dd8d4b9ad425f2b330a3e9a9109"
 Refs #26281 -- Added a helpful error message for an invalid "r" specifier
 to dateformat.format().
 }}}

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.4af828f0c055ebd99113033093a2e3af%40djangoproject.com.

Re: [Django] #27914: makemigrations produces incorrect path for inner classes

[Django]

#27914: makemigrations produces incorrect path for inner classes
-+-
 Reporter:  Serge van den Boom   |Owner:  Hasan
 |  Ramezani
 Type:  New feature  |   Status:  new
Component:  Migrations   |  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 John Bowen):

 Submitted PR: https://github.com/django/django/pull/12125

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.c9c765a57bbda32cc065064f5663d9d7%40djangoproject.com.

Re: [Django] #27914: makemigrations produces incorrect path for inner classes

[Django]

#27914: makemigrations produces incorrect path for inner classes
-+-
 Reporter:  Serge van den Boom   |Owner:  Hasan
 |  Ramezani
 Type:  New feature  |   Status:  new
Component:  Migrations   |  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 John Bowen):

 * Attachment "0001-Fixes-27914-Fixed-serialization-of-nested-classes-
 se.patch" added.

 PR: https://github.com/django/django/pull/12125

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.177d75670830413e3c1a2dc5a03a2c1c%40djangoproject.com.

Re: [Django] #31023: __second lookup doesn't work on Django 2.2.7. (was: Filtering DatetimeField by second not working on Django 2.2.7 (it works on Django 1.10))

[Django]

#31023: __second lookup doesn't work on Django 2.2.7.
-+-
 Reporter:  Ismael Jerez |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  query, filter,   | Triage Stage:
  datetimefield, second  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

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


Comment:

 Thanks for this report, however I'm not able to reproduce this issue. If
 you use `USE_TZ = True` then it can be related with the lack of
 [https://docs.djangoproject.com/en/2.2/ref/models/querysets/#database-
 time-zone-definitions time zone definitions in the database]. Can you
 provide more details or a sample project?

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

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

Re: [Django] #30996: Add AsWKB and AsWKT GIS functions.

[Django]

#30996: Add AsWKB and AsWKT GIS functions.
-+-
 Reporter:  Sergey Fedoseev  |Owner:  Sergey
 |  Fedoseev
 Type:  New feature  |   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 Mariusz Felisiak ):

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


Comment:

 In [changeset:"a5855c8f0fe17b7e888bd8137874ef78012a7294" a5855c8]:
 {{{
 #!CommitTicketReference repository=""
 revision="a5855c8f0fe17b7e888bd8137874ef78012a7294"
 Fixed #30996 -- Added AsWKB and AsWKT GIS functions.
 }}}

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.7d3a22e4ee92f17034ad6a8d08b0e6cc%40djangoproject.com.

Re: [Django] #27914: makemigrations produces incorrect path for inner classes

[Django]

#27914: makemigrations produces incorrect path for inner classes
-+-
 Reporter:  Serge van den Boom   |Owner:  Hasan
 |  Ramezani
 Type:  New feature  |   Status:  new
Component:  Migrations   |  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 John Bowen):

 * has_patch:  0 => 1


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

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

Re: [Django] #30916: Added support for functional constraints.

[Django]

#30916: Added support for functional constraints.
-+-
 Reporter:  Safwan Rahman|Owner:
 |  saadalsaad
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  constraint   | Triage Stage:  Accepted
  functional |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by saadalsaad):

 Replying to [ticket:30916 Safwan Rahman]:
 > Case insensitive unique constraint is needed for various purposes like
 storing emails. In postgresql, its possible to add
 [https://www.postgresql.org/message-
 id/c57a8ecec259afdc4f4caafc5d0e9...@mitre.org a functional unique index
 with `Lower`] and it will work as a case insensitive unique constraint. I
 have tried to implement that functional unique index/constraint in django,
 but looking at the source it seems that it is not possible to add
 functional unique index/constraint in django.
 [https://github.com/django/django/pull/11929 PR 11929] is created for
 adding functional index, but it seems like it is not possible to create
 unique functional index with it.
 >
 > I think there should be a option like `case_insensitive=True` that can
 be passed to `UniqueConstraint` so the `UniqueConstraint` create a
 functional unique index with `Lower`.
 >
 > I know, its possible to store the value as lower case always and
 mitigate this issue, but it does not provide DB level constrains safety
 from anomaly.

 Ticket description suggested adding case_insensitive option to be added in
 UniqueConstraint to create a functional unique index with `Lower`
 since we are not going to add such option, seems we need to modify ticket
 description
 felixxm, do you mean supporting functional constraints (supporting
 expressions in class based constraints ?) similar to indexes in #26167 ?

 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/070.c8ba37d867a80c1c18b68e89ffc43c01%40djangoproject.com.

Re: [Django] #30916: Added support for functional constraints.

[Django]

#30916: Added support for functional constraints.
-+-
 Reporter:  Safwan Rahman|Owner:
 |  saadalsaad
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  constraint   | Triage Stage:  Accepted
  functional |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by felixxm):

 Replying to [comment:16 saadalsaad]:

 > felixxm, do you mean supporting functional constraints (supporting
 expressions in class based constraints ?) similar to indexes in #26167 ?
 >
 > Thanks

 Yes exactly, see [https://code.djangoproject.com/ticket/30916?#comment:5
 comment].

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

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

[Django] #31024: firstof template tag documentation incorrectly specifies value testing

[Django]

#31024: firstof template tag documentation incorrectly specifies value testing
+
   Reporter:  Keryn Knight  |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Documentation |Version:  master
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 The documentation for `{%firstof x y z %}` says:

 > Outputs the first argument variable that is not **False**. Outputs
 nothing if all the passed variables are **False**.

 The emphasis not mine, and indicates it's specifically testing for the
 singleton False. But the example it gives as an equivalent is based on
 normal [https://docs.python.org/3/library/stdtypes.html#truth-value-
 testing truth value testing]:
 {{{
 {% if var1 %}
 {{ var1 }}
 {% elif var2 %}
 {{ var2 }}
 {% elif var3 %}
 {{ var3 }}
 {% endif %}
 }}}
 and the
 
[https://github.com/django/django/blob/a5855c8f0fe17b7e888bd8137874ef78012a7294/django/template/defaulttags.py#L125
 code is also based on truthiness]

 The documentation for how a simple `{% if ... %}` behaves meanwhile more
 correctly prescribes it's function related to ''"true"'' and what that
 means.
 > evaluates a variable, and if that variable is “true” (i.e. exists, is
 not empty, and is not a false boolean value) the contents of the block are
 output

 Were it actually based on **False** rather than **Falsiness**, the
 following would not output ''truthy''.
 {{{
 >>> from django.template import Template, Context
 >>> context = {'a': None,'b': False,'c': 0,'d': '','e': (),'f': [],'g':
 {},'h': set(),'i': "truthy"}
 >>> t = Template("{% firstof a b c d e f g h i %}")
 >>> t.render(Context(context))
 'truthy'
 }}}

 Suggestion is to clarify that it's based on truthiness/falsiness, rather
 than imply it's directly based on encountering **False**.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/052.f29f312ca89c6637f5000f06af3ed5d1%40djangoproject.com.

Re: [Django] #30953: Model Inheritance and select_for_update with 'of'

[Django]

#30953: Model Inheritance and select_for_update with 'of'
-+-
 Reporter:  Abhijeet |Owner:  Abhijeet
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  2.1
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  select_for_update| Triage Stage:  Accepted
  mti model inheritance  |
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * needs_better_patch:  0 => 1
 * needs_tests:  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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.b0f11dac6ff634c5ad13b3ef5a56e2bb%40djangoproject.com.

Re: [Django] #25287: Multiplying and dividing connectors for datetime expressions are not supported by sqlite backed.

[Django]

#25287: Multiplying and dividing connectors for datetime expressions are not
supported by sqlite backed.
-+-
 Reporter:  Ahmet DAL|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  sqlite3, | Triage Stage:  Accepted
  combine_duration_expression, F |
  expressions,   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Baptiste Mispelon):

 * version:  1.8 => 3.0


Comment:

 I was able to reproduce the reported error on the latest master
 (a5855c8f0fe17b7e888bd8137874ef78012a7294) by using the following models:
 {{{
 #!python
 from django.db import models


 class Ticket(models.Model):
 date_opened = models.DateTimeField()


 class Rule(models.Model):
 duration = models.DurationField()


 class Action(models.Model):
 percent = models.FloatField()
 rule = models.ForeignKey('Rule', on_delete=models.CASCADE)


 class Expire(models.Model):
 ticket = models.ForeignKey('Ticket', on_delete=models.CASCADE)
 action = models.ForeignKey('Action', on_delete=models.CASCADE)
 }}}

 And the following testcase:
 {{{
 #!python
 from datetime import timedelta

 from django.db.models import F
 from django.test import TestCase
 from django.utils import timezone

 from .models import Ticket, Rule, Action, Expire


 class TicketTestCase(TestCase):
 def test_ticket(self):
 now = timezone.now()

 ticket1 = Ticket.objects.create(date_opened=now-timedelta(days=6))
 ticket2 = Ticket.objects.create(date_opened=now-timedelta(days=4))

 rule = Rule.objects.create(duration=timedelta(days=10))
 action = Action.objects.create(rule=rule, percent=50)

 expire = Expire.objects.create(ticket=ticket1, action=action)
 expire = Expire.objects.create(ticket=ticket2, action=action)


 qs =
 Expire.objects.filter(ticket__date_opened__lte=(timezone.now() -
 F("action__percent") * F("action__rule__duration") / 100))
 self.assertQuerysetEqual(qs, [ticket1.pk], transform=lambda x:
 x.ticket.pk)
 }}}

 As described in the original ticket, the testcase fails with sqlite
 (`DatabaseError: Invalid connector for timedelta: *.`) but passes when
 using postgresql.

 The proposed solution of adding the new `*` and `/` operators to
 `sqlite3.DatebaseOperations.combine_duration_expression()` [1] only works
 in that the `DatebaseError` disappears but the test still fails because
 the returned queryset is empty.

 Josh's suggestions of wrapping everything in an `ExpressionWrapper` don't
 seem to make a difference either.



 [1]
 
https://github.com/django/django/blob/a5855c8f0fe17b7e888bd8137874ef78012a7294/django/db/backends/sqlite3/operations.py#L315

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.08c1cf15111d06ccbbfcc9b6b9d09e1f%40djangoproject.com.

Re: [Django] #25060: Add support for str(timedelta) representation in parse_duration

[Django]

#25060: Add support for str(timedelta) representation in parse_duration
-+
 Reporter:  Mikhail  |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Utilities|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by Baptiste Mispelon):

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


Comment:

 Replying to [comment:10 Matthew Schinckel]:
 > I think the parse_duration() function already does this.

 That's correct. It looks like this was inadvertently added with #24897
 (262d4db8c4c849b0fdd84550fb96472446cf90df).

 There are even tests for a variety of different `timedelta` cases:
 
https://github.com/django/django/blob/a5855c8f0fe17b7e888bd8137874ef78012a7294/tests/utils_tests/test_dateparse.py#L54

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.e31e47e3edb6ed4a2c6a2182fcab2296%40djangoproject.com.

Re: [Django] #25177: Filter reference field on model to a date difference raise a TypeError

[Django]

#25177: Filter reference field on model to a date difference raise a TypeError
-+-
 Reporter:  Mounir   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.8
  (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
-+-
Changes (by Tim Graham):

 * Attachment "25177-test.diff" removed.

 A test for Django's test suite that reproduces the crash.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/059.3898d7c4d76dc9870dd5a164008a15d4%40djangoproject.com.

Re: [Django] #25177: Filter reference field on model to a date difference raise a TypeError

[Django]

#25177: Filter reference field on model to a date difference raise a TypeError
-+-
 Reporter:  Mounir   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.8
  (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
-+-
Changes (by Baptiste Mispelon):

 * Attachment "25177-test.diff" added.

 Updated test patch to latest 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/074.0562149193d58c970ceb6d61e1fb2dc3%40djangoproject.com.

Re: [Django] #31010: Add subdomains of localhost to ALLOWED_HOSTS in DEBUG mode

[Django]

#31010: Add subdomains of localhost to ALLOWED_HOSTS in DEBUG mode
---+
 Reporter:  thenewguy  |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  2.2
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+
Changes (by thenewguy):

 * status:  closed => new
 * resolution:  needsinfo =>
 * easy:  0 => 1
 * stage:  Unreviewed => Accepted


Old description:

> It would minimize configuration for new projects if ALLOWED_HOSTS +=
> ['.localhost'] when DEBUG=True
>
> Chrome resolves *.localhost to localhost without modifying any host files
> or DNS
>
> Referencing the project this way makes it easy to test subdomains ->
> static.localhost, uploads.localhost, www.localhost, etc

New description:

 It would minimize configuration for new projects if ALLOWED_HOSTS +=
 ['.localhost'] when DEBUG=True

 Chrome resolves *.localhost to localhost without modifying any host files
 or DNS

 Referencing the project this way makes it easy to test subdomains ->
 static.localhost, uploads.localhost, www.localhost, etc

 ---
 Updated
 ---

 Conversation on developer mailing list resulted in decision to reopen and
 accept ticket.  The conversation turned up that this behavior is spec
 compliant per https://tools.ietf.org/html/rfc6761#section-6.3

--

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.0ecb4b53def6bde26266653d317b089c%40djangoproject.com.

Re: [Django] #24709: ArrayField doesn't support .update() and F() objects

[Django]

#24709: ArrayField doesn't support .update() and F() objects
-+-
 Reporter:  ris  |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  contrib.postgres |  Version:  1.8
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  postgresql contrib   | Triage Stage:  Accepted
  arrayfield update  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Baptiste Mispelon):

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


Comment:

 Duplicate of #26355

 (even though this ticket is older, the other one has a pull request which
 is why I'm closing this one)

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/061.e5809bf5878c58581356176bb12c2bfd%40djangoproject.com.

Re: [Django] #26355: Add support for PostgreSQL's array_append to ArrayField

[Django]

#26355: Add support for PostgreSQL's array_append to ArrayField
-+-
 Reporter:  Paul Grau|Owner:  Asif
 |  Saifuddin Auvi
 Type:  New feature  |   Status:  assigned
Component:  contrib.postgres |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Baptiste Mispelon):

 For reference, I just closed #24709 as a duplicate. It had some ideas
 about a possible API which might be worth a look for anyone interested in
 picking this up again.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.5251d6e1e5c7ab39fd4d66c9e1430949%40djangoproject.com.

Re: [Django] #27914: makemigrations produces incorrect path for inner classes

[Django]

#27914: makemigrations produces incorrect path for inner classes
-+-
 Reporter:  Serge van den Boom   |Owner:  Hasan
 |  Ramezani
 Type:  New feature  |   Status:  new
Component:  Migrations   |  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 John Bowen):

 * Attachment "0002-Fixed-
 WriterTests.test_deconstruct_class_arguments-t.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.97da7a45ecffabb5c9e5e54db391b333%40djangoproject.com.

Re: [Django] #28469: Add additional response type subclasses

[Django]

#28469: Add additional response type subclasses
-+-
 Reporter:  Adam (Chainz)|Owner:  nobody
  Johnson|
 Type:  New feature  |   Status:  new
Component:  HTTP handling|  Version:  1.11
 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 Baptiste Mispelon):

 * has_patch:  0 => 1


Comment:

 I took a first stab at a documentation patch for this:
 https://github.com/django/django/pull/12126

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.72bba4ae1e225670c67966e7d62f6a16%40djangoproject.com.

[Django] #31025: Deprecation warning when building the docs

[Django]

#31025: Deprecation warning when building the docs
+
   Reporter:  Baptiste Mispelon |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Documentation |Version:  master
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  1
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 I noticed a deprecation warning while building the documentation locally
 today:
 {{{
 ./django/docs/_ext/djangodocs.py:260: RemovedInSphinx30Warning:
 HTMLTranslator.highlightlinenothreshold is deprecated.
   linenos = win_text.count('\n') >= self.highlightlinenothreshold - 1
 }}}

 Looks like the `highlightlinenothreshold` property is going away in Sphinx
 3.0.
 Luckily it looks like the fix should be straightforward
 (`highlightlinenothreshold` was basically an alias for `sys.maxsize`). [1]

 PR incoming.

 [1] https://github.com/sphinx-
 doc/sphinx/commit/61098a0ae2e696a804459d36bd74ca57db76eda5#diff-
 9ae39fbf16dabc27af998b9c0a6968a0L977

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/052.c80477f2faaf25d4dfd211d7bcf2cbb7%40djangoproject.com.

Re: [Django] #31006: Document how to escape a date/time format character for the |date and |time filters.

[Django]

#31006: Document how to escape a date/time format character for the |date and 
|time
filters.
-+-
 Reporter:  Baptiste Mispelon|Owner:  Ryan
 Type:   |  Cheley
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Ryan Cheley):

 I have made the requested change (I think) which can be found here
 [https://github.com/ryancheley/django/tree/ticket_31006]

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.c72c703878e393afaa931dfaeb34fea3%40djangoproject.com.