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

[Django]

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

Comment (by Mateusz Więckowski):

 I'm using cmd. I did some changes to "non-interactive" part in Django's
 createsuperuser.py

 It's rather quick, so you could do it yourself and check:
 Move this line:
 
https://github.com/django/django/blob/main/django/contrib/auth/management/commands/createsuperuser.py#L226
 above the if statement at the line 222
 In the if itself add the following:
 {{{
 if field.blank and options[field_name] is not None:
 continue
 }}}

-- 
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/01070189677e4d85-3fb601f7-6b63-4cc0-82f7-5436ef76129f-00%40eu-central-1.amazonses.com.

Re: [Django] #34716: Class methods from nested classes cannot be used as Field.default.

[Django]

#34716: Class methods from nested classes cannot be used as Field.default.
-+-
 Reporter:  Nicolò Intrieri  |Owner:  Nicolò
 |  Intrieri
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  4.2
 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:"e8252fc4451ee2c05779b28e74417174f0a2eeef" e8252fc]:
 {{{
 #!CommitTicketReference repository=""
 revision="e8252fc4451ee2c05779b28e74417174f0a2eeef"
 Fixed #34716 -- Fixed serialization of nested class methods in migrations.

 Co-authored-by: Nicolò 
 }}}

-- 
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/01070189670a2d32-aa548242-7523-429c-990f-eebd3c0d9ba2-00%40eu-central-1.amazonses.com.

Re: [Django] #34720: BaseReloader.watch_dir() incorrectly checks for existence of path

[Django]

#34720: BaseReloader.watch_dir() incorrectly checks for existence of path
---+
 Reporter:  Josh   |Owner:  Josh
 Type:  Bug|   Status:  assigned
Component:  Utilities  |  Version:  4.2
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by Josh):

 * 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/0107018966d5e689-7cc0a7c7-9a59-4733-b673-76d6aff3a731-00%40eu-central-1.amazonses.com.

Re: [Django] #34720: BaseReloader.watch_dir() incorrectly checks for existence of path

[Django]

#34720: BaseReloader.watch_dir() incorrectly checks for existence of path
---+
 Reporter:  Josh   |Owner:  Josh
 Type:  Bug|   Status:  assigned
Component:  Utilities  |  Version:  4.2
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by Josh):

 * owner:  nobody => Josh
 * 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/0107018966aded09-737f0b48-7fdb-4288-ad79-734ce30bd670-00%40eu-central-1.amazonses.com.

Re: [Django] #34036: Low text contrast over light blue backgrounds in admin light theme

[Django]

#34036: Low text contrast over light blue backgrounds in admin light theme
-+-
 Reporter:  Thibaud Colas|Owner:  Mariana
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  Version:  4.0
 Severity:  Normal   |   Resolution:
 Keywords:  accessibility,   | Triage Stage:  Accepted
  color contrast, ux |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-
Changes (by Mariana):

 * needs_better_patch:  1 => 0


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/01070189663016ba-93815ff9-1409-41ec-8a42-c6872955535f-00%40eu-central-1.amazonses.com.

Re: [Django] #34720: BaseReloader.watch_dir() incorrectly checks for existence of path

[Django]

#34720: BaseReloader.watch_dir() incorrectly checks for existence of path
---+
 Reporter:  Josh   |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Utilities  |  Version:  4.2
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by Simon Charette):

 * component:  Uncategorized => Utilities
 * stage:  Unreviewed => Accepted


Comment:

 Looking at #30647 (fc75694257b5bceab82713f84fe5a1b23d641c3f) it seems that
 `absolute` actually did raise previously on Python 3.6 at least hence the
 wrapping here.

 Given `absolute` is not meant to raise in the first place then I think
 that calling `.resolve()` explicitly as Jeff pointed out might be the
 right way to go here. That should also allow us to remove
 
[https://github.com/django/django/blob/4a72da71001f154ea60906a2f74898d32b7322a7/tests/utils_tests/test_autoreload.py#L671-L675
 the mocking in the test].

 Feel free to assign the ticket to you and work on it.

-- 
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/01070189661e3998-997e51e2-7735-4292-937e-5feccb038658-00%40eu-central-1.amazonses.com.

Re: [Django] #34720: BaseReloader.watch_dir() incorrectly checks for existence of path

[Django]

#34720: BaseReloader.watch_dir() incorrectly checks for existence of path
---+--
 Reporter:  Josh   |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Uncategorized  |  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
---+--

Comment (by Jeff Triplett):

 If the goal is to raise the exception, `Path.resolve(strict=False)` might
 also be worth taking a look at to raise the FileNotFoundError exception.
 See: https://docs.python.org/3/library/pathlib.html#pathlib.Path.resolve

-- 
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/0107018966159b14-16cb7b1c-6ca2-4261-a61b-9ffc63f212a5-00%40eu-central-1.amazonses.com.

Re: [Django] #34720: BaseReloader.watch_dir() incorrectly checks for existence of path

[Django]

#34720: BaseReloader.watch_dir() incorrectly checks for existence of path
---+--
 Reporter:  Josh   |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Uncategorized  |  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 Josh:

Old description:

> Within the `watch_dir` method in `django.utils.autoreload.BaseReloader`,
> the path is checked by calling on the `absolute` method on the `Path`
> object:
>
> {{{
> def watch_dir(self, path, glob):
> path = Path(path)
> try:
> path = path.absolute()
> except FileNotFoundError:
> logger.debug(
> "Unable to watch directory %s as it cannot be resolved.",
> path,
> exc_info=True,
> )
> return
> logger.debug("Watching dir %s with glob %s.", path, glob)
> self.directory_globs[path].add(glob)
> }}}
>
> Except `absolute` doesn't raise, it just returns the absolute path.
> Should be changed to an if check on `path.exists()`:
>
> {{{
> Python 3.11.4 (main, Jul 17 2023, 15:40:49) [GCC 9.4.0]
> Type 'copyright', 'credits' or 'license' for more information
> IPython 8.14.0 -- An enhanced Interactive Python. Type '?' for help.
>
> In [1]: from pathlib import Path
>
> In [2]: Path('/home/josh/projects/django/nonexistent').absolute()
> Out[2]: PosixPath('/home/josh/projects/django/nonexistent')
>
> In [3]: Path('/home/josh/projects/django/nonexistent').exists()
> Out[3]: False
> }}}
>
> Willing to prepare a patch.

New description:

 Within the `watch_dir` method in `django.utils.autoreload.BaseReloader`,
 the path is checked by calling on the `absolute` method on the `Path`
 object:

 {{{
 def watch_dir(self, path, glob):
 path = Path(path)
 try:
 path = path.absolute()
 except FileNotFoundError:
 logger.debug(
 "Unable to watch directory %s as it cannot be resolved.",
 path,
 exc_info=True,
 )
 return
 logger.debug("Watching dir %s with glob %s.", path, glob)
 self.directory_globs[path].add(glob)
 }}}

 Except `absolute` doesn't raise, it just returns the absolute path. Should
 be changed to an if check on `path.exists()`:

 {{{
 Python 3.11.4 (main, Jul 17 2023, 15:40:49) [GCC 9.4.0]
 Type 'copyright', 'credits' or 'license' for more information
 IPython 8.14.0 -- An enhanced Interactive Python. Type '?' for help.

 In [1]: from pathlib import Path

 In [2]: Path('/home/josh/projects/django/nonexistent').absolute()
 Out[2]: PosixPath('/home/josh/projects/django/nonexistent')

 In [3]: Path('/home/josh/projects/django/nonexistent').exists()
 Out[3]: False
 }}}

 Willing to prepare a patch. I'm not sure of the etiquette behind self-
 assigning a ticket before it's been reviewed, so I'm just leaving it
 unassigned for now.

--

-- 
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/0107018965fcee5b-ed54fae5-3414-4f65-a2ca-2c598dca105f-00%40eu-central-1.amazonses.com.

Re: [Django] #34720: BaseReloader.watch_dir() incorrectly checks for existence of path (was: Path checking in BaseReloader.watch_dir() incorrectly checks for existence of path)

[Django]

#34720: BaseReloader.watch_dir() incorrectly checks for existence of path
---+--
 Reporter:  Josh   |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Uncategorized  |  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
---+--

-- 
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/0107018965e0f5bd-14bf1ffe-a834-4d31-ae19-2acda2ea6d21-00%40eu-central-1.amazonses.com.

[Django] #34720: Path checking in BaseReloader.watch_dir() incorrectly checks for existence of path

[Django]

#34720: Path checking in BaseReloader.watch_dir() incorrectly checks for 
existence
of path
-+
   Reporter:  Josh   |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Uncategorized  |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  |
-+
 Within the `watch_dir` method in `django.utils.autoreload.BaseReloader`,
 the path is checked by calling on the `absolute` method on the `Path`
 object:

 {{{
 def watch_dir(self, path, glob):
 path = Path(path)
 try:
 path = path.absolute()
 except FileNotFoundError:
 logger.debug(
 "Unable to watch directory %s as it cannot be resolved.",
 path,
 exc_info=True,
 )
 return
 logger.debug("Watching dir %s with glob %s.", path, glob)
 self.directory_globs[path].add(glob)
 }}}

 Except `absolute` doesn't raise, it just returns the absolute path. Should
 be changed to an if check on `path.exists()`:

 {{{
 Python 3.11.4 (main, Jul 17 2023, 15:40:49) [GCC 9.4.0]
 Type 'copyright', 'credits' or 'license' for more information
 IPython 8.14.0 -- An enhanced Interactive Python. Type '?' for help.

 In [1]: from pathlib import Path

 In [2]: Path('/home/josh/projects/django/nonexistent').absolute()
 Out[2]: PosixPath('/home/josh/projects/django/nonexistent')

 In [3]: Path('/home/josh/projects/django/nonexistent').exists()
 Out[3]: False
 }}}

 Willing to prepare a patch.

-- 
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/0107018965da71f1-416d8298-7792-4b1c-88ef-0454081eb1fd-00%40eu-central-1.amazonses.com.

Re: [Django] #34719: modelBase.add_to_class is ineffective when called in __init_subclass__ of an abstract Model

[Django]

#34719: modelBase.add_to_class is ineffective when called in __init_subclass__ 
of
an abstract Model
-+-
 Reporter:  piscvau  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  4.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  dynamic model| Triage Stage:
  modification   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Simon Charette):

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


Comment:

 Duplicate of #34555.

-- 
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/0107018965bbf6de-20a15bc9-c975-4382-843c-1d87d44455c3-00%40eu-central-1.amazonses.com.

Re: [Django] #34719: modelBase.add_to_class is ineffective when called in __init_subclass__ of an abstract Model

[Django]

#34719: modelBase.add_to_class is ineffective when called in __init_subclass__ 
of
an abstract Model
-+-
 Reporter:  piscvau  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  4.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  dynamic model| Triage Stage:
  modification   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by piscvau):

 * Attachment "tests_abcmodel_bug.py" added.

 unittest test file to reproduce

-- 
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/0107018965981bfd-dff7f5be-50ac-4070-a91a-2c32bbc27453-00%40eu-central-1.amazonses.com.

[Django] #34719: modelBase.add_to_class is ineffective when called in __init_subclass__ of an abstract Model

[Django]

#34719: modelBase.add_to_class is ineffective when called in __init_subclass__ 
of
an abstract Model
-+-
   Reporter:  piscvau|  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Database   |Version:  4.1
  layer (models, ORM)|   Keywords:  dynamic model
   Severity:  Normal |  modification
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Using an abstract model which is also an abstract class.
 In the subclass, I need to modify a field. This is done in the
 __init_subclass__ method, by creating a field and adding it to the model
 with ModelBase.add_to_class.
 The field disappears from the class.

 Doing exactly the same on a model which is not an abstract class works
 fine.

 see unittest file to reproduce this 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/010701896596cf06-2fad741f-d4ea-4740-acb0-423b674c04c4-00%40eu-central-1.amazonses.com.

Re: [Django] #34716: Class methods from nested classes cannot be used as Field.default.

[Django]

#34716: Class methods from nested classes cannot be used as Field.default.
-+-
 Reporter:  Nicolò Intrieri  |Owner:  Nicolò
 |  Intrieri
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  4.2
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Nicolò Intrieri):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/17087 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/01070189658db20b-a2191598-e010-404b-92d8-62cf5e126849-00%40eu-central-1.amazonses.com.

Re: [Django] #29061: manage.py makemessages throws syntax error due to incorrectly generated django.pot, again

[Django]

#29061: manage.py makemessages throws syntax error due to incorrectly generated
django.pot, again
-+-
 Reporter:  Kyan |Owner:  Anvansh
 |  Singh
 Type:  Bug  |   Status:  assigned
Component:  Core (Management |  Version:  2.0
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:  gettext, | Triage Stage:  Accepted
  makemessages, Windows  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Anvansh Singh):

 I am a bit unsure what would be the best place to add the regression test
 for it. Can really use some help with that.

-- 
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/0107018965618c47-af11ce7c-c30f-44ad-903b-209578c464fe-00%40eu-central-1.amazonses.com.

Re: [Django] #34718: Allow django.contrib.admin's ListFilter to render details tag collasped by default

[Django]

#34718: Allow django.contrib.admin's ListFilter to render details tag collasped 
by
default
-+-
 Reporter:  Christophe Henry |Owner:
 Type:   |  Christophe Henry
  Cleanup/optimization   |   Status:  closed
Component:  contrib.admin|  Version:  4.2
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-

Comment (by Marcelo Galigniana):

 Yes! I agree with you +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/01070189653bd0ab-cf091d3e-be03-4f8a-86b5-18a4fba21f4d-00%40eu-central-1.amazonses.com.

Re: [Django] #34718: Allow django.contrib.admin's ListFilter to render details tag collasped by default

[Django]

#34718: Allow django.contrib.admin's ListFilter to render details tag collasped 
by
default
-+-
 Reporter:  Christophe Henry |Owner:
 Type:   |  Christophe Henry
  Cleanup/optimization   |   Status:  closed
Component:  contrib.admin|  Version:  4.2
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-

Comment (by Mariusz Felisiak):

 Replying to [comment:5 Marcelo Galigniana]:
 > And add an option in SimpleListFilter to collapse ALL filters by default
 would make sense?

 My point is that if you have `ListFilter` with a long list of options, you
 will probably use something other than the built-in `ListFilter` because
 collapsing options by default would not solve the long-rendering issue.

-- 
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/01070189652cb568-134f2aca-3445-4d83-89a1-f7c32803c790-00%40eu-central-1.amazonses.com.

Re: [Django] #34718: Allow django.contrib.admin's ListFilter to render details tag collasped by default

[Django]

#34718: Allow django.contrib.admin's ListFilter to render details tag collasped 
by
default
-+-
 Reporter:  Christophe Henry |Owner:
 Type:   |  Christophe Henry
  Cleanup/optimization   |   Status:  closed
Component:  contrib.admin|  Version:  4.2
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-

Comment (by Marcelo Galigniana):

 Here is the PR where we added the collapse filter arrows (to solve the
 ''long page'' problem): https://github.com/django/django/pull/15424

 I wouldn't allow user edit ListFilter as, ''if I'm not wrong'', we don't
 recommend it in
 https://docs.djangoproject.com/en/4.2/ref/contrib/admin/filters

 And add an option in SimpleListFilter to collapse ALL filters by default
 would make sense?

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018965238675-852ccd9b-cef4-4734-a377-6b144c38c6a1-00%40eu-central-1.amazonses.com.

Re: [Django] #27471: Make admin's list_filter choices collapsable

[Django]

#27471: Make admin's list_filter choices collapsable
-+-
 Reporter:  Greg McCoy   |Owner:  Marcelo
 |  Galigniana
 Type:  New feature  |   Status:  closed
Component:  contrib.admin|  Version:  1.10
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  filter admin | Triage Stage:  Ready for
  collaspe   |  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:"4a72da71001f154ea60906a2f74898d32b7322a7" 4a72da71]:
 {{{
 #!CommitTicketReference repository=""
 revision="4a72da71001f154ea60906a2f74898d32b7322a7"
 Refs #27471 -- Made admin's filter choice arrows use cursor pointers.
 }}}

-- 
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/01070189651ace86-d26887e1-f48a-4c6d-9e4d-a56ed2fe57de-00%40eu-central-1.amazonses.com.

Re: [Django] #34717: Cannot use aggregate over window functions since 4.2

[Django]

#34717: Cannot use aggregate over window functions since 4.2
-+-
 Reporter:  younes-chaoui|Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  4.2
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  aggregation, window  | Triage Stage:  Accepted
  functions, psycopg |
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 => Simon Charette
 * 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/0107018965012f96-cd128a34-2d85-4536-a3b0-fda79bfcbce0-00%40eu-central-1.amazonses.com.

Re: [Django] #34709: charset should be ignored for the application/x-www-form-urlencoded content type.

[Django]

#34709: charset should be ignored for the application/x-www-form-urlencoded 
content
type.
-+-
 Reporter:  Mariusz Felisiak |Owner:  Mariusz
 |  Felisiak
 Type:  Bug  |   Status:  assigned
Component:  HTTP handling|  Version:  4.2
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak):

 Replying to [comment:10 Claude Paroz]:
 > Indeed, by default `parse_sql` is calling `decode()` with
 `errors='replace'`, which will produce � (U+FFFD, the official REPLACEMENT
 CHARACTER) for invalid UTF-8 sequences. I'm still not convinced it will be
 a real improvement over the current situation…

 We could raise 400 instead of silently ignoring a custom charset.

-- 
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/0107018964e79437-d7c51f4d-66af-44a4-9fcd-e06861139cfa-00%40eu-central-1.amazonses.com.

Re: [Django] #34718: Allow django.contrib.admin's ListFilter to render details tag collasped by default

[Django]

#34718: Allow django.contrib.admin's ListFilter to render details tag collasped 
by
default
-+-
 Reporter:  Christophe Henry |Owner:
 Type:   |  Christophe Henry
  Cleanup/optimization   |   Status:  closed
Component:  contrib.admin|  Version:  4.2
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-
Changes (by Mariusz Felisiak):

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


Comment:

 I don't think that removing `open` will make much of a difference as
 exactly the same HTML will be build (with all options).

-- 
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/0107018964e44c2a-5f7737e1-1049-4fe1-a361-d3d651ced0c9-00%40eu-central-1.amazonses.com.

Re: [Django] #34717: Cannot use aggregate over window functions since 4.2

[Django]

#34717: Cannot use aggregate over window functions since 4.2
-+-
 Reporter:  younes-chaoui|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  4.2
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  aggregation, window  | Triage Stage:  Accepted
  functions, psycopg |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Simon Charette):

 * status:  closed => new
 * severity:  Normal => Release blocker
 * component:  Uncategorized => Database layer (models, ORM)
 * has_patch:  0 => 1
 * resolution:  needsinfo =>
 * stage:  Unreviewed => Accepted


Comment:

 Confirmed this is a regression similar to #34551 but for window
 expressions.

 @younes-chaoui could you confirm the following patch addresses our issue
 [PR](https://github.com/django/django/pull/17084)

-- 
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/0107018964c778b5-bff2b8a4-1a9e-4664-ab66-40373b35f28f-00%40eu-central-1.amazonses.com.

Re: [Django] #34718: Allow django.contrib.admin's ListFilter to render details tag collasped by default

[Django]

#34718: Allow django.contrib.admin's ListFilter to render details tag collasped 
by
default
-+-
 Reporter:  Christophe Henry |Owner:
 Type:   |  Christophe Henry
  Cleanup/optimization   |   Status:  assigned
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:  1
-+-
Changes (by Marcelo Galigniana):

 * owner:  nobody => Christophe Henry
 * 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/0107018964ac09c9-bf614a0e-c819-4c1e-900d-f305a98dfa21-00%40eu-central-1.amazonses.com.

Re: [Django] #34716: Class methods from nested classes cannot be used as Field.default.

[Django]

#34716: Class methods from nested classes cannot be used as Field.default.
-+-
 Reporter:  Nicolò Intrieri  |Owner:  Nicolò
 |  Intrieri
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  4.2
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak):

 > I would be very happy to prepare a patch, i will do my best to write a
 test that's coherent with the current suite

 You can check tests in `tests.migrations.test_writer.WriterTests`, e.g.
 `test_serialize_nested_class()`.

-- 
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/0107018964a0314d-fd186f70-300a-445e-924a-387a81f5d0c9-00%40eu-central-1.amazonses.com.

Re: [Django] #34718: Allow django.contrib.admin's ListFilter to render details tag collasped by default

[Django]

#34718: Allow django.contrib.admin's ListFilter to render details tag collasped 
by
default
-+-
 Reporter:  Christophe Henry |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
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:  1
-+-
Changes (by Mariusz Felisiak):

 * cc: Marcelo Galigniana (added)
 * type:  Uncategorized => Cleanup/optimization


-- 
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/010701896497505e-100264c1-b90b-486f-8096-2daba111ba50-00%40eu-central-1.amazonses.com.

Re: [Django] #34714: Async support for get_object_or_404()/get_list_or_404().

[Django]

#34714: Async support for get_object_or_404()/get_list_or_404().
-+-
 Reporter:  patagoniapy  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  4.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Olivier Tabone):

 @patagoniapy do you mind if I claim this ticket ?

 Cheers

-- 
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/0107018964781ce8-006fb90d-2457-4edd-ac26-f07e85c66040-00%40eu-central-1.amazonses.com.

Re: [Django] #34714: Async support for get_object_or_404()/get_list_or_404().

[Django]

#34714: Async support for get_object_or_404()/get_list_or_404().
-+-
 Reporter:  patagoniapy  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  4.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Olivier Tabone):

 * cc: Olivier Tabone (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/010701896470a8dd-2391f7cf-78bd-4cd3-9a52-3fd2c920e2cd-00%40eu-central-1.amazonses.com.

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

[Django]

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

Comment (by Stefan):

 @Natalia, apologies I should've said, it was PSQL 14.3.

 I want to clarify that from a purely ORM perspective the result is
 surprising, given

 {{{#!python
 Book.objects.update(published=timezone.now())
 
Book.objects.annotate(_published_trunc=TruncSecond('published')).filter(_published_trunc__lte=timezone.now()).count()
 # 0
 }}}

 the result is 0. One has to dive in to the SQL to understand why this is
 happening, and it's because `AT TIME ZONE 'Europe/Berlin'` is making the
 timezone naive in the DB level. The docs do say:

 Trunc() - "If a different timezone like Australia/Melbourne is active
 in Django, then the datetime is converted to the new timezone before the
 value is truncated."

 Although it says the datetime is converted to the new timezone before the
 value is truncated, ''converted to new timezone'' doesn't necessarily
 suggest that the resulting time zone is naive - one could still assume it
 an aware timezone just with an offset of +11:00. The latter is further
 suggested because the immediately following examples in that doc show the
 returned value on the annotation are an aware value with an offset of
 +11:00, and not naive.

-- 
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/01070189643eb452-5d5fb5fb-986b-4497-beb1-845bc1d76e79-00%40eu-central-1.amazonses.com.

Re: [Django] #34717: Cannot use aggregate over window functions since 4.2

[Django]

#34717: Cannot use aggregate over window functions since 4.2
-+-
 Reporter:  younes-chaoui|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Uncategorized|  Version:  4.2
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  aggregation, window  | Triage Stage:
  functions, psycopg |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Natalia Bidart):

 * cc: Simon Charette (added)
 * status:  new => closed
 * resolution:   => needsinfo


Comment:

 Hello! Could you please provide a minimal Django test project with models
 to reproduce this issue? Or a regression test that would pass on Django
 4.1 but fail in 4.2? Thank you!

-- 
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/010701896430abd2-3e1ef0df-1e71-4bd0-8e06-c76c52bd7f90-00%40eu-central-1.amazonses.com.

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

[Django]

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

Comment (by Natalia Bidart):

 Replying to [comment:15 Mateusz Więckowski]:
 > Okay, got It. This is how it works for me now:
 >
 >
 > {{{
 > py manage.py createsuperuser --username testing --noinput
 > CommandError: You must use --email with --noinput.
 >
 > py manage.py createsuperuser --email "" --username testing --noinput
 > Superuser created successfully.
 > }}}
 >
 > I did not change anything for the "interactive" part of the process - as
 far as I've understood from the comments it works as intended.

 Thanks for sharing this. What shell are you using? I'm using bash on an
 ubuntu system with Python 3.11, and I get this:

 {{{
 $ python -Wall manage.py createsuperuser --email "" --username testing
 --noinput
 CommandError: You must use --email with --noinput.
 }}}

-- 
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/0107018964107de7-d8b91fa1-4dbb-419d-9636-419f4f0a2d7a-00%40eu-central-1.amazonses.com.

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

[Django]

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

Comment (by Natalia Bidart):

 Replying to [comment:9 Mariusz Felisiak]:
 > It works as documented:
 > - `timezone.now()` - ''"If USE_TZ is True, this will be an aware
 datetime representing the **current time in UTC**. Note that now() will
 always return times in UTC regardless of the value of TIME_ZONE; you can
 use localtime() to get the time in the current time zone."''
 > - `Trunc()` - ''"If a different timezone like Australia/Melbourne is
 active in Django, then the datetime **is converted to the new timezone**
 before the value is truncated."''

 Right, I understand the docs above and how that match the results I got.
 But, at the same time, the first paragraph about "Time Zones" says:

 ''When support for time zones is enabled, Django stores datetime
 information in UTC in the database, uses time-zone-aware datetime objects
 internally, and translates them to the end user’s time zone in templates
 and forms.
 [...]
 Even if your website is available in only one time zone, it’s still good
 practice to store data in UTC in your database.''

 The above aligns perfectly (and makes sense) with `timezone.now` returning
 an aware datetime in UTC. But then, at least to me, is quite surprising
 that `TruncSecond`, which is an operation fully occurring in the DB, would
 not "respect" that "UTC invariant" and have the `TIME_ZONE` setting
 affecting the results. Does my point make sense? Do you have historic
 information about why `TruncSecond` (and related functions) would not
 operate with/keep the tz defined in the datetime being processed?

-- 
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/010701896405df60-757fb278-9734-496c-897c-36577b0522bd-00%40eu-central-1.amazonses.com.

Re: [Django] #34718: Allow django.contrib.admin's ListFilter to render details tag collasped by default

[Django]

#34718: Allow django.contrib.admin's ListFilter to render details tag collasped 
by
default
--+--
 Reporter:  Christophe Henry  |Owner:  nobody
 Type:  Uncategorized |   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:  1
--+--
Changes (by Christophe Henry):

 * ui_ux:  0 => 1
 * component:  Uncategorized => contrib.admin


Old description:

> Custom ``ListFilter`` in django admin can yield a lot of results, in
> which case, the page can be very long.
>
> This could be solved by adding a ``details_collapsed = True`` attribute
> to the ``ListFilter`` class and render the  tag according to
> that attribute.

New description:

 Custom `ListFilter` in django admin can yield a lot of results, in which
 case, the page can be very long.

 This could be solved by adding a `details_collapsed = True` attribute to
 the `ListFilter` class and render the `` tag according to that
 attribute.

--

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018963fa8fdd-cebe8fe6-0520-4888-a084-e5286d59e985-00%40eu-central-1.amazonses.com.

[Django] #34718: Allow django.contrib.admin's ListFilter to render details tag collasped by default

[Django]

#34718: Allow django.contrib.admin's ListFilter to render details tag collasped 
by
default
+
   Reporter:  Christophe Henry  |  Owner:  nobody
   Type:  Uncategorized | Status:  new
  Component:  Uncategorized |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 |
+
 Custom ``ListFilter`` in django admin can yield a lot of results, in which
 case, the page can be very long.

 This could be solved by adding a ``details_collapsed = True`` attribute to
 the ``ListFilter`` class and render the  tag according to
 that attribute.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018963f9a2b1-30c32363-1397-499c-80eb-b0e112928a1f-00%40eu-central-1.amazonses.com.

Re: [Django] #34716: Class methods from nested classes cannot be used as Field.default.

[Django]

#34716: Class methods from nested classes cannot be used as Field.default.
-+-
 Reporter:  Nicolò Intrieri  |Owner:  Nicolò
 |  Intrieri
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  4.2
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Nicolò Intrieri):

 * owner:  nobody => Nicolò Intrieri
 * 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/0107018963f16cb6-ad9bb568-7e52-4f98-9b91-5d10a66c309c-00%40eu-central-1.amazonses.com.

Re: [Django] #34716: Class methods from nested classes cannot be used as Field.default.

[Django]

#34716: Class methods from nested classes cannot be used as Field.default.
-+
 Reporter:  Nicolò Intrieri  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  4.2
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by Nicolò Intrieri):

 Replying to [comment:1 Mariusz Felisiak]:
 > Thanks for the report. It seems that `FunctionTypeSerializer` should use
 `__qualname__` instead of `__name__`:
 > {{{#!diff
 > diff --git a/django/db/migrations/serializer.py
 b/django/db/migrations/serializer.py
 > index d88cda6e20..06657ebaab 100644
 > --- a/django/db/migrations/serializer.py
 > +++ b/django/db/migrations/serializer.py
 > @@ -168,7 +168,7 @@ class FunctionTypeSerializer(BaseSerializer):
 >  ):
 >  klass = self.value.__self__
 >  module = klass.__module__
 > -return "%s.%s.%s" % (module, klass.__name__,
 self.value.__name__), {
 > +return "%s.%s.%s" % (module, klass.__qualname__,
 self.value.__name__), {
 >  "import %s" % module
 >  }
 >  # Further error checking
 >
 > }}}
 >
 > Would you like to prepare a patch? (regression test is required)

 I would be very happy to prepare a patch, i will do my best to write a
 test that's coherent with the current suite

-- 
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/0107018963ef7fc0-924ad0b6-a776-4061-8287-83e0242a4c15-00%40eu-central-1.amazonses.com.

Re: [Django] #34716: Class methods from nested classes cannot be used as Field.default.

[Django]

#34716: Class methods from nested classes cannot be used as Field.default.
-+
 Reporter:  Nicolò Intrieri  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  4.2
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by Nicolò Intrieri):

 Replying to [comment:2 David Sanders]:
 > Also to nitpick the terminology: `Capability` is a nested class, not a
 subclass. (fyi for anyone preparing tests/commit message)

 You're right, that was inaccurate. Thanks for having fixed the title

-- 
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/0107018963e8a7b3-3ca32a37-3dd1-440e-9328-b59e27c52183-00%40eu-central-1.amazonses.com.

Re: [Django] #34709: charset should be ignored for the application/x-www-form-urlencoded content type.

[Django]

#34709: charset should be ignored for the application/x-www-form-urlencoded 
content
type.
-+-
 Reporter:  Mariusz Felisiak |Owner:  Mariusz
 |  Felisiak
 Type:  Bug  |   Status:  assigned
Component:  HTTP handling|  Version:  4.2
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Claude Paroz):

 Indeed, by default `parse_sql` is calling `decode()` with
 `errors='replace'`, which will produce � (U+FFFD, the official REPLACEMENT
 CHARACTER) for invalid UTF-8 sequences. I'm still not convinced it will be
 a real improvement over the current situation…

-- 
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/0107018963e6a9f7-9c8f7237-5c4d-401d-b1e5-f5d87cd56a57-00%40eu-central-1.amazonses.com.

Re: [Django] #34717: Cannot use aggregate over window functions since 4.2

[Django]

#34717: Cannot use aggregate over window functions since 4.2
-+-
 Reporter:  younes-chaoui|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Uncategorized|  Version:  4.2
 Severity:  Normal   |   Resolution:
 Keywords:  aggregation, window  | Triage Stage:
  functions, psycopg |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by younes-chaoui):

 * keywords:   => aggregation, window functions, psycopg
 * 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/0107018963ddac1f-f1fd3856-e287-4972-89e2-1855adce6382-00%40eu-central-1.amazonses.com.

[Django] #34717: Cannot use aggregate over window functions since 4.2

[Django]

#34717: Cannot use aggregate over window functions since 4.2
-+
   Reporter:  younes-chaoui  |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Uncategorized  |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  |
-+
 After upgrading to Django 4.2, I encountered an exception when executing
 ORM queries that involve aggregates over Window functions. The specific
 error was `psycopg2.errors.GroupingError: aggregate function calls cannot
 contain window function calls`

 Dependencies :

 psycopg2 version: 2.9.3
 django version: 4.1.9
 PostgreSQL version: 13.4


 Example Code:



 {{{
 queryset = queryset.annotate(
 cumul_DJR=Coalesce(Window(Sum("DJR"), order_by=F("date").asc()), 0.0)
 )

 aggregate = queryset.aggregate(
 DJR_total=Sum("DJR"),
 cumul_DJR_total=Sum("cumul_DJR")
 )
 }}}

-- 
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/0107018963dd2bf0-a2dd3c6e-d071-45b4-8881-f08a689fea5f-00%40eu-central-1.amazonses.com.

Re: [Django] #34716: Class methods from nested classes cannot be used as Field.default. (was: Class methods from subclasses cannot be used as Field.default.)

[Django]

#34716: Class methods from nested classes cannot be used as Field.default.
-+
 Reporter:  Nicolò Intrieri  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  4.2
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

-- 
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/0107018963d1b2cd-8882f533-7fa3-4185-803e-7b4baa0d9010-00%40eu-central-1.amazonses.com.

Re: [Django] #34716: Class methods from subclasses cannot be used as Field.default.

[Django]

#34716: Class methods from subclasses cannot be used as Field.default.
-+
 Reporter:  Nicolò Intrieri  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  4.2
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by David Sanders):

 Also to nitpick the terminology: `Capability` is a nested class, not a
 subclass. (fyi for anyone preparing tests/commit message)

-- 
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/0107018963d1094f-199e451b-b59c-4631-8e1b-77f7a268c7d3-00%40eu-central-1.amazonses.com.

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

[Django]

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

Comment (by Mariusz Felisiak):

 It works as documented:
 - `timezone.now()` - ''"If USE_TZ is True, this will be an aware datetime
 representing the **current time in UTC**. Note that now() will always
 return times in UTC regardless of the value of TIME_ZONE; you can use
 localtime() to get the time in the current time zone."''
 - `Trunc()` - ''"If a different timezone like Australia/Melbourne is
 active in Django, then the datetime **is converted to the new timezone**
 before the value is truncated."''

-- 
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/0107018963b6b015-81d487f6-48d9-4507-a9de-d502e0f79841-00%40eu-central-1.amazonses.com.

Re: [Django] #34711: Make ChoiceField auto-detect and coerce values. (was: form.has_changed() is always True for IntegerChoices Enum Model Field)

[Django]

#34711: Make ChoiceField auto-detect and coerce values.
-+--
 Reporter:  GHPS |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Forms|  Version:  4.2
 Severity:  Normal   |   Resolution:  wontfix
 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):

 * status:  new => closed
 * type:  Bug => New feature
 * resolution:   => wontfix


Comment:

 I appreciate you'd like to reopen the ticket, but we will not change this
 long-standing behavior and incorporate `TypedChoiceField` logic in
 `ChoiceField`. If you don't agree, please
 [https://docs.djangoproject.com/en/stable/internals/contributing/triaging-
 tickets/#closing-tickets follow the triaging guidelines with regards to
 wontfix tickets] and take this to DevelopersMailingList.

-- 
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/0107018963b20754-a3275b7c-95a2-4724-9df9-0eca505a4c9f-00%40eu-central-1.amazonses.com.

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

[Django]

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

Comment (by Natalia Bidart):

 Thanks Mariusz for your insight. I was wondering what are your thoughts
 for my example above, where the result of calling `TruncSecond` on a
 timestamp would have a timezone different than the argument.

-- 
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/0107018963ae846e-e56c6c9a-3b31-484a-9b9e-624fa6b30e68-00%40eu-central-1.amazonses.com.

Re: [Django] #34712: Prevent misconfiguration of `STORAGES` setting

[Django]

#34712: Prevent misconfiguration of `STORAGES` setting
-+-
 Reporter:  Bruno Alla   |Owner:  Bruno
 Type:   |  Alla
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.staticfiles  |  Version:  4.2
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Bruno Alla):

 * 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/0107018963a899ac-318e76d9-fda8-4b20-9391-3a878e20c5c2-00%40eu-central-1.amazonses.com.

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

[Django]

#34711: form.has_changed() is always True for IntegerChoices Enum Model Field
+--
 Reporter:  GHPS|Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Forms   |  Version:  4.2
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--

Comment (by GHPS):

 Update:

 Setting **coerce=int** in TypeChoiceField works as well but seems to me a
 rather crude way to treat
 the original problem.

 With this approach the developer is forced to remember the right field
 type (TypeChoiceField) and
 involved values (ints) to clamp a conversion mechanism hidden behind the
 scene down to ground.

 In both, the enum (IntegerChoice) and the model
 (PositiveSmallIntegerField) the information is available
 that we are dealing with integers. Perhaps this information can be
 utilized to let ChoiceField do
 the right thing without intervention...

-- 
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/0107018963a2a492-e028a422-6ca7-4ef3-b31d-fd378dd02041-00%40eu-central-1.amazonses.com.

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

[Django]

#34711: form.has_changed() is always True for IntegerChoices Enum Model Field
+--
 Reporter:  GHPS|Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Forms   |  Version:  4.2
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Changes (by GHPS):

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


Comment:

 Sorry for reopening this issue again...

 Replying to [comment:6 David Sanders]:
 >> If you want to manually override model form fields you must be sure to
 use the correct form field type. In the case of an IntegerField with
 choices you must use a ​TypedChoiceField A model form will use these
 automatically for an IntegerField by default.

 Thanks for the suggestion which I checked on the small test project
 mentioned above.

 So I've changed the form field type from ChoiceField to TypedCoiceField.
 {{{
 eAsset=forms.TypedChoiceField(choices=sampleModel.eAssets.choices)
 }}}

 This change, however, did nothing to the original problem: The
 form.has_changed() flag is alway True
 regardless of changing or not changing any field in the form.

 In the next step I completely removed said line and therefore relied on
 the
 form field automatically generated - voila, no problem.

 Seemingly the ChoiceField/TypedChoiceField methods convert the outgoing
 and incoming choice values which confuses the form.has_changed()
 detection.

-- 
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/01070189638fbecf-29dc8817-5960-4a21-94b5-22d828902fe0-00%40eu-central-1.amazonses.com.

Re: [Django] #34709: charset should be ignored for the application/x-www-form-urlencoded content type.

[Django]

#34709: charset should be ignored for the application/x-www-form-urlencoded 
content
type.
-+-
 Reporter:  Mariusz Felisiak |Owner:  Mariusz
 |  Felisiak
 Type:  Bug  |   Status:  assigned
Component:  HTTP handling|  Version:  4.2
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak):

 Replying to [comment:8 Claude Paroz]:
 > Did you explore what will happen in practice if an incoming request is
 encoded in a different encoding and we try to decode it with `utf-8`?
 Server error (500)? Bad request(400)?

 I was only able to achieve a badly decoded string, no crash 樂

-- 
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/010701896386c94c-c77c7328-9861-4fdb-82d2-753764c9aa54-00%40eu-central-1.amazonses.com.

Re: [Django] #34709: charset should be ignored for the application/x-www-form-urlencoded content type.

[Django]

#34709: charset should be ignored for the application/x-www-form-urlencoded 
content
type.
-+-
 Reporter:  Mariusz Felisiak |Owner:  Mariusz
 |  Felisiak
 Type:  Bug  |   Status:  assigned
Component:  HTTP handling|  Version:  4.2
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Claude Paroz):

 Replying to [comment:5 Mariusz Felisiak]:
 > We could raise a warning when `self._encoding` is not `utf-8`, that it
 will be ignored in Django 6.0. I'm just not sure it's worth doing.

 The warning will probably only be ever raised on production servers, so
 hardly visible in practice.

 Did you explore what will happen in practice if an incoming request is
 encoded in a different encoding and we try to decode it with `utf-8`?
 Server error (500)? Bad request(400)?

-- 
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/0107018963625337-87cb06c5-cc67-4231-a8eb-e05e4a4dbbed-00%40eu-central-1.amazonses.com.

Re: [Django] #34712: Prevent misconfiguration of `STORAGES` setting

[Django]

#34712: Prevent misconfiguration of `STORAGES` setting
-+-
 Reporter:  Bruno Alla   |Owner:  Bruno
 Type:   |  Alla
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.staticfiles  |  Version:  4.2
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Bruno Alla):

 * owner:  nobody => Bruno Alla
 * 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/01070189635a3990-f157b6e6-859e-4502-9590-b3ae5527c1eb-00%40eu-central-1.amazonses.com.

Re: [Django] #34716: Class methods from subclasses cannot be used as Field.default. (was: Using subclass method as a callable for a field's default value results in wrong reference in the correspondin

[Django]

#34716: Class methods from subclasses cannot be used as Field.default.
-+
 Reporter:  Nicolò Intrieri  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Migrations   |  Version:  4.2
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by Mariusz Felisiak):

 * stage:  Unreviewed => Accepted


Old description:

> {{{
> #!div
>
> Given the following model:
>
>   {{{#!python
>
> class Profile(models.Model):
>
> class Capability(models.TextChoices):
> BASIC = ("BASIC", "Basic")
> PROFESSIONAL = ("PROFESSIONAL", "Professional")
>
> @classmethod
> def default(cls) -> list[str]:
> return [cls.BASIC]
>
> capabilities = ArrayField(
>   models.CharField(choices=Capability.choices, max_length=30,
> blank=True),
>   null=True,
>   default=Capability.default
> )
>

>   }}}
>
> The resulting migration contained the following:
>  {{{#!python
> # ...
>   migrations.AddField(
> model_name='profile',
> name='capabilities',
> field=django.contrib.postgres.fields.ArrayField(base_field=models.CharField(blank=True,
> choices=[('BASIC', 'Basic'), ('PROFESSIONAL', 'Professional')],
> max_length=30), default=appname.models.Capability.default, null=True,
> size=None),
> ),
> # ...
>   }}}
> }}}
>

> As you can see, migrations.AddField is passed as argument "default" a
> wrong value "appname.models.Capability.default", which leads to an error
> when trying to migrate. The right value should be
> "appname.models.Profile.Capability.default".

New description:

 {{{
 #!div

 Given the following model:

   {{{#!python

 class Profile(models.Model):

 class Capability(models.TextChoices):
 BASIC = ("BASIC", "Basic")
 PROFESSIONAL = ("PROFESSIONAL", "Professional")

 @classmethod
 def default(cls) -> list[str]:
 return [cls.BASIC]

 capabilities = ArrayField(
 models.CharField(choices=Capability.choices, max_length=30,
 blank=True),
 null=True,
 default=Capability.default
 )


   }}}

 The resulting migration contained the following:
  {{{#!python
 # ...
   migrations.AddField(
 model_name='profile',
 name='capabilities',
 
field=django.contrib.postgres.fields.ArrayField(base_field=models.CharField(blank=True,
 choices=[('BASIC', 'Basic'), ('PROFESSIONAL', 'Professional')],
 max_length=30), default=appname.models.Capability.default, null=True,
 size=None),
 ),
 # ...
   }}}
 }}}


 As you can see, migrations.AddField is passed as argument "default" a
 wrong value "appname.models.Capability.default", which leads to an error
 when trying to migrate. The right value should be
 "appname.models.Profile.Capability.default".

--

Comment:

 Thanks for the report. It seems that `FunctionTypeSerializer` should use
 `__qualname__` instead of `__name__`:
 {{{#!diff
 diff --git a/django/db/migrations/serializer.py
 b/django/db/migrations/serializer.py
 index d88cda6e20..06657ebaab 100644
 --- a/django/db/migrations/serializer.py
 +++ b/django/db/migrations/serializer.py
 @@ -168,7 +168,7 @@ class FunctionTypeSerializer(BaseSerializer):
  ):
  klass = self.value.__self__
  module = klass.__module__
 -return "%s.%s.%s" % (module, klass.__name__,
 self.value.__name__), {
 +return "%s.%s.%s" % (module, klass.__qualname__,
 self.value.__name__), {
  "import %s" % module
  }
  # Further error checking

 }}}

 Would you like to prepare a patch? (regression test is required)

-- 
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/01070189634cb06a-d5f11cea-e6c8-482c-94a3-8fb669e76fda-00%40eu-central-1.amazonses.com.

[Django] #34716: Using subclass method as a callable for a field's default value results in wrong reference in the corresponding migration

[Django]

#34716: Using subclass method as a callable for a field's default value results 
in
wrong reference in the corresponding migration
---+
   Reporter:  Nicolò Intrieri  |  Owner:  nobody
   Type:  Bug  | Status:  new
  Component:  Migrations   |Version:  4.2
   Severity:  Normal   |   Keywords:
   Triage Stage:  Unreviewed   |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+
 {{{
 #!div

 Given the following model:

   {{{#!python

 class Profile(models.Model):

 class Capability(models.TextChoices):
 BASIC = ("BASIC", "Basic")
 PROFESSIONAL = ("PROFESSIONAL", "Professional")

 @classmethod
 def default(cls) -> list[str]:
 return [cls.BASIC]

 capabilities = ArrayField(
   models.CharField(choices=Capability.choices, max_length=30,
 blank=True),
   null=True,
   default=Capability.default
 )


   }}}

 The resulting migration contained the following:
  {{{#!python
 # ...
   migrations.AddField(
 model_name='profile',
 name='capabilities',
 
field=django.contrib.postgres.fields.ArrayField(base_field=models.CharField(blank=True,
 choices=[('BASIC', 'Basic'), ('PROFESSIONAL', 'Professional')],
 max_length=30), default=appname.models.Capability.default, null=True,
 size=None),
 ),
 # ...
   }}}
 }}}


 As you can see, migrations.AddField is passed as argument "default" a
 wrong value "appname.models.Capability.default", which leads to an error
 when trying to migrate. The right value should be
 "appname.models.Profile.Capability.default".

-- 
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/0107018963298a74-43a4af94-1336-4b05-a6b1-8d3f3bee6d44-00%40eu-central-1.amazonses.com.

Re: [Django] #34118: Python 3.12 compatibility

[Django]

#34118: Python 3.12 compatibility
-+-
 Reporter:  Mariusz Felisiak |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Core (Other) |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by GitHub ):

 In [changeset:"da2f8e8257d1bea4215381684ca4abfcee333c43" da2f8e8]:
 {{{
 #!CommitTicketReference repository=""
 revision="da2f8e8257d1bea4215381684ca4abfcee333c43"
 Refs #34118 -- Improved sanitize_address() error message for tuple with
 empty strings.
 }}}

-- 
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/0107018963176f7b-8c6793d3-2fe2-4eb1-b7b1-06f992a0e69b-00%40eu-central-1.amazonses.com.

Re: [Django] #30950: Replace __file__ with importlib.resources

[Django]

#30950: Replace __file__ with importlib.resources
-+-
 Reporter:  John Vandenberg  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Other) |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  freezers | Triage Stage:  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Joachim Jablon):

 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.

-- 
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/0107018962d05e23-57546000-2d0c-450c-b7b0-dd064f6b5827-00%40eu-central-1.amazonses.com.

Re: [Django] #34036: Low text contrast over light blue backgrounds in admin light theme

[Django]

#34036: Low text contrast over light blue backgrounds in admin light theme
-+-
 Reporter:  Thibaud Colas|Owner:  Mariana
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  Version:  4.0
 Severity:  Normal   |   Resolution:
 Keywords:  accessibility,   | Triage Stage:  Accepted
  color contrast, ux |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  1
-+-
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/0107018962878984-b4c071ea-9638-44e2-9627-4dcf7022e004-00%40eu-central-1.amazonses.com.

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

[Django]

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

Comment (by Mateusz Więckowski):

 Okay, got It. This is how it works for me now:


 {{{
 py manage.py createsuperuser --username testing --noinput
 CommandError: You must use --email with --noinput.

 py manage.py createsuperuser --email "" --username testing --noinput
 Superuser created successfully.
 }}}

 I did not change anything for the "interactive" part of the process - as
 far as I've understood from the comments it works as intended.

-- 
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/0107018962746723-408af2b7-39ae-4b29-88f8-3b2b00f44f0d-00%40eu-central-1.amazonses.com.