Re: [Django] #32055: Add Surrogate-Control header to the 304 response

[Django]

#32055: Add Surrogate-Control header to the 304 response
---+--
 Reporter:  bungoume   |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  HTTP handling  |  Version:  master
 Severity:  Normal |   Resolution:  needsinfo
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by Nick Pope):

 Thanks for the extra detail. I can see that this has been defined for
 nearly 20 years, so it isn't something new, but it is quite niche.

 The point here is that it allows you to configure the caching behaviour of
 a proxy independently from the caching behaviour of the browser. (See
 [https://docs.fastly.com/en/guides/configuring-caching#applying-different-
 cache-rules-for-fastly-and-browsers here].)

 The main question is whether you are only using `max-age` with `Surrogate-
 Control`?
 If that is the case, then you can use `s-maxage` with `Cache-Control` to
 achieve the same goal. ([https://docs.fastly.com/en/guides/configuring-
 caching#cache-control-s-maxage Fastly], [https://developer.mozilla.org/en-
 US/docs/Web/HTTP/Headers/Cache-Control#Expiration MDN])
 The only difference is that this is not stripped, but `private` caches
 (a.k.a. the browser) will still ignore it.

 I found this useful [https://www.integralist.co.uk/posts/http-caching/
 guide]. It seems to imply that there are
 [https://www.integralist.co.uk/posts/http-caching/#surrogate-control-
 directives very few options] other than `max-age` that are likely to be of
 interest or work.

 On that basis I'm -½ on doing anything here if you only care about `max-
 age` for `Cache-Control` as there is an good alternate in `s-maxage` for
 `Cache-Control`.

 That said, if there is a strong need for doing something more complex that
 would require the `Surrogate-Control` header, there is no easy extension
 point for adding this in a custom middleware due to how this is currently
 implemented. In that case I could see a good reason to add this with a
 suitable 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/066.1d3d7b7d76cbe3b3383b0a3703407c41%40djangoproject.com.

Re: [Django] #32053: Accessibility issues with Congrats page for new projects

[Django]

#32053: Accessibility issues with Congrats page for new projects
---+
 Reporter:  Thibaud Colas  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Core (Other)   |  Version:  3.1
 Severity:  Normal |   Resolution:
 Keywords:  accessibility, ui  | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  1
---+

Comment (by Thibaud Colas):

 it’s just the one attribute – I’m happy to remove it if you think this
 isn’t worthwhile. The consequences of _not_ having it are simply that the
 SVGs become tab-able in IE11, which is annoying but not too big of a deal
 at the bottom of a page like this.

 I can see myself doing similar focused audits (and hopefully fixes too!)
 following the accessibility discussion on django-developers, so any
 feedback on the audit format above and how to implement the fixes is
 appreciated. Hopefully we’ll discuss a more systematic approach to this as
 part of the accessibility team DEP, but in the meantime I’m keen to tackle
 the low-hanging fruits.

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

Re: [Django] #32047: Required mutually exclusive groups don't work with boolean arguments.

[Django]

#32047: Required mutually exclusive groups don't work with boolean arguments.
-+-
 Reporter:  Mark Gajdosik|Owner:  Hasan
 |  Ramezani
 Type:  Bug  |   Status:  assigned
Component:  Core (Management |  Version:  3.1
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:  call_command,| Triage Stage:  Accepted
  exclusive group, store_true,   |
  action, explicit, error|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Hasan Ramezani):

 * owner:  nobody => Hasan Ramezani
 * status:  new => assigned
 * 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/070.cc0e5f0f340ae8009ae24184c2ab57cc%40djangoproject.com.

Re: [Django] #32049: Database connection differs between Middleware and views running under ASGI.

[Django]

#32049: Database connection differs between Middleware and views running under
ASGI.
-+-
 Reporter:  Hugo Osvaldo |Owner:  nobody
  Barrera|
 Type:  Bug  |   Status:  closed
Component:  HTTP handling|  Version:  3.1
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  ASGI | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Andrew Godwin):

 It's worth noting that I still consider this a bug since it's a type of
 failure, but it's already been fixed in asgiref:
 
https://github.com/django/asgiref/commit/7becc9daca2628c46af1cb7e46b4c47c1ea27adf

 As of the next release, that will enforce that all synchronous calls run
 inside the same, single thread, slightly hurting performance but crucially
 meaning that this issue would not have happened.

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

Re: [Django] #32056: Improve assigning to the reverse side of a OneToOne relationship

[Django]

#32056: Improve assigning to the reverse side of a OneToOne relationship
-+-
 Reporter:  Yu Li|Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Yu Li):

 Replying to [comment:4 felixxm]:
 > > I'm not sure why you are closing this as a duplicate when the other
 ticket is also closed.
 > > Is this a wontfix?
 >
 > There is no reason to open multiple tickets with the same description
 and the same request. You can comment in the original ticket instead of
 creating duplicates. If you don't agree with the decision made in #18638
 please [https://docs.djangoproject.com/en/stable/internals/contributing
 /triaging-tickets/#closing-tickets ​follow triaging guidelines with
 regards to wontfix tickets].

 Thanks for pointing out the direction :)

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

Re: [Django] #32055: Add Surrogate-Control header to the 304 response

[Django]

#32055: Add Surrogate-Control header to the 304 response
---+--
 Reporter:  bungoume   |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  HTTP handling  |  Version:  master
 Severity:  Normal |   Resolution:  needsinfo
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by bungoume):

 Taking the intent of rfc7232 section 4.1, it seems to me that we should
 reduce the amount of data by excluding all but the headers related to the
 cache.

 Surrogate-Control is a cache control header that has been around for a
 long time and is increasingly used in CDNs.
 Its notations are the same as Cache-Control.

 I think the reason it's not mentioned in rfc7232 is because it's only
 recently started to be used.

 This is used in cases where you want to keep browser cache control and CDN
 cache control separate.

 If Surrogate-Control disappears with 304, the CDN or proxy will use Cache-
 Control as a cache control, and it won't do what you expect it to do.

 To get around this, we''ll need to re-implement ConditionalGetMiddleware
 on our own.

 I believe it is more beneficial in many use cases to leave the headers in
 place rather than erasing them based on rfc7232.

 https://www.w3.org/TR/edge-arch/
 https://docs.fastly.com/en/guides/configuring-caching#surrogate-control

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

Re: [Django] #32056: Improve assigning to the reverse side of a OneToOne relationship

[Django]

#32056: Improve assigning to the reverse side of a OneToOne relationship
-+-
 Reporter:  Yu Li|Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by felixxm):

 > I'm not sure why you are closing this as a duplicate when the other
 ticket is also closed.
 > Is this a wontfix?

 There is no reason to open multiple tickets with the same description and
 the same request. You can comment in the original ticket instead of
 creating duplicates. If you don't agree with the decision made in #18638
 please [https://docs.djangoproject.com/en/stable/internals/contributing
 /triaging-tickets/#closing-tickets ​follow triaging guidelines with
 regards to wontfix tickets].

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

Re: [Django] #32056: Improve assigning to the reverse side of a OneToOne relationship

[Django]

#32056: Improve assigning to the reverse side of a OneToOne relationship
-+-
 Reporter:  Yu Li|Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Yu Li):

 Replying to [comment:1 felixxm]:
 > Duplicate of #18638. Please don't open duplicates of existing tickets
 and [https://docs.djangoproject.com/en/stable/internals/contributing
 /triaging-tickets/#closing-tickets follow triaging guidelines with regards
 to closed tickets].

 I'm not sure why you are closing this as a duplicate when the other ticket
 is also closed.
 Is this a wontfix?

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

Re: [Django] #32056: Improve assigning to the reverse side of a OneToOne relationship

[Django]

#32056: Improve assigning to the reverse side of a OneToOne relationship
-+-
 Reporter:  Yu Li|Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Yu Li):

 Hello, this was a feature request. If this couldn't be done because of an
 architectural reason, please suggest here so that other users can find an
 explanation.

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

Re: [Django] #18638: Reverse OneToOne relationship does not save properly.

[Django]

#18638: Reverse OneToOne relationship does not save properly.
-+-
 Reporter:  David Hatch  |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |
 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):

 * needs_better_patch:  1 => 0
 * has_patch:  1 => 0
 * resolution:  worksforme => wontfix
 * type:  Bug => New feature


Comment:

 #32056 was closed as a duplicate, we can treat this as a request for a new
 feature.

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

Re: [Django] #32056: Improve assigning to the reverse side of a OneToOne relationship

[Django]

#32056: Improve assigning to the reverse side of a OneToOne relationship
-+-
 Reporter:  Yu Li|Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * status:  new => closed
 * resolution:   => duplicate
 * component:  Uncategorized => Database layer (models, ORM)


Comment:

 Duplicate of #18638. Please don't open duplicates of existing tickets and
 [https://docs.djangoproject.com/en/stable/internals/contributing/triaging-
 tickets/#closing-tickets follow triaging guidelines with regards to closed
 tickets].

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

Re: [Django] #32049: Database connection differs between Middleware and views running under ASGI.

[Django]

#32049: Database connection differs between Middleware and views running under
ASGI.
-+-
 Reporter:  Hugo Osvaldo |Owner:  nobody
  Barrera|
 Type:  Bug  |   Status:  closed
Component:  HTTP handling|  Version:  3.1
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  ASGI | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Hugo Osvaldo Barrera):

 Ah, right, makes sense. I'll be sure to do testing of this kind of
 functionality with daphne too then.

 Thanks a lot for your feedback/insight here.

 It should be noted that, apparently, since both unittests and runserver
 run synchronously, these bugs are very hard to pick up -- for me they
 _only_ occur on the 404 page, and on production.

 Do you have any hints on how to safely do what I'm trying to do? E.g.:
 keep a pseudo-global state isolated to the context of a single 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/068.15498a543431018157840b98bd875240%40djangoproject.com.

Re: [Django] #32055: Add Surrogate-Control header to the 304 response

[Django]

#32055: Add Surrogate-Control header to the 304 response
---+--
 Reporter:  bungoume   |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  HTTP handling  |  Version:  master
 Severity:  Normal |   Resolution:  needsinfo
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by felixxm):

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


Comment:

 `Surrogate-Control` is not mentioned in
 [https://tools.ietf.org/html/rfc7232#section-4.1 Section 4.1 of RFC 7232]
 (see #19705). Can you provide more details, any spec etc.? I'm not an
 expert, but I've never heard about this HTTP header, it seems that is not
 really common.

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

[Django] #32055: Add Surrogate-Control header to the 304 response

[Django]

#32055: Add Surrogate-Control header to the 304 response
-+
   Reporter:  bungoume   |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  HTTP handling  |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  |
-+
 The Surrogate-Control header is used in CDN cache control.

 Currently, the Surrogate-Control header is removed on NotModified
 response, and only like the Cache-Control headers are returned.

 Therefore, applications with a Surrogate-Control based caching strategy
 may cause unexpected caching to take place in the CDN.

-- 
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/051.7c85e3e2bc631c78a547c2e7eb8ec011%40djangoproject.com.

Re: [Django] #32054: Signal disconnect not working with multiple decorators

[Django]

#32054: Signal disconnect not working with multiple decorators
-+-
 Reporter:  Ron  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  signals  | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Ron):

 Sure, I'll update my question accordingly. Thanks for your time so far!

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

Re: [Django] #32049: Database connection differs between Middleware and views running under ASGI.

[Django]

#32049: Database connection differs between Middleware and views running under
ASGI.
-+-
 Reporter:  Hugo Osvaldo |Owner:  nobody
  Barrera|
 Type:  Bug  |   Status:  closed
Component:  HTTP handling|  Version:  3.1
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  ASGI | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Carlton Gibson):

 `runserver` doesn't yet support ASGI, so it's running as a WSGI app in a
 single thread.

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

Re: [Django] #32049: Database connection differs between Middleware and views running under ASGI.

[Django]

#32049: Database connection differs between Middleware and views running under
ASGI.
-+-
 Reporter:  Hugo Osvaldo |Owner:  nobody
  Barrera|
 Type:  Bug  |   Status:  closed
Component:  HTTP handling|  Version:  3.1
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  ASGI | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Hugo Osvaldo Barrera):

 You mention this is expected behaviour, but which one? `runserver` does
 one thing, but `daphne` does another.
 If one of them is behaving as expected, then the other is misbehaving,
 right? I don't think the intent is for them to run different, is it?

 Side note:
 I find it curious that for non-404 views, the same db connection is used
 for both the middleware and the view. The exception seems to _only_ how
 the 404 view is called.

 > you're going to have to find a thread-safe way of doing this if you want
 to use ASGI here, now

 Any hints on something that's safe?
 What I'm doing right now is setting a `tenant` based on the domain name,
 and this is used in various places (e.g.: by my custom staticfiles'
 `Storage`).

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

Re: [Django] #31880: QuerySet.aggregate() mixes annotated fields names.

[Django]

#31880: QuerySet.aggregate() mixes annotated fields names.
-+-
 Reporter:  Thodoris |Owner:  David
  Sotiropoulos   |  Wobrock
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"058747b77a3e6710301138b8ab3bc4256077fdfa" 058747b]:
 {{{
 #!CommitTicketReference repository=""
 revision="058747b77a3e6710301138b8ab3bc4256077fdfa"
 Fixed #31880 -- Made QuerySet.aggregate() raise FieldError when
 aggregating over aggregation aliases.
 }}}

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

Re: [Django] #32049: Database connection differs between Middleware and views running under ASGI. (was: Middleware behaviour inconsistent between runserver and daphne)

[Django]

#32049: Database connection differs between Middleware and views running under
ASGI.
-+-
 Reporter:  Hugo Osvaldo |Owner:  nobody
  Barrera|
 Type:  Bug  |   Status:  closed
Component:  HTTP handling|  Version:  3.1
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  ASGI | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Carlton Gibson:

Old description:

> All my views expect a particular middleware to have run (it detects the
> current tenant based on the request's host).
>
> I'm having an issue which ''only'' occurs on production, but I could not
> reproduce in development mode (even with `DEBUG=False`) nor via unit
> tests.
>
> After just inspecting stack traces, it seems that when `handler404` is
> run, behaviour varies between runserver and daphne.
>
> Looking at the backtrace of my `handler404` function:
>
> - When running `django-admin runserver 0.0.0.0:8000`, all my middlewares
> are in my backtrace, meaning they've gotten executed and the function is
> called in their context.
> - When running `daphne myapp.asgi:application --bind 0.0.0.0 --port 8000
> --http-timeout 90`, I put a tracepoint in my `handler404`, and the
> middleware **are not** in the backtrace. It seems that the view is run
> outside the context of these middlewares.
>
> I haven't been able to find anything in the docs clarifying whether error
> handlers should expect middleware to have run successfully, but whatever
> the ''intended'' behaviour is, it should be consistent across the two.

New description:

 (Was: Middleware behaviour inconsistent between runserver and daphne)

 All my views expect a particular middleware to have run (it detects the
 current tenant based on the request's host).

 I'm having an issue which ''only'' occurs on production, but I could not
 reproduce in development mode (even with `DEBUG=False`) nor via unit
 tests.

 After just inspecting stack traces, it seems that when `handler404` is
 run, behaviour varies between runserver and daphne.

 Looking at the backtrace of my `handler404` function:

 - When running `django-admin runserver 0.0.0.0:8000`, all my middlewares
 are in my backtrace, meaning they've gotten executed and the function is
 called in their context.
 - When running `daphne myapp.asgi:application --bind 0.0.0.0 --port 8000
 --http-timeout 90`, I put a tracepoint in my `handler404`, and the
 middleware **are not** in the backtrace. It seems that the view is run
 outside the context of these middlewares.

 I haven't been able to find anything in the docs clarifying whether error
 handlers should expect middleware to have run successfully, but whatever
 the ''intended'' behaviour is, it should be consistent across the two.

--

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

Re: [Django] #32053: Accessibility issues with Congrats page for new projects

[Django]

#32053: Accessibility issues with Congrats page for new projects
---+
 Reporter:  Thibaud Colas  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Core (Other)   |  Version:  3.1
 Severity:  Normal |   Resolution:
 Keywords:  accessibility, ui  | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  1
---+
Changes (by Carlton Gibson):

 * stage:  Unreviewed => Accepted


Comment:

 Hi Thibaud. Thanks for this. Very happy to look at changes here.

 One note: at least for the admin, we don't support any version of IE (it's
 Edge only). If it's just an extra attribute then no problem, but I'd
 double-check before we add lots of code for IE compat.

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

Re: [Django] #32049: Middleware behaviour inconsistent between runserver and daphne

[Django]

#32049: Middleware behaviour inconsistent between runserver and daphne
-+-
 Reporter:  Hugo Osvaldo |Owner:  nobody
  Barrera|
 Type:  Bug  |   Status:  closed
Component:  HTTP handling|  Version:  3.1
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  ASGI | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * cc: Andrew Godwin (added)
 * keywords:   => ASGI
 * status:  new => closed
 * resolution:   => invalid


Comment:

 This is an interesting one. The issue is the way the ASGIHandler runs your
 code in separate threads. (The bottom-line will be that what you're trying
 to do isn't supported: you're going to have to find a thread-safe way of
 doing this if you want to use ASGI here, now.)

 Your middleware sets `connection.tenant` in Thread 1. Via the
 `DefaultConnectionProxy` this fetches and sets the property on the
 `"default"` connection for Thread 1.
 Your view is then run on Thread 2. Attempting to get `connection.tenant`
 the  `DefaultConnectionProxy` fetches the `"default"` connection for
 Thread 2.
 Since DB connections are not shared between thread, this is not the same
 connection, so the `tenant` attribute you set doesn't exist.

 I'll cc Andrew since it's an interesting case, but it's expected
 behaviour. ASGI/async implies/requires much more thought about what thread
 you're going to be running on here, and hence how you pass this kind of
 info around.

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

Re: [Django] #31880: QuerySet.aggregate() mixes annotated fields names.

[Django]

#31880: QuerySet.aggregate() mixes annotated fields names.
-+-
 Reporter:  Thodoris |Owner:  David
  Sotiropoulos   |  Wobrock
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * stage:  Accepted => Ready for checkin


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

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

Re: [Django] #31550: AssertionError raised by test_file_response method of ASGITest class.

[Django]

#31550: AssertionError raised by test_file_response method of ASGITest class.
-+-
 Reporter:  Yash Saini   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  HTTP handling|  Version:  3.0
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  ASGI tests   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

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


Comment:

 Hi Addison. This works for me. #32041 came up recently, which is related.

 If you can dig-in and come up with some more information we can look into
 it but short of a concrete analysis I'm not sure what we can do. What
 action are we to take? (The line in the tests is as it is because this was
 the behaviour we hit developing the feature…)

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

Re: [Django] #32054: Signal disconnect not working with multiple decorators

[Django]

#32054: Signal disconnect not working with multiple decorators
-+-
 Reporter:  Ron  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  signals  | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Ron:

Old description:

> Here's my setup:
>

>
> {{{
> class MyModel(models.Model):
>  pass
>
> @receiver(post_save, sender=MyModel)
> @receiver(post_delete, sender=MyModel)
> def process_stuff(sender, instance, **kwargs):
> # to some magic
> pass
> }}}
>
> When I want to disconnect the post_save signal like this:
>
> {{{
> from django.db.models import signals
> signals.post_save.disconnect(
> receiver=process_stuff,
> sender=MyModel,
> }}}
>
> ... it does not work.
>
> If I comment out the second decorator with `post_delete`, it works.
>
> If I split this up and use two different functions, it works as well.
>
> I posted at StackOverflow (https://stackoverflow.com/q/64102708/1331671)
> and in some django groups, but no replies yet.
>
> Seems like a bug to me :(

New description:

 Here's my setup on django 3.0.10:


 {{{
 class MyModel(models.Model):
  pass

 @receiver(post_save, sender=MyModel)
 @receiver(post_delete, sender=MyModel)
 def process_stuff(sender, instance, **kwargs):
 # to some magic
 pass
 }}}

 When I want to disconnect the post_save signal like this:

 {{{
 from django.db.models import signals
 signals.post_save.disconnect(
 receiver=process_stuff,
 sender=MyModel,
 }}}

 ... it does not work.

 If I comment out the second decorator with `post_delete`, it works.

 If I split this up and use two different functions, it works as well.

 I posted at StackOverflow (https://stackoverflow.com/q/64102708/1331671)
 and in some django groups, but no replies yet.

 Seems like a bug to me :(

--

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

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

Re: [Django] #18995: String formatting error when passing floats as values in {% blocktrans %} tags

[Django]

#18995: String formatting error when passing floats as values in {% blocktrans 
%}
tags
-+-
 Reporter:  Bruno Renié  |Owner:  Jacob
 Type:   |  Walls
  Cleanup/optimization   |   Status:  closed
Component:   |  Version:  master
  Internationalization   |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"01a7af09b9d61aa66f5bf345fc32cc8f90ecb62a" 01a7af09]:
 {{{
 #!CommitTicketReference repository=""
 revision="01a7af09b9d61aa66f5bf345fc32cc8f90ecb62a"
 Fixed #18995 -- Made blocktranslate tag raise TemplateSyntaxError when
 plural count is not a number.
 }}}

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

Re: [Django] #18995: String formatting error when passing floats as values in {% blocktrans %} tags

[Django]

#18995: String formatting error when passing floats as values in {% blocktrans 
%}
tags
-+-
 Reporter:  Bruno Renié  |Owner:  Jacob
 Type:   |  Walls
  Cleanup/optimization   |   Status:  assigned
Component:   |  Version:  master
  Internationalization   |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * stage:  Accepted => Ready for checkin


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

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