Re: [Django] #35169: updated asgi handler for disconnects does not process ROOT_PATH

[Django]

#35169: updated asgi handler for disconnects does not process ROOT_PATH
-+-
 Reporter:  Michael Smith|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (Other) |  Version:  5.0
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  asgi, handler,   | Triage Stage:
  root_path  |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Sören Weber):

 * cc: Sören Weber (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/0107018da68c56e2-9b576eb7-6319-4a47-97bf-75476897dd3b-00%40eu-central-1.amazonses.com.

Re: [Django] #35194: Postgres 16.2 with _iexact leads to psycopg2.errors.IndeterminateCollation

[Django]

#35194: Postgres 16.2 with _iexact leads to 
psycopg2.errors.IndeterminateCollation
--+--
 Reporter:  Aldalen   |Owner:  (none)
 Type:  Bug   |   Status:  new
Component:  contrib.postgres  |  Version:  5.0
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Description changed by Aldalen:

Old description:

> There is something up with how "_iexact" GeneratedField expressions are
> handling _iexact expressions.  This leads to a
> "psycopg2.errors.IndeterminateCollation: could not determine which
> collation to use for upper() function" error.   This was caught in our
> CI/CD env when I revved it to 16.2.  Existing / old migrations failed.
> This is a reduced examples from our code, with exception paths redacted
> where necessary.
>
> Model Definition:
>
> {{{
> class TestModel(models.Model):
>  test = models.CharField(max_length=254, blank=True)
>  test_gen =
> models.GeneratedField(expression=models.Q(test__iexact='yes'),
> output_field=models.BooleanField(), db_persist=True)
> }}}
>

> Migration content:
>
> {{{
> migrations.AddField(
> model_name='testmodel',
> name='test_gen',
> field=models.GeneratedField(db_persist=True,
> expression=models.Q(("test__iexact",'yes')),
> output_field=models.BooleanField()),
> )
> }}}
>
> Error:
>
> {{{
>   Applying module.migration_name...Traceback (most recent call last):
>   File "/opt/venv/lib/python3.11/site-
> packages/django/db/backends/utils.py", line 103, in _execute
> return self.cursor.execute(sql)
>
> psycopg2.errors.IndeterminateCollation: could not determine which
> collation to use for upper() function
> HINT:  Use the COLLATE clause to set the collation explicitly.
> The above exception was the direct cause of the following exception:
> Traceback (most recent call last):
>   File "/builds/[redacted]/manage.py", line 15, in 
> execute_from_command_line(sys.argv)
>   File "/opt/[redacted]/lib/python3.11/site-
> packages/django/core/management/__init__.py", line 442, in
> execute_from_command_line
> utility.execute()
>   File "/opt/[redacted]/lib/python3.11/site-
> packages/django/core/management/__init__.py", line 436, in execute
> self.fetch_command(subcommand).run_from_argv(self.argv)
>   File "/opt/[redacted]/lib/python3.11/site-
> packages/django/core/management/base.py", line 413, in run_from_argv
> self.execute(*args, **cmd_options)
>   File "/opt/[redacted]/lib/python3.11/site-
> packages/django/core/management/base.py", line 459, in execute
> output = self.handle(*args, **options)
>  ^
>   File "/opt/[redacted]/lib/python3.11/site-
> packages/django/core/management/base.py", line 107, in wrapper
> res = handle_func(*args, **kwargs)
>   
>   File "/opt/[redacted]/lib/python3.11/site-
> packages/django/core/management/commands/migrate.py", line 356, in handle
> post_migrate_state = executor.migrate(
>  ^
>   File "/opt/[redacted]/lib/python3.11/site-
> packages/django/db/migrations/executor.py", line 135, in migrate
> state = self._migrate_all_forwards(
> ^^^
>   File "/opt/[redacted]/lib/python3.11/site-
> packages/django/db/migrations/executor.py", line 167, in
> _migrate_all_forwards
> state = self.apply_migration(
> ^
>   File "/opt/[redacted]/lib/python3.11/site-
> packages/django/db/migrations/executor.py", line 252, in apply_migration
> state = migration.apply(state, schema_editor)
> ^
>   File "/opt/[redacted]/lib/python3.11/site-
> packages/django/db/migrations/migration.py", line 132, in apply
> operation.database_forwards(
>   File "/opt/[redacted]/lib/python3.11/site-
> packages/django/db/migrations/operations/fields.py", line 108, in
> database_forwards
> schema_editor.add_field(
>   File "/opt/[redacted]/lib/python3.11/site-
> packages/django/db/backends/base/schema.py", line 750, in add_field
> self.execute(sql, params)
>   File "/opt/[redacted]/lib/python3.11/site-
> packages/django/db/backends/postgresql/schema.py", line 48, in execute
> return super().execute(sql, None)
>^^
>   File "/opt/[redacted]/lib/python3.11/site-
> packages/django/db/backends/base/schema.py", line 201, in execute
> cursor.execute(sql, params)
>   

Re: [Django] #35194: Postgres 16.2 with _iexact leads to psycopg2.errors.IndeterminateCollation

[Django]

#35194: Postgres 16.2 with _iexact leads to 
psycopg2.errors.IndeterminateCollation
--+--
 Reporter:  Aldalen   |Owner:  (none)
 Type:  Bug   |   Status:  new
Component:  contrib.postgres  |  Version:  5.0
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Comment (by Aldalen):

 This was tested with django 5.0.2 and latest psycopg2 2.9.9.
-- 
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/0107018da6877e02-34736907-5019-4cb7-920c-66fbac5cc2a8-00%40eu-central-1.amazonses.com.

[Django] #35194: Postgres 16.2 with _iexact leads to psycopg2.errors.IndeterminateCollation

[Django]

#35194: Postgres 16.2 with _iexact leads to 
psycopg2.errors.IndeterminateCollation
+
   Reporter:  Michael A |  Owner:  (none)
   Type:  Bug   | Status:  new
  Component:  contrib.postgres  |Version:  5.0
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 There is something up with how "_iexact" GeneratedField expressions are
 handling _iexact expressions.  This leads to a
 "psycopg2.errors.IndeterminateCollation: could not determine which
 collation to use for upper() function" error.   This was caught in our
 CI/CD env when I revved it to 16.2.  Existing / old migrations failed.
 This is a reduced examples from our code, with exception paths redacted
 where necessary.

 Model Definition:

 {{{
 class TestModel(models.Model):
  test = models.CharField(max_length=254, blank=True)
  test_gen =
 models.GeneratedField(expression=models.Q(test__iexact='yes'),
 output_field=models.BooleanField(), db_persist=True)
 }}}


 Migration content:

 {{{
 migrations.AddField(
 model_name='testmodel',
 name='test_gen',
 field=models.GeneratedField(db_persist=True,
 expression=models.Q(("test__iexact",'yes')),
 output_field=models.BooleanField()),
 )
 }}}

 Error:

 {{{
   Applying module.migration_name...Traceback (most recent call last):
   File "/opt/venv/lib/python3.11/site-
 packages/django/db/backends/utils.py", line 103, in _execute
 return self.cursor.execute(sql)

 psycopg2.errors.IndeterminateCollation: could not determine which
 collation to use for upper() function
 HINT:  Use the COLLATE clause to set the collation explicitly.
 The above exception was the direct cause of the following exception:
 Traceback (most recent call last):
   File "/builds/[redacted]/manage.py", line 15, in 
 execute_from_command_line(sys.argv)
   File "/opt/[redacted]/lib/python3.11/site-
 packages/django/core/management/__init__.py", line 442, in
 execute_from_command_line
 utility.execute()
   File "/opt/[redacted]/lib/python3.11/site-
 packages/django/core/management/__init__.py", line 436, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "/opt/[redacted]/lib/python3.11/site-
 packages/django/core/management/base.py", line 413, in run_from_argv
 self.execute(*args, **cmd_options)
   File "/opt/[redacted]/lib/python3.11/site-
 packages/django/core/management/base.py", line 459, in execute
 output = self.handle(*args, **options)
  ^
   File "/opt/[redacted]/lib/python3.11/site-
 packages/django/core/management/base.py", line 107, in wrapper
 res = handle_func(*args, **kwargs)
   
   File "/opt/[redacted]/lib/python3.11/site-
 packages/django/core/management/commands/migrate.py", line 356, in handle
 post_migrate_state = executor.migrate(
  ^
   File "/opt/[redacted]/lib/python3.11/site-
 packages/django/db/migrations/executor.py", line 135, in migrate
 state = self._migrate_all_forwards(
 ^^^
   File "/opt/[redacted]/lib/python3.11/site-
 packages/django/db/migrations/executor.py", line 167, in
 _migrate_all_forwards
 state = self.apply_migration(
 ^
   File "/opt/[redacted]/lib/python3.11/site-
 packages/django/db/migrations/executor.py", line 252, in apply_migration
 state = migration.apply(state, schema_editor)
 ^
   File "/opt/[redacted]/lib/python3.11/site-
 packages/django/db/migrations/migration.py", line 132, in apply
 operation.database_forwards(
   File "/opt/[redacted]/lib/python3.11/site-
 packages/django/db/migrations/operations/fields.py", line 108, in
 database_forwards
 schema_editor.add_field(
   File "/opt/[redacted]/lib/python3.11/site-
 packages/django/db/backends/base/schema.py", line 750, in add_field
 self.execute(sql, params)
   File "/opt/[redacted]/lib/python3.11/site-
 packages/django/db/backends/postgresql/schema.py", line 48, in execute
 return super().execute(sql, None)
^^
   File "/opt/[redacted]/lib/python3.11/site-
 packages/django/db/backends/base/schema.py", line 201, in execute
 cursor.execute(sql, params)
   File "/opt/[redacted]/lib/python3.11/site-
 packages/django/db/backends/utils.py", line 122, in execute
 return super().execute(sql, params)

Re: [Django] #28263: TestCase breaks for databases that don't support savepoints

[Django]

#28263: TestCase breaks for databases that don't support savepoints
---+--
 Reporter:  Lokesh Dokara  |Owner:  Tim Graham
 Type:  Bug|   Status:  closed
Component:  Testing framework  |  Version:  1.11
 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 GitHub ):

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

Comment:

 In [changeset:"bf692b2fdcb5e55fafa5d3d38e286407eeef2ef4" bf692b2f]:
 {{{#!CommitTicketReference repository=""
 revision="bf692b2fdcb5e55fafa5d3d38e286407eeef2ef4"
 Fixed #28263 -- Fixed TestCase setup for databases that don't support
 savepoints.
 }}}
-- 
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/0107018da6683ac7-86f4edd7-6274-4b9f-a3ce-fd0a54ea9d82-00%40eu-central-1.amazonses.com.

Re: [Django] #28646: Migration calls "CREATE INDEX" when one already exists when 'unique' field attribute is added (PostgreSQL)

[Django]

#28646: Migration calls "CREATE INDEX" when one already exists when 'unique' 
field
attribute is added (PostgreSQL)
-+-
 Reporter:  Hari - 何瑞理|Owner:  bcail
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
  postgresql,migration,index,#djangocph|
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/0107018da65e5856-475b3d58-4c02-495b-bd30-982d8d8655fa-00%40eu-central-1.amazonses.com.

Re: [Django] #27029: Make EmailValidator accept non-ASCII characters

[Django]

#27029: Make EmailValidator accept non-ASCII characters
-+-
 Reporter:  Ramin Farajpour  |Owner:  j-bernard
  Cami   |
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Core (Other) |  Version:  dev
 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 Collin Anderson):

 * cc: Collin Anderson (added)


Old description:

> {{{
> from django.core.validators import validate_email
> validate_email('うえあいお@email.com')
> }}}
>

> if you check this url email chacker with うえあいお@address.com , this is
> not valid email address ,
>
> Thanks,
> Ramin

New description:

 {{{
 from django.core.validators import validate_email
 validate_email('うえあいお@email.com')
 }}}


 if you check this url email chacker with うえあいお@address.com , this is
 not valid email address ,

 Thanks,
 Ramin

--
Comment:

 I'm just noticing today that unicode.org has recommendations on email
 security:

 https://www.unicode.org/reports/tr39/#Email_Security_Profiles

 - It must be in NFKC format
 - It must have level =  or less, from
 `Restriction_Level_Detection`
 - It must not have mixed number systems according to
 `Mixed_Number_Detection`
 - It must satisfy dot-atom-text from RFC 5322 §3.2.3, where atext is
 extended as follows:
   - Where C ≤ U+007F, C is defined as in §3.2.3. (That is, C ∈
 [!#-'*+\-/-9=?A-Z\^-~]. This list copies what is already in §3.2.3, and
 follows HTML5 for ASCII.)
   - Where C > U+007F, both of the following conditions are true:
 - C has `Identifier_Status=Allowed` from General Security Profile
 - If C is the first character, it must be `XID_Start` from Default
 Identifier_Syntax in [UAX31]

 It doesn't recommend which "restriction level" to use, and maybe we should
 allow the user to decide what level to use (defaulting to 1: ASCII-Only).

 (Also, it would be nice if Python implemented "Mixed-Script Detection",
 "Restriction-Level Detection" and "Mixed-Number Detection" as part of
 unicodedata.)
-- 
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/0107018da47f8c0b-ac22e7ad-70f4-4c86-9f42-5d43d63f5f4f-00%40eu-central-1.amazonses.com.

Re: [Django] #23251: Use a temporary folder to store uploaded files during tests

[Django]

#23251: Use a temporary folder to store uploaded files during tests
-+
 Reporter:  Shai Berger  |Owner:  bcail
 Type:  Bug  |   Status:  assigned
Component:  Testing framework|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  file storage upload  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by bcail):

 * owner:  (none) => bcail
 * needs_better_patch:  1 => 0
 * status:  new => assigned

Comment:

 I opened a [https://github.com/django/django/pull/17853 PR].

 I fixed some of the tests by overriding the settings to be more like the
 defaults. There's one test that tests the defaults, and it's still
 failing.

 Right now there's no override for the temp directory... do we want to add
 a setting? Or check for something in the `STORAGES` setting?
-- 
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/0107018da462b26a-fc6fabbf-9c3e-4a52-a637-057e14fdb103-00%40eu-central-1.amazonses.com.

Re: [Django] #28646: Migration calls "CREATE INDEX" when one already exists when 'unique' field attribute is added (PostgreSQL)

[Django]

#28646: Migration calls "CREATE INDEX" when one already exists when 'unique' 
field
attribute is added (PostgreSQL)
-+-
 Reporter:  Hari - 何瑞理|Owner:  bcail
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
  postgresql,migration,index,#djangocph|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by bcail):

 * needs_better_patch:  1 => 0

Comment:

 Hi Mariusz, I added that test. I also updated the code to use "CREATE
 INDEX IF NOT EXISTS"... what do you think of going that direction?
-- 
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/0107018da443ce23-a3e5726d-89fb-4819-9125-c3ef0ef1ff12-00%40eu-central-1.amazonses.com.

Re: [Django] #35187: Django 5.0+ doesn't work with pyc files only

[Django]

#35187: Django 5.0+ doesn't work with pyc files only
-+--
 Reporter:  Marcus Hoffmann  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Other) |  Version:  5.0
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Comment (by William Schwartz):

 I agree that what's happening here is the use (where the traceback shows)
 of [https://docs.python.org/3/library/inspect.html#inspect.getsourcelines
 inspect.getsourcelines], the documentation of which says, "An `OSError` is
 raised if the source code cannot be retrieved." I also agree that the
 problem started with https://github.com/django/django/pull/16831, which
 says,
 To persist the sensitive variables list for async functions, we can
 use a global dict with the hash of the filename and line number of the
 function as the key (more formally: `hash(f"{file_path}:{line_number}")`
 and the value is the tuple or sensitive variables (or `__ALL__`). Then,
 during traceback cleanup we can read this dict by reconstructing the same
 key with `f_code.co_filename` and `f_code.co_firstlineno` to lookup the
 relevant value in the dict.

 I don't have the bandwidth these days to offer an alternative solution.
 All I can say is that the implementation assumes the existence of a file
 path that Python does not guarantee exists. To be clear on this: **Python
 does not guarantee that there is a source file or cache file associated
 with any object.** Modules without source files exist in *all* CPython
 instances because of the `sys` module, and in most CPython instances
 because of the frozen `importlib` submodules. They occur frequently in
 embedded instance of Python, e.g., when running code directly from pyc
 cache files (which I have always [back to 2010] understood was a fully
 supported solution) or using a compiler such as PyOxidizer, which I use.
 So a correct solution to whatever
 https://github.com/django/django/pull/16831 was trying to fix for async
 functions cannot rely on source files. I think what went wrong was
 essentially what comment:10:ticket:30950 warned of:
  I could be wrong but I believe that whatever we do to tackle this
 ticket, it's important ensure that __file__ isn't added back by new
 contributions in the future. Ideally this shouldn't be a burden on
 reviewers, there should be a linting rule, or a test or something that
 ensures that any contributions following the resolution of this ticket
 isn't adding this back.

 Ideally there'd be a test run of Django in CI that runs in embedded form
 on an embedded project/app (whether cache-only, frozen, or PyOxidered or
 whatever). That would have caught this issue since `__file__` isn't being
 ''directly'' used, just indirectly via `inspect.getsourcelines`.
 Unfortunately I don't have the time to do this myself.

 PS, I'm excited that someone else is using Django embedded! FWIW I've been
 successfully using Django 3.2.13 with PyOxidizer Python applications for
 awhile. However, I haven't embedded Django itself, which continues to
 exist in source form next to my applications, i.e., only my own
 application code is embedded in the PyOxidizer-generated binary, not
 Django itself. Moreover, we do not use the admin or auth contrib apps.
 That said, I would certainly prefer to embed Django one day. If I recall
 correctly, at the time I ran out of budget to work on this, the barrier to
 embedding Django for us was the `loaddata` command.
-- 
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/0107018da412984e-ae561941-b328-4142-b216-4456904bda0f-00%40eu-central-1.amazonses.com.

Re: [Django] #35190: django with postgresql is incompatible with pypy

[Django]

#35190: django with postgresql is incompatible with pypy
-+--
 Reporter:  Владимир |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (Other) |  Version:  dev
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  pypy postgresql  | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by Mariusz Felisiak):

 * resolution:  invalid => duplicate

-- 
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/0107018da369392d-9ead9fac-1327-44ce-b099-a7c7fe62c8d5-00%40eu-central-1.amazonses.com.

Re: [Django] #35122: --prune should take app_label into account then checking squashed migrations.

[Django]

#35122: --prune should take app_label into account then checking squashed
migrations.
-+-
 Reporter:  Moein Bbp|Owner:  Moein Bbp
 Type:  Bug  |   Status:  closed
Component:  Core (Management |  Version:  4.2
  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:"cf107fe255dbc4e1619c0985e4becdd9cabe8235" cf107fe2]:
 {{{#!CommitTicketReference repository=""
 revision="cf107fe255dbc4e1619c0985e4becdd9cabe8235"
 Fixed #35122 -- Made migrate --prune option respect --app_label.
 }}}
-- 
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/0107018da34af8d4-a2e68d4a-c43d-4d11-a8db-6021e55e3959-00%40eu-central-1.amazonses.com.

Re: [Django] #35187: Django 5.0+ doesn't work with pyc files only

[Django]

#35187: Django 5.0+ doesn't work with pyc files only
-+--
 Reporter:  Marcus Hoffmann  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Other) |  Version:  5.0
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by Carlton Gibson):

 * cc: William Schwartz (added)

Comment:

 This may be related to #32316, #30950  If so William Schwartz was
 actively using _frozen apps_ so **may** be able to advise.
-- 
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/0107018da3454961-54aabdbb-a6c9-431a-92d3-e638476da9b1-00%40eu-central-1.amazonses.com.

[Django] #35193: Timezone unaware datetimes and psycopg 3

[Django]

#35193: Timezone unaware datetimes and psycopg 3
-+-
   Reporter:  Mapiarz|  Owner:  nobody
   Type: | Status:  new
  Uncategorized  |
  Component:  Database   |Version:  4.2
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Hi. I encountered a blocker that I'm not sure how to resolve.

 I'm running Django 4.2 and wanted to update from psycopg2 to psycopg (the
 latest version 3).

 The update itself is quite simple in my case and almost everything works
 except timezone unaware datetime ranges. Let me explain.

 In my app, I have timezones enabled. For a few rare exceptions, I need to
 store timezone unaware datetimes. I was able to accomplish this by
 subclassing the DateTimeField shipped by Django and removing the related
 timezone conversions. Furthermore, I also need timezone unaware datetime
 ranges. That's also easy since I can subclass DateTimeRangeField and
 specify my timezone unaware field as the base_field, use timezone unaware
 range_type and make sure the correct db_type is returned from db_type
 method (tsrange).

 This has gotten me a very long way with psycopg2. After migrating to
 latest psycopg, I started getting a DB crash whenever I try to modify one
 of my objects that has a timezone unaware datetime range. This crash,
 specifically, happens when checking an ExclusionConstraint with an
 OVERLAPS expression on the datetime range. The error is:

 Got a database error calling check() on ...: cannot cast type tstzrange to
 tsrange ...02-17 00:00:00","2024-02-24 00:00:00")'::tstzrange::tsrange)...

 As far as I can tell, this is caused by
 django.db.backends.postgresql.psycopg_any.DjangoRangeDumper which assumes
 that there can only ever be timezone aware timestamps.

 Overall, I'm not sure how to proceed. I'm not familiar with the django
 postgres backend or psycopg itself. Please advise.
-- 
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/0107018da33990db-74cf49bf-dcb7-4a73-8b59-9f23c865401c-00%40eu-central-1.amazonses.com.

[Django] #35192: Support injecting custom context into widget templates

[Django]

#35192: Support injecting custom context into widget templates
+
   Reporter:  oxan  |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Forms |Version:  5.0
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 The context available to widget templates is currently very rigid and does
 not allow any customization. For example, it's currently almost impossible
 to add an `invalid` CSS class to widgets that have errors.

 I think my preferred solution would be to insert a call to a form renderer
 method in the callchain between `BoundField.as_widget()` and
 `Widget.render()`, which can be overridden by a custom renderer. It should
 receive the `BoundField` itself as an argument so that it has access to
 the current state. Something like the following sketch:

 {{{#!python
 class BoundField:
 def as_widget(self, widget=None, attrs=None, only_initial=False):
 ... # leave current code as-is, except for last call to
 widget.render()
 return self.form.renderer.render_widget(
 field=self,
 widget=widget,
 name=self.html_initial_name if only_initial else
 self.html_name,
 value=value,
 attrs=attrs,
 )

 class BaseRenderer:
 def render_widget(self, field, widget, name, value, attrs=None):
 # this can be overridden to add/change/remove `attrs`, or to
 render the widget in an entirely different way
 return widget.render(name, value, attrs)
 }}}
-- 
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/0107018da3321a32-1f56b4f8-6da1-471c-9e7e-a6aa7866e9df-00%40eu-central-1.amazonses.com.

[Django] #35191: Allow form renderer to use custom template for label tag

[Django]

#35191: Allow form renderer to use custom template for label tag
-+-
   Reporter:  oxan   |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |
  Component:  Forms  |Version:  5.0
   Severity:  Normal |   Keywords:  forms render
   Triage Stage: |  template
  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+-
 Currently, a form renderer can't easily change the template used by the
 `BoundField.label_tag()` method: `template_name_label` can be set on the
 form, but there exists no `label_template_name` on the `FormRenderer` that
 it fallbacks to.

 This is problematic if e.g. CSS classes need to be set on the form labels.
 Writing out the `` tag in the template instead of calling
 `label_tag()` is also not an option, as `label_tag()` does somewhat
 complex processing to ensure the correct id (and label) are used.
-- 
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/0107018da3160a15-67ec007f-79ac-46ed-aa44-e884ca126c77-00%40eu-central-1.amazonses.com.

Re: [Django] #28263: TestCase breaks for databases that don't support savepoints

[Django]

#28263: TestCase breaks for databases that don't support savepoints
---+--
 Reporter:  Lokesh Dokara  |Owner:  Tim Graham
 Type:  Bug|   Status:  assigned
Component:  Testing framework  |  Version:  1.11
 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 Simon Charette):

 * owner:  nobody => Tim Graham
 * needs_better_patch:  1 => 0
 * status:  new => assigned
 * 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/0107018da30921a8-bea40281-1722-4810-9703-6ad7d2ee68d0-00%40eu-central-1.amazonses.com.

Re: [Django] #35190: django with postgresql is incompatible with pypy

[Django]

#35190: django with postgresql is incompatible with pypy
-+--
 Reporter:  Владимир |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (Other) |  Version:  dev
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  pypy postgresql  | 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:   => invalid
 * version:  4.2 => dev
 * component:  Database layer (models, ORM) => Core (Other)

Comment:

 Hello Владимир, thank you for your report.

 Support for Django using PyPy3.10 was confirmed when #34986 was fixed. See
 scheduled tests runs showing passing runs for latest Django, Postgresql
 and PyPy3.10:

 https://github.com/django/django/actions/runs/7881024587/job/21503974819

 {{{
 ...
 2024-02-13T02:44:21.6498968Z Complete job name: Ubuntu, PostgreSQL,
 PyPy3.10
 ...
 2024-02-13T02:44:26.5855397Z Status: Downloaded newer image for
 postgres:13-alpine
 2024-02-13T02:44:26.5869670Z docker.io/library/postgres:13-alpine
 2024-02-13T02:44:26.5970128Z ##[command]/usr/bin/docker create --name
 9705ff7849d54424b276eb457c41eb91_postgres13alpine_c2c9a3 --label 149869
 --network github_network_aef26d97bf734bdd832322cc2f43c1d6 --network-alias
 postgres -p 5432:5432 --health-cmd pg_isready --health-interval 10s
 --health-timeout 5s --health-retries 5 -e "POSTGRES_DB=django" -e
 "POSTGRES_USER=user" -e "POSTGRES_PASSWORD=postgres" -e
 GITHUB_ACTIONS=true -e CI=true postgres:13-alpine
 ...
 2024-02-13T02:44:41.0532390Z postgres service is healthy.
 ...
 2024-02-13T02:59:31.9557002Z
 --
 2024-02-13T02:59:31.9557502Z Ran 16838 tests in 577.079s
 2024-02-13T02:59:31.9557727Z
 2024-02-13T02:59:31.9557854Z OK (skipped=594, expected failures=7)
 ...
 }}}

 I'll be closing this issue as invalid, but if you are still having
 problems after trying latest Django and PyPy3.10, you can reach out to any
 of the user support channels from
 [https://docs.djangoproject.com/en/dev/faq/help/#how-do-i-do-x-why-
 doesn-t-y-work-where-can-i-go-to-get-help this link].
-- 
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/0107018da2d5dac1-cac3c901-b185-4c84-810c-f3c3fd1cc256-00%40eu-central-1.amazonses.com.

Re: [Django] #35190: django with postgresql is incompatible with pypy

[Django]

#35190: django with postgresql is incompatible with pypy
-+-
 Reporter:  Владимир |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  4.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  pypy postgresql  | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Владимир):

 * type:  Uncategorized => Bug

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018da2c495b8-92d1bfe5-335b-46e0-9036-8c0d7921947c-00%40eu-central-1.amazonses.com.

Re: [Django] #35187: Django 5.0+ doesn't work with pyc files only

[Django]

#35187: Django 5.0+ doesn't work with pyc files only
-+--
 Reporter:  Marcus Hoffmann  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Other) |  Version:  5.0
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by Natalia Bidart):

 * component:  Uncategorized => Core (Other)

Comment:

 Hello Marcus, thank you for your report and for helping making Django
 better.

 I'm trying to triage this bug properly but I would like to understand a
 few things before making any further decision:

 * In the CPython thread, while they say that source-les imports are
 supported, there seems to be a general pushback around it ("we
 historically discourage them unless you have a pressing use-case", ".pyc-
 only imports are CPython-specific", "that doesn't mean any 3rd party
 packages or other tools support a source-less mode of operation"). You
 affirmed that "this is an officially supported way of running cpython",
 where do you read that exactly?

 * While I can see a value and valid use cases for running Python in
 embedded systems, I'm not sure there are use cases for running a Django
 web server in an embedded system. Would you have examples for wanting to
 run Django in a "minified" rootfs?

 I'm trying to determine whether this report pertains to a specific need
 arising from a niche use case or if it applies to the broader ecosystem.
 Django is a framework designed to offer robust and accurate solutions for
 common scenarios.
-- 
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/0107018da2c28da9-a357358e-039a-44c1-a7be-74af067f4e5c-00%40eu-central-1.amazonses.com.

[Django] #35190: django with postgresql is incompatible with pypy

[Django]

#35190: django with postgresql is incompatible with pypy
-+-
   Reporter:  Владимир   |  Owner:  nobody
   Type: | Status:  new
  Uncategorized  |
  Component:  Database   |Version:  4.2
  layer (models, ORM)|
   Severity:  Normal |   Keywords:  pypy postgresql
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 When using django 4.2 and higher with pypy, it is impossible to use
 postgresql. Versions below require psycopg2cffi, and perfectly work with
 it, but once I switched to django.4.2, I faced following exception:

 File "/opt/pypy/lib/pypy3.10/site-
 packages/django/db/backends/postgresql/base.py", line 47, in 
  from .psycopg_any import IsolationLevel, is_psycopg3  # NOQA
 isort:skip
 File "/opt/pypy/lib/pypy3.10/site-
 packages/django/db/backends/postgresql/psycopg_any.py", line 77, in
 
  from psycopg2 import errors, extensions, sql  # NOQA
-- 
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/0107018da2c256f2-c9efc34d-3cba-414a-a9ea-d97611ce5d0b-00%40eu-central-1.amazonses.com.

Re: [Django] #35122: --prune should take app_label into account then checking squashed migrations.

[Django]

#35122: --prune should take app_label into account then checking squashed
migrations.
-+-
 Reporter:  Moein Bbp|Owner:  Moein Bbp
 Type:  Bug  |   Status:  assigned
Component:  Core (Management |  Version:  4.2
  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):

 * 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/0107018da2b8cd43-277bbeb5-2505-46cc-b0c4-0501888bc933-00%40eu-central-1.amazonses.com.

Re: [Django] #35189: Accessibility issues with collapsed fieldsets in admin forms

[Django]

#35189: Accessibility issues with collapsed fieldsets in admin forms
-+-
 Reporter:  Thibaud Colas|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  contrib.admin|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  accessibility,   | Triage Stage:  Accepted
  whcm, forced colors, screen|
  reader, forms, admin   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-
Changes (by Natalia Bidart):

 * version:  5.0 => dev
 * type:  Bug => Cleanup/optimization
 * stage:  Unreviewed => Accepted

Comment:

 Hello Thibaud, thanks for this report and its detailed content.

 Accepting following the provided rationale. A few notes:

 * Regarding the (loosing of the) rounded corners, I think we need to
 consider consistency with the "regular" fieldsets headings which are non
 rounded. Up to verification, I think we should remove the rounding
 altogether for this fieldset title. It seems the rounding comes from
 reusing the style of the action row, and then when active, the style comes
 from the usual fieldset legend.
 * It's likely that we can get rid of the Javascript performing the toggle
 by using newest CSS selectors.
-- 
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/0107018da2a200f3-171e39e4-c376-4d17-8fe4-e20ac5fd3638-00%40eu-central-1.amazonses.com.

Re: [Django] #35189: Accessibility issues with collapsed fieldsets in admin forms

[Django]

#35189: Accessibility issues with collapsed fieldsets in admin forms
-+-
 Reporter:  Thibaud Colas|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  5.0
 Severity:  Normal   |   Resolution:
 Keywords:  accessibility,   | Triage Stage:
  whcm, forced colors, screen|  Unreviewed
  reader, forms, admin   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-
Comment (by Marijke Luttekes):

 I'd like to pick this one up!
-- 
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/0107018da212b1c6-3fe84ac5-244f-4f68-86c3-6dce32d4e700-00%40eu-central-1.amazonses.com.

Re: [Django] #7732: Oracle Backend with SessionPool

[Django]

#7732: Oracle Backend with SessionPool
-+-
 Reporter:  halturin |Owner:  Suraj
 |  Shaw
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  yandex-sprint| Triage Stage:  Accepted
  oracle session pool|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Suraj Shaw):

 * needs_docs:  1 => 0
 * has_patch:  1 => 0
 * 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/0107018da209b947-2b8680f3-a65e-4d3d-8ada-621863a6fe7c-00%40eu-central-1.amazonses.com.

Re: [Django] #35189: Accessibility issues with collapsed fieldsets in admin forms

[Django]

#35189: Accessibility issues with collapsed fieldsets in admin forms
-+-
 Reporter:  Thibaud Colas|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  5.0
 Severity:  Normal   |   Resolution:
 Keywords:  accessibility,   | Triage Stage:
  whcm, forced colors, screen|  Unreviewed
  reader, forms, admin   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-
Description changed by Thibaud Colas:

Old description:

> There are a number of issues with the "collapsible fieldset" in admin
> forms. This can be most easily tested on flatpages, with the "Advanced
> options" fields. Here’s a [https://django-admin-
> tests.netlify.app/django_admin_tests/v5.1/english/admin/flatpages/flatpage/1/change/
> Change flat page demo page]. And a screen recording of the widget:
>
> I think there are enough problems that it makes sense to fix it all in
> one go, though the issues are technically separate.
>
> === Accessibility bugs
>
> 1. The toggle should be a ``, not a link, so screen reader and
> WHCM users understand what the element is for more easily.
> 2. The toggle needs an `aria-expanded` attribute set to true or false
> based on its current state, so screen reader users know what the state of
> the element is. See the
> [https://www.w3.org/WAI/ARIA/apg/patterns/disclosure/ APG disclosure
> pattern] for further information.
> 3. The `` element should have a ``, so the fields are
> understood to be grouped for screen reader users.
> 4. The toggle must have a minimum size of 24x24, so it’s easier for users
> with low-precision pointing devices or low mobility to hit it.
> 5. The toggle shouldn’t change size based on the length of text within
> (in English show/hide is very close, in other languages not necessarily).
> 6. The toggle’s appearance must be distinguished from other heading text
> via other means than color, so colorblind users can spot it.
> 7. In the active state, it’s impossible to tell the toggle apart from the
> other header text.
> 8. The collapsible heading is a ``, even though the whole form itself
> is titled with an ``. It should be an `` instead so screen reader
> users have a more accurate representation of the page’s hierarchy.
> 9. In forced colors mode, it’s much harder to spot the location of the
> collapsible section header/heading, as background colors aren’t shown.
>
> === Styling issues
>
> While we’re at it there are also styling issues which I think could be
> fixed at the same time:
>
> 1. The collapsible section heading’s left edge isn’t aligned with the
> left edge of other form fields’ labels (8px left padding vs. 10px
> elsewhere)
> 2. The collapsible section heading should have a font size at least as
> large as the field labels within, so the visual hierarchy is clearer.
> 3. In the active state, the collapsible section header’s styles change
> too drastically. It doesn’t need to call for attention so much, when the
> user’s focus should be on what was revealed. Ideally the toggle’s styles
> would be different, as that’s the key UI element that’s in a different
> state.
> 4. It seems odd the collapsible section header looses its rounded corners
> when in the active state.
> 5. In forced colors mode, it’s distracting that the position of the
> heading / toggle shifts due to the collapsible header area border
> disappearing.
>
> === Solution
>
> I think this is a good candidate for a full rebuild, which could keep
> some of the visual cues of the existing component but there are enough
> accessibility issues to address that it could also be more different. The
> new version should:
>
> 1. Either use a `` and `` element for the collapsing,
> or implement the [https://www.w3.org/WAI/ARIA/apg/patterns/disclosure/
> APG disclosure pattern] to spec.
> 2. Preserve any bespoke logic of the current component to show/hide based
> on form state (don’t collapse if there are form errors within?)
> 3. Use a `` for the heading and `` for the heading (probably
> `summary > h3 > legend` or `button > h3 > legend` but TBC)
> 4. Use a fixed-size toggle – possibly with a visual device such as a
> caret to convey the state without use of color. Ideally the whole section
> header area would be clickable.
> 5. Look and work great for all of the admin’s
> [https://docs.djangoproject.com/en/5.0/faq/admin/#what-assistive-
> technologies-are-supported-for-using-the-admin supported assistive
> technologies].
>
> There could be some value in using `` so this all works without
> JS, though we’d need to make sure to still 

Re: [Django] #35189: Accessibility issues with collapsed fieldsets in admin forms

[Django]

#35189: Accessibility issues with collapsed fieldsets in admin forms
-+-
 Reporter:  Thibaud Colas|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  5.0
 Severity:  Normal   |   Resolution:
 Keywords:  accessibility,   | Triage Stage:
  whcm, forced colors, screen|  Unreviewed
  reader, forms, admin   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-
Changes (by Thibaud Colas):

 * Attachment "collapsed-fieldset-django.gif" added.

 Screen recording of the "Advanced options" collapsible fieldset in
 flatpages change forms
-- 
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/0107018da1e3f879-90574b12-fc93-4670-93e9-8463a4d684d2-00%40eu-central-1.amazonses.com.

[Django] #35189: Accessibility issues with collapsed fieldsets in admin forms

[Django]

#35189: Accessibility issues with collapsed fieldsets in admin forms
-+-
   Reporter:  Thibaud|  Owner:  nobody
  Colas  |
   Type:  Bug| Status:  new
  Component: |Version:  5.0
  contrib.admin  |   Keywords:  accessibility,
   Severity:  Normal |  whcm, forced colors, screen reader,
   Triage Stage: |  forms, admin
  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  1  |
-+-
 There are a number of issues with the "collapsible fieldset" in admin
 forms. This can be most easily tested on flatpages, with the "Advanced
 options" fields. Here’s a [https://django-admin-
 
tests.netlify.app/django_admin_tests/v5.1/english/admin/flatpages/flatpage/1/change/
 Change flat page demo page]. And a screen recording of the widget:

 I think there are enough problems that it makes sense to fix it all in one
 go, though the issues are technically separate.

 === Accessibility bugs

 1. The toggle should be a ``, not a link, so screen reader and
 WHCM users understand what the element is for more easily.
 2. The toggle needs an `aria-expanded` attribute set to true or false
 based on its current state, so screen reader users know what the state of
 the element is. See the
 [https://www.w3.org/WAI/ARIA/apg/patterns/disclosure/ APG disclosure
 pattern] for further information.
 3. The `` element should have a ``, so the fields are
 understood to be grouped for screen reader users.
 4. The toggle must have a minimum size of 24x24, so it’s easier for users
 with low-precision pointing devices or low mobility to hit it.
 5. The toggle shouldn’t change size based on the length of text within (in
 English show/hide is very close, in other languages not necessarily).
 6. The toggle’s appearance must be distinguished from other heading text
 via other means than color, so colorblind users can spot it.
 7. In the active state, it’s impossible to tell the toggle apart from the
 other header text.
 8. The collapsible heading is a ``, even though the whole form itself
 is titled with an ``. It should be an `` instead so screen reader
 users have a more accurate representation of the page’s hierarchy.
 9. In forced colors mode, it’s much harder to spot the location of the
 collapsible section header/heading, as background colors aren’t shown.

 === Styling issues

 While we’re at it there are also styling issues which I think could be
 fixed at the same time:

 1. The collapsible section heading’s left edge isn’t aligned with the left
 edge of other form fields’ labels (8px left padding vs. 10px elsewhere)
 2. The collapsible section heading should have a font size at least as
 large as the field labels within, so the visual hierarchy is clearer.
 3. In the active state, the collapsible section header’s styles change too
 drastically. It doesn’t need to call for attention so much, when the
 user’s focus should be on what was revealed. Ideally the toggle’s styles
 would be different, as that’s the key UI element that’s in a different
 state.
 4. It seems odd the collapsible section header looses its rounded corners
 when in the active state.
 5. In forced colors mode, it’s distracting that the position of the
 heading / toggle shifts due to the collapsible header area border
 disappearing.

 === Solution

 I think this is a good candidate for a full rebuild, which could keep some
 of the visual cues of the existing component but there are enough
 accessibility issues to address that it could also be more different. The
 new version should:

 1. Either use a `` and `` element for the collapsing, or
 implement the [https://www.w3.org/WAI/ARIA/apg/patterns/disclosure/ APG
 disclosure pattern] to spec.
 2. Preserve any bespoke logic of the current component to show/hide based
 on form state (don’t collapse if there are form errors within?)
 3. Use a `` for the heading and `` for the heading (probably
 `summary > h3 > legend` or `button > h3 > legend` but TBC)
 4. Use a fixed-size toggle – possibly with a visual device such as a caret
 to convey the state without use of color. Ideally the whole section header
 area would be clickable.
 5. Look and work great for all of the admin’s
 [https://docs.djangoproject.com/en/5.0/faq/admin/#what-assistive-
 technologies-are-supported-for-using-the-admin supported assistive
 technologies].

 There could be some value in using `` so this all works without
 JS, though we’d need to make sure to still support any JS-dependent
 behavior of the collapsible section.
-- 
Ticket URL: 
Django 

Re: [Django] #35167: JSONFIeld get_db_prep_value being called with `Cast` types

[Django]

#35167: JSONFIeld get_db_prep_value being called with `Cast` types
-+-
 Reporter:  Samantha Hughes  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  4.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  JSONField| Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Krish):

 * cc: Krish (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/0107018da1dadfc4-b7793eac-be3e-4cd7-b21c-bed38ae26b43-00%40eu-central-1.amazonses.com.

Re: [Django] #35188: Redirect URI Mismatch with Box API

[Django]

#35188: Redirect URI Mismatch with Box API
--+--
 Reporter:  Arnautt   |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  contrib.auth  |  Version:  5.0
 Severity:  Normal|   Resolution:  invalid
 Keywords:| Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by David Sanders):

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

Comment:

 Trac is not a support request channel. If you need help setting up Django
 you can get help from a friendly community member in one of the official
 support channels: https://www.djangoproject.com/community/ ☺️
-- 
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/0107018da1c555a1-7da53b40-a0bf-4fd6-aa0c-203a4aab745b-00%40eu-central-1.amazonses.com.

[Django] #35188: Redirect URI Mismatch with Box API

[Django]

#35188: Redirect URI Mismatch with Box API
+
   Reporter:  Arnautt   |  Owner:  nobody
   Type:  Bug   | Status:  new
  Component:  contrib.auth  |Version:  5.0
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 When attempting to authenticate with the Box API, user encounter a
 "redirect_uri_mismatch" error. Here are the steps to reproduce :


 - Set up a Box application and configure the redirect URI to
 http://localhost:8000/

 - Create the minimal example to reproduce the error

 1. **settings.py**


 {{{
 BOX_CLIENT_ID = 'YOUR_BOX_CLIENT_ID'
 BOX_CLIENT_SECRET = 'YOUR_BOX_CLIENT_SECRET'
 }}}


 2. **views.py**


 {{{
 from django.shortcuts import redirect
 from django.conf import settings
 from boxsdk import OAuth2

 def authenticate_with_box(request):
 oauth = OAuth2(
 client_id=settings.BOX_CLIENT_ID,
 client_secret=settings.BOX_CLIENT_SECRET,
 )
 auth_url, csrf_token =
 
oauth.get_authorization_url(redirect_url=request.build_absolute_uri(reverse('upload')))
 request.session['csrf_token'] = csrf_token
 return redirect(auth_url)

 def upload(request):
 return render(request, "upload.html", {'access_token':
 request.session["access_token"]})

 }}}


 3. **urls.py**


 {{{
 from django.urls import path
 from .views import authenticate_with_box

 urlpatterns = [
 path('', authenticate_with_box, name='authenticate_with_box'),
 path('upload/', views.upload, name='upload'),
 ]
 }}}


 - Run the server


 {{{
 python manage.py runserver
 }}}
-- 
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/0107018da1bdd1f9-bccaada7-e600-4d87-af8e-a756dad802f6-00%40eu-central-1.amazonses.com.