Re: [Django] #34077: Make BoundField renderable.

2022-11-15 Thread Django 
#34077: Make BoundField renderable.
-+---
 Reporter:  David Smith  |Owner:  David Smith
 Type:  New feature  |   Status:  assigned
Component:  Forms|  Version:  4.1
 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 David Smith):

 * owner:  skidipap => David Smith


-- 
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/010701847f4efdba-c811eea9-e571-416c-96d5-1924be07a3ef-00%40eu-central-1.amazonses.com.

Re: [Django] #34118: Python 3.12 compatibility

2022-11-15 Thread 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:"67504ea505797f515fb51c9688ce746c0997e9b2" 67504ea5]:
 {{{
 #!CommitTicketReference repository=""
 revision="67504ea505797f515fb51c9688ce746c0997e9b2"
 Refs #34118 -- Skipped not compatible requirements on daily builds for
 Python 3.12.
 }}}

-- 
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/010701847f4c27e2-1e8d0779-c6d6-42c7-b2c2-5c16d6a66c61-00%40eu-central-1.amazonses.com.

Re: [Django] #33308: Add psycopg3 backend

2022-11-15 Thread Django 
#33308: Add psycopg3 backend
-+-
 Reporter:  Paolo Melchiorre |Owner:  Florian
 |  Apolloner
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  database postgresql  | Triage Stage:  Accepted
  backend orm|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"5c23d9f0c32f166c81ecb6f3f01d5077a6084318" 5c23d9f]:
 {{{
 #!CommitTicketReference repository=""
 revision="5c23d9f0c32f166c81ecb6f3f01d5077a6084318"
 Refs #33308 -- Used get_db_prep_value() to adapt JSONFields.
 }}}

-- 
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/010701847f4380b8-0158e2a9-40b6-47a5-a973-c65db1e94121-00%40eu-central-1.amazonses.com.

Re: [Django] #33308: Add psycopg3 backend

2022-11-15 Thread Django 
#33308: Add psycopg3 backend
-+-
 Reporter:  Paolo Melchiorre |Owner:  Florian
 |  Apolloner
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  database postgresql  | Triage Stage:  Accepted
  backend orm|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"d87a7b9f4b4c75fc03ce6bbf55c880a79d524306" d87a7b9]:
 {{{
 #!CommitTicketReference repository=""
 revision="d87a7b9f4b4c75fc03ce6bbf55c880a79d524306"
 Refs #33308 -- Stopped inheriting from FieldGetDbPrepValueMixin by
 PostgresOperatorLookup.
 }}}

-- 
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/010701847f43800c-72edb3e0-9114-4816-97f0-36c3dc02d402-00%40eu-central-1.amazonses.com.

Re: [Django] #34163: ImproperlyConfigured: Requested setting INSTALLED_APPS, but settings are not configured (was: django.core.exceptions.ImproperlyConfigured: Requested setting INSTALLED_APPS, but se

2022-11-15 Thread Django 
#34163: ImproperlyConfigured: Requested setting INSTALLED_APPS, but settings are
not configured
---+--
 Reporter:  zic13  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Uncategorized  |  Version:  4.1
 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 Mariusz Felisiak):

 * status:  new => closed
 * resolution:   => invalid
 * severity:  Release blocker => Normal


Old description:

> I have tried everything to resolve this issue. Still its not resolving .
> I did makemigrtions ,migrate user modules are loading . I will add my
> traceback below for reference.
>
>  from adam.common.common import check_database_exists
>   File "/home/finq/review/106_review/adam/adam/common/common.py", line 9,
> in 
> from adam.graphical_user_interface.db_graphical_user_interface.models
> import UserLogin
>   File
> "/home/finq/review/106_review/adam/adam/graphical_user_interface/db_graphical_user_interface/models.py",
> line 5, in 
> class UserLogin(models.Model):
>   File "/home/finq/miniconda3/envs/adam/lib/python3.10/site-
> packages/django/db/models/base.py", line 127, in __new__
> app_config = apps.get_containing_app_config(module)
>   File "/home/finq/miniconda3/envs/adam/lib/python3.10/site-
> packages/django/apps/registry.py", line 260, in get_containing_app_config
> self.check_apps_ready()
>   File "/home/finq/miniconda3/envs/adam/lib/python3.10/site-
> packages/django/apps/registry.py", line 137, in check_apps_ready
> settings.INSTALLED_APPS
>   File "/home/finq/miniconda3/envs/adam/lib/python3.10/site-
> packages/django/conf/__init__.py", line 87, in __getattr__
> self._setup(name)
>   File "/home/finq/miniconda3/envs/adam/lib/python3.10/site-
> packages/django/conf/__init__.py", line 67, in _setup
> raise ImproperlyConfigured(
> django.core.exceptions.ImproperlyConfigured: Requested setting
> INSTALLED_APPS, but settings are not configured. You must either define
> the environment variable DJANGO_SETTINGS_MODULE or call
> settings.configure() before accessing settings.

New description:

 I have tried everything to resolve this issue. Still its not resolving . I
 did makemigrtions ,migrate user modules are loading . I will add my
 traceback below for reference.
 {{{
  from adam.common.common import check_database_exists
   File "/home/finq/review/106_review/adam/adam/common/common.py", line 9,
 in 
 from adam.graphical_user_interface.db_graphical_user_interface.models
 import UserLogin
   File
 
"/home/finq/review/106_review/adam/adam/graphical_user_interface/db_graphical_user_interface/models.py",
 line 5, in 
 class UserLogin(models.Model):
   File "/home/finq/miniconda3/envs/adam/lib/python3.10/site-
 packages/django/db/models/base.py", line 127, in __new__
 app_config = apps.get_containing_app_config(module)
   File "/home/finq/miniconda3/envs/adam/lib/python3.10/site-
 packages/django/apps/registry.py", line 260, in get_containing_app_config
 self.check_apps_ready()
   File "/home/finq/miniconda3/envs/adam/lib/python3.10/site-
 packages/django/apps/registry.py", line 137, in check_apps_ready
 settings.INSTALLED_APPS
   File "/home/finq/miniconda3/envs/adam/lib/python3.10/site-
 packages/django/conf/__init__.py", line 87, in __getattr__
 self._setup(name)
   File "/home/finq/miniconda3/envs/adam/lib/python3.10/site-
 packages/django/conf/__init__.py", line 67, in _setup
 raise ImproperlyConfigured(
 django.core.exceptions.ImproperlyConfigured: Requested setting
 INSTALLED_APPS, but settings are not configured. You must either define
 the environment variable DJANGO_SETTINGS_MODULE or call
 settings.configure() before accessing settings.
 }}}

--

Comment:

 Please don't use Trac as a support channel. Closing per
 TicketClosingReasons/UseSupportChannels.

-- 
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/010701847f341704-ce6c3aab-a435-4b16-ad14-ef1302ac7ea9-00%40eu-central-1.amazonses.com.

Re: [Django] #34155: ModelAdmin.render_change_form does not lowercase the app_label when setting template directories

2022-11-15 Thread Django 
#34155: ModelAdmin.render_change_form does not lowercase the app_label when 
setting
template directories
---+--
 Reporter:  Rishi Diwan|Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  contrib.admin  |  Version:  3.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:  0
---+--

Comment (by Rishi Diwan):

 I agree backward compatibility breaks, but there is a consistency issue
 here.
 `InculsionAdminNode.render` explicitly does a `app_label.lower()` so we
 now have two folders with different cases for the different admin
 templates.
 The case-sensitive folder has issues in the OSX folders because of the FS.

-- 
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/010701847f206ec9-d87f4ff7-9a3c-4e7b-b452-b7595212a2a2-00%40eu-central-1.amazonses.com.

[Django] #34163: django.core.exceptions.ImproperlyConfigured: Requested setting INSTALLED_APPS, but settings are not configured. You must either define the environment variable DJANGO_SETTINGS_MODULE

2022-11-15 Thread Django 
#34163: django.core.exceptions.ImproperlyConfigured: Requested setting
INSTALLED_APPS, but settings are not configured. You must either define the
environment variable DJANGO_SETTINGS_MODULE or call settings.configure()
before accessing settings.
---+
   Reporter:  zic13|  Owner:  nobody
   Type:  Bug  | Status:  new
  Component:  Uncategorized|Version:  4.1
   Severity:  Release blocker  |   Keywords:
   Triage Stage:  Unreviewed   |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+
 I have tried everything to resolve this issue. Still its not resolving . I
 did makemigrtions ,migrate user modules are loading . I will add my
 traceback below for reference.

  from adam.common.common import check_database_exists
   File "/home/finq/review/106_review/adam/adam/common/common.py", line 9,
 in 
 from adam.graphical_user_interface.db_graphical_user_interface.models
 import UserLogin
   File
 
"/home/finq/review/106_review/adam/adam/graphical_user_interface/db_graphical_user_interface/models.py",
 line 5, in 
 class UserLogin(models.Model):
   File "/home/finq/miniconda3/envs/adam/lib/python3.10/site-
 packages/django/db/models/base.py", line 127, in __new__
 app_config = apps.get_containing_app_config(module)
   File "/home/finq/miniconda3/envs/adam/lib/python3.10/site-
 packages/django/apps/registry.py", line 260, in get_containing_app_config
 self.check_apps_ready()
   File "/home/finq/miniconda3/envs/adam/lib/python3.10/site-
 packages/django/apps/registry.py", line 137, in check_apps_ready
 settings.INSTALLED_APPS
   File "/home/finq/miniconda3/envs/adam/lib/python3.10/site-
 packages/django/conf/__init__.py", line 87, in __getattr__
 self._setup(name)
   File "/home/finq/miniconda3/envs/adam/lib/python3.10/site-
 packages/django/conf/__init__.py", line 67, in _setup
 raise ImproperlyConfigured(
 django.core.exceptions.ImproperlyConfigured: Requested setting
 INSTALLED_APPS, but settings are not configured. You must either define
 the environment variable DJANGO_SETTINGS_MODULE or call
 settings.configure() before accessing settings.

-- 
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/010701847ec43858-f9cdc04c-3357-4b81-91e5-17bdf294a2b3-00%40eu-central-1.amazonses.com.

Re: [Django] #33682: Clarify using distinct() with related fields that have Meta.ordering defined.

2022-11-15 Thread Django 
#33682: Clarify using distinct() with related fields that have Meta.ordering
defined.
-+-
 Reporter:  Robert Leach |Owner:  anegawa-j
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Documentation|  Version:  3.2
 Severity:  Normal   |   Resolution:
 Keywords:  sql, distinct| Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by anegawa-j):

 * owner:  nobody => anegawa-j
 * 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/010701847e596807-3fe95f9a-de24-42b6-8233-bf30dc883d98-00%40eu-central-1.amazonses.com.

[Django] #34162: Wrong URL generated by get_admin_url in admin index "Recent Actions" panel in custom Django Admin Site

2022-11-15 Thread Django 
#34162: Wrong URL generated by get_admin_url in admin index "Recent Actions" 
panel
in custom Django Admin Site
-+
   Reporter:  Rigo-Villalta  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  contrib.admin  |Version:  4.0
   Severity:  Normal |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 When a custom Admin Site is generated the method {{{ get_admin_url }}} of
 the class {{{ LogEntry }}} in {{{ contrib/admin/models }}} generates a
 link to {{{ /admin/... }}} instead of {{{ /custom-admin/... }}}

 This is the code of the method:

 {{{
 if self.content_type and self.object_id:
 url_name = "admin:%s_%s_change" % (
 self.content_type.app_label,
 self.content_type.model,
 )
 try:
 return reverse(url_name, args=(quote(self.object_id),))
 }}}

 The problem here is that the class LogEntry has not an instance of Admin
 Site as in this ticket: [https://code.djangoproject.com/ticket/33077] .

 I have tested this bug in Django 3.2, 3.1 and 4.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/010701847e2e4528-70bb8ff7-a3f9-434a-9bd5-152a24b07221-00%40eu-central-1.amazonses.com.

Re: [Django] #34160: Django 4.1 Expression contains mixed types for (Big/Small)IntegerFields.

2022-11-15 Thread Django 
#34160: Django 4.1 Expression contains mixed types for (Big/Small)IntegerFields.
-+-
 Reporter:  Martin Lehoux|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  4.1
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette):

 I agree with your suggested solution Markusz. Adding entries to
 `_connector_combinations` seems like the way to go for a backport.

 > Based on my experience with the related patch, I think it would be worth
 checking what MySQL and Postgres do for cases like this - there could be
 some unexpected surprises

 I know that Postgres will silently cast values outside of the `bigint`
 range to `numeric` with [https://code.jeremyevans.net/2022-11-01-forcing-
 sequential-scans-on-postgresql.html its unfortunate side effect] so I'm
 pretty that it has operators defined to make integer comparison as
 implicit as possible.

-- 
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/010701847cfc5d71-98ef8194-f702-4888-b85c-6d71a7e57c65-00%40eu-central-1.amazonses.com.

Re: [Django] #34160: Django 4.1 Expression contains mixed types for (Big/Small)IntegerFields.

2022-11-15 Thread Django 
#34160: Django 4.1 Expression contains mixed types for (Big/Small)IntegerFields.
-+-
 Reporter:  Martin Lehoux|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  4.1
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Luke Plant):

 I agree we should try to automatically resolve the type. Based on my
 experience with the related patch, I think it would be worth checking what
 MySQL and Postgres do for cases like this - there could be some unexpected
 surprises e.g. the database actually casts to the smaller of the type, or
 the first type. In this case, the user may need to know that it isn't
 going to do what you expect.

-- 
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/010701847ce28581-935fa773-ae35-424d-86a6-56166b63938a-00%40eu-central-1.amazonses.com.

Re: [Django] #34160: Django 4.1 Expression contains mixed types for (Big/Small)IntegerFields. (was: Django 4.1 Expression contains mixed types)

2022-11-15 Thread Django 
#34160: Django 4.1 Expression contains mixed types for (Big/Small)IntegerFields.
-+-
 Reporter:  Martin Lehoux|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  4.1
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * cc: Simon Charette, Luke Plant (added)
 * type:  Uncategorized => Bug
 * severity:  Normal => Release blocker
 * stage:  Unreviewed => Accepted


Comment:

 Thanks for the report. I think we should automatically resolved
 `output_field` for a mix of integer types, e.g.:
 - `IntegerField` and `SmallIntegerField` -> `IntegerField`,
 - `IntegerField` and `BigIntegerField` -> `BigIntegerField`,
 - `BigIntegerField` and `SmallIntegerField` -> `BigIntegerField`.

 Regression in 40b8a6174f001a310aa33f7880db0efeeb04d4c4.

-- 
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/010701847c9a9c07-85efb066-dad2-4029-978a-d938498eb743-00%40eu-central-1.amazonses.com.

Re: [Django] #34161: Wrong Name in Django Relationship

2022-11-15 Thread Django 
#34161: Wrong Name in Django Relationship
-+--
 Reporter:  Vshivam1710  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Documentation|  Version:  4.1
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  ManyToManyField  | 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
 * resolution:   => invalid
 * component:  Database layer (models, ORM) => Documentation


Comment:

 This page also contains information about `ForeignKey`. I don't see
 anything wrong with this section.

-- 
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/010701847c4a23c7-81b5edb5-164c-448b-9548-da5c0e303c5e-00%40eu-central-1.amazonses.com.

Re: [Django] #34161: Wrong Name in Django Relationship

2022-11-15 Thread Django 
#34161: Wrong Name in Django Relationship
-+-
 Reporter:  Vshivam1710  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  4.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  ManyToManyField  | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Vshivam1710):

 * Attachment "Screenshot from 2022-11-15 22-14-24.png" added.

 Typo mistake

-- 
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/010701847c38758c-7c66dca8-4f8c-4d07-bbb0-69f0f8853da0-00%40eu-central-1.amazonses.com.

[Django] #34161: Wrong Name in Django Relationship

2022-11-15 Thread Django 
#34161: Wrong Name in Django Relationship
-+-
   Reporter: |  Owner:  nobody
  Vshivam1710|
   Type:  Bug| Status:  new
  Component:  Database   |Version:  4.1
  layer (models, ORM)|
   Severity:  Normal |   Keywords:  ManyToManyField
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 I have read about the relationship on this page
 [https://docs.djangoproject.com/en/4.1/topics/db/models/].

 In this page Many-to-Many relationship information present. But by mistake
 `ForeignKeyField` name placed reather then `ManyToManyField`.

 Please check and correct it. Let me also share screenshot.

-- 
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/010701847c37d354-fdbd7f01-faf9-44c6-b415-b8ce12c8cd3b-00%40eu-central-1.amazonses.com.

Re: [Django] #34160: Django 4.1 Expression contains mixed types (was: Django 4.1)

2022-11-15 Thread Django 
#34160: Django 4.1 Expression contains mixed types
-+-
 Reporter:  Martin Lehoux|Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Database layer   |  Version:  4.1
  (models, ORM)  |
 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/010701847c154806-67294896-c673-47fb-bf8c-c7e1a0c2b0bd-00%40eu-central-1.amazonses.com.

[Django] #34160: Django 4.1

2022-11-15 Thread Django 
#34160: Django 4.1
-+-
   Reporter:  Martin |  Owner:  nobody
  Lehoux |
   Type: | Status:  new
  Uncategorized  |
  Component:  Database   |Version:  4.1
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Hi,

 During an update from Django 4.0.8 to 4.1.3, an unexpected bug occured in
 our tests.

 {{{
 django.core.exceptions.FieldError: Expression contains mixed types:
 IntegerField, SmallIntegerField. You must set output_field.
 }}}

 I understand what it means, but I couldn't find what changed between these
 two versions that could explain the appearance of this error.


 {{{
 Case(
 When(
 True,
  then=F("inventory_count") + Value(1),
 ),
 default=F("inventory_count"),
 )
 }}}

 I could easily fix it with

 {{{
 Case(
 When(
 True,
  then=F("inventory_count") + Value(1),
 ),
 default=F("inventory_count"),
 output_field=IntegerField(),
 )
 }}}

-- 
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/010701847c0d5d5d-914c470a-cb08-497a-bf8a-f90df36aa5b6-00%40eu-central-1.amazonses.com.

Re: [Django] #28987: Migration changing ManyToManyField target to 'self' doesn't work correctly

2022-11-15 Thread Django 
#28987: Migration changing ManyToManyField target to 'self' doesn't work 
correctly
-+
 Reporter:  MSleepyPanda |Owner:  Bhuvnesh
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  2.0
 Severity:  Normal   |   Resolution:
 Keywords:  ManyToManyField  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by Bhuvnesh):

 * 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/010701847b6c6e41-35446460-c634-4f4f-97e2-11e236d158ec-00%40eu-central-1.amazonses.com.

Re: [Django] #33689: Django theme color variables are inconsistently named and poorly documented

2022-11-15 Thread Django 
#33689: Django theme color variables are inconsistently named and poorly 
documented
-+-
 Reporter:  Murray Chapman   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  contrib.admin|  Version:  4.0
 Severity:  Normal   |   Resolution:
 Keywords:  theme dark mode  | Triage Stage:  Accepted
  color variables documentation  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Michael):

 I agree with the original poster. It takes a bit of trial and error to
 skin the admin. Sometimes you skin something in one situation, and then
 the same variable is used elsewhere, and then it clashes (doesnt work
 visually) down the line. I also have had clashes with Django CSS custom
 property names.

 Just a side comment: In the web framework context, it is a common pattern
 to use a two letter acronym for namespacing, e.g. `tw` for tailwind, `ng`
 for angular. We could prefix all variables with `dj`. e.g. ` --dj-body-
 fg`.

 Another solution would be to place properties under a top level admin
 container instead of `:root`, e.g.

 {{{
 .admin-top-level-container {
   --body-fg: black;
 }
 }}}

-- 
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/010701847b5a3ed6-0fa1f98b-4fa8-4d5b-a006-f6faa443a15f-00%40eu-central-1.amazonses.com.

Re: [Django] #34155: ModelAdmin.render_change_form does not lowercase the app_label when setting template directories

2022-11-15 Thread Django 
#34155: ModelAdmin.render_change_form does not lowercase the app_label when 
setting
template directories
---+--
 Reporter:  Rishi Diwan|Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  contrib.admin  |  Version:  3.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:  0
---+--

Comment (by Mariusz Felisiak):

 > macOS APFS is case insensitive:

 TIL

-- 
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/010701847acb018d-ecb6ddbb-0f46-4a54-a2c5-cf3fcb2d2c1f-00%40eu-central-1.amazonses.com.

Re: [Django] #34155: ModelAdmin.render_change_form does not lowercase the app_label when setting template directories

2022-11-15 Thread Django 
#34155: ModelAdmin.render_change_form does not lowercase the app_label when 
setting
template directories
---+--
 Reporter:  Rishi Diwan|Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  contrib.admin  |  Version:  3.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:  0
---+--

Comment (by Carlton Gibson):

 macOS APFS is case insensitive:

 {{{
 % mkdir App
 % mkdir app
 mkdir: app: File exists
 % ls
 App
 % diskutil info /System/Volumes/Data | grep Personality
File System Personality:   APFS
 }}}

 However...

 > However on OSX systems the file shows up as
 template/django/admin/app/inventory/change_form.html.
 > This breaks the functionality since the template is no longer found in
 the App/inventory directory.

 On macOS I'd expect the template to be found regardless of the casing of
 the `app` directory.
 (A full runnable example showing otherwise please.)

 This is a long-standing gotcha of macOS. Linux has case sensitive names so
 don't use `App` unless you mean it there. It's best just to use lowercase,
 and then you don't hit problems.
 (Use `AppConfig.verbose_name` if you want that for display purposes.)

 > ...forcing lowercase would be highly backward incompatible

 Exactly. This isn't something we can realistically change.

-- 
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/010701847ac46e4d-6b4576cc-c2e2-4bb7-9769-f43ba9d04712-00%40eu-central-1.amazonses.com.

Re: [Django] #34159: Django potential improvement - views decorator for http_timeout with auto retry

2022-11-15 Thread Django 
#34159: Django potential improvement - views decorator for http_timeout with 
auto
retry
-+-
 Reporter:  JDonMc   |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  HTTP handling|  Version:  4.1
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  views decorator  | Triage Stage:
  timeout|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-
Changes (by Carlton Gibson):

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


Comment:

 > Ideally I'd set a timer so that any request that takes 4+ seconds to
 solve is killed and retried,
 and a secondary timer so that any request that has been retried 7 times
 redirects to an error page,
 on the error page implement some javascript to re-request the page.

 I think this would work well as a third-party app. Certainly prototyping
 it there would be appropriate, following up on the DevelopersMailingList
 to discuss inclusion at that point.

 For the simpler case, perhaps a [https://adamj.eu/tech/2019/05/27/the-
 simplest-wsgi-middleware/ WSGI Middleware] would be the easiest thing to
 add?

-- 
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/010701847ab8e4f3-896745ab-83bb-492d-8cf1-dc7089e68702-00%40eu-central-1.amazonses.com.

Re: [Django] #34123: Ambiguous aliases in ordering on combined queries with select_related().

2022-11-15 Thread Django 
#34123: Ambiguous aliases in ordering on combined queries with select_related().
-+-
 Reporter:  Shai Berger  |Owner:  David
 |  Sanders
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:  select_related   | 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:"70499b25c708557fb9ee2264686cd172f4b2354e" 70499b2]:
 {{{
 #!CommitTicketReference repository=""
 revision="70499b25c708557fb9ee2264686cd172f4b2354e"
 Fixed #34123 -- Fixed combinator order by alias when using
 select_related().

 Regression in c58a8acd413ccc992dd30afd98ed900897e1f719.

 Thanks to Shai Berger for the report and tests.

 Co-Authored-By: David Sanders 
 }}}

-- 
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/010701847ab16e64-2b1dfe99-9ce3-42d3-9c56-39af53e61ae1-00%40eu-central-1.amazonses.com.

Re: [Django] #34123: Ambiguous aliases in ordering on combined queries with select_related().

2022-11-15 Thread Django 
#34123: Ambiguous aliases in ordering on combined queries with select_related().
-+-
 Reporter:  Shai Berger  |Owner:  David
 |  Sanders
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  select_related   | 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):

 * has_patch:  0 => 1
 * stage:  Accepted => Ready for checkin


Comment:

 [https://github.com/django/django/pull/16296 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/010701847a879781-0be36e77-30ed-4016-944f-bd87e3e240c3-00%40eu-central-1.amazonses.com.

[Django] #34159: Django potential improvement - views decorator for http_timeout with auto retry

2022-11-15 Thread Django 
#34159: Django potential improvement - views decorator for http_timeout with 
auto
retry
-+-
   Reporter:  JDonMc |  Owner:  nobody
   Type:  New| Status:  new
  feature|
  Component:  HTTP   |Version:  4.1
  handling   |   Keywords:  views decorator
   Severity:  Normal |  timeout
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  1  |
-+-
 Sometimes django views take 30+ seconds to load, and then timeout.

 The weird thing is, that you can refresh the page from a browser, and it
 will load in less than a second.

 Because it's non-deterministic, it's really hard to solve.

 Ideally I'd set a timer so that any request that takes 4+ seconds to solve
 is killed and retried,
 and a secondary timer so that any request that has been retried 7 times
 redirects to an error page,
 on the error page implement some javascript to re-request the page.

 I understand it's a bit much, but the first thing is important to me.
 Most 99% of my requests are under 2 seconds,
 but for some reason at random intervals it hits 30+ and sends an 503
 error,
 But it's non-deterministic because that same page can still be loaded
 exactly the same within 2 seconds.

-- 
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/010701847a4e802e-5edff6b4-a171-4e31-9be3-c92e8d87a4fc-00%40eu-central-1.amazonses.com.