Re: [Django] #32641: Log the number of tests found in DiscoverRunner.build_suite()

[Django]

#32641: Log the number of tests found in DiscoverRunner.build_suite()
-+-
 Reporter:  Chris Jerdonek   |Owner:  Girish
 Type:   |  Sontakke
  Cleanup/optimization   |   Status:  assigned
Component:  Testing framework|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
  DiscoverRunner,build_suite |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Girish Sontakke):

 * owner:  nobody => Girish Sontakke
 * 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/067.d3987ec4b88a9b04cb897fe9bf340b24%40djangoproject.com.

Re: [Django] #32650: Cannot combine two queryset in a subquery

[Django]

#32650: Cannot combine two queryset in a subquery
-+-
 Reporter:  Raffaele Salmaso |Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Release blocker  |   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 Simon Charette):

 * owner:  nobody => Simon Charette
 * status:  new => assigned
 * severity:  Normal => Release blocker
 * stage:  Unreviewed => Accepted


Comment:

 Looks like the code doesn't properly handle nested subquery exclusion,
 likely due to re-aliasing in `Query.trim_start`.

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

Re: [Django] #32650: Cannot combine two queryset in a subquery

[Django]

#32650: Cannot combine two queryset in a subquery
-+-
 Reporter:  Raffaele Salmaso |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 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 Raffaele Salmaso):

 It seems to be related to https://code.djangoproject.com/ticket/32143
 
(https://github.com/django/django/commit/8593e162c9cb63a6c0b06daf045bc1c21eb4d7c1)

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

Re: [Django] #32650: Cannot combine two queryset in a subquery

[Django]

#32650: Cannot combine two queryset in a subquery
-+-
 Reporter:  Raffaele Salmaso |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 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
-+-
Description changed by Raffaele Salmaso:

Old description:

> [Sample project https://github.com/rsalmaso/django32-subquery-test and
> run `./manage.py query`]
>
> Django 3.2 fails this query (a combined queryset in a subquery):
>
> {{{#!python
> import datetime as dt
> from decimal import Decimal
>
> from django.conf import settings
> from django.db import models
> from django.db.models import Case, OuterRef, Q, Subquery, Value, When
> from django.utils import timezone
>

> class UserQuerySet(models.QuerySet):
> def annotate_active_subscription_id(self):
> return self.annotate(
> active_subscription_id_db=Subquery(
> Subscription.objects.active()
> .annotate(
> plan_order=Case(
> When(plan__code="BASE", then=Value(1)),
> default=Value(0),
> output_field=models.PositiveSmallIntegerField(),
> )
> )
> .filter(user=OuterRef("id"))
> .order_by("plan_order", "-id")
> .values("id")[:1]
> )
> )
>

> class User(models.Model):
> objects = models.Manager.from_queryset(UserQuerySet)()
>

> class Plan(models.Model):
> code = models.CharField(verbose_name="Codice", max_length=255)
>

> class SubscriptionQuerySet(models.QuerySet):
> def will_be_renewed_today(self):
> today = dt.date.today()
> return
> self.filter(start_date__lte=today).exclude(user__subscriptions__start_date=today).distinct()
>
> def active(self):
> return self.filter(enabled=True).distinct() |
> self.will_be_renewed_today()
>

> class Subscription(models.Model):
> user = models.ForeignKey(User, verbose_name="Utente",
> on_delete=models.CASCADE, related_name="subscriptions")
> plan = models.ForeignKey(Plan, on_delete=models.CASCADE,
> verbose_name="Piano di abbonamento")
> start_date = models.DateField(verbose_name="Data di inizio",
> default=dt.date.today)
> enabled = models.BooleanField(verbose_name="Abilitato", default=True)
>
> objects = models.Manager.from_queryset(SubscriptionQuerySet)()
>

> print(User.objects.annotate_active_subscription_id().count())
> }}}
>

> with django 3.1.8
>
> {{{#!sql
> SELECT
>   "subquery_user"."id",
>   (
> SELECT
>   "subquery"."id"
> FROM
>   (
> SELECT
>   DISTINCT U0."id",
>   CASE WHEN (U2."code" = BASE) THEN 1 ELSE 0 END
> FROM
>   "subquery_subscription" U0
>   INNER JOIN "subquery_plan" U2 ON (U0."plan_id" = U2."id")
> WHERE
>   (
> (
>   U0."enabled"
>   OR (
> U0."start_date" <= 2021 - 04 - 13
> AND NOT (
>   U0."user_id" IN (
> SELECT
>   U2."user_id"
> FROM
>   "subquery_subscription" U2
> WHERE
>   U2."start_date" = 2021 - 04 - 13
>   )
> )
>   )
> )
> AND U0."user_id" = "subquery_user"."id"
>   )
> ORDER BY
>   CASE WHEN (U2."code" = BASE) THEN 1 ELSE 0 END ASC,
>   U0."id" DESC
> LIMIT
>   1
>   ) subquery
>   ) AS "active_subscription_id_db"
> FROM
>   "subquery_user"
> }}}
>
> with django 3.2 (
>
> {{{#!sql
> SELECT
>   "subquery_user"."id",
>   (
> SELECT
>   "subquery"."id"
> FROM
>   (
> SELECT
>   DISTINCT U0."id",
>   CASE WHEN (U2."code" = BASE) THEN 1 ELSE 0 END
> FROM
>   "subquery_subscription" U0
>   INNER JOIN "subquery_plan" U2 ON (U0."plan_id" = U2."id")
> WHERE
>   (
> (
>   U0."enabled"
>   OR (
> U0."start_date" <= 2021 - 04 - 13
> AND NOT (
>   EXISTS(
> SELECT
>   (1) AS "a"
> FROM
>   "subquery_subscription" V2
>  

[Django] #32650: Cannot combine two queryset in a subquery

[Django]

#32650: Cannot combine two queryset in a subquery
-+-
   Reporter:  Raffaele   |  Owner:  nobody
  Salmaso|
   Type:  Bug| Status:  new
  Component:  Database   |Version:  3.2
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 [Sample project https://github.com/rsalmaso/django32-subquery-test and run
 `./manage.py query`]

 Django 3.2 fails this query (a combined queryset in a subquery):

 {{{#!python
 import datetime as dt
 from decimal import Decimal

 from django.conf import settings
 from django.db import models
 from django.db.models import Case, OuterRef, Q, Subquery, Value, When
 from django.utils import timezone


 class UserQuerySet(models.QuerySet):
 def annotate_active_subscription_id(self):
 return self.annotate(
 active_subscription_id_db=Subquery(
 Subscription.objects.active()
 .annotate(
 plan_order=Case(
 When(plan__code="BASE", then=Value(1)),
 default=Value(0),
 output_field=models.PositiveSmallIntegerField(),
 )
 )
 .filter(user=OuterRef("id"))
 .order_by("plan_order", "-id")
 .values("id")[:1]
 )
 )


 class User(models.Model):
 objects = models.Manager.from_queryset(UserQuerySet)()


 class Plan(models.Model):
 code = models.CharField(verbose_name="Codice", max_length=255)


 class SubscriptionQuerySet(models.QuerySet):
 def will_be_renewed_today(self):
 today = dt.date.today()
 return
 
self.filter(start_date__lte=today).exclude(user__subscriptions__start_date=today).distinct()

 def active(self):
 return self.filter(enabled=True).distinct() |
 self.will_be_renewed_today()


 class Subscription(models.Model):
 user = models.ForeignKey(User, verbose_name="Utente",
 on_delete=models.CASCADE, related_name="subscriptions")
 plan = models.ForeignKey(Plan, on_delete=models.CASCADE,
 verbose_name="Piano di abbonamento")
 start_date = models.DateField(verbose_name="Data di inizio",
 default=dt.date.today)
 enabled = models.BooleanField(verbose_name="Abilitato", default=True)

 objects = models.Manager.from_queryset(SubscriptionQuerySet)()


 print(User.objects.annotate_active_subscription_id().count())
 }}}


 with django 3.1.8

 {{{#!sql
 SELECT
   "subquery_user"."id",
   (
 SELECT
   "subquery"."id"
 FROM
   (
 SELECT
   DISTINCT U0."id",
   CASE WHEN (U2."code" = BASE) THEN 1 ELSE 0 END
 FROM
   "subquery_subscription" U0
   INNER JOIN "subquery_plan" U2 ON (U0."plan_id" = U2."id")
 WHERE
   (
 (
   U0."enabled"
   OR (
 U0."start_date" <= 2021 - 04 - 13
 AND NOT (
   U0."user_id" IN (
 SELECT
   U2."user_id"
 FROM
   "subquery_subscription" U2
 WHERE
   U2."start_date" = 2021 - 04 - 13
   )
 )
   )
 )
 AND U0."user_id" = "subquery_user"."id"
   )
 ORDER BY
   CASE WHEN (U2."code" = BASE) THEN 1 ELSE 0 END ASC,
   U0."id" DESC
 LIMIT
   1
   ) subquery
   ) AS "active_subscription_id_db"
 FROM
   "subquery_user"
 }}}

 with django 3.2 (

 {{{#!sql
 SELECT
   "subquery_user"."id",
   (
 SELECT
   "subquery"."id"
 FROM
   (
 SELECT
   DISTINCT U0."id",
   CASE WHEN (U2."code" = BASE) THEN 1 ELSE 0 END
 FROM
   "subquery_subscription" U0
   INNER JOIN "subquery_plan" U2 ON (U0."plan_id" = U2."id")
 WHERE
   (
 (
   U0."enabled"
   OR (
 U0."start_date" <= 2021 - 04 - 13
 AND NOT (
   EXISTS(
 SELECT
   (1) AS "a"
 FROM
   "subquery_subscription" V2
 WHERE
   (
 V2."start_date" = 2021 - 04 - 13
 AND V2."user_id" = V0."user_id"
   )
 LIMIT
   1
   )
   

Re: [Django] #32640: Non-manager instance assigned to model class' objects is silently ignored

[Django]

#32640: Non-manager instance assigned to model class' objects is silently  
ignored
-+-
 Reporter:  Shai Berger  |Owner:  Shai
 |  Berger
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Shai Berger):

 * owner:  nobody => Shai Berger
 * needs_better_patch:  0 => 1
 * has_patch:  0 => 1
 * status:  new => assigned


Comment:

 We'll see what CI says, but on my machine, the
 [https://github.com/django/django/pull/14260 WIP PR] only seems to break
 tests for invalid models, by making them "more invalid" (fail to create
 the class instead of failing a check).

 I'm not sure if that's a bad thing.

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

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

Re: [Django] #32649: django.contrib.admin.ModelAdmin.search_fields crashes for a search term with three quotes

[Django]

#32649: django.contrib.admin.ModelAdmin.search_fields crashes for a search term
with three quotes
---+--
 Reporter:  Dlis   |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  3.2
 Severity:  Normal |   Resolution:
 Keywords:  admin, search  | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by Dlis):

 If somebody has such the problem, here is our temporary fix which was
 added to our internal basic ModelAdmin:

 {{{
 def get_search_results(self, request, queryset, search_term):
 parts = search_term.split()
 try:
 for part in text.smart_split(search_term):
 text.unescape_string_literal(part)
 except ValueError:
 parts = map(lambda t: str(t).strip('"').strip("'"), parts)
 return super().get_search_results(request, queryset, ' '.join(parts))
 }}}

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

Re: [Django] #32649: django.contrib.admin.ModelAdmin.search_fields crashes for a search term with three quotes

[Django]

#32649: django.contrib.admin.ModelAdmin.search_fields crashes for a search term
with three quotes
---+--
 Reporter:  Dlis   |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  3.2
 Severity:  Normal |   Resolution:
 Keywords:  admin, search  | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by Dlis):

 The bag can be reproduced by the following way:

 {{{
 from django.utils.text import smart_split
 from django.utils.text import unescape_string_literal

 search_term = 'Foo "Bar "Baz"'
 parts = list(smart_split(search_term))
 unescape_string_literal(parts[1])
 }}}

 Result is {{{ValueError: Not a string literal: '"Bar "Baz'}}}

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

Re: [Django] #32649: django.contrib.admin.ModelAdmin.search_fields crashes for a search term with three quotes

[Django]

#32649: django.contrib.admin.ModelAdmin.search_fields crashes for a search term
with three quotes
---+--
 Reporter:  Dlis   |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  3.2
 Severity:  Normal |   Resolution:
 Keywords:  admin, search  | 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 Dlis:

Old description:

> django.contrib.admin.ModelAdmin.search_fields now allows searching
> against quoted phrases with spaces but unfortunately search crashes for a
> search term like **Foo "Foo "Baz"** (with three quotes, some company
> names match such the pattern)

New description:

 django.contrib.admin.ModelAdmin.search_fields now allows searching against
 quoted phrases with spaces but unfortunately search crashes for a search
 term like **Foo "Bar "Baz"** (with three quotes, some company names match
 such the pattern)

--

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

[Django] #32649: django.contrib.admin.ModelAdmin.search_fields crashes for a search term with three quotes

[Django]

#32649: django.contrib.admin.ModelAdmin.search_fields crashes for a search term
with three quotes
-+---
   Reporter:  Dlis   |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  contrib.admin  |Version:  3.2
   Severity:  Normal |   Keywords:  admin, search
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+---
 django.contrib.admin.ModelAdmin.search_fields now allows searching against
 quoted phrases with spaces but unfortunately search crashes for a search
 term like **Foo "Foo "Baz"** (with three quotes, some company names match
 such the pattern)

-- 
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/047.9317906bd2eab77ee894926768d2139d%40djangoproject.com.

Re: [Django] #32648: New sitemap 'alternates' generation feature is bugged using default values.

[Django]

#32648: New sitemap 'alternates' generation feature is bugged using default 
values.
--+--
 Reporter:  paris-ci  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.sitemaps  |  Version:  3.2
 Severity:  Normal|   Resolution:
 Keywords:  alternates| Triage Stage:  Unreviewed
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by paris-ci):

 * has_patch:  0 => 1


Comment:

 Here's the pull request that should fix the problem
 https://github.com/django/django/pull/14259.

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

[Django] #32648: New sitemap 'alternates' generation feature is bugged using default values.

[Django]

#32648: New sitemap 'alternates' generation feature is bugged using default 
values.
+
   Reporter:  paris-ci  |  Owner:  nobody
   Type:  Bug   | Status:  new
  Component:  contrib.sitemaps  |Version:  3.2
   Severity:  Normal|   Keywords:  alternates
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 (First time reporting a bug in Django, please be kind)

 Hi,

 When closing ticket #27395 with the following commit
 
https://github.com/django/django/commit/16218c20606d8cd89c5393970c83da04598a3e04#
 a bug was added in Django.

 If alternates is set to False, or if i18n is disabled on the sitemap, this
 line
 
https://github.com/django/django/commit/16218c20606d8cd89c5393970c83da04598a3e04
 #diff-d0316d5baddb3fd017c4a17ac10d784a4668a05ae39bf8a0485ec80da1409c51R189
 will not get executed, meaning `url_info` will not have `alternates` set.

 Later, when rendering in the template, the inner loop
 
(https://github.com/django/django/commit/16218c20606d8cd89c5393970c83da04598a3e04
 #diff-a2c649c9d199c72cb1df4204ce54d92a480f4f077e7b423db91ee1ab421895d8R10)
 will try to access alternates anyway, causing the following stacktrace to
 be printed


 {{{#!python
 [DEBUG   ] (base._resolve_lookup) Exception while resolving variable
 'alternates' in template 'sitemap.xml'.

 Traceback (most recent call last):
   File "/usr/local/lib/python3.9/site-packages/django/template/base.py",
 line 829, in _resolve_lookup
 current = current[bit]
 KeyError: 'alternates'

 During handling of the above exception, another exception occurred:

 Traceback (most recent call last):
   File "/usr/local/lib/python3.9/site-packages/django/template/base.py",
 line 837, in _resolve_lookup
 current = getattr(current, bit)
 AttributeError: 'dict' object has no attribute 'alternates'

 During handling of the above exception, another exception occurred:

 Traceback (most recent call last):
   File "/usr/local/lib/python3.9/site-packages/django/template/base.py",
 line 843, in _resolve_lookup
 current = current[int(bit)]
 ValueError: invalid literal for int() with base 10: 'alternates'

 During handling of the above exception, another exception occurred:

 Traceback (most recent call last):
   File "/usr/local/lib/python3.9/site-packages/django/template/base.py",
 line 848, in _resolve_lookup
 raise VariableDoesNotExist("Failed lookup for key "

 django.template.base.VariableDoesNotExist: Failed lookup for key
 [alternates] in {'item': , 'location': 'https://myurl',
 'lastmod': None, 'changefreq': 'always', 'priority': ''}
 }}}

 A simple fix is the meantime is to redefine the _urls() method in the
 Sitemap to include the alternates attribute to an empty list :

 {{{#!python
 class Sitemap(sitemaps.Sitemap):
 """
 Fixes the Exception while resolving variable 'alternates' in template
 'sitemap.xml'
 """
 def _urls(self, *args, **kwargs):
 urls = super()._urls(*args, **kwargs)

 for url_info in urls:
 url_info['alternates'] = []

 return urls
 }}}

 That said, the patch is probably a 1-liner, to check if url.alternates
 exist before using it.

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

[Django] #32647: Select multiple action checkboxes with shift+mouseclick in django admin

[Django]

#32647: Select multiple action checkboxes with shift+mouseclick in django admin
-+-
   Reporter: |  Owner:  nobody
  varicocelehealing  |
   Type:  Bug| Status:  new
  Component: |Version:  3.2
  contrib.admin  |   Keywords:  Admin, Changelist,
   Severity:  Normal |  Shift Click
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 This feature which allowed users to select multiple checkboxes in Django
 3.1 seems to have been disabled or removed in Django 3.2. I am not able to
 select multiple action checkboxes in the django admin changelist.

-- 
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/060.65fcaa7ed2dcba4c151c7c13f14d5292%40djangoproject.com.

Re: [Django] #32646: add request.json() shortcut

[Django]

#32646: add request.json() shortcut
-+--
 Reporter:  Collin Anderson  |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  HTTP handling|  Version:  4.0
 Severity:  Normal   |   Resolution:  duplicate
 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 Collin Anderson):

 I can see the case for content negotiation.

 My two sense: In browsers, there's a standard `.json()` method for http
 responses [0], and the Python `requests` library also has `.json()`
 method, so a simple `.json()` method is becoming more of the norm for a
 lot of simple use cases.

 I don't think I'd be wrong if I said most apis only need to speak json.
 Content negotiation, while needed for some use cases, is probably overkill
 for many people's. Some people aren't going to want their endpoint to
 accept xml and yaml.

 [0] https://developer.mozilla.org/en-US/docs/Web/API/Body/json

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

Re: [Django] #32643: CookieStorage for contrib.messages crashes after upgrade to django 3.2

[Django]

#32643: CookieStorage for contrib.messages crashes after upgrade to django 3.2
-+-
 Reporter:  Jan Pieter   |Owner:  nobody
  Waagmeester|
 Type:  Bug  |   Status:  new
Component:  contrib.messages |  Version:  3.2
 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 Mariusz Felisiak):

 * cc: Florian Apolloner (added)


Comment:

 Jan thanks for this report, however I cannot reproduce this issue.
 Everything works when I will use your messages in
 
[https://github.com/django/django/blob/59552bea5790c97be0da0a6f16ccd0189857c7a7/tests/messages_tests/test_cookie.py#L182-L193
 messages_tests.test_cookie.CookieTests.test_legacy_encode_decode].

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

Re: [Django] #32644: TemplateDoesNotExist for templates in local apps

[Django]

#32644: TemplateDoesNotExist for templates in local apps
-+--
 Reporter:  Ron  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Template system  |  Version:  3.2
 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 Mariusz Felisiak):

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


Comment:

 Yes, `DIRS`  should contain full paths as
 [https://docs.djangoproject.com/en/3.2/ref/templates/api/#the-dirs-option
 documented], so in your case `'DIRS': [BASE_DIR / 'templates']`. It works
 for me with the described project structure. Please use one of
 [https://code.djangoproject.com/wiki/TicketClosingReasons/UseSupportChannels
 support channels] if you still have an issue with templates.

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

Re: [Django] #32646: add request.json() shortcut

[Django]

#32646: add request.json() shortcut
-+--
 Reporter:  Collin Anderson  |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  HTTP handling|  Version:  4.0
 Severity:  Normal   |   Resolution:  duplicate
 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 Adam Johnson):

 There's also #21442 for Tom Christie's work.

 I think adding `request.json()` would be a bit of a mis-feature, when we
 could instead add `request.data` with a parsing framework that's more
 "future-proof". It would be based on DRF's behaviour, so would be familiar
 to most Django devs already.

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

Re: [Django] #32630: Autoreloader doesn't work on Windows 10.

[Django]

#32630: Autoreloader doesn't work on Windows 10.
---+--
 Reporter:  Jan Staal  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Utilities  |  Version:  3.2
 Severity:  Normal |   Resolution:  worksforme
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by Carlton Gibson):

 Thanks for the confirmation Jan.

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

Re: [Django] #32646: add request.json() shortcut

[Django]

#32646: add request.json() shortcut
-+--
 Reporter:  Collin Anderson  |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  HTTP handling|  Version:  4.0
 Severity:  Normal   |   Resolution:  duplicate
 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 Carlton Gibson):

 * cc: Adam Johnson (added)


Comment:

 I think this also relates to #32259. Completing the
 [https://github.com/django/deps/blob/main/draft/content-negotiation.rst
 content negotiation story] as suggested on #27415 would be the
 ''significant benefits'' justifying changes in #32259. 樂

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

Re: [Django] #32646: add request.json() shortcut

[Django]

#32646: add request.json() shortcut
-+--
 Reporter:  Collin Anderson  |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  HTTP handling|  Version:  4.0
 Severity:  Normal   |   Resolution:  duplicate
 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 Mariusz Felisiak):

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


Comment:

 As far as I'm aware, it's a duplicate of #27415.

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

Re: [Django] #32646: add request.json() shortcut

[Django]

#32646: add request.json() shortcut
-+--
 Reporter:  Collin Anderson  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  HTTP handling|  Version:  4.0
 Severity:  Normal   |   Resolution:
 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 Collin Anderson):

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

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

[Django] #32646: add request.json() shortcut

[Django]

#32646: add request.json() shortcut
---+
   Reporter:  Collin Anderson  |  Owner:  nobody
   Type:  New feature  | Status:  new
  Component:  HTTP handling|Version:  4.0
   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|
---+
 It would be nice to have a request.json() shortcut.

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

Re: [Django] #32640: Non-manager instance assigned to model class' objects is silently ignored

[Django]

#32640: Non-manager instance assigned to model class' objects is silently  
ignored
-+-
 Reporter:  Shai Berger  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Shai Berger):

 Hmmm. That makes me wonder if the real change we need to make is in
 {{{add_to_class()}}} -- make it not override existing attributes so
 carelessly. That will fix this issue, and maybe some others like it; I
 only wonder what it will break.

 I'll try to make a PR for that later.

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

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

Re: [Django] #32644: TemplateDoesNotExist for templates in local apps

[Django]

#32644: TemplateDoesNotExist for templates in local apps
-+--
 Reporter:  Ron  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Template system  |  Version:  3.2
 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 Tim Graham):

 I think the issue is that `DIRS` isn't an absolute path. If that worked in
 previous versions, it was probably only by chance.

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

[Django] #32645: order_by().update() support on MySQL / MariaDB fails with multi-table inheritance

[Django]

#32645: order_by().update() support on MySQL / MariaDB fails with multi-table
inheritance
-+-
   Reporter:  Matt   |  Owner:  nobody
  Westcott   |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  3.2
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 The support for respecting queryset ordering on update queries in MySQL /
 MariaDB (added in #31573, 779e615e362108862f1681f965ee9e4f1d0ae6d2) does
 not account for multi-table inheritance setups where the columns in the
 ordering exist in a different table from the one being updated. This
 causes failures on some queries that worked prior to Django 3.2.

 Testing against MySQL 8.0.23, and given the model definitions:
 {{{
 class Place(models.Model):
 name = models.CharField(max_length=255)


 class Restaurant(Place):
 stars = models.IntegerField()
 }}}

 the query `Restaurant.objects.order_by('name').update(stars=3)` fails with
 `django.db.utils.OperationalError: (1054, "Unknown column
 'core_place.name' in 'order clause'")`. (Obviously in this example the
 `order_by` clause is somewhat spurious, but in a real-world setup it could
 be introduced by a custom manager on the Place model, for example.)

 Meanwhile, `Restaurant.objects.order_by('name').update(name='Pizza Hut')`
 fails with `django.db.utils.ProgrammingError: (1064, "You have an error in
 your SQL syntax; check the manual that corresponds to your MySQL server
 version for the right syntax to use near 'ORDER BY `core_place`.`name`
 ASC' at line 1")`. In this case, the base SQLUpdateCompiler class returns
 an empty string to denote that no UPDATE is needed on the `restaurant`
 table (the UPDATE on `place` would happen in a subsequent call to
 `as_sql`), but the MySQL backend is appending the ORDER BY clause to that
 empty string.

-- 
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/049.4d002b19540cd3a025ec6b985a16b96c%40djangoproject.com.

Re: [Django] #32628: Add extra data to autocomplete request

[Django]

#32628: Add extra data to autocomplete request
---+--
 Reporter:  Seb G  |Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  contrib.admin  |  Version:  3.2
 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
---+--

Comment (by Seb G):

 Thanks for clarifying the situation Johannes. I'll stick with my own
 override then :-)

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

[Django] #32644: TemplateDoesNotExist for templates in local apps

[Django]

#32644: TemplateDoesNotExist for templates in local apps
---+
   Reporter:  Ron  |  Owner:  nobody
   Type:  Bug  | Status:  new
  Component:  Template system  |Version:  3.2
   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|
---+
 Ok, I do hope this one is a valid bug ticket!

 Since the update from 3.1.8 to 3.2 I get a `TemplateDoesNotExist` error
 for alle templates **not living in the main template folder** but within
 my local apps.

 Project structure:

 Apps live under: myproject/apps/
 Main template dir: myproject/templates
 Templates for an app live under: myproject/apps/myapp/templates

 My config:
 {{{
 TEMPLATES = [
 {
 'BACKEND': 'django.template.backends.django.DjangoTemplates',
 'DIRS': ['templates'],
 'APP_DIRS': True,
 'OPTIONS': {
 'context_processors': [
 'django.template.context_processors.debug',
 'django.template.context_processors.request',
 'django.contrib.auth.context_processors.auth',
 'django.contrib.messages.context_processors.messages',
 ],
 },
 },
 ]
 }}}

 When I run my tests under 3.1.8, it works. When I update to 3.2 and run
 them, it throws the `TemplateDoesNotExist` exceptions.

 I'd be happy to assist in any way possible.

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

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

Re: [Django] #32634: AlterField drops contraints in the wrong order when performed as reverse migration

[Django]

#32634: AlterField drops contraints in the wrong order when performed as reverse
migration
--+--
 Reporter:  Matthias Dellweg  |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  Migrations|  Version:  3.2
 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 Mariusz Felisiak):

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


Comment:

 Matthias, thanks for details, however this is not a migration created by
 Django. Everything works when I will remove `0002_auto_20210413_0915.py`
 and use a generated migration:
 {{{
 $ python manage.py migrate
 Operations to perform:
   Apply all migrations: admin, auth, contenttypes, pk_migration, sessions
 Running migrations:
   Applying pk_migration.0001_initial... OK
   Applying pk_migration.0002_auto_20210413_1116... OK

 $ python manage.py migrate pk_migration zero
 Operations to perform:
   Unapply all migrations: pk_migration
 Running migrations:
   Rendering model states... DONE
   Unapplying pk_migration.0002_auto_20210413_1116... OK
   Unapplying pk_migration.0001_initial... OK
 }}}

 You could probably make it works with `SeparateDatabaseAndState()`.

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

Re: [Django] #32643: CookieStorage for contrib.messages crashes after upgrade to django 3.2

[Django]

#32643: CookieStorage for contrib.messages crashes after upgrade to django 3.2
-+-
 Reporter:  Jan Pieter   |Owner:  nobody
  Waagmeester|
 Type:  Bug  |   Status:  new
Component:  contrib.messages |  Version:  3.2
 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
-+-
Description changed by Jan Pieter Waagmeester:

Old description:

> After upgrading to django 3.2, a prevously stored cookie for
> contrib.messages crashes in
>
> https://github.com/django/django/blob/d6314c4c2ef647efe0d12450214fc5b4a4055290/django/contrib/messages/storage/cookie.py#L175
>
> Django Version: 3.2
> Python Version: 3.8.2
>
> {{{
> Traceback (most recent call last):
>   File "/home/obs/virtualenv/lib/python3.8/site-
> packages/django/core/handlers/exception.py", line 47, in inner
> response = get_response(request)
>   File "/home/obs/virtualenv/lib/python3.8/site-
> packages/django/utils/deprecation.py", line 119, in __call__
> response = self.process_response(request, response)
>   File "/home/obs/virtualenv/lib/python3.8/site-
> packages/django/contrib/messages/middleware.py", line 23, in
> process_response
> unstored_messages = request._messages.update(response)
>   File "/home/obs/virtualenv/lib/python3.8/site-
> packages/django/contrib/messages/storage/base.py", line 127, in update
> messages = self._loaded_messages + self._queued_messages
>   File "/home/obs/virtualenv/lib/python3.8/site-
> packages/django/contrib/messages/storage/base.py", line 79, in
> _loaded_messages
> messages, all_retrieved = self._get()
>   File "/home/obs/virtualenv/lib/python3.8/site-
> packages/django/contrib/messages/storage/fallback.py", line 25, in _get
> messages, all_retrieved = storage._get()
>   File "/home/obs/virtualenv/lib/python3.8/site-
> packages/django/contrib/messages/storage/cookie.py", line 86, in _get
> messages = self._decode(data)
>   File "/home/obs/virtualenv/lib/python3.8/site-
> packages/django/contrib/messages/storage/cookie.py", line 175, in _decode
> return self.signer.unsign_object(data, serializer=MessageSerializer)
>   File "/home/obs/virtualenv/lib/python3.8/site-
> packages/django/core/signing.py", line 195, in unsign_object
> data = b64_decode(base64d)
>   File "/home/obs/virtualenv/lib/python3.8/site-
> packages/django/core/signing.py", line 68, in b64_decode
> return base64.urlsafe_b64decode(s + pad)
>   File "/usr/lib/python3.8/base64.py", line 133, in urlsafe_b64decode
> return b64decode(s)
>   File "/usr/lib/python3.8/base64.py", line 87, in b64decode
> return binascii.a2b_base64(s)
>
> Exception Type: Error at /user/login/
> Exception Value: Invalid base64-encoded string: number of data characters
> (369) cannot be 1 more than a multiple of 4
> }}}
>
> (redacted) contents of the 'messages' cookie:
> {{{
> '[["__json_message",0,25,"Successfully signed in as '
>  'ad...@example.org."],["__json_message",0,25,"Successfully '
>  'signed in as jieter."],["__json_message",0,25,"Ingelogd als '
>  'ad...@example.org."],["__json_message",0,25,"Ingelogd '
>  'als '
>  'ad...@example.org."],["__json_message",0,20,"Bevestigingsmail '
>  'verzonden naar t...@example.nl."],["__json_message",0,25,"Ingelogd '
>  'als '
>  't...@example.nl."]]:1lTkj1:j_3PlpYSKiqPTMAB6_p2Q00eE8j6k7n0Sg_-
> _IpXG7Y')
> }}}

New description:

 After upgrading to django 3.2, a previously stored cookie for
 contrib.messages crashes in

 
https://github.com/django/django/blob/d6314c4c2ef647efe0d12450214fc5b4a4055290/django/contrib/messages/storage/cookie.py#L175

 Django Version: 3.2
 Python Version: 3.8.2

 {{{
 Traceback (most recent call last):
   File "/home/obs/virtualenv/lib/python3.8/site-
 packages/django/core/handlers/exception.py", line 47, in inner
 response = get_response(request)
   File "/home/obs/virtualenv/lib/python3.8/site-
 packages/django/utils/deprecation.py", line 119, in __call__
 response = self.process_response(request, response)
   File "/home/obs/virtualenv/lib/python3.8/site-
 packages/django/contrib/messages/middleware.py", line 23, in
 process_response
 unstored_messages = request._messages.update(response)
   File "/home/obs/virtualenv/lib/python3.8/site-
 packages/django/contrib/messages/storage/base.py", line 127, in update
 messages = self._loaded_messages + self._queued_messages
   File "/home/obs/virtualenv/lib/python3.8/site-
 

[Django] #32643: CookieStorage for contrib.messages crashes after upgrade to django 3.2

[Django]

#32643: CookieStorage for contrib.messages crashes after upgrade to django 3.2
--+
   Reporter:  Jan Pieter Waagmeester  |  Owner:  nobody
   Type:  Bug | Status:  new
  Component:  contrib.messages|Version:  3.2
   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   |
--+
 After upgrading to django 3.2, a prevously stored cookie for
 contrib.messages crashes in

 
https://github.com/django/django/blob/d6314c4c2ef647efe0d12450214fc5b4a4055290/django/contrib/messages/storage/cookie.py#L175

 Django Version: 3.2
 Python Version: 3.8.2

 {{{
 Traceback (most recent call last):
   File "/home/obs/virtualenv/lib/python3.8/site-
 packages/django/core/handlers/exception.py", line 47, in inner
 response = get_response(request)
   File "/home/obs/virtualenv/lib/python3.8/site-
 packages/django/utils/deprecation.py", line 119, in __call__
 response = self.process_response(request, response)
   File "/home/obs/virtualenv/lib/python3.8/site-
 packages/django/contrib/messages/middleware.py", line 23, in
 process_response
 unstored_messages = request._messages.update(response)
   File "/home/obs/virtualenv/lib/python3.8/site-
 packages/django/contrib/messages/storage/base.py", line 127, in update
 messages = self._loaded_messages + self._queued_messages
   File "/home/obs/virtualenv/lib/python3.8/site-
 packages/django/contrib/messages/storage/base.py", line 79, in
 _loaded_messages
 messages, all_retrieved = self._get()
   File "/home/obs/virtualenv/lib/python3.8/site-
 packages/django/contrib/messages/storage/fallback.py", line 25, in _get
 messages, all_retrieved = storage._get()
   File "/home/obs/virtualenv/lib/python3.8/site-
 packages/django/contrib/messages/storage/cookie.py", line 86, in _get
 messages = self._decode(data)
   File "/home/obs/virtualenv/lib/python3.8/site-
 packages/django/contrib/messages/storage/cookie.py", line 175, in _decode
 return self.signer.unsign_object(data, serializer=MessageSerializer)
   File "/home/obs/virtualenv/lib/python3.8/site-
 packages/django/core/signing.py", line 195, in unsign_object
 data = b64_decode(base64d)
   File "/home/obs/virtualenv/lib/python3.8/site-
 packages/django/core/signing.py", line 68, in b64_decode
 return base64.urlsafe_b64decode(s + pad)
   File "/usr/lib/python3.8/base64.py", line 133, in urlsafe_b64decode
 return b64decode(s)
   File "/usr/lib/python3.8/base64.py", line 87, in b64decode
 return binascii.a2b_base64(s)

 Exception Type: Error at /user/login/
 Exception Value: Invalid base64-encoded string: number of data characters
 (369) cannot be 1 more than a multiple of 4
 }}}

 (redacted) contents of the 'messages' cookie:
 {{{
 '[["__json_message",0,25,"Successfully signed in as '
  'ad...@example.org."],["__json_message",0,25,"Successfully '
  'signed in as jieter."],["__json_message",0,25,"Ingelogd als '
  'ad...@example.org."],["__json_message",0,25,"Ingelogd '
  'als '
  'ad...@example.org."],["__json_message",0,20,"Bevestigingsmail '
  'verzonden naar t...@example.nl."],["__json_message",0,25,"Ingelogd '
  'als '
  't...@example.nl."]]:1lTkj1:j_3PlpYSKiqPTMAB6_p2Q00eE8j6k7n0Sg_-_IpXG7Y')
 }}}

-- 
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/049.cc981576a8f11dee6a67d06353eb082e%40djangoproject.com.

Re: [Django] #32634: AlterField drops contraints in the wrong order when performed as reverse migration

[Django]

#32634: AlterField drops contraints in the wrong order when performed as reverse
migration
--+--
 Reporter:  Matthias Dellweg  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Migrations|  Version:  3.2
 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 Matthias Dellweg):

 * status:  closed => new
 * version:  2.2 => 3.2
 * resolution:  needsinfo =>


Comment:

 I could reproduce with Django==3.2.

 I created a sample project here:
 https://github.com/mdellweg/migrationtest

 If you configure this app to a postgres driver and call
 `migrationtest/manage.py sqlmigrate --backwards pk_migration 0002`, you
 will see:
 {{{
 BEGIN;
 --
 -- Alter field secondbase_ptr on child
 --
 SET CONSTRAINTS
 "pk_migration_child_secondbase_ptr_id_9b785ce8_fk_pk_migrat" IMMEDIATE;
 ALTER TABLE "pk_migration_child" DROP CONSTRAINT
 "pk_migration_child_secondbase_ptr_id_9b785ce8_fk_pk_migrat";
 ALTER TABLE "pk_migration_child" ALTER COLUMN "secondbase_ptr_id" DROP NOT
 NULL;
 ALTER TABLE "pk_migration_child" DROP CONSTRAINT
 "pk_migration_child_secondbase_ptr_id_9b785ce8_pk";
 ALTER TABLE "pk_migration_child" ADD CONSTRAINT
 "pk_migration_child_secondbase_ptr_id_9b785ce8_uniq" UNIQUE
 ("secondbase_ptr_id");
 ALTER TABLE "pk_migration_child" ADD CONSTRAINT
 "pk_migration_child_secondbase_ptr_id_9b785ce8_fk_pk_migrat" FOREIGN KEY
 ("secondbase_ptr_id") REFERENCES "pk_migration_secondbase" ("id")
 DEFERRABLE INITIALLY DEFERRED;
 --
 -- Remove field firstbase_ptr from child
 --
 ALTER TABLE "pk_migration_child" ADD COLUMN "firstbase_ptr_id" bigint NOT
 NULL PRIMARY KEY CONSTRAINT
 "pk_migration_child_firstbase_ptr_id_3ea33ffb_fk_pk_migrat" REFERENCES
 "pk_migration_firstbase"("id") DEFERRABLE INITIALLY DEFERRED; SET
 CONSTRAINTS "pk_migration_child_firstbase_ptr_id_3ea33ffb_fk_pk_migrat"
 IMMEDIATE;
 --
 -- MIGRATION NOW PERFORMS OPERATION THAT CANNOT BE WRITTEN AS SQL:
 -- Raw Python operation
 --
 --
 -- Add field secondbase_ptr to child
 --
 SET CONSTRAINTS
 "pk_migration_child_secondbase_ptr_id_9b785ce8_fk_pk_migrat" IMMEDIATE;
 ALTER TABLE "pk_migration_child" DROP CONSTRAINT
 "pk_migration_child_secondbase_ptr_id_9b785ce8_fk_pk_migrat";
 ALTER TABLE "pk_migration_child" DROP COLUMN "secondbase_ptr_id" CASCADE;
 COMMIT;
 }}}
 Which will fail to migrate with `column "secondbase_ptr_id" is in a
 primary key` when trying to execute `ALTER TABLE "pk_migration_child"
 ALTER COLUMN "secondbase_ptr_id" DROP NOT NULL;`.

 If you move `ALTER TABLE "pk_migration_child" DROP CONSTRAINT
 "pk_migration_child_secondbase_ptr_id_9b785ce8_pk";` one place up in the
 command chain, the migration will succeed.

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

Re: [Django] #32642: RuntimeError: 'apps.core.apps' declares more than one default AppConfig on custom admin setup

[Django]

#32642: RuntimeError: 'apps.core.apps' declares more than one default AppConfig 
on
custom admin setup
---+--
 Reporter:  Ron|Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  contrib.admin  |  Version:  3.2
 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 Mariusz Felisiak):

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


Comment:

 As far as I'm aware it's not a bug in Django. First of all you should
 customize a default admin site inside a main project directory (like
 described in the documentation) not in an app, secondly `INSTALLED_APPS`
 must point to
 [https://docs.djangoproject.com/en/3.2/ref/applications/#troubleshooting
 the config].

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

Re: [Django] #32574: Add support for Proj 8.x.

[Django]

#32574: Add support for Proj 8.x.
-+---
 Reporter:  David Smith  |Owner:  David Smith
 Type:  New feature  |   Status:  assigned
Component:  GIS  |  Version:  dev
 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 David Smith):

 * 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/066.210f8c65efc7df6b6ba4f5b5f9a14352%40djangoproject.com.

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

[Django]

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

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


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

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

Re: [Django] #32574: Add support for Proj 8.x.

[Django]

#32574: Add support for Proj 8.x.
-+---
 Reporter:  David Smith  |Owner:  David Smith
 Type:  New feature  |   Status:  assigned
Component:  GIS  |  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 David Smith):

 * owner:  nobody => David Smith
 * 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/066.636c8082c61f38d05be8d8d840564366%40djangoproject.com.

[Django] #32642: RuntimeError: 'apps.core.apps' declares more than one default AppConfig on custom admin setup

[Django]

#32642: RuntimeError: 'apps.core.apps' declares more than one default AppConfig 
on
custom admin setup
-+
   Reporter:  Ron|  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  contrib.admin  |Version:  3.2
   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  |
-+
 Hi!

 I just migrated my project to django 3.2 and I get the following error:

 > RuntimeError: 'apps.core.apps' declares more than one default AppConfig:
 'AdminConfig', 'CustomAdminConfig'.

 Here is my apps.py:


 {{{
 from django.contrib.admin.apps import AdminConfig

 class CustomAdminConfig(AdminConfig):
 default_site = 'apps.core.admin.site.CustomAdminSite'
 }}}

 To narrow down the bug I renamed the import:

 {{{
 from django.contrib.admin.apps import AdminConfig as XAdminConfig

 class CustomAdminConfig(XAdminConfig):
 default_site = 'apps.core.admin.site.CustomAdminSite'
 }}}

 Then the error changes to:

 > RuntimeError: 'apps.core.apps' declares more than one default AppConfig:
 'XAdminConfig', 'CustomAdminConfig'.

 So I guess the new apps autoloader is following the import statement.

 I looked at the docs
 (https://docs.djangoproject.com/en/3.2/ref/contrib/admin/#overriding-the-
 default-admin-site) but the described way seems like the stuff I did.

 I honestly hope, I'm not making any stupid mistakes here.

 Best regards and thx!
 Ronny

-- 
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/049.68805821a54256cbce95e34905219657%40djangoproject.com.

Re: [Django] #32636: QuerySet.values()/values_list() crashes on a combined queryset ordered by "extra" select.

[Django]

#32636: QuerySet.values()/values_list() crashes on a combined queryset ordered 
by
"extra" select.
-+-
 Reporter:  Mariusz Felisiak |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  queryset combined| Triage Stage:  Accepted
  union difference intersection  |
  extra  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * stage:  Unreviewed => Accepted


Comment:

 OK. The idea being that the `extra` should come from the respective
 queryset, not the first one.

 Do it the other way around and the test passes `qs2.union(qs1)...`
 (Because Celebrity has a `name`, I suppose).

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

Re: [Django] #32641: Log the number of tests found in DiscoverRunner.build_suite()

[Django]

#32641: Log the number of tests found in DiscoverRunner.build_suite()
-+-
 Reporter:  Chris Jerdonek   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Testing framework|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
  DiscoverRunner,build_suite |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * easy:  0 => 1
 * stage:  Unreviewed => Accepted


Comment:

 An extra line in the output should be fine.

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

Re: [Django] #32606: Allow rich configuration of Selenium tests

[Django]

#32606: Allow rich configuration of Selenium tests
---+--
 Reporter:  Dominik George |Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  Testing framework  |  Version:  dev
 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 Carlton Gibson):

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


Comment:

 Hi Dominik.

 I'm going to say wontfix here initially. That doesn't mean definitely not,
 just that it seems out of scope for what we'd include in Django itself.

 If you want to pull together a proof-of-concept, it's something we could
 look at. (And happily so!) (So I'm tempted towards `needsinfo` again for
 that reason.)

 **Maybe** what you're suggesting would be a trivial pass-through to
 selenium, but a quick initial look browser capabilities there presents a
 wall of posts and docs that aren't exactly inviting, so it's hard to
 assess.

 (New features like this often need some idea of what's really involved,
 and we often begin with discussion on the DevelopersMailingList, which has
 a larger audience, rather than straight here on Trac, which is better for
 concrete addressable with a plan.)

 I hope that makes sense.

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

Re: [Django] #32640: Non-manager instance assigned to model class' objects is silently ignored

[Django]

#32640: Non-manager instance assigned to model class' objects is silently  
ignored
-+-
 Reporter:  Shai Berger  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * stage:  Unreviewed => Accepted


Comment:

 Hi Shai.

 I think we might be able to do **something** here…

 If you get into
 
[https://github.com/django/django/blob/3b8527e32b665df91622649550813bb1ec9a9251/django/db/models/base.py#L357-L365
 this block where the `objects` manager is automatically added]:


 {{{
 if not opts.managers:
 if any(f.name == 'objects' for f in opts.fields):
 raise ValueError(
 "Model %s must specify a custom Manager, because it
 has a "
 "field named 'objects'." % cls.__name__
 )
 manager = Manager()
 manager.auto_created = True
 cls.add_to_class('objects', manager)
 }}}

 …then it seems that any value of `objects` is an error 樂 — but
 particularly if `objects` is a `Manager` **class**.

 {{{
 >>> from django.db import models
 >>> class MyModel(models.Model):
 ... objects = "not-a-manager"
 ... class Meta:
 ... app_label = "testing"
 ...
 >>> MyModel.objects
 
 }}}

 I'd think we could at least warn there, but arguably even raise.

 Not sure how far down this road it would be worth going.

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

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

Re: [Django] #32641: Log the number of tests found in DiscoverRunner.build_suite()

[Django]

#32641: Log the number of tests found in DiscoverRunner.build_suite()
-+-
 Reporter:  Chris Jerdonek   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Testing framework|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
  DiscoverRunner,build_suite |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Chris Jerdonek:

Old description:

> Currently, when running tests with `DiscoverRunner`, the number of tests
> is displayed only at the very end of the test run.
>
> However, knowing this number at the ''beginning'' of a test run could I
> think provide an increase in usability. For example, you'd be able to
> notice right away if a new test you're working was or wasn't included as
> expected, based on whether the number is the same or different from the
> previous run. Similarly, the early feedback would be helpful as a sanity
> check if you're trying to reduce the number of tests using different
> command-line options, and you're not sure if your invocation is correct.
>
> Thus, I'd like to suggest that `DiscoverRunner` display by default the
> number of tests discovered (and that match any filters) at the earliest
> point where this is known. This could be done inside
> `DiscoverRunner.build_suite()`.
>
> The code change could be as simple as:
>
> {{{
> diff --git a/django/test/runner.py b/django/test/runner.py
> index f187107157..c975ed92be 100644
> --- a/django/test/runner.py
> +++ b/django/test/runner.py
> @@ -652,7 +652,8 @@ class DiscoverRunner:
>  # _FailedTest objects include things like test modules that
> couldn't be
>  # found or that couldn't be loaded due to syntax errors.
>  test_types = (unittest.loader._FailedTest, *self.reorder_by)
> -all_tests = reorder_tests(all_tests, test_types, self.reverse)
> +all_tests = list(reorder_tests(all_tests, test_types,
> self.reverse))
> +print('Found %d tests' % len(all_tests))
>  suite = self.test_suite(all_tests)
>
>  if self.parallel > 1:
> }}}
>
> If there is any concern about adding an additional message, another
> possibility would be to display the current "Testing against Django
> installed in ..." message later in the test run, only after the number of
> tests is known, and include the test count in that message.

New description:

 Currently, when running tests with `DiscoverRunner`, the number of tests
 is displayed only at the very end of the test run.

 However, knowing this number at the ''beginning'' of a test run could I
 think provide an increase in usability. For example, you'd be able to
 notice right away if a new test you're working on was or wasn't included
 as expected, based on whether the number is the same or different from the
 previous run. Similarly, the early feedback would be helpful as a sanity
 check if you're trying to reduce the number of tests using different
 command-line options, and you're not sure if your invocation is correct.

 Thus, I'd like to suggest that `DiscoverRunner` display by default the
 number of tests discovered (and that match any filters) at the earliest
 point where this is known. This could be done inside
 `DiscoverRunner.build_suite()`.

 The code change could be as simple as:

 {{{
 diff --git a/django/test/runner.py b/django/test/runner.py
 index f187107157..c975ed92be 100644
 --- a/django/test/runner.py
 +++ b/django/test/runner.py
 @@ -652,7 +652,8 @@ class DiscoverRunner:
  # _FailedTest objects include things like test modules that
 couldn't be
  # found or that couldn't be loaded due to syntax errors.
  test_types = (unittest.loader._FailedTest, *self.reorder_by)
 -all_tests = reorder_tests(all_tests, test_types, self.reverse)
 +all_tests = list(reorder_tests(all_tests, test_types,
 self.reverse))
 +if self.verbosity >= 1:
 +print('Found %d tests' % len(all_tests))
  suite = self.test_suite(all_tests)

  if self.parallel > 1:
 }}}

 If there is any concern about adding an additional message, another
 possibility would be to display the current "Testing against Django
 installed in ..." message later in the test run, only after the number of
 tests is known, and include the test count in that message.

--

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

-- 
You 

[Django] #32641: Log the number of tests found in DiscoverRunner.build_suite()

[Django]

#32641: Log the number of tests found in DiscoverRunner.build_suite()
-+-
   Reporter:  Chris  |  Owner:  nobody
  Jerdonek   |
   Type: | Status:  new
  Cleanup/optimization   |
  Component:  Testing|Version:  dev
  framework  |   Keywords:
   Severity:  Normal |  DiscoverRunner,build_suite
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Currently, when running tests with `DiscoverRunner`, the number of tests
 is displayed only at the very end of the test run.

 However, knowing this number at the ''beginning'' of a test run could I
 think provide an increase in usability. For example, you'd be able to
 notice right away if a new test you're working was or wasn't included as
 expected, based on whether the number is the same or different from the
 previous run. Similarly, the early feedback would be helpful as a sanity
 check if you're trying to reduce the number of tests using different
 command-line options, and you're not sure if your invocation is correct.

 Thus, I'd like to suggest that `DiscoverRunner` display by default the
 number of tests discovered (and that match any filters) at the earliest
 point where this is known. This could be done inside
 `DiscoverRunner.build_suite()`.

 The code change could be as simple as:

 {{{
 diff --git a/django/test/runner.py b/django/test/runner.py
 index f187107157..c975ed92be 100644
 --- a/django/test/runner.py
 +++ b/django/test/runner.py
 @@ -652,7 +652,8 @@ class DiscoverRunner:
  # _FailedTest objects include things like test modules that
 couldn't be
  # found or that couldn't be loaded due to syntax errors.
  test_types = (unittest.loader._FailedTest, *self.reorder_by)
 -all_tests = reorder_tests(all_tests, test_types, self.reverse)
 +all_tests = list(reorder_tests(all_tests, test_types,
 self.reverse))
 +print('Found %d tests' % len(all_tests))
  suite = self.test_suite(all_tests)

  if self.parallel > 1:
 }}}

 If there is any concern about adding an additional message, another
 possibility would be to display the current "Testing against Django
 installed in ..." message later in the test run, only after the number of
 tests is known, and include the test count in that message.

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

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

Re: [Django] #32635: System checks for invalid model field names in CheckConstraint.check/UniqueConstraint.condition crash with a reverse 020 relation.

[Django]

#32635: System checks for invalid model field names in
CheckConstraint.check/UniqueConstraint.condition crash with a reverse 020
relation.
-+-
 Reporter:  sim1234  |Owner:  Hasan
 |  Ramezani
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  UniqueConstraint | Triage Stage:  Accepted
  OneToOneField  |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Hasan Ramezani):

 [https://github.com/django/django/pull/14255 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/065.cc569fd53ca7d9f4a145c36922a25281%40djangoproject.com.

Re: [Django] #32639: ADMINS and MANAGERS may contain invalid email addreses

[Django]

#32639: ADMINS and MANAGERS may contain invalid email addreses
-+-
 Reporter:  Matthias Kestenholz  |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Core (System |  Version:  4.0
  checks)|
 Severity:  Normal   |   Resolution:  wontfix
 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 Matthias Kestenholz):

 Thanks!

 I tend to agree that adding checks is bothersome, especially since I have
 been bitten by new checks in the past.  However, `mail_managers` and
 friends will choke later anyway and it would be better to catch typos
 earlier. Django's `EmailValidator` is battle tested and has been
 essentially unchanged since 2015 and building on this should (yeah I know,
 famous last words) be safe. `root@localhost` etc. are valid according to
 the `EmailValidator` so I really have a hard time imagining regressions.
 Also, such regressions would be detected very early, when starting up the
 application server, not in the middle of the night when everyone is
 sleeping.

 Because of these points I still think this new check would be a good idea.

 Of course it is your call. Thanks again :)

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

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

Re: [Django] #32630: Autoreloader doesn't work on Windows 10.

[Django]

#32630: Autoreloader doesn't work on Windows 10.
---+--
 Reporter:  Jan Staal  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Utilities  |  Version:  3.2
 Severity:  Normal |   Resolution:  worksforme
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by Jan Staal):

 I have tried this again and even I am no longer able to reproduce the
 behaviour.
 System: windows 10
 Python: 3.9
 Ticket can be closed.

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

Re: [Django] #32637: Technical 404 debug page doesn't display Http404's message in Django 3.2.

[Django]

#32637: Technical 404 debug page doesn't display Http404's message in Django 
3.2.
-+-
 Reporter:  Atul Varma   |Owner:  Mariusz
 |  Felisiak
 Type:  Bug  |   Status:  closed
Component:  Error reporting  |  Version:  3.2
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"d6314c4c2ef647efe0d12450214fc5b4a4055290" d6314c4]:
 {{{
 #!CommitTicketReference repository=""
 revision="d6314c4c2ef647efe0d12450214fc5b4a4055290"
 [3.2.x] Fixed #32637 -- Restored exception message on technical 404 debug
 page.

 Thanks Atul Varma for the report.
 Backport of 3b8527e32b665df91622649550813bb1ec9a9251 from main
 }}}

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

Re: [Django] #32637: Technical 404 debug page doesn't display Http404's message in Django 3.2.

[Django]

#32637: Technical 404 debug page doesn't display Http404's message in Django 
3.2.
-+-
 Reporter:  Atul Varma   |Owner:  Mariusz
 |  Felisiak
 Type:  Bug  |   Status:  closed
Component:  Error reporting  |  Version:  3.2
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by GitHub ):

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


Comment:

 In [changeset:"3b8527e32b665df91622649550813bb1ec9a9251" 3b8527e3]:
 {{{
 #!CommitTicketReference repository=""
 revision="3b8527e32b665df91622649550813bb1ec9a9251"
 Fixed #32637 -- Restored exception message on technical 404 debug page.

 Thanks Atul Varma for the report.
 }}}

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

Re: [Django] #32635: System checks for invalid model field names in CheckConstraint.check/UniqueConstraint.condition crash with a reverse 020 relation.

[Django]

#32635: System checks for invalid model field names in
CheckConstraint.check/UniqueConstraint.condition crash with a reverse 020
relation.
-+-
 Reporter:  sim1234  |Owner:  Hasan
 |  Ramezani
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  UniqueConstraint | Triage Stage:  Accepted
  OneToOneField  |
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/065.bb31b85223afecfb89d8997aabf2e7d4%40djangoproject.com.

Re: [Django] #32639: ADMINS and MANAGERS may contain invalid email addreses

[Django]

#32639: ADMINS and MANAGERS may contain invalid email addreses
-+-
 Reporter:  Matthias Kestenholz  |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Core (System |  Version:  4.0
  checks)|
 Severity:  Normal   |   Resolution:  wontfix
 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 Mariusz Felisiak):

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


Comment:

 Thanks for this proposition, however I don't think that we need extra
 checks, because we will probably introduce some regressions with them
 (like we did in the past). Email validation is too fragile.

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

[Django] #32640: Non-manager instance assigned to model class' objects is silently ignored

[Django]

#32640: Non-manager instance assigned to model class' objects is silently  
ignored
-+-
   Reporter:  Shai   |  Owner:  nobody
  Berger |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  2.2
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  1
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Consider this models file:

 {{{#!python
 from django.db import models


 class MyManager(models.Manager):
 def get_queryset(self):
 return self.none()


 class MyModel(models.Model):
 one = models.IntegerField()

 objects = MyManager  # Note: Missing parentheses
 }}}

 The assignment of a manager class, rather than manager instance, is an
 easy mistake to make. I know, because I've made it. In a private
 discussion, Carlton Gibson suggested another variant of this:

 {{{#!python
 class MyOtherModel(models.Model):
 ...
 objects = models.Manager.from_queryset(SomeQueryset())
 # The above, too, is missing a pair of parentheses
 }}}

 But what should Django do?

 There's two possible behaviors I would consider reasonable:
 - Trust the user, and rely on Duck Typing. This would blow up very fast in
 this case, as any method invocation would be missing the {{{self}}}
 argument.
 - Raise an error on model creation, or at least in {{{check}}}.

 What Django does instead, is ignore the assignment and use a
 {{{models.Manager}}} instance.

 Two points to clarify that this is indeed a bug:
 - Assigning any object which isn't a {{{models.Manager}}} instance -- say,
 the number 17 -- gets the same result.
 - This only happens if only one manager is defined. If another manager is
 defined, the assignment stands as written (the first "reasonable" behavior
 described above).

 I found this on 2.2, it is still this way on 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/048.0ae4e734f527ffe2b79b509bab3547fe%40djangoproject.com.

Re: [Django] #32639: ADMINS and MANAGERS may contain invalid email addreses

[Django]

#32639: ADMINS and MANAGERS may contain invalid email addreses
-+-
 Reporter:  Matthias Kestenholz  |Owner:  nobody
 Type:  New feature  |   Status:  assigned
Component:  Core (System |  Version:  4.0
  checks)|
 Severity:  Normal   |   Resolution:
 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 Matthias Kestenholz):

 [https://github.com/django/django/pull/14254 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/067.cf36a15bf6b001edda9f952b0cccd4c5%40djangoproject.com.

[Django] #32639: ADMINS and MANAGERS may contain invalid email addreses

[Django]

#32639: ADMINS and MANAGERS may contain invalid email addreses
+--
   Reporter:  Matthias Kestenholz   |  Owner:  nobody
   Type:  New feature   | Status:  assigned
  Component:  Core (System checks)  |Version:  4.0
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  1
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+--
 I propose a new system check which prevents users from configuring invalid
 email addresses.

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

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

Re: [Django] #32630: Autoreloader doesn't work on Windows 10.

[Django]

#32630: Autoreloader doesn't work on Windows 10.
---+--
 Reporter:  Jan Staal  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Utilities  |  Version:  3.2
 Severity:  Normal |   Resolution:  worksforme
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Carlton Gibson):

 * resolution:  needsinfo => worksforme


Comment:

 Testing with Django 3.2 and Python 3.8 on Windows 10, this works for 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/069.90543e19221665f60694df13cb364d8b%40djangoproject.com.

Re: [Django] #32638: threading.Thread.setDaemon has been deprecated in Python 3.10

[Django]

#32638: threading.Thread.setDaemon has been deprecated in Python 3.10
-+-
 Reporter:  Xtreak   |Owner:  Xtreak
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Utilities|  Version:  dev
 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 Mariusz Felisiak):

 * status:  assigned => closed
 * resolution:   => duplicate
 * component:  Uncategorized => Utilities


Comment:

 Duplicate of #32074.

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