Re: [Django] #33647: bulk_update silently truncating values for size limited fields

[Django]

#33647: bulk_update silently truncating values for size limited fields
-+-
 Reporter:  jerch|Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  4.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Dan Hamilton):

 * owner:  Dan Hamilton => (none)
 * status:  assigned => new


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018956b7f676-3d65d54b-cf07-4408-824a-47b5266f45cc-00%40eu-central-1.amazonses.com.

Re: [Django] #34711: form.has_changed() is always True for IntegerChoices Enum Model Field

[Django]

#34711: form.has_changed() is always True for IntegerChoices Enum Model Field
+--
 Reporter:  GHPS|Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  Forms   |  Version:  4.2
 Severity:  Normal  |   Resolution:  needsinfo
 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 Natalia Bidart):

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


Comment:

 Hello,

 I have tried to reproduce your issue, and since the provided code is
 incomplete, I built my own models and tests. But, in my testing, if
 request.POST has the correct and complete information for the model
 instance, `has_changed` correctly reports False.

 So, I'll be closing this report as `needsinfo` since we need more
 information to properly triage this ticket. Specifically, we'd need a
 django test project with the necessary models and forms, plus instructions
 in how to trigger the issue.

 Could you please provide that? Thanks!

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/010701895637f1b7-3bca29d4-de15-4c1d-9164-75bc2622e110-00%40eu-central-1.amazonses.com.

Re: [Django] #34679: Cannot run collectstatic with existing unsupported manifest file

[Django]

#34679: Cannot run collectstatic with existing unsupported manifest file
-+-
 Reporter:  Jarosław Wygoda  |Owner:  Jarosław
 |  Wygoda
 Type:  Bug  |   Status:  closed
Component:  contrib.staticfiles  |  Version:  4.1
 Severity:  Normal   |   Resolution:  needsinfo
 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 Natalia Bidart):

 Hello,

 In my last comment I mentioned that I can not even reproduce the reported
 issue. Could you share a test project with clear steps to reproduce?

 Thanks, Natalia.

-- 
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/0107018955e61331-7364e40a-e673-479f-9b64-2e7d2d0149ba-00%40eu-central-1.amazonses.com.

Re: [Django] #34542: Required fields allowed to be blank are not accepted non-interactively using createsuperuser

[Django]

#34542: Required fields allowed to be blank are not accepted non-interactively
using createsuperuser
-+-
 Reporter:  Lantizia |Owner:  Anvansh
 |  Singh
 Type:  Bug  |   Status:  assigned
Component:  contrib.auth |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  auth | Triage Stage:  Accepted
  createsuperuser superuser email|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Natalia Bidart):

 Hello Mateusz, the goal for the fix is to allow the email value to be
 blank, not to allow it to be missing. So basically an invocation with
 `--email ""` should succeed but not passing `--email` at all should fail
 for `noinput` or should prompt for `email` if interactive.

 Does that make 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/0107018955deb919-5ce2af37-f97e-43a6-ace7-349ab7efeab4-00%40eu-central-1.amazonses.com.

Re: [Django] #34699: Filtering on annotated TruncSecond expression gives unexpected result.

[Django]

#34699: Filtering on annotated TruncSecond expression gives unexpected result.
-+-
 Reporter:  Stefan   |Owner:  Francesco
 Type:   |  Panico
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  4.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Natalia Bidart):

 * type:  Uncategorized => Cleanup/optimization
 * stage:  Unreviewed => Accepted


Comment:

 I did some more research on this. I'm accepting this ticket because I do
 believe there is an unexpected behavior, which may be a bug or just a
 documentation issue.

 The simplest test of getting all books and printing their `published` date
 and their truncated-to-seconds published date is, IMHO, unexpected: the
 `published` value is in UTC but the annotated value is in the timezone the
 app is configured. My settings:

 {{{
 USE_TZ = True
 TIME_ZONE = "Europe/Berlin"
 }}}

 The model:

 {{{
 from django.db import models
 from django.utils import timezone


 class Book(models.Model):
 published = models.DateTimeField(default=timezone.now)
 }}}

 In the shell:
 {{{
 import time
 from django.db.models.functions import TruncSecond
 from testapp.models import Book
 for i in range(3):
 Book.objects.create(); time.sleep(1)
 annotated_books =
 Book.objects.annotate(_published_trunc=TruncSecond('published'))
 for i in annotated_books.all():
 print(i.published, i._published_trunc)
 }}}

 With output:
 {{{
 2023-07-14 18:39:22.620603+00:00 2023-07-14 20:39:22+02:00
 2023-07-14 18:39:28.585856+00:00 2023-07-14 20:39:28+02:00
 2023-07-14 18:39:29.590469+00:00 2023-07-14 20:39:29+02:00
 2023-07-14 18:39:30.595811+00:00 2023-07-14 20:39:30+02:00
 }}}

-- 
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/0107018955c43298-5f8bdd89-8b47-4bff-bf14-54dea8795a3a-00%40eu-central-1.amazonses.com.

Re: [Django] #34711: form.has_changed() is always True for IntegerChoices Enum Model Field

[Django]

#34711: form.has_changed() is always True for IntegerChoices Enum Model Field
+--
 Reporter:  GHPS|Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Forms   |  Version:  4.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 GHPS:

Old description:

> Summary:
>
> While trying to find out why the forms in two different applications are
> marked for saving even if no field has been changed, I could pin the
> problem down
> to the integer enum fields used in both models and form.ChoiceField
> involved.
> In short form.has_changed() is triggered because of a double data
> conversion
> during the round-trip.
>
> The value of the integer enum field is converted to a string and
> rendered.
> The POST request comes back with this string which gets compared to the
> original
> enum integer which shows that they are different. During the -
> unnecessary - saving
> the string becomes an int again - which is why the original problem is
> hidden
> from the perspective of a user.
>
> Background:
>
> In Django 4.2 on Linux (Kubuntu 22.04) take the following enum and
> create a model field in model.py:
>
> {{{
> class eAssets(models.IntegerChoices):
> dvd   =1, _('DVD')
> bluray=3, _('Blu-ray')
> none  =0, _('-')
>
> eAsset=models.PositiveSmallIntegerField(choices=eAssets.choices,
> default=eAssets.none)
> }}}
>

> Create a choice form field in form.py:
>
> {{{
> eAsset=forms.ChoiceField(label=mdMovie._meta.get_field('eAsset').verbose_name,
> choices=[(dcEntry.value, dcEntry.label) for dcEntry in mdMovie.eAssets],
>   initial=mdMovie.eAssets.none)
>
> After processing the POST request, form.has_changed() is always true in
> view.py:
>
> >fmForm=fmMovie(vRequest.POST, vRequest.FILES or None,
> instance=rcCurrentMovie)
> >fmForm.has_changed()
> True
> >fmForm.changed_data
> ['eAsset']
> }}}
>
> Links:
> - I've found an old ticket #22097 and it looks to me like this nine year
> old bug has shown its ugly face again.
> - On Stackoverflow someone reported the same problem.
> [https://stackoverflow.com/questions/68763230/django-forms-a-dynamic-
> integer-model-choice-field-always-fails-form-has-changed|A dynamic
> integer model choice field always fails form.has_changed()]

New description:

 Summary:

 While trying to find out why the forms in two different applications are
 marked for saving even if no field has been changed, I could pin the
 problem down
 to the integer enum fields used in both models and form.ChoiceField
 involved.
 In short, form.has_changed() is triggered because of a double data
 conversion
 during the round-trip.

 The value of the integer enum field is converted to a string and rendered.
 The POST request comes back with this string which gets compared to the
 original
 enum integer which shows that they are different. During the - unnecessary
 - saving
 the string becomes an int again - which is why the original problem is
 hidden
 from the perspective of a user.

 This bug seem to be a regression from bug #22097.

 Background:

 In Django 4.2 on Linux (Kubuntu 22.04) take the following enum and
 create a model field in model.py:

 {{{
 class eAssets(models.IntegerChoices):
 dvd   =1, _('DVD')
 bluray=3, _('Blu-ray')
 none  =0, _('-')

 eAsset=models.PositiveSmallIntegerField(choices=eAssets.choices,
 default=eAssets.none)
 }}}


 Create a choice form field in form.py:

 {{{
 eAsset=forms.ChoiceField(label=mdMovie._meta.get_field('eAsset').verbose_name,
 choices=[(dcEntry.value, dcEntry.label) for dcEntry in mdMovie.eAssets],
   initial=mdMovie.eAssets.none)
 }}}

 After processing the POST request, form.has_changed() is always true in
 view.py:

 {{{
 >fmForm=fmMovie(vRequest.POST, vRequest.FILES or None,
 instance=rcCurrentMovie)
 >fmForm.has_changed()
 True
 >fmForm.changed_data
 ['eAsset']
 }}}

 Links:
 - I've found an old ticket #22097 and it looks to me like this nine year
 old bug has shown its ugly face again.
 - On Stackoverflow someone reported the same problem.
 [https://stackoverflow.com/questions/68763230/django-forms-a-dynamic-
 integer-model-choice-field-always-fails-form-has-changed|A dynamic integer
 model choice field always fails form.has_changed()]

--

-- 
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 

[Django] #34711: form.has_changed() is always True for IntegerChoices Enum Model Field

[Django]

#34711: form.has_changed() is always True for IntegerChoices Enum Model Field
--+
   Reporter:  GHPS|  Owner:  nobody
   Type:  Bug | Status:  new
  Component:  Forms   |Version:  4.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   |
--+
 Summary:

 While trying to find out why the forms in two different applications are
 marked for saving even if no field has been changed, I could pin the
 problem down
 to the integer enum fields used in both models and form.ChoiceField
 involved.
 In short form.has_changed() is triggered because of a double data
 conversion
 during the round-trip.

 The value of the integer enum field is converted to a string and rendered.
 The POST request comes back with this string which gets compared to the
 original
 enum integer which shows that they are different. During the - unnecessary
 - saving
 the string becomes an int again - which is why the original problem is
 hidden
 from the perspective of a user.

 Background:

 In Django 4.2 on Linux (Kubuntu 22.04) take the following enum and
 create a model field in model.py:

 {{{
 class eAssets(models.IntegerChoices):
 dvd   =1, _('DVD')
 bluray=3, _('Blu-ray')
 none  =0, _('-')

 eAsset=models.PositiveSmallIntegerField(choices=eAssets.choices,
 default=eAssets.none)
 }}}


 Create a choice form field in form.py:

 {{{
 eAsset=forms.ChoiceField(label=mdMovie._meta.get_field('eAsset').verbose_name,
 choices=[(dcEntry.value, dcEntry.label) for dcEntry in mdMovie.eAssets],
   initial=mdMovie.eAssets.none)

 After processing the POST request, form.has_changed() is always true in
 view.py:

 >fmForm=fmMovie(vRequest.POST, vRequest.FILES or None,
 instance=rcCurrentMovie)
 >fmForm.has_changed()
 True
 >fmForm.changed_data
 ['eAsset']
 }}}

 Links:
 - I've found an old ticket #22097 and it looks to me like this nine year
 old bug has shown its ugly face again.
 - On Stackoverflow someone reported the same problem.
 [https://stackoverflow.com/questions/68763230/django-forms-a-dynamic-
 integer-model-choice-field-always-fails-form-has-changed|A dynamic integer
 model choice field always fails form.has_changed()]

-- 
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/0107018955ad1a4c-3fa767c7-5973-4998-85c5-39c1aae5ac45-00%40eu-central-1.amazonses.com.

Re: [Django] #22097: IntegerField with given choices leads to wrong has_changed() work

[Django]

#22097: IntegerField with given choices leads to wrong has_changed() work
-+
 Reporter:  igor.mitrenko@…  |Owner:  Claude Paroz
 Type:  Bug  |   Status:  closed
Component:  Forms|  Version:  1.7-alpha-1
 Severity:  Release blocker  |   Resolution:  fixed
 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 Mariusz Felisiak):

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


Comment:

 GHPS, please don't reopen old already fixed issue. If you believe it's an
 issue in Django, then please create a new ticket in Trac and follow our
 [https://docs.djangoproject.com/en/dev/internals/contributing/bugs-and-
 features/#reporting-bugs bug reporting guidelines].

-- 
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/01070189557334b0-97d42d84-17d5-4d65-b533-ce439dc6f2cc-00%40eu-central-1.amazonses.com.

Re: [Django] #22097: IntegerField with given choices leads to wrong has_changed() work

[Django]

#22097: IntegerField with given choices leads to wrong has_changed() work
-+
 Reporter:  igor.mitrenko@…  |Owner:  Claude Paroz
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  4.2
 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 GHPS):

 * cc: GHPS (added)
 * version:  1.7-alpha-1 => 4.2


-- 
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/01070189554bee99-52ac6354-5881-4083-9f1b-5d12152410f2-00%40eu-central-1.amazonses.com.

Re: [Django] #22097: IntegerField with given choices leads to wrong has_changed() work

[Django]

#22097: IntegerField with given choices leads to wrong has_changed() work
-+
 Reporter:  igor.mitrenko@…  |Owner:  Claude Paroz
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  1.7-alpha-1
 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 GHPS):

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


Comment:

 Summary:

 While trying to find out why the forms in two different applications are
 marked for saving even if no field has been changed, I could pin the
 problem down
 to the integer enum fields used in both models and form.ChoiceField
 involved.
 In short form.has_changed() is triggered because of a double data
 conversion
 during the round-trip.

 The value of the integer enum field is converted to a string and rendered.
 The POST request comes back with this string which gets compared to the
 original
 enum integer which shows that they are different. During the - unnecessary
 - saving
 the string becomes an int again - which is why the original problem is
 hidden
 from the perspective of a user.

 I found this old ticket and it looks to me like the nine year old bug has
 shown its ugly face again.

 Background:

 Take the following enum and create a model field in model.py:

 {{{

 class eAssets(models.IntegerChoices):
 dvd   =1, _('DVD')
 bluray=3, _('Blu-ray')
 none  =0, _('-')

 eAsset=models.PositiveSmallIntegerField(choices=eAssets.choices,
 default=eAssets.none)
 }}}


 Create a choice form field in form.py:

 {{{

 eAsset=forms.ChoiceField(label=mdMovie._meta.get_field('eAsset').verbose_name,
 choices=[(dcEntry.value, dcEntry.label) for dcEntry in mdMovie.eAssets],
   initial=mdMovie.eAssets.none)

 After processing the POST request, form.has_changed() is always true in
 view.py:

 fmForm=fmMovie(vRequest.POST, vRequest.FILES or None,
 instance=rcCurrentMovie)
 fmForm.has_changed()
 True
 fmForm.changed_data
 ['eAsset']
 }}}


 Links:
 On Stackoverflow someone reported the same problem.
 [https://stackoverflow.com/questions/68763230/django-forms-a-dynamic-
 integer-model-choice-field-always-fails-form-has-changed|A dynamic integer
 model choice field always fails form.has_changed()]

-- 
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/010701895541de0b-303ed10e-39e1-49c8-8814-dc8f3f38b037-00%40eu-central-1.amazonses.com.

Re: [Django] #34262: Queryset grouped by annotation with aggregates on another annotated expression crashes on MySQL with sql_mode=only_full_group_by.

[Django]

#34262: Queryset grouped by annotation with aggregates on another annotated
expression crashes on MySQL with sql_mode=only_full_group_by.
-+-
 Reporter:  Mariusz Felisiak |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  4.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  mysql| Triage Stage:  Accepted
  only_full_group_by |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak):

 Replying to [comment:5 Amir Karimi]:
 > I'm curios to know what happened with this issue. Any updates?

 Feel-free to work on this issue. Please don't leave comments like `any
 updates?` they don't help and cause unnecessary noise to the history.

-- 
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/0107018955274555-b7a5b882-a5da-4ddc-9515-a2c29e585aa6-00%40eu-central-1.amazonses.com.

Re: [Django] #34692: django.forms.renderers.get_default_renderer()'s template loader cache is not being reset on autoloads.

[Django]

#34692: django.forms.renderers.get_default_renderer()'s template loader cache is
not being reset on autoloads.
+
 Reporter:  Andrew  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Forms   |  Version:  4.2
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Accepted
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+

Comment (by Mariusz Felisiak):

 Replying to [comment:5 Amir Karimi]:
 > It seems if we don't want to add some codes like the above, we have to
 change the flow of creation of the default renderer's engine. The default
 engine is not included in the
 > {{{
 > engines.all()
 > }}}
 >
 > @MariuszFelisiak
 > Do you think it is worth changing the flow? I suggest letting it be
 solved in the simplest way.

 I'm not sure what are you proposing. We didn't reject any proposition.

-- 
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/0107018955258620-92b0c156-3065-400f-ac10-ca1fe8abea30-00%40eu-central-1.amazonses.com.

Re: [Django] #34262: Queryset grouped by annotation with aggregates on another annotated expression crashes on MySQL with sql_mode=only_full_group_by.

[Django]

#34262: Queryset grouped by annotation with aggregates on another annotated
expression crashes on MySQL with sql_mode=only_full_group_by.
-+-
 Reporter:  Mariusz Felisiak |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  4.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  mysql| Triage Stage:  Accepted
  only_full_group_by |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Amir Karimi):

 Replying to [comment:4 Simon Charette]:
 > Thanks for the analysis David, option 1. and 2. were also the conclusion
 of [https://github.com/django/django/pull/16460#discussion_r1071497499 my
 limited investigation on the subject] so it's great to have cross peer
 validation on the subject.
 >
 > I think there might be a way to implement 3. by reusing
 
[https://github.com/django/django/blob/d3c93cdc597e0efc2815111c04dd5a427432ed37/django/db/models/sql/compiler.py#L669-L680
 some of the logic used to implement masking of columns when filtering
 against window functions] which requires two level of subquery wrapping.
 >
 > A different of approaching 3. is to think that any form of ''masking''
 of annotations/aliases used for grouping purposes would result in a
 subquery pushdown. So to reuse your example, instead of performing a
 subquery pushdown to compute expressions used with aggregate queries we'd
 do it the other way around to have MySQL group against top level `SELECT`
 expressions which it's good at inferring dependencies from
 >
 > {{{#!sql
 > SELECT LEAST(min_pages, greatest_pages) AS `least` FROM (
 >   SELECT
 > GREATEST(`aggregation_book`.`pages`, 600) greatest_pages,
 > MIN(`aggregation_book`.`pages`) min_pages
 >   FROM `aggregation_book`
 >   GROUP BY 1 ORDER BY NULL
 > ) masked
 > }}}
 >
 > This should reduce the area of impact of this change to aggregating
 queries that group against a value that isn't explicitly selected and
 would also happen to solve the last remaining known issue with using
 server-side parameters binding for Postgres (#34255).

 I'm curios to know what happened with this issue. Any updates?

-- 
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/0107018954ec968d-d02aff38-0f76-49df-a6fd-987e1495873d-00%40eu-central-1.amazonses.com.

Re: [Django] #30746: Add Permissions-Policy (was Feature-Policy) header support.

[Django]

#30746: Add Permissions-Policy (was Feature-Policy) header support.
-+-
 Reporter:  Nick Pope|Owner:  (none)
 Type:  New feature  |   Status:  new
Component:  Utilities|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  feature-policy,  | Triage Stage:
  permissions-policy |  Someday/Maybe
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Nick Pope):

 * owner:  Nick Pope => (none)
 * status:  assigned => new


Comment:

 See [https://github.com/django/django/pull/11735#issuecomment-1635949403
 my comment] on the PR.

 This basically isn't progressing very quickly right now and much still
 seems to be in flux.

 If and when things progress/stabilize, we can revisit this.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018954cfd74f-5923f3ae-166b-453d-b68b-64ae1fd48529-00%40eu-central-1.amazonses.com.

Re: [Django] #34060: Creating CheckConstraint on JSONField with __exact lookup on key transforms crashes on Oracle.

[Django]

#34060: Creating CheckConstraint on JSONField with __exact lookup on key 
transforms
crashes on Oracle.
-+-
 Reporter:  Mariusz Felisiak |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  4.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  Oracle   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Amir Karimi):

 Replying to [comment:5 r4ge]:
 > No, Trying to setup the oracle once done will update if I found the
 solution.
 How's it going with this issue? Have you got it done?

-- 
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/01070189548a3d33-ee7abbf4-cf98-4952-8624-5185ce3a1bd6-00%40eu-central-1.amazonses.com.

Re: [Django] #34692: django.forms.renderers.get_default_renderer()'s template loader cache is not being reset on autoloads.

[Django]

#34692: django.forms.renderers.get_default_renderer()'s template loader cache is
not being reset on autoloads.
+
 Reporter:  Andrew  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Forms   |  Version:  4.2
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Accepted
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+

Comment (by Amir Karimi):

 It seems if we don't want to add some codes like the above, we have to
 change the flow of creation of the default renderer's engine. The default
 engine is not included in the
 {{{
 engines.all()
 }}}

 @MariuszFelisiak
 Do you think it is worth changing the flow? I suggest letting it be solved
 in the simplest way.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/01070189548132c1-265f44ef-09bc-464d-a778-5ff4cb86727e-00%40eu-central-1.amazonses.com.

Re: [Django] #33647: bulk_update silently truncating values for size limited fields

[Django]

#33647: bulk_update silently truncating values for size limited fields
-+-
 Reporter:  jerch|Owner:  danhamilt
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  4.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by danhamilt):

 * owner:  nobody => danhamilt
 * 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/0107018954720458-a7a97337-74dd-415c-85ac-824b6b8e6b89-00%40eu-central-1.amazonses.com.

Re: [Django] #34677: Django Admin built-in password reset feature has UI issues

[Django]

#34677: Django Admin built-in password reset feature has UI issues
-+-
 Reporter:  Yaniv Toledano   |Owner:  Priyank
 Type:   |  Panchal
  Cleanup/optimization   |   Status:  closed
Component:  contrib.admin|  Version:  4.2
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  1
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"0016a4299569a8f09ff24053ff2b8224f7fa4113" 0016a429]:
 {{{
 #!CommitTicketReference repository=""
 revision="0016a4299569a8f09ff24053ff2b8224f7fa4113"
 Fixed #34677 -- Made admin password reset templates more consistent.
 }}}

-- 
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/0107018954175c2d-a230ec0f-ada3-4d6c-9884-2113fdcbdc27-00%40eu-central-1.amazonses.com.

Re: [Django] #34413: Variant of Prefetch but for the earliest/latest related object

[Django]

#34413: Variant of Prefetch but for the earliest/latest related object
-+-
 Reporter:  Willem Van Onsem |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Gordon Wrigley):

 I would like to do singular prefetches, which seems kinda like what this
 is asking for.

 With regard to:
 {{{#!python
 User.objects.prefetch_related(
 Prefetch("groups", queryset=Group.objects.order_by('name')[:1],
 to_attr="first_group")
 )
 }}}

 The downside of this is "first_group" is actually a 1 element list. I was
 imagining maybe it could be just the item when there is a single item
 slice, or failing that a "flat=True" option on Prefetch.

-- 
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/0107018953ebe464-449ef409-248b-4880-96bd-e6108b525eac-00%40eu-central-1.amazonses.com.

Re: [Django] #34677: Django Admin built-in password reset feature has UI issues

[Django]

#34677: Django Admin built-in password reset feature has UI issues
-+-
 Reporter:  Yaniv Toledano   |Owner:  Priyank
 Type:   |  Panchal
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.admin|  Version:  4.2
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  1
-+-
Changes (by Mariusz Felisiak):

 * stage:  Accepted => Ready for checkin


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018953ddf607-8ae5cde5-adb9-4069-bedb-bf2e3d4a78f6-00%40eu-central-1.amazonses.com.

Re: [Django] #34677: Django Admin built-in password reset feature has UI issues

[Django]

#34677: Django Admin built-in password reset feature has UI issues
-+-
 Reporter:  Yaniv Toledano   |Owner:  Priyank
 Type:   |  Panchal
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.admin|  Version:  4.2
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  1
-+-
Changes (by Priyank Panchal):

 * needs_better_patch:  1 => 0


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018953ca5357-f2841549-3ccd-4157-9e9c-cbc65db0d248-00%40eu-central-1.amazonses.com.

Re: [Django] #30686: Improve utils.text.Truncator to use a full HTML parser.

[Django]

#30686: Improve utils.text.Truncator  to use a full HTML parser.
---+---
 Reporter:  Thomas Hooper  |Owner:  David Smith
 Type:  Bug|   Status:  assigned
Component:  Utilities  |  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
---+---

Comment (by Mariusz Felisiak ):

 In [changeset:"6f1b8c00d8151059cc1902a92f067bbdc1673779" 6f1b8c00]:
 {{{
 #!CommitTicketReference repository=""
 revision="6f1b8c00d8151059cc1902a92f067bbdc1673779"
 Refs #30686 -- Moved add_truncation_text() helper to a module level.
 }}}

-- 
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/0107018953b6ef1a-d68776b7-8053-4f13-9fc8-0f70e2bbefcf-00%40eu-central-1.amazonses.com.

Re: [Django] #30686: Improve utils.text.Truncator to use a full HTML parser.

[Django]

#30686: Improve utils.text.Truncator  to use a full HTML parser.
---+---
 Reporter:  Thomas Hooper  |Owner:  David Smith
 Type:  Bug|   Status:  assigned
Component:  Utilities  |  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
---+---

Comment (by Mariusz Felisiak ):

 In [changeset:"1d0dfc0b920916900d2770f3b5640da08af36d97" 1d0dfc0]:
 {{{
 #!CommitTicketReference repository=""
 revision="1d0dfc0b920916900d2770f3b5640da08af36d97"
 Refs #30686 -- Moved Parser.SELF_CLOSING_TAGS to
 django.utils.html.VOID_ELEMENTS
 }}}

-- 
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/0107018953b6ef35-3a918a17-7dc5-40d9-9777-237132c29bda-00%40eu-central-1.amazonses.com.

Re: [Django] #34448: makemessages' --no-obsolete option is undocumented and untested.

[Django]

#34448: makemessages' --no-obsolete option is undocumented and untested.
-+-
 Reporter:  Tom Sparrow  |Owner:  Tushar
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Core (Management |  Version:  4.1
  commands)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"88a2de3c3906f5acc14bb68e98c128fc13f2f1ae" 88a2de3c]:
 {{{
 #!CommitTicketReference repository=""
 revision="88a2de3c3906f5acc14bb68e98c128fc13f2f1ae"
 Fixed #34448 -- Doc'd and tested --no-obsolete option of makemessages.

 Co-authored-by: Mariusz Felisiak 
 }}}

-- 
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/01070189536bb265-3ea11c05-2ae6-46d0-9255-c01e3fc28e15-00%40eu-central-1.amazonses.com.

Re: [Django] #30686: Improve utils.text.Truncator to use a full HTML parser.

[Django]

#30686: Improve utils.text.Truncator  to use a full HTML parser.
---+---
 Reporter:  Thomas Hooper  |Owner:  David Smith
 Type:  Bug|   Status:  assigned
Component:  Utilities  |  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):

 * needs_better_patch:  1 => 0


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018953677d27-053d1ce8-6c90-4d64-80ab-5adf6fd151d0-00%40eu-central-1.amazonses.com.

Re: [Django] #34677: Django Admin built-in password reset feature has UI issues

[Django]

#34677: Django Admin built-in password reset feature has UI issues
-+-
 Reporter:  Yaniv Toledano   |Owner:  Priyank
 Type:   |  Panchal
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.admin|  Version:  4.2
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  1
-+-
Changes (by Mariusz Felisiak):

 * needs_tests:  1 => 0


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/01070189534e48c8-45a1995e-b101-4fd9-8f1c-58e4a187bf70-00%40eu-central-1.amazonses.com.

Re: [Django] #34448: makemessages' --no-obsolete option is undocumented and untested.

[Django]

#34448: makemessages' --no-obsolete option is undocumented and untested.
-+-
 Reporter:  Tom Sparrow  |Owner:  Tushar
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Core (Management |  Version:  4.1
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * needs_better_patch:  1 => 0
 * stage:  Accepted => Ready for checkin


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/01070189532b3df9-d86cb413-fc4f-4510-8c0b-d185244ccc3d-00%40eu-central-1.amazonses.com.

Re: [Django] #34677: Django Admin built-in password reset feature has UI issues

[Django]

#34677: Django Admin built-in password reset feature has UI issues
-+-
 Reporter:  Yaniv Toledano   |Owner:  Priyank
 Type:   |  Panchal
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.admin|  Version:  4.2
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  1
-+-
Changes (by Priyank Panchal):

 * needs_docs:  1 => 0


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/01070189531ab9f0-31cc2a5f-fadd-4228-8ad2-728a6613b595-00%40eu-central-1.amazonses.com.