Re: [Django] #32502: Replace SQLite schema table rebuild by ALTER functions when supported

2022-02-11 Thread Django
#32502: Replace SQLite schema table rebuild by ALTER functions when supported
-+-
 Reporter:  Simon Charette   |Owner:  Mariusz
 Type:   |  Felisiak
  Cleanup/optimization   |   Status:  closed
Component:  Migrations   |  Version:  dev
 Severity:  Normal   |   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 Mariusz Felisiak):

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


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


Re: [Django] #32502: Replace SQLite schema table rebuild by ALTER functions when supported

2022-02-11 Thread Django
#32502: Replace SQLite schema table rebuild by ALTER functions when supported
-+-
 Reporter:  Simon Charette   |Owner:  Mariusz
 Type:   |  Felisiak
  Cleanup/optimization   |   Status:  assigned
Component:  Migrations   |  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 GitHub ):

 In [changeset:"3702819227fd0cdd9b581cd99e11d1561d51cbeb" 37028192]:
 {{{
 #!CommitTicketReference repository=""
 revision="3702819227fd0cdd9b581cd99e11d1561d51cbeb"
 Refs #32502 -- Avoided table rebuild when removing fields on SQLite
 3.35.5+.

 ALTER TABLE ... DROP COLUMN was introduced in SQLite 3.35+ however
 a data corruption issue was fixed in SQLite 3.35.5.
 }}}

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


Re: [Django] #32114: Workaround for subtest issue with parallel test runner

2022-02-11 Thread Django
#32114: Workaround for subtest issue with parallel test runner
-+-
 Reporter:  Jordan Ephron|Owner:  Jonny
 Type:   |  Arnold
  Cleanup/optimization   |   Status:  assigned
Component:  Testing framework|  Version:  3.1
 Severity:  Normal   |   Resolution:
 Keywords:  Test subtest | Triage Stage:  Accepted
  parallel   |
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/065.0a97c9462e1f2a131e523cb5588b6315%40djangoproject.com.


Re: [Django] #32114: Workaround for subtest issue with parallel test runner

2022-02-11 Thread Django
#32114: Workaround for subtest issue with parallel test runner
-+-
 Reporter:  Jordan Ephron|Owner:  Jonny
 Type:   |  Arnold
  Cleanup/optimization   |   Status:  assigned
Component:  Testing framework|  Version:  3.1
 Severity:  Normal   |   Resolution:
 Keywords:  Test subtest | Triage Stage:  Accepted
  parallel   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Jonny Arnold):

 * needs_better_patch:  1 => 0
 * needs_tests:  1 => 0


Comment:

 I've responded to the comment on the Pull Request. Please let me know if I
 need to make any further changes.

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


[Django] #33512: DateTimeField auto_add_now is NUL when creating child model object referencing parent model's object

2022-02-11 Thread Django
#33512: DateTimeField auto_add_now is NUL when creating child model object
referencing parent model's object
-+-
   Reporter:  eeriks |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Database   |Version:  4.0
  layer (models, ORM)|
   Severity:  Normal |   Keywords:  auto_add_now
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Description:
 When creating Model object which inherits from other Model which has
 `DateTimeField` with `auto_add_now=True` and passing `parent_ptr_id`
 value, then Django tries to update base Model by setting the auto_now_add
 field to NUL (although the field is null=False)

 Expected result:
 ChildModel instance created with a link to ParentModel.

 Code examples:
 `models.py`
 {{{
 class ParentModel(models.Model):
 created = models.DateTimeField(auto_now_add=True)
 modified = models.DateTimeField(auto_now=True)


 class ChildModel(SomeBaseModel):
 some_field = models.CharField(max_length=12)
 }}}

 `manage.py shell`
 {{{
 from app.models import ParentModel, ChildModel
 parent_object = ParentModel.objects.create()  # OK
 ChildModel.objects.create()  # OK
 ChildModel.objects.create(parentmodel_ptr=parent_object)  # IntegrityError
 }}}

 Actual result:
 Django tries to update ParentModel's `created` with NULL
 {{{
 UPDATE "app_parentmodel" SET "created" = NULL, "modified" = ? WHERE
 "app_parentmodel"."id" = ?
 }}}
 And raises
 {{{
 django.db.utils.IntegrityError: NOT NULL constraint failed:
 app_parentmodel.created
 }}}


 Noticed in Django 2.2, reproduced in 3.2 and 4.0. with both Postgres and
 SQlite database backends.
 [https://github.com/eeriks/django-demo Demo project on GitHub] to
 reproduce bug.

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

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


Re: [Django] #33380: Change runserver's auto-reloader to prefer (likely) user files when scanning for changes.

2022-02-11 Thread Django
#33380: Change runserver's auto-reloader to prefer (likely) user files when
scanning for changes.
-+-
 Reporter:  Keryn Knight |Owner:
 |  Hrushikesh Vaidya
 Type:  New feature  |   Status:  assigned
Component:  Core (Management |  Version:  dev
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Hrushikesh Vaidya):

 * needs_better_patch:  0 => 1
 * has_patch:  0 => 1


Comment:

 An initial [https://github.com/django/django/pull/15418 PR]. It's not 100%
 correct (some other non-project files manage to filter through), but all
 of the user's project files are put at the 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/067.af2fce1f2828f10dbe5ca73af59c7395%40djangoproject.com.


Re: [Django] #33405: Documentation for template filter 'escapejs' is extremely unclear

2022-02-11 Thread Django
#33405: Documentation for template filter 'escapejs' is extremely unclear
---+--
 Reporter:  Jon Ribbens|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Documentation  |  Version:  4.0
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Jon Ribbens):

 * cc: Jon Ribbens (added)


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

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


Re: [Django] #33405: Documentation for template filter 'escapejs' is extremely unclear

2022-02-11 Thread Django
#33405: Documentation for template filter 'escapejs' is extremely unclear
---+--
 Reporter:  Jon Ribbens|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Documentation  |  Version:  4.0
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Jon Ribbens):

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


Comment:

 This is not a support request, I am reporting a bug in the documentation,
 which is so garbled as to be essentially completely meaningless and to
 render a long-standing and potentially-useful Django feature useless.

 Your reference to #29055 is helpful as it helped me understand the
 documentation is even worse than I thought it was - when it says
 "JavaScript template literals" this doesn't mean "a JavaScript literal
 created from a Django template" which would be the obvious interpretation
 given that is precisely what this feature is for, it means the relatively-
 recent JavaScript backtick syntax.

 Add that to the fact that the second sentence has two clauses which
 contradict each other, and I cannot understand how you can possibly think
 the current text is "ok" - it's complete gibberish.

 Since you're asking for a concrete proposal I would suggest:

 Escapes characters for use in JavaScript strings. This makes the
 string safe for use in HTML and JavaScript or JSON string literals. Note
 that it does ''not'' make it safe for use in "JavaScript template
 literals" (i.e. the JavaScript backtick syntax).
 For example:
 

Re: [Django] #33476: Formatting Code with Black

2022-02-11 Thread Django
#33476: Formatting Code with Black
-+-
 Reporter:  Mariusz Felisiak |Owner:  Mariusz
 Type:   |  Felisiak
  Cleanup/optimization   |   Status:  closed
Component:  Core (Other) |  Version:  4.0
 Severity:  Normal   |   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:  assigned => closed
 * resolution:   => fixed


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


Re: [Django] #33476: Formatting Code with Black

2022-02-11 Thread Django
#33476: Formatting Code with Black
-+-
 Reporter:  Mariusz Felisiak |Owner:  Mariusz
 Type:   |  Felisiak
  Cleanup/optimization   |   Status:  assigned
Component:  Core (Other) |  Version:  4.0
 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 ):

 In [changeset:"d113b5a837f726d1c638d76c4e88445e6cd59fd5" d113b5a]:
 {{{
 #!CommitTicketReference repository=""
 revision="d113b5a837f726d1c638d76c4e88445e6cd59fd5"
 Refs #33476 -- Made management commands use black.

 Run black on generated files, if it is available on PATH.
 }}}

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


Re: [Django] #32502: Replace SQLite schema table rebuild by ALTER functions when supported

2022-02-11 Thread Django
#32502: Replace SQLite schema table rebuild by ALTER functions when supported
-+-
 Reporter:  Simon Charette   |Owner:  Mariusz
 Type:   |  Felisiak
  Cleanup/optimization   |   Status:  assigned
Component:  Migrations   |  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 Mariusz Felisiak):

 * owner:  (none) => Mariusz Felisiak
 * status:  new => assigned
 * has_patch:  0 => 1


Comment:

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


Re: [Django] #32502: Replace SQLite schema table rebuild by ALTER functions when supported

2022-02-11 Thread Django
#32502: Replace SQLite schema table rebuild by ALTER functions when supported
--+
 Reporter:  Simon Charette|Owner:  (none)
 Type:  Cleanup/optimization  |   Status:  new
Component:  Migrations|  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
--+
Description changed by Mariusz Felisiak:

Old description:

> Per https://www.sqlite.org/lang_altertable.html
>
> - `ALTER TABLE RENAME COLUMN` is
> [https://www.sqlite.org/search?s=c&q=RENAME+COLUMN supported since 3.25
> but had issues with unique columns until 3.27]
> - `ALTER TABLE ADD COLUMN` is
> [https://www.sqlite.org/search?s=c&q=ADD+COLUMN supported since 3.2.0]
> not sure why it wasn't used in the first place since 3.2 was released in
> 2005? (added in 2f73e5406d54cb8945e187eff302a3a3373350be)
> - `ALTER TABLE DROP COLUMN`
> [https://www.sqlite.org/draft/releaselog/3_35_0.html will be supported by
> 3.35]
>
> This will leave only `ALTER COLUMN` and `ADD/REMOVE CONSTRAINT` that must
> be emulated on SQLite 3.35+

New description:

 Per https://www.sqlite.org/lang_altertable.html

 - ~~`ALTER TABLE RENAME COLUMN` is
 [https://www.sqlite.org/search?s=c&q=RENAME+COLUMN supported since 3.25
 but had issues with unique columns until 3.27] ~~ (duplicate of #29763).
 - `ALTER TABLE ADD COLUMN` is
 [https://www.sqlite.org/search?s=c&q=ADD+COLUMN supported since 3.2.0] not
 sure why it wasn't used in the first place since 3.2 was released in 2005?
 (added in 2f73e5406d54cb8945e187eff302a3a3373350be)
 - `ALTER TABLE DROP COLUMN`
 [https://www.sqlite.org/draft/releaselog/3_35_0.html will be supported by
 3.35]

 This will leave only `ALTER COLUMN` and `ADD/REMOVE CONSTRAINT` that must
 be emulated on SQLite 3.35+

--

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


Re: [Django] #33471: AlterField operation should be noop when adding/changing choices on SQLite.

2022-02-11 Thread Django
#33471: AlterField operation should be noop when adding/changing choices on 
SQLite.
-+-
 Reporter:  David Szotten|Owner:  Douglas
 Type:   |  Mumme
  Cleanup/optimization   |   Status:  assigned
Component:  Migrations   |  Version:  4.0
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Mariusz Felisiak):

 Replying to [comment:10 David Szotten]:
 > do you know off the top of your head what mechanism makes it a no-op on
 pg already?

 There is nothing specific to PostgreSQL here, it's also a noop on MySQL
 and Oracle. It's caused by remaking tables on SQLite that is necessary in
 most of cases (see related ticket #32502). Overwriting
 `_field_should_be_altered()` in the SQLite backend should do the trick.

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


Re: [Django] #33471: AlterField operation should be noop when adding/changing choices on SQLite.

2022-02-11 Thread Django
#33471: AlterField operation should be noop when adding/changing choices on 
SQLite.
-+-
 Reporter:  David Szotten|Owner:  Douglas
 Type:   |  Mumme
  Cleanup/optimization   |   Status:  assigned
Component:  Migrations   |  Version:  4.0
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by David Szotten):

 do you know off the top of your head what mechanism makes it a no-op on pg
 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/070.6e6bf7726a00c970b8c1316192008468%40djangoproject.com.


Re: [Django] #33511: Single-select admin autcomplete widget has lost its auto-focus

2022-02-11 Thread Django
#33511: Single-select admin autcomplete widget has lost its auto-focus
-+-
 Reporter:   |Owner:  nobody
  jul...@pinabausch.org  |
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  4.0
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  1
-+-

Comment (by jul...@pinabausch.org):

 Thanks & sorry!

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


Re: [Django] #33511: Single-select admin autcomplete widget has lost its auto-focus

2022-02-11 Thread Django
#33511: Single-select admin autcomplete widget has lost its auto-focus
-+-
 Reporter:   |Owner:  nobody
  jul...@pinabausch.org  |
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  4.0
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  1
-+-
Changes (by Mariusz Felisiak):

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


Comment:

 Duplicate of #33504.

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


Re: [Django] #33511: Single-select admin autcomplete widget has lost its auto-focus

2022-02-11 Thread Django
#33511: Single-select admin autcomplete widget has lost its auto-focus
-+-
 Reporter:   |Owner:  nobody
  jul...@pinabausch.org  |
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  4.0
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  1
-+-
Changes (by jul...@pinabausch.org):

 * Attachment "Ohne Titel.png" added.


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

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


[Django] #33511: Single-select admin autcomplete widget has lost its auto-focus

2022-02-11 Thread Django
#33511: Single-select admin autcomplete widget has lost its auto-focus
-+
   Reporter:  jul...@pinabausch.org  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  contrib.admin  |Version:  4.0
   Severity:  Normal |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  1  |
-+
 Dear Django team,

 here’s a bug in Django admin related to the autocomplete fields
 functionality.

 I believe that the single-select autocomplete widget does not auto-focus
 the input field anymore since Django 4 has been released.

 I've been checking myself, but couldn't track down the issue.
 I checked
 https://github.com/django/django/tree/main/django/contrib/admin/static/admin/js
 for a breaking change introduced in 4.0.
 The release log doesn't mention anything either:
 https://docs.djangoproject.com/en/4.0/releases/4.0/#django-contrib-admin

 Current behavior:

 Inside any change form view, click a field that is single-select with
 auto-complete enabled.
 A panel opens. It has a search field and shows the initial batch of
 results.
 The search field is not focused automatically (like it used to be in 3.x).

 (see screenshot)

 Expected behavior:

 Same as above, but with the search field being focused.

-- 
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/054.63b0dfda770a7cd6b8651b7effa9d83a%40djangoproject.com.