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

[Django]

#30686: Improve utils.text.Truncator  to use a full HTML parser.
-+-
 Reporter:  Thomas Hooper|Owner:  David
 |  Smith
 Type:  Bug  |   Status:  closed
Component:  Utilities|  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:"3cadeea077a98367a4ed344d645df0aff243de91" 3cadeea]:
 {{{#!CommitTicketReference repository=""
 revision="3cadeea077a98367a4ed344d645df0aff243de91"
 Refs #30686 -- Removed unused regexes in django.utils.text.

 Unused since 6ee37ada3241ed263d8d1c2901b030d964cbd161.
 }}}
-- 
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/0107018dabb4aae2-ac981527-524a-4c29-b096-1d0588adfcf5-00%40eu-central-1.amazonses.com.

Re: [Django] #35196: auto running of server is not working , when making changes in admin.py [Django==4.2.10]

[Django]

#35196: auto running of server is not working , when making changes in admin.py
[Django==4.2.10]
--+--
 Reporter:  krishnkantdhakad  |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  contrib.admin |  Version:  4.2
 Severity:  Normal|   Resolution:  invalid
 Keywords:| Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by David Sanders):

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

Comment:

 Hi & thanks for the report, though this is correct behaviour: the dev
 server will not reload if there's an exception.
-- 
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/0107018dabb315d1-80092915-b21b-4307-8972-c63703e6f6cb-00%40eu-central-1.amazonses.com.

Re: [Django] #35196: auto running of server is not working , when making changes in admin.py [Django==4.2.10]

[Django]

#35196: auto running of server is not working , when making changes in admin.py
[Django==4.2.10]
--+--
 Reporter:  krishnkantdhakad  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.admin |  Version:  4.2
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Description changed by krishnkantdhakad:

Old description:

> When I'm making changes on the live development server, if I make any
> errors in view.py and fix them, the server auto-reloads. However, this
> isn't happening with admin.py. The error message is breaking the server's
> auto-running
> it happened on my both mac and linux machines
>
> {{{
>
> File "/Users/krishnkant/Merumesh/venv/lib/python3.10/site-
> packages/django/utils/module_loading.py", line 58, in
> autodiscover_modules
> import_module("%s.%s" % (app_config.name, module_to_search))
>   File
> "/opt/homebrew/Cellar/python@3.10/3.10.13_2/Frameworks/Python.framework/Versions/3.10/lib/python3.10/importlib/__init__.py",
> line 126, in import_module
> return _bootstrap._gcd_import(name[level:], package, level)
>   File "", line 1050, in _gcd_import
>   File "", line 1027, in _find_and_load
>   File "", line 1006, in
> _find_and_load_unlocked
>   File "", line 688, in _load_unlocked
>   File "", line 883, in exec_module
>   File "", line 241, in
> _call_with_frames_removed
>   File "/Users/krishnkant/Merumesh/Saas-backend-api/users/admin.py", line
> 7, in 
> admin.site.register(Organization)
>   File "/Users/krishnkant/Merumesh/venv/lib/python3.10/site-
> packages/django/contrib/admin/sites.py", line 132, in register
> raise AlreadyRegistered(msg)
> django.contrib.admin.sites.AlreadyRegistered: The model Organization is
> already registered in app 'users'.
> }}}

New description:

 When I'm making changes on the live development server, if I make any
 errors in view.py and fix them, the server auto-reloads. However, this
 isn't happening with admin.py. The error message is breaking the server's
 auto-running
 it happened on my both mac and linux machines

 {{{

 File "/Users/krishnkant/venv/lib/python3.10/site-
 packages/django/utils/module_loading.py", line 58, in autodiscover_modules
 import_module("%s.%s" % (app_config.name, module_to_search))
   File
 
"/opt/homebrew/Cellar/python@3.10/3.10.13_2/Frameworks/Python.framework/Versions/3.10/lib/python3.10/importlib/__init__.py",
 line 126, in import_module
 return _bootstrap._gcd_import(name[level:], package, level)
   File "", line 1050, in _gcd_import
   File "", line 1027, in _find_and_load
   File "", line 1006, in
 _find_and_load_unlocked
   File "", line 688, in _load_unlocked
   File "", line 883, in exec_module
   File "", line 241, in
 _call_with_frames_removed
   File "/Users/krishnkant/Saas-backend-api/users/admin.py", line 7, in
 
 admin.site.register(Organization)
   File "/Users/krishnkant/venv/lib/python3.10/site-
 packages/django/contrib/admin/sites.py", line 132, in register
 raise AlreadyRegistered(msg)
 django.contrib.admin.sites.AlreadyRegistered: The model Organization is
 already registered in app 'users'.
 }}}

--
-- 
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/0107018dabac4b7b-5e55a830-51a8-421e-8fb7-dee8561d268a-00%40eu-central-1.amazonses.com.

[Django] #35196: auto running of server is not working , when making changes in admin.py [Django==4.2.10]

[Django]

#35196: auto running of server is not working , when making changes in admin.py
[Django==4.2.10]
+
   Reporter:  krishnkantdhakad  |  Owner:  nobody
   Type:  Bug   | Status:  new
  Component:  contrib.admin |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 |
+
 When I'm making changes on the live development server, if I make any
 errors in view.py and fix them, the server auto-reloads. However, this
 isn't happening with admin.py. The error message is breaking the server's
 auto-running
 it happened on my both mac and linux machines

 {{{

 File "/Users/krishnkant/Merumesh/venv/lib/python3.10/site-
 packages/django/utils/module_loading.py", line 58, in autodiscover_modules
 import_module("%s.%s" % (app_config.name, module_to_search))
   File
 
"/opt/homebrew/Cellar/python@3.10/3.10.13_2/Frameworks/Python.framework/Versions/3.10/lib/python3.10/importlib/__init__.py",
 line 126, in import_module
 return _bootstrap._gcd_import(name[level:], package, level)
   File "", line 1050, in _gcd_import
   File "", line 1027, in _find_and_load
   File "", line 1006, in
 _find_and_load_unlocked
   File "", line 688, in _load_unlocked
   File "", line 883, in exec_module
   File "", line 241, in
 _call_with_frames_removed
   File "/Users/krishnkant/Merumesh/Saas-backend-api/users/admin.py", line
 7, in 
 admin.site.register(Organization)
   File "/Users/krishnkant/Merumesh/venv/lib/python3.10/site-
 packages/django/contrib/admin/sites.py", line 132, in register
 raise AlreadyRegistered(msg)
 django.contrib.admin.sites.AlreadyRegistered: The model Organization is
 already registered in app 'users'.
 }}}
-- 
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/0107018dabaa5fb6-e9b17f5b-a57c-47d2-9565-4f6ee2375e12-00%40eu-central-1.amazonses.com.

Re: [Django] #35187: @sensitive_variables/sensitive_post_parameters decorators crash with .pyc-only builds. (was: Django 5.0+ doesn't work with pyc files only)

[Django]

#35187: @sensitive_variables/sensitive_post_parameters decorators crash with 
.pyc-
only builds.
-+
 Reporter:  Marcus Hoffmann  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Other) |  Version:  5.0
 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 Mariusz Felisiak):

 * summary:  Django 5.0+ doesn't work with pyc files only =>
 @sensitive_variables/sensitive_post_parameters decorators crash with
 .pyc-only builds.
 * severity:  Normal => Release blocker
 * stage:  Unreviewed => Accepted

-- 
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/0107018dab30901d-22039c28-a6be-4ba5-bf3e-e815d7a95614-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 Mariusz Felisiak):

 Replying to [comment:6 Jon Janzen]:
 > I think there are alternatives, I don't really have time to explore them
 right now but:
 >
 > 1. Use a different cache key, like swap the line number for the function
 name perhaps

 Great idea! Marcus, does it work for you?
 {{{#!diff
 diff --git a/django/views/decorators/debug.py
 b/django/views/decorators/debug.py
 index 7ea8a540de..6540fc0651 100644
 --- a/django/views/decorators/debug.py
 +++ b/django/views/decorators/debug.py
 @@ -47,7 +47,6 @@ def sensitive_variables(*variables):

  try:
  file_path = inspect.getfile(wrapped_func)
 -_, first_file_line = inspect.getsourcelines(wrapped_func)
  except TypeError:  # Raises for builtins or native functions.
  raise ValueError(
  f"{func.__name__} cannot safely be wrapped by "
 @@ -55,7 +54,8 @@ def sensitive_variables(*variables):
  "Python file (not a builtin or from a native
 extension)."
  )
  else:
 -key = hash(f"{file_path}:{first_file_line}")
 +first_line_number = wrapped_func.__code__.co_firstlineno
 +key = hash(f"{file_path}:{first_line_number}")

  if variables:
  coroutine_functions_to_sensitive_variables[key] =
 variables

 }}}
-- 
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/0107018dab2e2642-2bbe3354-8d46-4a28-83ad-9b07005a73a5-00%40eu-central-1.amazonses.com.

Re: [Django] #35173: DisallowedModelAdminLookup raised when filtering with __isnull on a ForeignKey not listed in list_filters

[Django]

#35173: DisallowedModelAdminLookup raised when filtering with __isnull on a
ForeignKey not listed in list_filters
-+-
 Reporter:  Stian Jensen |Owner:  Hisham
 |  Mahmood
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  5.0
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by GitHub ):

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

Comment:

 In [changeset:"8db593de05c3516c939b7d4b9eb91e8791f4c79a" 8db593de]:
 {{{#!CommitTicketReference repository=""
 revision="8db593de05c3516c939b7d4b9eb91e8791f4c79a"
 Fixed #35173 -- Fixed ModelAdmin.lookup_allowed() for lookups on foreign
 keys when not included in ModelAdmin.list_filter.

 Regression in f80669d2f5a5f1db9e9b73ca893fefba34f955e7.

 Thanks Sarah Boyce for the review.
 }}}
-- 
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/0107018daa6272f6-8a3e0905-f58a-48de-b1be-96a26011d6c3-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 Jon Janzen):

 > As far as I'm aware, the only way to fix this is to revert

 I think there are alternatives, I don't really have time to explore them
 right now but:

 1. Use a different cache key, like swap the line number for the function
 name perhaps
 2. I think the code object stores the line numbers right? So perhaps
 there's a way to fetch the code object and get the line number that way.

 If the above commit is reverted I think we'd have to think about reverting
 other things that depend on it like
 https://github.com/django/django/pull/16636
-- 
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/0107018daa4efa17-80c2bf1f-f6ec-44b5-a5fc-00bdfdd8bd4b-00%40eu-central-1.amazonses.com.

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

[Django]

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

 * 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/0107018da909e27d-251dcd71-dce2-476f-b6d8-a65ff8a12778-00%40eu-central-1.amazonses.com.

Re: [Django] #21065: Internally choosing how to process a template is inconsistent

[Django]

#21065: Internally choosing how to process a template is inconsistent
-+-
 Reporter:  Keryn Knight |Owner:  nobody
   |
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Template system  |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by bcail):

 * cc: bcail (added)

Comment:

 One option would be to add a `resolve_template()` method/function to the
 engine and loader modules. The `resolve_template()` function could handle
 choosing between `select_template()` and `get_template()`.

 This would allow removing `resolve_template()` in
 `SimpleTemplateResponse`, and `Engine.render_to_string` and
 `InclusionNode` could use the `resolve_template()` in the `engine` module.

 If there's interest in this, I could open a 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/0107018da8ea08b5-41d7b2cc-b48a-4355-8cb1-2459ed12940f-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:  Marijke
 Type:   |  Luttekes
  Cleanup/optimization   |   Status:  assigned
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
-+-
Comment (by Marijke Luttekes):

 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.

 Agreed. When toggling the fieldset, the element also seems to move a
 pixel, which is visually unpleasing
 I will switch to straight edges for these items.

   It's likely that we can get rid of the Javascript performing the toggle
 by using newest CSS selectors.

 My original idea for a fix does use a little JavaScript (no jQuery).
 I will check with the accessibility team if they know of a better method,
 e.g., using a checkbox in HTML and the `:checked` CSS pseudo-class
 selector.
-- 
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/0107018da8a1382a-fab17f69-8c13-45ff-9913-ba95dd98e03d-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:

 I reverted the "IF NOT EXISTS" changes, and split out the create-new-index
 and recreate-deleted-index conditions into separate methods.
-- 
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/0107018da881d6ba-6c7884c4-ca83-455b-a691-ab2174f71594-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:  Marijke
 Type:   |  Luttekes
  Cleanup/optimization   |   Status:  assigned
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 Marijke Luttekes):

 * owner:  nobody => Marijke Luttekes
 * status:  new => assigned

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018da8588da4-6af858e0-f6aa-492e-875e-833c4e2b9c7f-00%40eu-central-1.amazonses.com.

Re: [Django] #35167: JSONField get_db_prep_value being called with `Cast` types (was: 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 Jacob Walls):

 * cc: Jacob Walls (added)
 * summary:  JSONFIeld get_db_prep_value being called with `Cast` types =>
 JSONField get_db_prep_value being called with `Cast` types

-- 
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/0107018da84fb5bb-c7ccad51-4a55-49e3-b362-195e669b806e-00%40eu-central-1.amazonses.com.

Re: [Django] #35195: Remove type="text/css" from

[Django]

#35195: Remove type="text/css" from 

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 Mariusz Felisiak):

 * cc: Jon Janzen (added)

Comment:

 As far as I'm aware, the only way to fix this is to revert
 38e391e95fe5258bc6d2467332dc9cd44ce6ba52.
-- 
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/0107018da82e23db-5093c211-788b-491b-877f-5d0f18bd720e-00%40eu-central-1.amazonses.com.

Re: [Django] #35195: Remove type="text/css" from

[Django]

#35195: Remove type="text/css" from 

Re: [Django] #35195: Remove type="text/css" from

[Django]

#35195: Remove type="text/css" from 

Re: [Django] #35195: Remove type="text/css" from

[Django]

#35195: Remove type="text/css" from 

Re: [Django] #35195: Remove type="text/css" from

[Django]

#35195: Remove type="text/css" from 

Re: [Django] #35195: Remove type="text/css" from

[Django]

#35195: Remove type="text/css" from 

Re: [Django] #24018: Support setting pragma options for SQLite. (was: Support journal_mode=WAL for sqlite)

[Django]

#24018: Support setting pragma options for SQLite.
-+-
 Reporter:  Curtis Maloney   |Owner:  Aaron
 |  Linville
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 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):

 * summary:  Support journal_mode=WAL for sqlite => Support setting pragma
 options for SQLite.

-- 
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/0107018da805ffb0-76042149-05cf-4588-8cd6-96577aee7f7e-00%40eu-central-1.amazonses.com.

Re: [Django] #35195: Remove type="text/css" from

[Django]

#35195: Remove type="text/css" from 

[Django] #35195: Remove all type="text/css" attributes

[Django]

#35195: Remove all type="text/css" attributes
+
   Reporter:  cosmicproc|  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Uncategorized |Version:  5.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:  0 |
+
 The attribute {{{type="text/css"}}} is unnecessary for 

Re: [Django] #35179: Admindocs does not recognize methods containing positional-only arguments or keyword-only arguments as such

[Django]

#35179: Admindocs does not recognize methods containing positional-only 
arguments
or keyword-only arguments as such
-+-
 Reporter:  David Sanders|Owner:  Salvo
 |  Polizzi
 Type:  Bug  |   Status:  closed
Component:  contrib.admindocs|  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
-+-
Changes (by Mariusz Felisiak ):

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

Comment:

 In [changeset:"e6fa74f02068b2c112de41e9c785f31041668a64" e6fa74f]:
 {{{#!CommitTicketReference repository=""
 revision="e6fa74f02068b2c112de41e9c785f31041668a64"
 Fixed #35179 -- Made admindocs detect positional/keyword-only arguments.
 }}}
-- 
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/0107018da7b05f65-3920f83f-0ef8-45a5-bedf-f223a9763498-00%40eu-central-1.amazonses.com.

Re: [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 van Leeuwen |Owner:  Almaz
 Type:  New feature  |   Status:  closed
Component:  Forms|  Version:  5.0
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  forms render | Triage Stage:
  template   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Comment (by Oxan van Leeuwen):

 I agree there are more templates that the renderer can't override, but in
 practice those are less of a problem, as it's easy to just not use them in
 your form and field templates. For example `ErrorDict` and `ErrorList` are
 thin wrappers around `dict` and `list` respectively, and you can iterate
 over those directly in the field template to generate an error list in
 whatever style you want. That's not the case for the label template, as
 `BoundField.label_tag()` contains (among other things) somewhat complex
 logic to generate the value for the `for` attribute that can't easily be
 replicated in a template. Furthermore, even if you do replicate it, I'd be
 worried about that logic being considered an implementation detail and
 changing in a future version of Django.

 What would also work is to extract the logic that generates the id and
 contents from `label_tag()` out into separate methods (or properties) of
 `BoundField`, which can then be used directly in the field template.

 The wider context here (and also behind #35192) is that I'm trying to
 implement something that renders forms in a way that's usable with
 existing frontend frameworks (such as Bootstrap or Tailwind). Current
 attempts at this (such as [https://github.com/django-crispy-forms/django-
 crispy-forms django-crispy-forms] or [https://github.com/zostera/django-
 bootstrap5 django-bootstrap5]) all render using a custom template tag,
 whose implementation pokes around in the internals of the forms component.
 In my experience those always have hardcoded special casing and can't
 support the full feature set and extensibility of the forms component.
 It'd be great if something like that could be implemented in plain Django,
 working along with instead of around the forms component. Form renderers
 seem like the logical extension point for such an implementation, and
 they're nearly there, but at the moment they are a bit too inflexible to
 cleanly allow all necessary customization.
-- 
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/0107018da79ae245-a74138cd-e4aa-4266-85ff-2e94030fd9a6-00%40eu-central-1.amazonses.com.

Re: [Django] #35179: Admindocs does not recognize methods containing positional-only arguments or keyword-only arguments as such

[Django]

#35179: Admindocs does not recognize methods containing positional-only 
arguments
or keyword-only arguments as such
-+-
 Reporter:  David Sanders|Owner:  Salvo
 |  Polizzi
 Type:  Bug  |   Status:  assigned
Component:  contrib.admindocs|  Version:  dev
 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):

 * owner:  nobody => Salvo Polizzi
 * status:  new => assigned
 * 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/0107018da78ebf09-902c1505-c1c5-4ec3-9ffa-37608dcbb338-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:  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/0107018da7802e20-bc9306ce-5b44-47f1-b529-b4f54ac8f27e-00%40eu-central-1.amazonses.com.

Re: [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 van Leeuwen |Owner:  Almaz
 Type:  New feature  |   Status:  closed
Component:  Forms|  Version:  5.0
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  forms render | Triage Stage:
  template   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Comment (by Mariusz Felisiak):

 > There's also the matter of consistency: the form, formset and field
 templates can already be changed by the renderer, why not the label?

 There are also many templates that the renderer cannot override, such as
 `ErrorDict` or `ErrorList` templates. There are also many templates that
 the renderer cannot override, such as `ErrorDict` or `ErrorList`
 templates. Adding a new customization option is always a bit controversial
 (we already have many of them).
-- 
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/0107018da77c6460-5e6a5f3f-0fe6-4293-991b-351c6038fd0e-00%40eu-central-1.amazonses.com.

Re: [Django] #35193: Range dumper assumes timezone aware datetimes. (was: Timezone unaware datetimes and psycopg 3)

[Django]

#35193: Range dumper assumes timezone aware datetimes.
-+-
 Reporter:  Mapiarz  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  4.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  psycopg3 | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * status:  new => closed
 * cc: Florian Apolloner (added)
 * resolution:   => invalid
 * summary:  Timezone unaware datetimes and psycopg 3 => Range dumper
 assumes timezone aware datetimes.
 * keywords:   => psycopg3
 * type:  Uncategorized => Bug

Comment:

 Thanks for the report. As far as I'm aware, there is no way in the dumper
 to detect that you're using `tsrange` and change the behavior. You should
 be able to use
 
[https://www.psycopg.org/psycopg3/docs/api/adapt.html#psycopg.adapt.AdaptersMap.register_dumper
 register_dumper()] to override the dumper.
-- 
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/0107018da76eb2c1-452391f7-c6fa-461d-a3cd-98563da9a3f8-00%40eu-central-1.amazonses.com.

Re: [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 van Leeuwen |Owner:  Almaz
 Type:  New feature  |   Status:  closed
Component:  Forms|  Version:  5.0
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  forms render | Triage Stage:
  template   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Comment (by Oxan van Leeuwen):

 The problem with overriding the default template is that it's global to
 the project, while form renderers are local to the form. This is useful
 e.g. if there multiple different form layouts are used within a project,
 or when incrementally transitioning between design systems. There's also
 the matter of consistency: the form, formset and field templates can
 already be changed by the renderer, why not the label? After all, the
 default template for those could also be globally overridden.
-- 
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/0107018da76be765-400cdcb4-5ee1-49d6-877d-4340ef80395e-00%40eu-central-1.amazonses.com.

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

[Django]

#35192: Support injecting custom context into widget templates
-+-
 Reporter:  Oxan van Leeuwen |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Forms|  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 Mariusz Felisiak):

 * cc: David Smith (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/0107018da7655c44-2bb1ad05-8295-4ba1-bb70-78b70c0b2ced-00%40eu-central-1.amazonses.com.

Re: [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 van Leeuwen |Owner:  Almaz
 Type:  New feature  |   Status:  closed
Component:  Forms|  Version:  5.0
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  forms render | Triage Stage:
  template   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * cc: David Smith (added)
 * status:  assigned => closed
 * resolution:   => wontfix
 * easy:  1 => 0
 * type:  Cleanup/optimization => New feature

Comment:

 I don't think a new attribute is needed. You can always
 [https://docs.djangoproject.com/en/5.0/ref/forms/renderers/#overriding-
 built-in-form-templates override the default template] as any other
 template in your project.
-- 
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/0107018da75eead2-0b4bb8c5-3bfa-4f7e-8f17-6315b4d2bc3c-00%40eu-central-1.amazonses.com.

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

[Django]

#35194: Postgres 16.2 with _iexact leads to IndeterminateCollation
-+-
 Reporter:  Aldalen  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * owner:  (none) => nobody
 * resolution:   => needsinfo
 * status:  new => closed
 * component:  contrib.postgres => Database layer (models, ORM)
 * summary:
 Postgres 16.2 with _iexact leads to
 psycopg2.errors.IndeterminateCollation
 => Postgres 16.2 with _iexact leads to IndeterminateCollation

Comment:

 Thanks for the report, this looks like a bug in PostgreSQL. I couldn't
 find anything related with this change in PostgreSQL 16.2 release notes.
 I've checked a few ways to define that kind of expression in the
 `GeneratedField` and it seems to be related to calling `UPPER()` on
 strings:
 - `models.GeneratedField(expression=models.Q(test__iexact='yes'),
 output_field=models.BooleanField(), db_persist=True)` crashes 
   - SQL:
 {{{#!sql
 "test_gen" boolean GENERATED ALWAYS AS (UPPER("test"::text) =
 UPPER('yes')) STORED
 }}}
 - `models.GeneratedField(expression=lookups.Exact(Upper("test"), "YES"),
 output_field=models.BooleanField(), db_persist=True)` works ✅
   - SQL:
 {{{#!sql
 "test_gen" boolean GENERATED ALWAYS AS (UPPER("test") = ('YES')) STORED
 }}}
 Removing `::text` doesn't change anything, it also crashes :
 {{{#!sql
 "test_gen" boolean GENERATED ALWAYS AS (UPPER("test") = UPPER('yes'))
 STORED
 }}}

 Please reopen the ticket if you provide details that this is an
 intentional behavior change in PostgreSQL.
-- 
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/0107018da74eb99f-bc660763-acc3-4b5e-8a9b-cffd15e8a9bc-00%40eu-central-1.amazonses.com.

Re: [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 van Leeuwen |Owner:  Almaz
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Forms|  Version:  5.0
 Severity:  Normal   |   Resolution:
 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
-+-
Changes (by Almaz):

 * owner:  nobody => Almaz
 * status:  new => assigned

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018da6f1a1f4-bb54ab6e-03fd-459e-97a0-cdf42cc6867d-00%40eu-central-1.amazonses.com.