[Django] #35458: Docs: clarify need for ALLOWED_HOSTS

[Django]

#35458: Docs: clarify need for ALLOWED_HOSTS
--+
   Reporter:  Klaas van Schelven  |  Owner:  nobody
   Type:  Uncategorized   | Status:  new
  Component:  Uncategorized   |Version:  5.0
   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   |
--+
 I understand why [https://security.stackexchange.com/questions/45687/what-
 does-djangos-allowed-hosts-variable-actually-do validation of the host
 header is important] but I do not understand why this would be the
 responsibility of Django.

 The [https://docs.djangoproject.com/en/5.0/ref/settings/#allowed-hosts
 docs for the settings] mysteriously mention

 > which are possible even under many seemingly-safe web server
 configurations.

 and the [https://docs.djangoproject.com/en/5.0/topics/security/#host-
 headers-virtual-hosting docs for the host header validation] mention
 something similar:

 > Because even seemingly-secure web server configurations are susceptible
 to fake Host headers

 and

 > Previous versions of this document recommended configuring your web
 server to ensure it validates incoming HTTP Host headers. While this is
 still recommended, in many common web servers a configuration that seems
 to validate the Host header may not in fact do so. For instance, even if
 Apache [..]

 However, these notes were added in 2013, when Apache still reigned supreme
 (moreover: a very different version, possibly with less sane defaults, of
 Apache). These days there are many more ways Django is deployed, not least
 of which cloud-based ones in which the passing of sane (actually checked)
 host headers is left up to some web-facing proxy / webserver in front of
 Django.

 In 2024, is there still any reason to fear these "many" (undocumented)
 "seemingly-safe server configurations" or can I just use a sane proxy
 server and let that do the validation instead? Setting `ALLOWED_HOSTS` to
 `["*"]` removes one more thing to think about while deploying.

 In the context of a bug report (and not just a question): the
 documentation should clarify what the actual wrong configurations would
 be, it should be mentioned as "defense in depth" rather than a first line
 of defense or the whole idea of ALLOWED_HOSTS checking should be removed.

 [https://stackoverflow.com/q/78476951/339144 Previously asked on
 StackOverflow in slightly different words]
-- 
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/0107018f801e95af-ce0d3748-1374-4fdf-ae09-9ba50a4211d3-00%40eu-central-1.amazonses.com.

Re: [Django] #35457: Documentation: Code inside of text box

[Django]

#35457: Documentation: Code inside of text box
-+-
 Reporter:  Treyson Grange   |Owner:  sammy20d
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Uncategorized|  Version:  5.0
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  Documentation| Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  1
-+-
Changes (by Sarah Boyce):

 * cc: Adam Johnson (added)
 * resolution:   => wontfix
 * status:  assigned => closed

Comment:

 Hello! Thank you for raising and I agree that we cannot currently do this.
 There is a feature suggested to add blacken-docs on/off comments:
 https://github.com/adamchainz/blacken-docs/issues/193 which we could
 potentially use in feature.

 I will close this as 'wontfix' but we can reopen/address this if this
 feature is to land in blacken-docs 👍
-- 
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/0107018f8014129d-e1a4642b-b52f-4be6-adfc-0209163658ab-00%40eu-central-1.amazonses.com.

Re: [Django] #35452: Unexpected results when Paginator's orphans is equal or higher than the page size

[Django]

#35452: Unexpected results when Paginator's orphans is equal or higher than the
page size
-+-
 Reporter:  Strapchay|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Core (Other) |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  pagination,  | Triage Stage:  Accepted
  paginator  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Comment (by Strapchay):

 I do not have a specific use case for having an orphan greater than the
 page size. I was only trying to get the results needed from a test case
 and needed the data gotten back to not break the ui context of amount to
 fit into the screen and created a base test case which was how I noticed
 the issue in the first place. I think the first one would be great. Also
 why not have a warning or an exception raised when the orphan specified is
 more than the page_size?, or what's your thought on that?
-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018f7f3077d7-62334128-90c3-4255-af27-bfb857cf10a3-00%40eu-central-1.amazonses.com.

Re: [Django] #21295: Add on_update support

[Django]

#21295: Add on_update support
-+-
 Reporter:  Anssi Kääriäinen |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  1
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/0107018f7eb2bca7-bdcd07ae-8a16-4a8b-abc3-c5c63a37b7be-00%40eu-central-1.amazonses.com.

Re: [Django] #21961: Add support for database-level cascading options

[Django]

#21961: Add support for database-level cascading options
-+-
 Reporter:  Christophe Pettus|Owner:  Akash
 |  Kumar Sen
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by 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/0107018f7eaf3ab4-d7f6cf99-d7d7-4010-a5ff-7e1a300a8f44-00%40eu-central-1.amazonses.com.

Re: [Django] #35457: Documentation: Code inside of text box

[Django]

#35457: Documentation: Code inside of text box
-+-
 Reporter:  Treyson-Grange   |Owner:  sammy20d
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Uncategorized|  Version:  5.0
 Severity:  Normal   |   Resolution:
 Keywords:  Documentation| Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  1
-+-
Changes (by sammy20d):

 * owner:  (none) => sammy20d
 * 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/0107018f7dc604f1-178f87b2-a5f6-46c9-92ea-ae20da549a09-00%40eu-central-1.amazonses.com.

Re: [Django] #35457: Documentation: Code inside of text box

[Django]

#35457: Documentation: Code inside of text box
-+-
 Reporter:  Treyson-Grange   |Owner:  (none)
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Uncategorized|  Version:  5.0
 Severity:  Normal   |   Resolution:
 Keywords:  Documentation| Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  1
-+-
Changes (by Treyson-Grange):

 * owner:  Treyson-Grange => (none)
 * status:  assigned => new


Old description:

> The first section of example code for
> [https://docs.djangoproject.com/en/5.0/topics/db/models/#field-name-
> restrictions Field name restrictions] is inside of a text box, ridding it
> of the usual code formatting and styling

New description:

 The first section of example code for
 [https://docs.djangoproject.com/en/5.0/topics/db/models/#field-name-
 restrictions Field name restrictions] is inside of a text box, ridding it
 of the usual code formatting and styling.

--
Comment:

 This has been done on purpose, as blaken-docs breaks when it tries to
 interpret pass = ... for the same reasons the example is showed in the
 first place. Don't believe there is a way around 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/0107018f7da4141e-d589536e-a195-4ea3-b3f6-22bc84e3af46-00%40eu-central-1.amazonses.com.

Re: [Django] #35378: Incorrect folding of long address headers with special characters when using 7bit Content-Transfer-Encoding in EmailMessage

[Django]

#35378: Incorrect folding of long address headers with special characters when
using 7bit Content-Transfer-Encoding in EmailMessage
-+
 Reporter:  andres   |Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  Core (Mail)  |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+
Changes (by Lufafa Joshua):

 * owner:  Lufafa Joshua => (none)
 * status:  assigned => new

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018f7d812a6c-2e3e7a20-6c81-428a-956d-cb5f6123d405-00%40eu-central-1.amazonses.com.

Re: [Django] #35457: Documentation: Code inside of text box

[Django]

#35457: Documentation: Code inside of text box
-+-
 Reporter:  Treyson-Grange   |Owner:  Treyson-
 Type:   |  Grange
  Cleanup/optimization   |   Status:  assigned
Component:  Uncategorized|  Version:  5.0
 Severity:  Normal   |   Resolution:
 Keywords:  Documentation| Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  1
-+-
Description changed by Treyson-Grange:

Old description:

> The first section of example code for Field name restrictions is inside
> of a text box, ridding it of the usual code formatting and styling

New description:

 The first section of example code for
 [https://docs.djangoproject.com/en/5.0/topics/db/models/#field-name-
 restrictions Field name restrictions] is inside of a text box, ridding it
 of the usual code formatting and styling

--
-- 
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/0107018f7d75b818-bd33d558-ca09-43ce-8512-99c4fbe83b7a-00%40eu-central-1.amazonses.com.

[Django] #35457: Documentation: Code inside of text box

[Django]

#35457: Documentation: Code inside of text box
-+-
   Reporter:  Treyson-   |  Owner:  Treyson-Grange
  Grange |
   Type: | Status:  assigned
  Cleanup/optimization   |
  Component: |Version:  5.0
  Uncategorized  |
   Severity:  Normal |   Keywords:  Documentation
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  1  |
-+-
 The first section of example code for Field name restrictions is inside of
 a text box, ridding it of the usual code formatting and styling
-- 
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/0107018f7d741b5e-3210f923-f233-4a2e-bbd9-e3d8be2ee60a-00%40eu-central-1.amazonses.com.

Re: [Django] #35456: Fieldset title inside StackedInline are `h3` but on errors are shown as `h2`

[Django]

#35456: Fieldset title inside StackedInline are `h3` but on errors are shown as
`h2`
-+-
 Reporter:  Natalia Bidart   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  contrib.admin|  Version:  5.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 Natalia Bidart):

 * Attachment "image-20240515-151005.png" added.

-- 
Ticket URL: <https://code.djangoproject.com/ticket/35456>
Django <https://code.djangoproject.com/>
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/0107018f7d72809c-1db2607a-372c-408a-b834-037707f4a5fa-00%40eu-central-1.amazonses.com.

Re: [Django] #35456: Fieldset title inside StackedInline are `h3` but on errors are shown as `h2`

[Django]

#35456: Fieldset title inside StackedInline are `h3` but on errors are shown as
`h2`
-+-
 Reporter:  Natalia Bidart   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  contrib.admin|  Version:  5.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 Natalia Bidart):

 * Attachment "image-20240515-150933.png" added.

-- 
Ticket URL: <https://code.djangoproject.com/ticket/35456>
Django <https://code.djangoproject.com/>
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/0107018f7d7201af-4898b143-4907-4327-ab9e-86fb5b9562cf-00%40eu-central-1.amazonses.com.

[Django] #35456: Fieldset title inside StackedInline are `h3` but on errors are shown as `h2`

[Django]

#35456: Fieldset title inside StackedInline are `h3` but on errors are shown as
`h2`
+
   Reporter:  Natalia Bidart|  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  contrib.admin |Version:  5.0
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  1 |
+
 Given the following models:

 {{{#!python
 from django.db import models
 from django.utils.timezone import now


 class Book(models.Model):
 title = models.CharField(max_length=100)
 author = models.CharField(max_length=100)
 publisher = models.CharField(max_length=100)
 publication_date = models.DateField(default=now)

 def __str__(self):
 return self.title


 class Cover(models.Model):
 book = models.ForeignKey(Book, on_delete=models.CASCADE)
 image = models.CharField(max_length=100)


 class Review(models.Model):
 book = models.ForeignKey(Book, on_delete=models.CASCADE)
 reviewer = models.CharField(max_length=100)
 content = models.TextField()
 creation_date = models.DateField(default=now)

 def __str__(self):
 return f"Review of {self.book.title} by {self.reviewer_name}"
 }}}

 And admin models:

 {{{#!python
 from django.contrib import admin

 from .models import Book, Cover, Review


 class CoverTabularInlin(admin.TabularInline):
 model = Cover
 fieldsets = (
 ("Cover Details", {
 "fields": ("image",),
 "classes": ("collapse",)
 }),
 )


 class ReviewStackedInline(admin.StackedInline):
 model = Review
 fieldsets = (
 (None, {
 "fields": ("reviewer",)
 }),
 ("History", {
 "fields": ("content", "creation_date"),
 "classes": ("collapse",)
 }),
 )



 class BookAdmin(admin.ModelAdmin):
 list_display = ("title", "author", "publisher","publication_date")
 search_fields = ("title", "author")
 list_filter = ("author", "publication_date")
 fieldsets = (
 (None, {
 "fields": ("title", "author")
 }),
 ("Advanced options", {
 "classes": ("collapse",),
 "fields": ("publisher", "publication_date",)
 }),
 )
 inlines = [
 CoverTabularInlin,
 ReviewStackedInline,
 ]


 admin.site.register(Book, BookAdmin)
 }}}

 When visiting the admin for a `Book`, the `ReviewStackedInline` shows
 fieldset heading using an `h3` tag, but on errors, it uses an `h2` tag
 (see screenshots attached). I think the correct tag to be used both with
 and without errors is an `h3`.
-- 
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/0107018f7d6dac9c-ae62bb3f-5734-48e0-ba52-9ae64960c9aa-00%40eu-central-1.amazonses.com.

Re: [Django] #35442: N+1 queries from RelatedManager + only("pk")

[Django]

#35442: N+1 queries from RelatedManager + only("pk")
-+-
 Reporter:  REGNIER Guillaume|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  4.2
  (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 Sarah Boyce):

 * type:  Uncategorized => 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/0107018f7cb51552-8b705f27-36a5-4256-9284-11ad86b883fb-00%40eu-central-1.amazonses.com.

Re: [Django] #35442: N+1 queries from RelatedManager + only("pk")

[Django]

#35442: N+1 queries from RelatedManager + only("pk")
-+-
 Reporter:  REGNIER Guillaume|Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Database layer   |  Version:  4.2
  (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 Sarah Boyce):

 * resolution:  duplicate =>
 * stage:  Unreviewed => Accepted
 * status:  closed => new

Comment:

 Thank you for the investigation Simon, reopening 👍
-- 
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/0107018f7cb4511b-b8696327-4096-4f41-8074-5c372dd613d1-00%40eu-central-1.amazonses.com.

Re: [Django] #12978: Support in syndication framework for CSS stylesheet links

[Django]

#12978: Support in syndication framework for CSS stylesheet links
-+-
 Reporter:  intrepidweb  |Owner:  Baptiste
 |  Mispelon
 Type:  New feature  |   Status:  assigned
Component:  contrib.syndication  |  Version:  1.1
 Severity:  Normal   |   Resolution:
 Keywords:  syndication css  | Triage Stage:  Accepted
  stylesheets|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Baptiste Mispelon):

 * needs_better_patch:  1 => 0

Comment:

 I've pushed an update with support for both single and multiple
 stylesheets. I think this is shaping up nicely, I'm enjoying the review
 process!
-- 
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/0107018f7c6489cb-44abdb5f-52ca-47b3-956b-47db86fa7900-00%40eu-central-1.amazonses.com.

Re: [Django] #12978: Support in syndication framework for CSS stylesheet links

[Django]

#12978: Support in syndication framework for CSS stylesheet links
-+-
 Reporter:  intrepidweb  |Owner:  Baptiste
 |  Mispelon
 Type:  New feature  |   Status:  assigned
Component:  contrib.syndication  |  Version:  1.1
 Severity:  Normal   |   Resolution:
 Keywords:  syndication css  | Triage Stage:  Accepted
  stylesheets|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Sarah Boyce):

 * needs_better_patch:  0 => 1

Comment:

 Tested using the test project provided by Baptiste and is working well:
 https://github.com/bmispelon/django-ticket-35420
 Have minor comments on the PR but the main change is requesting support
 can adding multiple stylesheets (then some doc updates around that).
 I think this is close 👍
-- 
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/0107018f7bc6161f-685c5ac4-2194-4680-b15b-a24a3ca3c6aa-00%40eu-central-1.amazonses.com.

Re: [Django] #35453: ManyToMany field is a concrete field on the defining side.

[Django]

#35453: ManyToMany field is a concrete field on the defining side.
-+-
 Reporter:  Harro|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 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 Harro):

 Yeah, maybe that would solve it, get_fields seems to have some caching but
 still does a lot of processing, while local_fields is stored on the
 options and the others are cached properties that only loop through the
 fields once.

 So performance wise it might be better to use them anyway.
-- 
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/0107018f7bb958a1-3f448e43-dcae-485d-b0ca-37ca728d44fb-00%40eu-central-1.amazonses.com.

Re: [Django] #35384: Assigning a file without a name property to a FileField results in file getting discarded silently

[Django]

#35384: Assigning a file without a name property to a FileField results in file
getting discarded silently
-+-
 Reporter:  john-parton  |Owner:  Jonny
 |  Park
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  5.0
  (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 Sarah Boyce <42296566+sarahboyce@…>):

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

Comment:

 In [changeset:"c0b0ce85ede1f1baf8826fb6c10c23f9adcbcca3" c0b0ce8]:
 {{{#!CommitTicketReference repository=""
 revision="c0b0ce85ede1f1baf8826fb6c10c23f9adcbcca3"
 Fixed #35384 -- Raised FieldError when saving a file without a name to
 FileField.
 }}}
-- 
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/0107018f7bb46837-bc603893-61fc-4851-9d8e-4133207a14fd-00%40eu-central-1.amazonses.com.

Re: [Django] #35453: ManyToMany field is a concrete field on the defining side.

[Django]

#35453: ManyToMany field is a concrete field on the defining side.
-+-
 Reporter:  Harro|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 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 Sarah Boyce):

 Replying to [comment:2 Harro]:
 > Also, the documentation doesn't mention the `local_fields` nor the
 `local_concrete_fields` so techically they shouldn't be used, but the
 get_field(s) api calls are documented, so I expect it to give me the
 information I need, as to which models are actually on a database table
 without extra weird conditions to exclude specifically one side of the
 ManyToMany relation.

 Yes, these are not documented. Previous work to document Model _meta API
 was done as part of #12663.
 I don't think using `local_fields` is a big risk and you could use this,
 maybe there is a case for it being documented.
-- 
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/0107018f7bb1ec77-61cb1df2-9b5f-4651-975a-86452d3edaa0-00%40eu-central-1.amazonses.com.

Re: [Django] #35453: ManyToMany field is a concrete field on the defining side.

[Django]

#35453: ManyToMany field is a concrete field on the defining side.
-+-
 Reporter:  Harro|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 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 Harro):

 I tried adding
 {{{
 def get_attname_column(self):
 attname, column = super().get_attname_column()
 return attname, None
 }}}
 to the ManyToMany field and it broke 7 tests that all seem to be related
 to migrations/schema, nothing else.

 So somewhere internally django migrations depend on ManyToMany having a
 column, which isn't actually there at all.
-- 
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/0107018f7ba93a7c-ccaa60e4-fc7d-4b6c-9cf7-f34a1fcea754-00%40eu-central-1.amazonses.com.

Re: [Django] #35455: psycopg3 warns about connections not being closed

[Django]

#35455: psycopg3 warns about connections not being closed
-+-
 Reporter:  HTErik   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  psycopg  | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Sarah Boyce):

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

Comment:

 Hi HTErik, I recommend you share more details of this in the async section
 of the forum: https://forum.djangoproject.com/c/internals/async/8, as this
 is the place for discussion and support.
 If there's an agreement that there is a bug in Django or that the docs
 need updating, come back and I'll be happy to accept improvements 👍
-- 
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/0107018f7b8e0c3b-ad0954a0-4a75-4767-8958-ed91822aba9d-00%40eu-central-1.amazonses.com.

Re: [Django] #10554: Response.set_cookie should allow setting two cookies of the same name.

[Django]

#10554: Response.set_cookie should allow setting two cookies of the same name.
---+
 Reporter:  Jeremy Dunck   |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  HTTP handling  |  Version:  dev
 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 Sarah Boyce):

 * stage:  Unreviewed => Accepted

Comment:

 With the concern from raised from RFC6265 as to whether we should do this,
 from what I read here:
 https://datatracker.ietf.org/doc/html/rfc6265#section-5.3

 > If the cookie store contains a cookie with the same name, domain, and
 path as the newly created cookie... [instructions on how to replace]

 I see no issue in two cookie's with the same name and uniqueness should be
 determined by the combination of name, domain and path.

 Based off how previously it was suggested this will be re-accepted
 providing there is a real world use-case, re-accepting.
-- 
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/0107018f7b82d073-c89df73e-e311-4ec0-ae1b-31e6e5d3acf4-00%40eu-central-1.amazonses.com.

Re: [Django] #35453: ManyToMany field is a concrete field on the defining side.

[Django]

#35453: ManyToMany field is a concrete field on the defining side.
-+-
 Reporter:  Harro|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 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 Harro):

 Which column does a ManyToMany have then?

 As far as I see it it has a table with has two (or more) columns pointing
 to two different tables, so why doesn't the other side of the ManyToMany
 not also have a column?

 `local_concrete_fields` is `local_fields` filtered on the concrete flag,
 but I can't find where the local_fields is filled in the source code, but
 it does not contain the ManyToMany fields defined on the model (so far
 that's correct)

 Also, the documentation doesn't mention the `local_fields` nor the
 `local_concrete_fields` so techically they shouldn't be used, but the
 get_field(s) api calls are documented, so I expect it to give me the
 information I need, as to which models are actually on a database table
 without extra weird conditions to exclude specifically one side of the
 ManyToMany relation.
-- 
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/0107018f7b761d1b-22f4816a-70b9-4e85-96bf-cf660990ba74-00%40eu-central-1.amazonses.com.

Re: [Django] #35455: psycopg3 warns about connections not being closed

[Django]

#35455: psycopg3 warns about connections not being closed
-+-
 Reporter:  HTErik   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  psycopg  | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Comment (by HTErik):

 I have identified the problem now.
 It happens when one performs Django queries from a separate thread. The DB
 connections in Django are thread local inside the `ConnectionHandler`, so
 when the thread finishes and is eventually GCd, the thread locals holding
 the DB connections in Django are also GCd, without any prior `close()`.

 To solve it, one must call this in a `finally` clause of all threads that
 run Django queries.

 {{{
 for conn in django.db.connections.all():
 conn.close()
 }}}

 I'm not sure if this is expected from users or if this is something Django
 should handle internally.
 The documentation on this topic could use some more details.
 https://docs.djangoproject.com/en/5.0/ref/databases/#connection-management
-- 
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/0107018f7b6e7f0f-4b6f92c3-fd41-4842-be13-45eb304da679-00%40eu-central-1.amazonses.com.

Re: [Django] #35453: ManyToMany field is a concrete field on the defining side.

[Django]

#35453: ManyToMany field is a concrete field on the defining side.
-+-
 Reporter:  Harro|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 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 Sarah Boyce):

 * cc: Mariusz Felisiak, Simon Charette (added)
 * resolution:   => invalid
 * status:  new => closed

Comment:

 I think the docs could potentially be clearer but I don't think
 `ManyToManyField` should have concrete as False.
 I believe `local_concrete_fields` is when the column exists on the model's
 table (rather than on a different table) and so is "local".
 I think the docs are correct that `ManyToManyField` does have a database
 column just not locally. Examples of non-concrete fields include
 `GenericForeignKey`, `GenericRelation` and `ForeignObject`.
-- 
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/0107018f7b59378d-c26b78f1-c460-4bfc-b3ad-7c24742c1b26-00%40eu-central-1.amazonses.com.