Re: [Django] #34832: Use `banner` landmark or `` element for the admin header area

[Django]

#34832: Use `banner` landmark or `` element for the admin header area
-+-
 Reporter:  Thibaud Colas|Owner:  Sarah
 Type:   |  Abderemane
  Cleanup/optimization   |   Status:  closed
Component:  contrib.admin|  Version:  4.2
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  accessibility,   | Triage Stage:  Ready for
  screen reader, landmarks   |  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:"814e7bc22062eeae4be9f189e89027e28d5dd290" 814e7bc]:
 {{{
 #!CommitTicketReference repository=""
 revision="814e7bc22062eeae4be9f189e89027e28d5dd290"
 Fixed #34832 -- Made admin's header content render in  tag.

 Header tag was changed to  get the landmark banner for
 accessibility.
 }}}

-- 
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/0107018a970c218c-82a3f574-0097-49ac-998e-dd3d30d1a03b-00%40eu-central-1.amazonses.com.

Re: [Django] #34832: Use `banner` landmark or `` element for the admin header area

[Django]

#34832: Use `banner` landmark or `` element for the admin header area
-+-
 Reporter:  Thibaud Colas|Owner:  Sarah
 Type:   |  Abderemane
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.admin|  Version:  4.2
 Severity:  Normal   |   Resolution:
 Keywords:  accessibility,   | Triage Stage:  Ready for
  screen reader, landmarks   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  1
-+-
Changes (by Mariusz Felisiak):

 * needs_docs:  1 => 0
 * needs_tests:  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/0107018a96e893ee-8211cfab-e7d5-47ac-89b6-4752132581d7-00%40eu-central-1.amazonses.com.

Re: [Django] #34840: Django 4.2 casts text fields when testing IS NULL, preventing use of partial indexes

[Django]

#34840: Django 4.2 casts text fields when testing IS NULL, preventing use of
partial indexes
-+-
 Reporter:  Alex Vandiver|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  4.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
-+-

Comment (by Mariusz Felisiak):

 Replying to [comment:5 Simon Charette]:
 > What do you think of making the casting conditional to the enablement of
 the `server_side_binding` option in this case?

 Yeah, I was thinking the same thing. This is probably the only reasonable
 option we have.

-- 
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/0107018a96d3f022-caf1fd8c-2e42-4e82-8ee8-3a2e6094f8ce-00%40eu-central-1.amazonses.com.

Re: [Django] #34840: Django 4.2 casts text fields when testing IS NULL, preventing use of partial indexes

[Django]

#34840: Django 4.2 casts text fields when testing IS NULL, preventing use of
partial indexes
-+-
 Reporter:  Alex Vandiver|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  4.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):

 * cc: Simon Charette (added)


Comment:

 What do you think of making the casting conditional to the enablement of
 the `server_side_binding` option in this case?

 That would contain the issue to the already existing buckets or problems
 that come with enabling this option that we're already aware of (e.g.
 grouping by parameterized annotation).

 Happy to prepare a patch if you believe that it's worth pursuing.

-- 
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/0107018a95cbabec-560fca90-4f7c-4879-8350-26fe19de5afb-00%40eu-central-1.amazonses.com.

Re: [Django] #34838: GeoDjango database functions incompatible with GeneratedField

[Django]

#34838: GeoDjango database functions incompatible with GeneratedField
-+-
 Reporter:  Paolo Melchiorre |Owner:  Paolo
 |  Melchiorre
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  field, database, | Triage Stage:  Ready for
  generated, output_field|  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:"68d769e691eb0d765228defddb3ba982eabdc761" 68d769e6]:
 {{{
 #!CommitTicketReference repository=""
 revision="68d769e691eb0d765228defddb3ba982eabdc761"
 Fixed #34838 -- Corrected output_field of resolved columns for
 GeneratedFields.

 Thanks Simon Charette for the implementation idea.
 }}}

-- 
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/0107018a954ac653-1604f00e-f9e6-4390-9d90-4a9fef822169-00%40eu-central-1.amazonses.com.

Re: [Django] #34838: GeoDjango database functions incompatible with GeneratedField

[Django]

#34838: GeoDjango database functions incompatible with GeneratedField
-+-
 Reporter:  Paolo Melchiorre |Owner:  Paolo
 |  Melchiorre
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  field, database, | Triage Stage:  Ready for
  generated, output_field|  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
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/0107018a95212b76-656c4c41-f0c5-441a-bcdc-8928b421dc3f-00%40eu-central-1.amazonses.com.

Re: [Django] #34834: Use `search` role for the admin changelist search form

[Django]

#34834: Use `search` role for the admin changelist search form
-+-
 Reporter:  Thibaud Colas|Owner:  Lemuel
 Type:   |  Sta Ana
  Cleanup/optimization   |   Status:  closed
Component:  contrib.admin|  Version:  4.2
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  accessibility,   | Triage Stage:  Ready for
  screen reader, landmarks   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"969ecb8236f033d183108fb28849974da188da50" 969ecb82]:
 {{{
 #!CommitTicketReference repository=""
 revision="969ecb8236f033d183108fb28849974da188da50"
 Fixed #34834 -- Added role="search" to the admin changelist search form.
 }}}

-- 
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/0107018a951ea844-6db5c87e-fd59-4357-b7c8-8bf303ec96cf-00%40eu-central-1.amazonses.com.

Re: [Django] #34834: Use `search` role for the admin changelist search form

[Django]

#34834: Use `search` role for the admin changelist search form
-+-
 Reporter:  Thibaud Colas|Owner:  Lemuel
 Type:   |  Sta Ana
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.admin|  Version:  4.2
 Severity:  Normal   |   Resolution:
 Keywords:  accessibility,   | Triage Stage:  Ready for
  screen reader, landmarks   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * needs_tests:  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/0107018a94fd2e1e-8fa9a092-870f-4764-a283-24995512d823-00%40eu-central-1.amazonses.com.

Re: [Django] #34841: Reverse migrations model state rendering slow with moderate to large migrations

[Django]

#34841: Reverse migrations model state rendering slow with moderate to large
migrations
-+-
 Reporter:  David Sanders|Owner:  David
 Type:   |  Sanders
  Cleanup/optimization   |   Status:  assigned
Component:  Migrations   |  Version:  4.2
 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
-+-
Changes (by David Sanders):

 * owner:  nobody => David Sanders
 * 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/0107018a94dd13b2-eb46ecb2-2561-40ad-9a3d-1f067bc6e3dc-00%40eu-central-1.amazonses.com.

[Django] #34841: Reverse migrations model state rendering slow with moderate to large migrations

[Django]

#34841: Reverse migrations model state rendering slow with moderate to large
migrations
+
   Reporter:  David Sanders |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Migrations|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 |
+
 Relevant discussion: https://forum.djangoproject.com/t/migrating-
 backwards-takes-orders-of-magnitude-longer-than-migrating-forwards/20873/2

 Investigations revealed 2 things.

 1. this block of code in `db/migrations/excecutor.py` was responsible for
 a large portion of processing time:
 
https://github.com/django/django/blob/b8b2f7451201f3ff60891b6ce55f177400700d7a/django/db/migrations/executor.py#L222-L232

 In my small project with only a moderate number of migrations, a simple
 reverse migrate of the last migration on the main app took ~20s. The block
 below was responsible for ~16s.

 {{{
 # Generate the post migration state by starting from the state
 before
 # the last migration is unapplied and mutating it to include all
 the
 # remaining applied migrations.
 last_unapplied_migration = plan[-1][0]
 state = states[last_unapplied_migration]
 for index, (migration, _) in enumerate(full_plan):
 if migration == last_unapplied_migration:
 for migration, _ in full_plan[index:]:
 if migration in applied_migrations:
 migration.mutate_state(state, preserve=False)
 break
 }}}

 2. these 2 lines appeared to be responsible for the slowdown, commenting
 them out made the block above run almost instantly:
 
https://github.com/django/django/blob/b8b2f7451201f3ff60891b6ce55f177400700d7a/django/db/migrations/executor.py#L203-L204

 {{{
 if "apps" not in state.__dict__:
 state.apps  # Render all -- performance critical
 }}}

 I have a small patch to move record the unapplied state before these 2
 lines and clone it, removing the `state.apps` attribute.

-- 
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/0107018a94dcdbae-91edbd0a-bdbe-4fb9-bb1e-d38a5a281415-00%40eu-central-1.amazonses.com.

Re: [Django] #15619: Logout link should be protected

[Django]

#15619: Logout link should be protected
-+-
 Reporter:  Alexey Boriskin  |Owner:  René
 Type:   |  Fleschenberg
  Cleanup/optimization   |   Status:  closed
Component:  contrib.auth |  Version:  dev
 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
-+-

Comment (by GitHub ):

 In [changeset:"e2a3a896cf0825a2da2347773c79ba7a341fe392" e2a3a896]:
 {{{
 #!CommitTicketReference repository=""
 revision="e2a3a896cf0825a2da2347773c79ba7a341fe392"
 Refs #15619 -- Removed deprecated annotation about logging out via GET
 requests.

 Follow up to 6c57c08ae52f86df843fccb5a3c1c6c45a10a26f.
 }}}

-- 
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/0107018a94cfae21-f611b0f6-bdc0-4027-a3de-589c588797c9-00%40eu-central-1.amazonses.com.

Re: [Django] #34840: Django 4.2 casts text fields when testing IS NULL, preventing use of partial indexes

[Django]

#34840: Django 4.2 casts text fields when testing IS NULL, preventing use of
partial indexes
-+-
 Reporter:  Alex Vandiver|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  4.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
-+-

Comment (by Mariusz Felisiak):

 Replying to [comment:3 Simon Charette]:
 > Any thoughts here Florian and Mariusz?

 I'd prefer to avoid casting, however, it is necessary when server-side
 binding is enabled.

-- 
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/0107018a94ce2295-79ef4b02-23ca-497f-afe5-9bf8da1e73c1-00%40eu-central-1.amazonses.com.

Re: [Django] #24561: Allow model field choices to accept callables.

[Django]

#24561: Allow model field choices to accept callables.
-+-
 Reporter:  Christopher Grebs|Owner:  Natalia
 |  Bidart
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Natalia Bidart):

 * 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/0107018a9473173b-b2a2055b-5169-4885-998d-3436571c7a08-00%40eu-central-1.amazonses.com.

Re: [Django] #34834: Use `search` role for the admin changelist search form

[Django]

#34834: Use `search` role for the admin changelist search form
-+-
 Reporter:  Thibaud Colas|Owner:  Lemuel
 Type:   |  Sta Ana
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.admin|  Version:  4.2
 Severity:  Normal   |   Resolution:
 Keywords:  accessibility,   | Triage Stage:  Accepted
  screen reader, landmarks   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Lemuel Sta Ana):

 Regression test added as per
 
[https://github.com/django/django/pull/17261/commits/393b524e0ddb974995cc1c3f5ab9851cf44f958d
 commit]

-- 
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/0107018a947307a1-f849f1a9-9899-4867-857c-5b9407c74a8f-00%40eu-central-1.amazonses.com.

Re: [Django] #34840: Django 4.2 casts text fields when testing IS NULL, preventing use of partial indexes

[Django]

#34840: Django 4.2 casts text fields when testing IS NULL, preventing use of
partial indexes
-+-
 Reporter:  Alex Vandiver|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  4.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):

 * cc: Florian Apolloner, Mariusz Felisiak (added)


Comment:

 > This also means that there's a bit of a pickle -- you can't just strip
 off the ::text in the query in some later 4.2 bugfix release, because that
 will also make any 4.2-inserted indexes with ::text not work with the
 newly ::text-less query.

 Right, that's what I feared. I think we should favour reverting to the
 previous behaviour if possible though as there are likely to be more
 constraints created prior to 4.2 in the wild than after even at this
 point. This is definitely something that should be mentioned in the
 release notes though.

 Any thoughts here Florian and Mariusz?

-- 
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/0107018a945588ac-90149e7c-a856-41ab-892c-ef63edc72b4b-00%40eu-central-1.amazonses.com.

Re: [Django] #34789: `filter_horizontal` duplicates entries in "Chosen" column after instance is added via in another field using the "plus" JS action

[Django]

#34789: `filter_horizontal` duplicates entries in "Chosen" column after 
instance is
added via in another field using the "plus" JS action
---+
 Reporter:  devin13cox |Owner:  yokeshwaran1
 Type:  Bug|   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 Natalia Bidart):

 * needs_better_patch:  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/0107018a9417b018-3f8a0a23-e03e-4cfd-bd85-68253fbf4e07-00%40eu-central-1.amazonses.com.

Re: [Django] #34840: Django 4.2 casts text fields when testing IS NULL, preventing use of partial indexes

[Django]

#34840: Django 4.2 casts text fields when testing IS NULL, preventing use of
partial indexes
-+-
 Reporter:  Alex Vandiver|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  4.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
-+-

Comment (by Alex Vandiver):

 Yes, the indexes as created on 4.2 ''do'' have the cast in them.  The diff
 of our schema across the 4.2 upgrade is:
 {{{
 $ diff -U0 <(rg -U '(?s)CREATE[^;]*;' before.sql) <(rg -U
 '(?s)CREATE[^;]*;' after.sql)
 --- /dev/fd/63  2023-09-13 12:55:09.595790167 -0700
 +++ /dev/fd/62  2023-09-13 12:55:09.595790167 -0700
 @@ -1095,4 +1095,4 @@
 -CREATE UNIQUE INDEX unique_installation_count ON
 zulip.analytics_installationcount USING btree (property, subgroup,
 end_time) WHERE (subgroup IS NOT NULL);
 -CREATE UNIQUE INDEX unique_installation_count_null_subgroup ON
 zulip.analytics_installationcount USING btree (property, end_time) WHERE
 (subgroup IS NULL);
 -CREATE UNIQUE INDEX unique_realm_count ON zulip.analytics_realmcount
 USING btree (realm_id, property, subgroup, end_time) WHERE (subgroup IS
 NOT NULL);
 -CREATE UNIQUE INDEX unique_realm_count_null_subgroup ON
 zulip.analytics_realmcount USING btree (realm_id, property, end_time)
 WHERE (subgroup IS NULL);
 +CREATE UNIQUE INDEX unique_installation_count ON
 zulip.analytics_installationcount USING btree (property, subgroup,
 end_time) WHERE ((subgroup)::text IS NOT NULL);
 +CREATE UNIQUE INDEX unique_installation_count_null_subgroup ON
 zulip.analytics_installationcount USING btree (property, end_time) WHERE
 ((subgroup)::text IS NULL);
 +CREATE UNIQUE INDEX unique_realm_count ON zulip.analytics_realmcount
 USING btree (realm_id, property, subgroup, end_time) WHERE
 ((subgroup)::text IS NOT NULL);
 +CREATE UNIQUE INDEX unique_realm_count_null_subgroup ON
 zulip.analytics_realmcount USING btree (realm_id, property, end_time)
 WHERE ((subgroup)::text IS NULL);
 @@ -1100,4 +1100,4 @@
 -CREATE UNIQUE INDEX unique_stream_count ON zulip.analytics_streamcount
 USING btree (stream_id, property, subgroup, end_time) WHERE (subgroup IS
 NOT NULL);
 -CREATE UNIQUE INDEX unique_stream_count_null_subgroup ON
 zulip.analytics_streamcount USING btree (stream_id, property, end_time)
 WHERE (subgroup IS NULL);
 -CREATE UNIQUE INDEX unique_user_count ON zulip.analytics_usercount USING
 btree (user_id, property, subgroup, end_time) WHERE (subgroup IS NOT
 NULL);
 -CREATE UNIQUE INDEX unique_user_count_null_subgroup ON
 zulip.analytics_usercount USING btree (user_id, property, end_time) WHERE
 (subgroup IS NULL);
 +CREATE UNIQUE INDEX unique_stream_count ON zulip.analytics_streamcount
 USING btree (stream_id, property, subgroup, end_time) WHERE
 ((subgroup)::text IS NOT NULL);
 +CREATE UNIQUE INDEX unique_stream_count_null_subgroup ON
 zulip.analytics_streamcount USING btree (stream_id, property, end_time)
 WHERE ((subgroup)::text IS NULL);
 +CREATE UNIQUE INDEX unique_user_count ON zulip.analytics_usercount USING
 btree (user_id, property, subgroup, end_time) WHERE ((subgroup)::text IS
 NOT NULL);
 +CREATE UNIQUE INDEX unique_user_count_null_subgroup ON
 zulip.analytics_usercount USING btree (user_id, property, end_time) WHERE
 ((subgroup)::text IS NULL);
 }}}

 So if the application's schema was inserted with 4.2, then its partial
 indexes work with the current code.  If it was inserted with Django < 4.2,
 then the indexes don't work with >= 4.2.

 This also means that there's a bit of a pickle -- you can't just strip off
 the `::text` in the query in some later 4.2 bugfix release, because that
 will also make any 4.2-inserted indexes with `::text` not work with the
 newly `::text`-less query.

 Replying to [comment:1 Simon Charette]:
 > We should try to avoid casts if possible (IIRC they are only required
 for server-side bindings).
 >
 > Out of curiosity, if you try re-creating your `UniqueConstraint` on 4.2,
 are they created with casts? By that I'm in no mean implying that a
 solution to this problem is to force the re-creation of constraints on
 each releases but I want to have an idea of the scope of the problem.
 >
 > If that's the case it means that reverting to no cast in a minor release
 might break Postgres query planer the other way around as constraint
 created on 4.2 include `::text` cast but queries on a future version
 removing them don't.

-- 
Ticket URL: 

Re: [Django] #24561: Allow model field choices to accept callables.

[Django]

#24561: Allow model field choices to accept callables.
-+-
 Reporter:  Christopher Grebs|Owner:  Natalia
 |  Bidart
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Natalia <124304+nessita@…>):

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


Comment:

 In [changeset:"691f70c47755c7f55fa75ce607d028f81468b745" 691f70c]:
 {{{
 #!CommitTicketReference repository=""
 revision="691f70c47755c7f55fa75ce607d028f81468b745"
 Fixed #24561 -- Added support for callables on model fields' choices.
 }}}

-- 
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/0107018a9407ed76-aacde051-338a-493e-82f5-95c040c6a22e-00%40eu-central-1.amazonses.com.

Re: [Django] #34838: GeoDjango database functions incompatible with GeneratedField

[Django]

#34838: GeoDjango database functions incompatible with GeneratedField
-+-
 Reporter:  Paolo Melchiorre |Owner:  Paolo
 |  Melchiorre
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  field, database, | Triage Stage:  Accepted
  generated, output_field|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Simon Charette):

 * keywords:  field, database, generated, gis, feodjango => field, database,
 generated, output_field
 * component:  GIS => Database layer (models, ORM)


-- 
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/0107018a93cffc58-062bd0bb-aadc-49b6-81ae-af8c99a07bd3-00%40eu-central-1.amazonses.com.

Re: [Django] #34831: Search in admin could allow issuing a query with many OR'd clauses

[Django]

#34831: Search in admin could allow issuing a query with many OR'd clauses
--+
 Reporter:  Natalia Bidart|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  contrib.admin |  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
--+

Comment (by Yves Weissig):

 Happy to have a look at this Natalia Bidart.

 Is limiting the amount of OR terms the agreed upon solution? Is there a
 discussion in the forum I'm missing?

-- 
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/0107018a931eece1-722e579e-a560-44f7-82b2-3a4f6958bf74-00%40eu-central-1.amazonses.com.

Re: [Django] #15881: FilteredSelectMultiple does not respect order

[Django]

#15881: FilteredSelectMultiple does not respect order
--+
 Reporter:  bmihelac  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  contrib.admin |  Version:  1.3
 Severity:  Normal|   Resolution:
 Keywords:  javascript| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  1
--+

Comment (by salmawisoky):

 The `FilteredSelectMultiple` widget in Django does not preserve the order
 of selected items by default. It displays the available choices in the
 order they are defined in the queryset, but the selected items are
 displayed in alphabetical order.

 If you want to maintain the order of selected items in the
 `FilteredSelectMultiple` widget, you can override the widget's rendering
 behavior by creating a custom widget that inherits from
 `FilteredSelectMultiple` and overrides the `render_option` method. [https
 ://drift-boss.pro Drift Boss]

 Here's an example of how you can create a custom widget that preserves the
 order of selected items:

 ```python
 from django.contrib.admin.widgets import FilteredSelectMultiple

 class OrderedFilteredSelectMultiple(FilteredSelectMultiple):
 def render_option(self, selected_choices, option_value, option_label):
 option_value = force_text(option_value)
 selected_html = (
 ' selected="selected"' if option_value in selected_choices
 else ''
 )
 return f'{force_text(option_label)}'
 ```

 In this custom widget, the `render_option` method is overridden to remove
 the alphabetical sorting behavior. Instead, it checks if the option value
 is in the selected choices and adds the `selected` attribute accordingly.
 This ensures that the selected items are rendered in the order they appear
 in the selected choices.

 To use this custom widget in your form, specify it as the widget for your
 `MultipleChoiceField`:

 ```python
 from django import forms

 class MyForm(forms.Form):
 my_field = forms.MultipleChoiceField(
 widget=OrderedFilteredSelectMultiple(attrs={'size': 10}),
 choices=my_choices,
 )
 ```

 Replace `my_field` with the name of your field and `my_choices` with the
 choices for your field.

 By using the `OrderedFilteredSelectMultiple` widget instead of the
 standard `FilteredSelectMultiple`, the selected items in the
 `FilteredSelectMultiple` widget will be displayed in the order they were
 selected.

-- 
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/0107018a931839c0-163612c4-ff18-4516-aba6-f14afc488e5c-00%40eu-central-1.amazonses.com.

Re: [Django] #34832: Use `banner` landmark or `` element for the admin header area

[Django]

#34832: Use `banner` landmark or `` element for the admin header area
-+-
 Reporter:  Thibaud Colas|Owner:  Sarah
 Type:   |  Abderemane
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.admin|  Version:  4.2
 Severity:  Normal   |   Resolution:
 Keywords:  accessibility,   | Triage Stage:  Accepted
  screen reader, landmarks   |
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  1
-+-
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/0107018a92eb27aa-838d8a30-67dc-45e4-8123-7fdbf80b3114-00%40eu-central-1.amazonses.com.

Re: [Django] #34834: Use `search` role for the admin changelist search form

[Django]

#34834: Use `search` role for the admin changelist search form
-+-
 Reporter:  Thibaud Colas|Owner:  Lemuel
 Type:   |  Sta Ana
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.admin|  Version:  4.2
 Severity:  Normal   |   Resolution:
 Keywords:  accessibility,   | Triage Stage:  Accepted
  screen reader, landmarks   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * 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/0107018a92ead212-6260a2c5-eaf0-4f56-8818-abed48597870-00%40eu-central-1.amazonses.com.

Re: [Django] #33651: Support prefetch GenericForeignKey with custom queryset.

[Django]

#33651: Support prefetch GenericForeignKey with custom queryset.
-+-
 Reporter:  elonzh   |Owner:  Clément
 |  Escolano
 Type:  New feature  |   Status:  assigned
Component:   |  Version:  4.0
  contrib.contenttypes   |
 Severity:  Normal   |   Resolution:
 Keywords:  GenericForeignKey| Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * needs_better_patch:  0 => 1


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018a92e314b6-26afeb5f-60bf-42d1-8e77-c79eb0c30793-00%40eu-central-1.amazonses.com.

Re: [Django] #34838: GeoDjango database functions incompatible with GeneratedField

[Django]

#34838: GeoDjango database functions incompatible with GeneratedField
-+-
 Reporter:  Paolo Melchiorre |Owner:  Paolo
 |  Melchiorre
 Type:  Bug  |   Status:  assigned
Component:  GIS  |  Version:  dev
 Severity:  Release blocker  |   Resolution:
 Keywords:  field, database, | Triage Stage:  Accepted
  generated, gis, feodjango  |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Paolo Melchiorre):

 I think the piece is ready. Thanks to Simon for the great help.

-- 
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/0107018a928cc541-b65fcb8a-c4bd-491f-b2b7-c2e39f75d066-00%40eu-central-1.amazonses.com.