Re: [Django] #13009: provide django.forms field type info for use in templates

[Django]

#13009: provide django.forms field type info for use in templates
-+-
 Reporter:  Tom von Schwerdtner  |Owner:  David
 |  Smith
 Type:  New feature  |   Status:  assigned
Component:  Forms|  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 felixxm):

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

Re: [Django] #31425: Support for Clear-Site-Data header. (was: Support for Clear-Site-Data header)

[Django]

#31425: Support for Clear-Site-Data header.
---+-
 Reporter:  Mads Jensen|Owner:  nobody
 Type:  New feature|   Status:  new
Component:  HTTP handling  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Someday/Maybe
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+-
Changes (by felixxm):

 * stage:  Unreviewed => Someday/Maybe


Old description:

> There's a new header described at https://github.com/w3c/webappsec-clear-
> site-data that can be used to enforce the browser to remove various types
> of data that the user leaves behind. A usage example is to clear data on
> either an account deletion, or simply when signing out. Examples are the
> cache and the cookies. The document is still a working draft.
>
> Some time ago, support for the cookie SameSite flag was implemented.
>
> It appears that the major browser vendors have implemented support for
> it, to some extend.
> https://developer.mozilla.org/enUS/docs/Web/HTTP/Headers/Clear-Site-Data

New description:

 There's a new header described at https://github.com/w3c/webappsec-clear-
 site-data that can be used to enforce the browser to remove various types
 of data that the user leaves behind. A usage example is to clear data on
 either an account deletion, or simply when signing out. Examples are the
 cache and the cookies. The document is still a working draft.

 Some time ago, support for the cookie SameSite flag was implemented.

 It appears that the major browser vendors have implemented support for it,
 to some extend. https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers
 /Clear-Site-Data

--

Comment:

 Marking as "Someday/Maybe" because specification is still a draft and may
 change at any moment.

-- 
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.dd38bc23fe71e3dcb0a7c58c84c42b96%40djangoproject.com.

Re: [Django] #31427: Better support for __html__ in django admin

[Django]

#31427: Better support for __html__ in django admin
+--
 Reporter:  Olivier Dalang  |Owner:  andyrobles
 Type:  New feature |   Status:  assigned
Component:  contrib.admin   |  Version:  3.0
 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:  1
+--
Changes (by andyrobles):

 * owner:  nobody => andyrobles
 * status:  new => assigned


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

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

Re: [Django] #31433: Model.objects.create() doesn't utilize caching for prefetches defined on the ObjectManager. (was: Model.objects.create() doesn't utilize caching for prefetches defined on the Obje

[Django]

#31433: Model.objects.create() doesn't utilize caching for prefetches defined on
the ObjectManager.
-+-
 Reporter:  Nathan Yan   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  prefetch cache   | 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:   => invalid


Comment:

 `get_queryset()` is not called for new objects created with
 `QuerySet.create()`. It's not a bug in Django it's a false assumption that
 you made in your implementation. Please use one of
 [https://code.djangoproject.com/wiki/TicketClosingReasons/UseSupportChannels
 support channels].


 Closing per TicketClosingReasons/UseSupportChannels.

-- 
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.753a1ea6bdb81c55dc49f447e181beea%40djangoproject.com.

Re: [Django] #31429: Django test client adds carriage return on empty request. (was: Django Client. Empty body adding carriage character)

[Django]

#31429: Django test client adds carriage return on empty request.
-+-
 Reporter:  Muresan Paul |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Testing framework|  Version:  3.0
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  carriage-character   | Triage Stage:
  Django-test security   |  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 ticket. First of all we're talking about **test** Client
 so it's hard for me to imagine how this can be a security issue. Secondly,
 can you provide any details why carriage is not expected e.g. RFC section.
 Thirdly `post()` already uses `json.dumps()`, so I'm not sure what kind of
 change you're proposing.

-- 
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.aff71e1611099121bbbc6286d71409ea%40djangoproject.com.

Re: [Django] #30779: technical_500.html: use filename:lineno format for exception location

[Django]

#30779: technical_500.html: use filename:lineno format for exception location
--+
 Reporter:  Daniel Hahler |Owner:  (none)
 Type:  Cleanup/optimization  |   Status:  new
Component:  Error reporting   |  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 Hasan Ramezani):

 * cc: Hasan Ramezani (added)
 * 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.0ae889c0bcb714678392a5aadabee2da%40djangoproject.com.

Re: [Django] #31358: Increase default password salt size in BasePasswordHasher.

[Django]

#31358: Increase default password salt size in BasePasswordHasher.
--+
 Reporter:  Jon Moroney   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Utilities |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Jon Moroney):

 No worries on the late reply. I know the world is a bit hectic right now
 :)

 I've gone ahead and made a PR which adds an empty decode function to the
 base password hasher as well as a simple implementation to the pbkdf2
 hasher.

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

 I think it's probably better to require the decode function rather than
 having to deal with if it exists or not and update salt lengths only if
 the function does exist. I feel that having this be optional will only
 lead to more headaches down the line.

 Let me know how you feel about this and I can update the PR to include
 similar `decode()`s for the other hashers included.

-- 
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.ed13900d3be0c2f040957178293824eb%40djangoproject.com.

Re: [Django] #31430: Bug in django.test.client.Client._handle_redirects.

[Django]

#31430: Bug in django.test.client.Client._handle_redirects.
---+---
 Reporter:  Jacob Stöhr|Owner:  Jacob Stöhr
 Type:  Bug|   Status:  closed
Component:  Testing framework  |  Version:  master
 Severity:  Normal |   Resolution:  invalid
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+---

Comment (by Jacob Stöhr):

 Thank you for your speedy response!

 I have now been debugging my issue for another ~2 hours (and I havent seen
 your mail until just now), turns out this was not django's fault (of
 course) but a commit no other than myself made 8 months ago that caused
 the problem in our project.
 I foolishly returned a bare `HttpResponse(status=308)` and overwrote the
 `Location` to force a redirect. This of course failed in the
 `_handle_redirects` method of the testclient because the `status_code` was
 in `redirect_status_codes` but the response was not based on
 `HttpResponseRedirectBase` and did thus not have the `url` property.

 Your suggestion is of course correct, I will fix it in our project. Thank
 you very much :)

-- 
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/069.d8d91271ececf12554c76031dfde6c64%40djangoproject.com.

Re: [Django] #31430: Bug in django.test.client.Client._handle_redirects. (was: Bug in django.test.client.Client._handle_redirects)

[Django]

#31430: Bug in django.test.client.Client._handle_redirects.
---+---
 Reporter:  Jacob Stöhr|Owner:  Jacob Stöhr
 Type:  Bug|   Status:  closed
Component:  Testing framework  |  Version:  master
 Severity:  Normal |   Resolution:  invalid
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+---
Changes (by felixxm):

 * status:  assigned => closed
 * resolution:   => invalid
 * component:  Uncategorized => Testing framework


Comment:

 `test.Client` supports 307 and 308 redirects (see #27999). You should
 return `HttpResponseRedirect(redirect_to, status=308)`.

-- 
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/069.2ed6cffd3e2fd72e57acf7c864e680df%40djangoproject.com.

[Django] #31433: Model.objects.create() doesn't utilize caching for prefetches defined on the ObjectManager

[Django]

#31433: Model.objects.create() doesn't utilize caching for prefetches defined on
the ObjectManager
-+-
   Reporter:  Nathan |  Owner:  nobody
  Yan|
   Type:  Bug| Status:  new
  Component:  Database   |Version:  3.0
  layer (models, ORM)|
   Severity:  Normal |   Keywords:  prefetch cache
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 In this example:


 {{{
 class Foo(models.Model):

 objects = FooManager()

 class FooManager(models.Manager):

 def get_queryset(self):
 return (...).prefetch_related("bars")


 fooA = Foo.objects.get(...)
 fooA.bars # already prefetched + cached for later
 fooB = Foo.objects.create()
 fooB.bars # not prefetched
 fooB.bars # queries again because not included in prefetch cache
 }}}

 I would expect fooA and fooB's caches to behave similarly since they're
 sourced from the same ObjectManager. If it's not a bug, is there a way to
 specify the same `prefetch_related` caching functionality for created
 objects?

-- 
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/056.33cb67f7fae75d2d41ea1dec6445de3f%40djangoproject.com.

Re: [Django] #31432: Conform to HTTP Status Code RFC's redirect classes. (was: Conform to HTTP Status Code RFC's more closely (django.http.response redirect classes))

[Django]

#31432: Conform to HTTP Status Code RFC's redirect classes.
-+-
 Reporter:  Jacob Stöhr  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  HTTP handling|  Version:  master
 Severity:  Normal   |   Resolution:  wontfix
 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:   => wontfix
 * component:  Uncategorized => HTTP handling


Comment:

 RFC 7238 is still experimental and as you already mentioned this change is
 strongly backward incompatible. Moreover 307/308 do not allow changing the
 request method from POST to GET. Deprecation process would be quite
 complicated. Please start a discussion on the DevelopersMailingList, we
 can re-open this ticket if we reach a consensus on a mailing list.

 Related to #30582.

-- 
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/069.f212210036901d9b715553e33d8b2323%40djangoproject.com.

Re: [Django] #31431: Coverage integration with multiprocessed Django tests. (was: Better Coverage Analysis integration with multiprocessed Django Test (ParallelTestSuite))

[Django]

#31431: Coverage integration with multiprocessed Django tests.
-+-
 Reporter:  Ichlasul Affan   |Owner:  Ichlasul
 |  Affan
 Type:  New feature  |   Status:  closed
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  coverage; parallel   | Triage Stage:
  testing|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

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


Comment:

 Thanks for this ticket, however it was already discussed in #4501 and we
 decided that it would be a overkill, see
 [https://code.djangoproject.com/ticket/4501#comment:24 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/072.ae85cd1c01b3796e1397770fe4a27e53%40djangoproject.com.

Re: [Django] #28919: Add support for Common Table Expression (CTE) queries

[Django]

#28919: Add support for Common Table Expression (CTE) queries
-+-
 Reporter:  Daniel Miller|Owner:  Moses
 |  Mugisha
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  QuerySet.extra   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Ryan Hiebert):

 * cc: Ryan Hiebert (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/067.567a306da7871da7a052a02a7015d4e6%40djangoproject.com.

Re: [Django] #31430: Bug in django.test.client.Client._handle_redirects

[Django]

#31430: Bug in django.test.client.Client._handle_redirects
---+---
 Reporter:  Jacob Stöhr|Owner:  Jacob Stöhr
 Type:  Bug|   Status:  assigned
Component:  Uncategorized  |  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
---+---

Comment (by Jacob Stöhr):

 While trying to fix this bug, I encountered something else which I filed
 under https://code.djangoproject.com/ticket/31432 . Fixing that ticket
 would render this ticket obsolete, therefore I will not produce a patch
 for this ticket yet.

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

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

[Django] #31432: Conform to HTTP Status Code RFC's more closely (django.http.response redirect classes)

[Django]

#31432: Conform to HTTP Status Code RFC's more closely (django.http.response
redirect classes)
+
   Reporter:  Jacob Stöhr   |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Uncategorized |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 |
+
 Hello,

 while filing (and trying to fix) #31430 I noticed that the class
 `HttpResponsePermanentRedirect` in django.http.response has its
 `status_code` set to `301`.

 According to the `http` python module and more specifically RFC 7238
 ([https://tools.ietf.org/html/rfc7238]) the name `PermanentRedirect` is
 used to describe the HTTP Status code `308`. `301` is called
 `MovedPermanently` according to  RFC 7231
 ([https://tools.ietf.org/html/rfc7231#section-6.4.2]).

 Therefore I propose to rename the class `HttpResponsePermanentRedirect` to
 `HttpResponseMovedPermanently` with a status code of `301` and to modify
 the existing class to have a status code of `308`. I am aware that this is
 backwards incompatible and will break 33 currently existing tests (I
 tested it real quick locally) and probably countless uses in tests.
 However I think it is important to comply with the official spec.

 I would appreciate any feedback, I don't know who would be responsible for
 this kind of ticket so I cannot assign it directly.
 If desired, I could probably come up with a patch or at least help with
 creating one.

 Regards,
 Jacob

-- 
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/054.f4e6a01133fcf4caf7419689bb2bb150%40djangoproject.com.

Re: [Django] #31431: Better Coverage Analysis integration with multiprocessed Django Test (ParallelTestSuite)

[Django]

#31431: Better Coverage Analysis integration with multiprocessed Django Test
(ParallelTestSuite)
-+-
 Reporter:  Ichlasul Affan   |Owner:  Ichlasul
 |  Affan
 Type:  New feature  |   Status:  assigned
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  coverage; parallel   | Triage Stage:
  testing|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Ichlasul Affan):

 * owner:  nobody => Ichlasul Affan
 * status:  new => assigned


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

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

[Django] #31431: Better Coverage Analysis integration with multiprocessed Django Test (ParallelTestSuite)

[Django]

#31431: Better Coverage Analysis integration with multiprocessed Django Test
(ParallelTestSuite)
-+-
   Reporter:  Ichlasul   |  Owner:  nobody
  Affan  |
   Type:  New| Status:  new
  feature|
  Component:  Testing|Version:  master
  framework  |   Keywords:  coverage; parallel
   Severity:  Normal |  testing
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Currently, to use {{{Coverage.py}}} for line coverage analysis on Django
 tests, we can use this command:
 {{{
 coverage run --omit='' manage.py test .
 coverage report -m
 }}}

 This method is valid on single-processed testing. {{{Coverage.py}}} will
 analyze which lines that Python interpreter has gone through when the
 testing process runs. Unfortunately, on multi-processed testing, coverage
 analysis result becomes invalid as it marks some lines as "uncovered",
 given the same code and test suites.

 Based on my initial observation, looks like the {{{Coverage.py}}} only
 analyze lines run by main Python interpreter process. The child processes
 are untouched. So, only tests run by the first process that are being
 analyzed. For example, I have two different test suites:
 - {{{AccountTests}}} for {{{account}}} app, and
 - {{{HistoryTests}}} for {{{history}}} app.
 Let's say the first test process will run {{{AccountTests}}}. The result
 will only mark as "covered" on code lines in {{{account}}} app, and some
 of the {{{models.py}}}, {{{urls.py}}}, and {{{apps.py}}} code of
 {{{history}}} app. The latter happened because Django initialized App
 registry, test models, and migrations using codes in {{{apps.py}}} and
 {{{models.py}}}. The parent {{{urls.py}}} also imports {{{urls.py}}}
 inside each app.

 These are subfeatures that I propose in this ticket:
 1. Integration of Coverage.py into Django Test engine, so we can use
 coverage analysis by using: {{{python manage.py test --check-coverage
 --coverage-omit='' ..}}}. The execution of Coverage.py is now
 handled by Django test using different test runner called
 {{{CoverageTestRunner}}}, that extends the ordinary {{{DiscoverRunner}}}.
 2. Implementation of {{{CoverageTestRunner}}} itself, by utilizing
 {{{Coverage.py}}}'s own API. This includes initialization process for
 coverage analysis inside the test runner.
 3. Implementation of multiprocessed test runner support. It might be
 implemented using different init worker than the usual
 {{{ParallelTestSuite}}}, or there might be any better idea in the future.
 When merging test results into parent process, it will also need to merge
 the coverage analysis result of each processes.

 I have no idea yet for a concrete Proof of Concept. The main idea is
 initializing coverage analysis API for each of test processes, then merge
 the results using {{{OR}}} operator. That said, a line counts as "covered"
 when it is executed by minimum of one test process. Any suggestions about
 this idea will be very much appreciated.

-- 
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.0f92d6dd1625d0269d1910ec276a7fef%40djangoproject.com.

Re: [Django] #31430: Bug in django.test.client.Client._handle_redirects

[Django]

#31430: Bug in django.test.client.Client._handle_redirects
---+---
 Reporter:  Jacob Stöhr|Owner:  Jacob Stöhr
 Type:  Bug|   Status:  assigned
Component:  Uncategorized  |  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 Jacob Stöhr):

 * owner:  nobody => Jacob Stöhr
 * status:  new => assigned


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

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

[Django] #31430: Bug in django.test.client.Client._handle_redirects

[Django]

#31430: Bug in django.test.client.Client._handle_redirects
-+
   Reporter:  Jacob Stöhr|  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Uncategorized  |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  |
-+
 When handling redirects via the method mentioned above, for example via
 `client.get(path, follow=True)`, a failure will occur when a response
 received somewhere in the chain does not bases `HttpResponseRedirectBase`
 from django.http.response because only instances/objects which are derived
 from that class have the `url` attribute. The attribute is accessed inside
 the function mentioned in the summary to determine where to redirect to.

 For example:
 a view yields a 308 Code which will be an instance of a plain
 `HttpResponse` object instead of a subclass of `HttpResponseRedirectBase`,
 thus it does not have a `url` attribute with the url the response is
 redirecting to.

 I will hand in a patch soon.

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

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

Re: [Django] #31429: Django Client. Empty body adding carriage character

[Django]

#31429: Django Client. Empty body adding carriage character
-+-
 Reporter:  paulpmi  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Testing framework|  Version:  3.0
 Severity:  Normal   |   Resolution:
 Keywords:  carriage-character   | Triage Stage:
  Django-test security   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by paulpmi):

 * type:  Cleanup/optimization => Bug


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

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

Re: [Django] #31429: Django Client. Empty body adding carriage character (was: Django Client. Empty body adding carraige character)

[Django]

#31429: Django Client. Empty body adding carriage character
-+-
 Reporter:  paulpmi  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Testing framework|  Version:  3.0
 Severity:  Normal   |   Resolution:
 Keywords:  carriage-character   | Triage Stage:
  Django-test security   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

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

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

Re: [Django] #31429: Django Client. Empty body adding carraige character (was: Django Client. Empty adding carraige character in body)

[Django]

#31429: Django Client. Empty body adding carraige character
-+-
 Reporter:  paulpmi  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Testing framework|  Version:  3.0
 Severity:  Normal   |   Resolution:
 Keywords:  carriage-character   | Triage Stage:
  Django-test security   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

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

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

[Django] #31429: Django Client. Empty adding carraige character in body

[Django]

#31429: Django Client. Empty adding carraige character in body
-+-
   Reporter:  paulpmi|  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |
  Component:  Testing|Version:  3.0
  framework  |   Keywords:  carriage-character
   Severity:  Normal |  Django-test security
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Steps to reproduce:
 1. Build endpoint for POST/PUT/PATCH
 2. use empty body client.post() on the reverse URL
 3. list(request.body) -> ['-', '-', 'B', 'o', 'U', 'n', 'D', 'a', 'R',
 'y', 'S', 't', 'R', 'i', 'N', 'g', '-', '-', '\r', '\n']

 Issue:
 If any security measures as in place \r will always be sanitized. Any
 checks done on the requests.body will have to take into account this
 atypical case. This is due to how django client does json encoding and
 presents a danger.

 Proposal:
 use the typical json.dumps() instead of the current implementation

-- 
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/050.a061f6194f749bbfe93332aea294e717%40djangoproject.com.

Re: [Django] #29069: Static file serving does not call request_finished signal

[Django]

#29069: Static file serving does not call request_finished signal
-+-
 Reporter:  André Cruz   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  HTTP handling|  Version:  3.0
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  streamingresponse| Triage Stage:  Accepted
  request_finished   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by felixxm):

 Thanks Tom.

 > Sorry, life has been rather hectic in the last couple of weeks. I was
 going to reploy that this seems to indeed fix the issue, but it would be
 good to have a specific test to ensure that the request_finish signal is
 called when static files are requested. The linked commit only tests this
 implicitly.

 Agreed.

-- 
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.e9aae7c68446f270a7029177b4c4666c%40djangoproject.com.

Re: [Django] #29069: Static file serving does not call request_finished signal

[Django]

#29069: Static file serving does not call request_finished signal
-+-
 Reporter:  André Cruz   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  HTTP handling|  Version:  3.0
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  streamingresponse| Triage Stage:  Accepted
  request_finished   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tom Forbes):

 Sorry, life has been rather hectic in the last couple of weeks. I was
 going to reploy that this seems to indeed fix the issue, but it would be
 good to have a specific test to ensure that the request_finish signal is
 called when static files are requested. The linked commit only tests this
 implicitly.

 I've added this to my to-do list, but if people think it's not worth it or
 anyone else wants to tackle it then that's 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.40e3aa32ba96b3fc0af3b5e445f1ccb2%40djangoproject.com.

Re: [Django] #29069: Static file serving does not call request_finished signal

[Django]

#29069: Static file serving does not call request_finished signal
-+-
 Reporter:  André Cruz   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  HTTP handling|  Version:  3.0
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  streamingresponse| Triage Stage:  Accepted
  request_finished   |
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
 * version:  1.11 => 3.0
 * resolution:   => fixed


Comment:

 Fixed by 1a3b3d18647b258331104520e76f977406c590d.

-- 
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.cf24ab1dacc1751556e73ce601c5c3e7%40djangoproject.com.

Re: [Django] #31428: Allow empty message in management command stdout and stderr proxies. (was: Allow empty message in management command stdout and stderr proxies)

[Django]

#31428: Allow empty message in management command stdout and stderr proxies.
-+-
 Reporter:  François Freitag |Owner:  François
 Type:   |  Freitag
  Cleanup/optimization   |   Status:  assigned
Component:  Core (Management |  Version:  master
  commands)  |
 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 felixxm):

 * owner:  nobody => François Freitag
 * status:  new => assigned
 * type:  New feature => Cleanup/optimization
 * stage:  Unreviewed => Accepted


Comment:

 I would rather focus on #21429, but we can accept this small cleanup.

-- 
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/073.81cfece77c82341a7e686607d17a7476%40djangoproject.com.

[Django] #31428: Allow empty message in management command stdout and stderr proxies

[Django]

#31428: Allow empty message in management command stdout and stderr proxies
-+-
   Reporter:  François   |  Owner:  nobody
  Freitag|
   Type:  New| Status:  new
  feature|
  Component:  Core   |Version:  master
  (Management commands)  |
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  1
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Django management commands wrap stdout and stderr in an `OutputWrapper`
 that adds a `\n` at the end of the text provided as the `out` argument.

 I suggest allowing `self.stdout.write()` and `self.stderr.write()` to add
 a newline to respectively `stdout` and `stderr`. Currently, it fails
 because `msg` is a positional argument.

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

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

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

Re: [Django] #31030: register SQLite functions as deterministic on Python 3.8

[Django]

#31030: register SQLite functions as deterministic on Python 3.8
-+-
 Reporter:  Sergey Fedoseev  |Owner:  Sergey
 Type:   |  Fedoseev
  Cleanup/optimization   |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  sqlite   | 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:"026719cf17ae2b088f7553321f2ca6b45efa8cb4" 026719cf]:
 {{{
 #!CommitTicketReference repository=""
 revision="026719cf17ae2b088f7553321f2ca6b45efa8cb4"
 Fixed #31030 -- Registered SQLite functions as deterministic on Python
 3.8+.
 }}}

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

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

Re: [Django] #31426: Add proper field validation to QuerySet.order_by.

[Django]

#31426: Add proper field validation to QuerySet.order_by.
-+-
 Reporter:  Maxim|Owner:  Simon
 Type:   |  Charette
  Cleanup/optimization   |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  ORDER_PATTERN,   | Triage Stage:  Accepted
  order_by   |
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:"513948735b799239f3ef8c89397592445e1a0cd5" 51394873]:
 {{{
 #!CommitTicketReference repository=""
 revision="513948735b799239f3ef8c89397592445e1a0cd5"
 Fixed #31426 -- Added proper field validation to QuerySet.order_by().

 Resolve the field reference instead of using fragile regex based string
 reference validation.
 }}}

-- 
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.f3801cbc96b24e9a78a02f949cacdc16%40djangoproject.com.

Re: [Django] #7098: FieldError Invalid order_by arguments in Admin pages when sorting on a ForeignKey

[Django]

#7098: FieldError Invalid order_by arguments in Admin pages when sorting on a
ForeignKey
---+--
 Reporter:  trbs   |Owner:  nobody
 Type: |   Status:  closed
Component:  contrib.admin  |  Version:  master
 Severity: |   Resolution:  fixed
 Keywords:  order_by   | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Mariusz Felisiak ):

 * ui_ux:   => 0
 * easy:   => 0


Comment:

 In [changeset:"98ea4f0f4696221f00e111f1d623452002192e6c" 98ea4f0f]:
 {{{
 #!CommitTicketReference repository=""
 revision="98ea4f0f4696221f00e111f1d623452002192e6c"
 Refs #7098 -- Deprecated passing raw column aliases to order_by().

 Now that order_by() has expression support passing RawSQL() can achieve
 the same result.

 This was also already supported through QuerySet.extra(order_by) for
 years but this API is more or less deprecated at this point.
 }}}

-- 
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/062.0381e0bb02371c3f2ad99766106eb6dd%40djangoproject.com.

Re: [Django] #31030: register SQLite functions as deterministic on Python 3.8

[Django]

#31030: register SQLite functions as deterministic on Python 3.8
-+-
 Reporter:  Sergey Fedoseev  |Owner:  Sergey
 Type:   |  Fedoseev
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  sqlite   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * needs_docs:  1 => 0


Comment:

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

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

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

Re: [Django] #31420: Using SimpleLazyObject with a nested subquery annotation fails.

[Django]

#31420: Using SimpleLazyObject with a nested subquery annotation fails.
-+-
 Reporter:  Jordan Ephron|Owner:  Hasan
 |  Ramezani
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  simplelazyobject,| Triage Stage:  Accepted
  queryset, subquery |
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:"4237050684427db45ea834fe89d9e11c0520201e" 4237050]:
 {{{
 #!CommitTicketReference repository=""
 revision="4237050684427db45ea834fe89d9e11c0520201e"
 Fixed #31420 -- Fixed crash when filtering subquery annotation against a
 SimpleLazyObject.

 Thanks Simon Charette for the solution and analysis.
 }}}

-- 
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.1b08c107fab7479ab0a518adbdd05133%40djangoproject.com.

Re: [Django] #31420: Using SimpleLazyObject with a nested subquery annotation fails.

[Django]

#31420: Using SimpleLazyObject with a nested subquery annotation fails.
-+-
 Reporter:  Jordan Ephron|Owner:  Hasan
 |  Ramezani
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  simplelazyobject,| Triage Stage:  Accepted
  queryset, subquery |
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:"22a2e97fc30487af89d7c34b753853e7b510083d" 22a2e97f]:
 {{{
 #!CommitTicketReference repository=""
 revision="22a2e97fc30487af89d7c34b753853e7b510083d"
 [3.0.x] Fixed #31420 -- Fixed crash when filtering subquery annotation
 against a SimpleLazyObject.

 Thanks Simon Charette for the solution and analysis.

 Backport of 4237050684427db45ea834fe89d9e11c0520201e 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.8a38fdfa4e80136884a1f14b03dcfa6a%40djangoproject.com.