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

[Django]

#33689: Django theme color variables are inconsistently named and poorly 
documented
-+-
 Reporter:  Murray Chapman   |Owner:  stimver
 Type:   |   Status:  assigned
  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
-+-
Changes (by stimver):

 * owner:  nobody => stimver
 * 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/0107018717576b4f-2f3da279-2549-4726-90bd-6403d2f80461-00%40eu-central-1.amazonses.com.

Re: [Django] #34411: Update obsolete GDAL API for DataSource handling

[Django]

#34411: Update obsolete GDAL API for DataSource handling
--+
 Reporter:  Claude Paroz  |Owner:  (none)
 Type:  Cleanup/optimization  |   Status:  new
Component:  GIS   |  Version:  dev
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+
Changes (by stimver):

 * owner:  stimver => (none)
 * status:  assigned => new


-- 
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/010701871755db68-424ac7d4-282a-47ed-a1f0-1f9ab45a52f7-00%40eu-central-1.amazonses.com.

Re: [Django] #34411: Update obsolete GDAL API for DataSource handling

[Django]

#34411: Update obsolete GDAL API for DataSource handling
--+
 Reporter:  Claude Paroz  |Owner:  stimver
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  GIS   |  Version:  dev
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+
Changes (by stimver):

 * owner:  (none) => stimver
 * 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/0107018717555d4c-5dcbd116-9b8e-43a0-8eb3-f63533cb70f5-00%40eu-central-1.amazonses.com.

Re: [Django] #34352: Unify terms in Signals docs.

[Django]

#34352: Unify terms in Signals docs.
--+
 Reporter:  PASCAL FOUQUE |Owner:  stimver
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Documentation |  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 stimver):

 * owner:  nobody => stimver
 * 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/01070187174e3678-976115aa-c84f-4612-bfc9-994ce47d0b60-00%40eu-central-1.amazonses.com.

Re: [Django] #34411: Update obsolete GDAL API for DataSource handling

[Django]

#34411: Update obsolete GDAL API for DataSource handling
--+
 Reporter:  Claude Paroz  |Owner:  (none)
 Type:  Cleanup/optimization  |   Status:  new
Component:  GIS   |  Version:  dev
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+
Changes (by stimver):

 * owner:  stimver => (none)
 * status:  assigned => new


-- 
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/01070187174d7423-b9fdb7e6-623c-4539-b528-3913a35faf58-00%40eu-central-1.amazonses.com.

Re: [Django] #34411: Update obsolete GDAL API for DataSource handling

[Django]

#34411: Update obsolete GDAL API for DataSource handling
--+
 Reporter:  Claude Paroz  |Owner:  stimver
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  GIS   |  Version:  dev
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+
Changes (by stimver):

 * owner:  nobody => stimver
 * 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/01070187174c7caf-253d60dc-6e42-45f4-9b9c-ff8d5c25526c-00%40eu-central-1.amazonses.com.

Re: [Django] #32263: squashmigrations produces incorrect result with a RenameModel on a ForeignKey target.

[Django]

#32263: squashmigrations produces incorrect result with a RenameModel on a
ForeignKey target.
-+-
 Reporter:  InvalidInterrupt |Owner:  Anvesh
 |  Mishra
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  3.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
-+-

Comment (by Durval Carvalho):

 I tried to deal with this problem as follows. In the CreateModel.reduce
 function, when executed with a RenameModel operation, I check if the
 CreateModel operation has any fields that may have been impacted by the
 RenameModel operation, because in this scenario, these fields need to be
 updated for this renamed model.


 {{{

 def reduce(self, operation, app_label):
 ...
 elif impacted_fields := [
 (_, field)
 for _, field in self.fields
 if field.remote_field
 and field.remote_field.model ==
 f'{app_label}.{operation.old_name_lower}'
 ]:
 not_impacted_fields = [
 (_, field)
 for (_, field) in self.fields
 if (_, field) not in impacted_fields
 ]

 fixed_fields = []

 for (_, impacted_field) in impacted_fields:
 name, path, args, kwargs = impacted_field.deconstruct()
 kwargs['to'] = f'{app_label}.{operation.new_name_lower}'
 impacted_field = impacted_field.__class__(*args, **kwargs)
 fixed_fields.append((_, impacted_field))

 return [
 CreateModel(
 self.name,
 fields=not_impacted_fields + fixed_fields,
 bases=self.bases,
 managers=self.managers,
 ),
 ]
 ...
 }}}

 However, this approach did not work for the following reason. When the
 CreateModel operation is executed with its respective RenameModel, both
 are reduced to the new CreateModel operation. Then, some checks are made
 to decide whether this new resulting operation will be added to the list
 of new operations. But with this new reduction that I created, the other
 CreateModel operations, the ones that reference the renamed model, are
 also reduced, and this breaks the verification described below.

 {{{
 ...
 for i, operation in enumerate(operations):
 right = True  # Should we reduce on the right or on the left.
 # Compare it to each operation after it
 for j, other in enumerate(operations[i + 1 :]):
 result = operation.reduce(other, app_label)
 if isinstance(result, list):
 in_between = operations[i + 1 : i + j + 1]
 if right:
 new_operations.extend(in_between)
 new_operations.extend(result)
 elif all(op.reduce(other, app_label) is True for op in
 in_between): # <<< This condition fails (I didn't understand what is
 being checked here)
 # Perform a left reduction if all of the in-
 between
 # operations can optimize through other.
 new_operations.extend(result)
 new_operations.extend(in_between)
 else:
 #  New operation `result` is not added to new operations list
 # Otherwise keep trying.
 new_operations.append(operation)
 break
 ...
 }}}


 Now I am stuck, trying to think of a way to work around this problem.
 Do any of you have any suggestions?

-- 
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/0107018715968041-0619c62c-bdda-4be2-9c9b-11f2fe328c16-00%40eu-central-1.amazonses.com.

Re: [Django] #34436: `makemigrations --check` fails with error code 1 if system checks identify warnings

[Django]

#34436: `makemigrations --check` fails with error code 1 if system checks 
identify
warnings
---+--
 Reporter:  James Addison  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Migrations |  Version:  4.2
 Severity:  Normal |   Resolution:  invalid
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by James Addison):

 I think this should be reopened - I suspect I didn't convey the meaning
 correctly?

 - `manage.py check` is ''correctly not failing'' (see the 0 exit code in
 my example)
   - nothing is currently (until 5.1 is released) in a broken check state
 - `manage.py makemigrations --check` is ''incorrectly failing'' (see 1
 exit code in my example above)
   - the 'check' for missing migrations yielded no missing migrations, so
 should not return an error
   - the fact that those warning are raised have nothing to do with
 migrations currently at risk (again, until 5.1 is released)

-- 
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/010701871572e78e-b28df699-5f71-411a-9dbb-366eb9ce9552-00%40eu-central-1.amazonses.com.

Re: [Django] #28553: Querysets: annotate() columns are forced into a certain position which may disrupt union()

[Django]

#28553: Querysets: annotate() columns are forced into a certain position which 
may
disrupt union()
-+-
 Reporter:  David Sanders|Owner:  David
 |  Wobrock
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak):

 Replying to [comment:14 Simon Charette]:
 > I'm bringing this up because most if not all of the changes made to
 `sql.Query` for change the type of `annotation_mask` are unnecessary to
 solve #28553 entirely.

 I will be happy to review any adjustments in this area, +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/0107018715502481-ef0be5eb-fd02-423f-b93d-566cf5da673e-00%40eu-central-1.amazonses.com.

Re: [Django] #34436: `makemigrations --check` fails with error code 1 if system checks identify warnings

[Django]

#34436: `makemigrations --check` fails with error code 1 if system checks 
identify
warnings
---+--
 Reporter:  James Addison  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Migrations |  Version:  4.2
 Severity:  Normal |   Resolution:  invalid
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Mariusz Felisiak):

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


Comment:

 Replying to [ticket:34436 James Addison]:
 > Note that both `manage.py makemigrations --check` and `manage.py check`
 are provided above for clarity.
 >
 > These are deprecation warnings (to be removed in Django 5.1). I think
 this management command should not be erroring out in relation to these at
 this point in time.

 `check` cannot succeed when warnings are raised, so a non-zero return code
 is expected. You can always use the
 [https://docs.djangoproject.com/en/4.1/ref/settings/#std-setting-
 SILENCED_SYSTEM_CHECKS SILENCED_SYSTEM_CHECKS] setting to ignore them.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/01070187154ba558-cbe3e382-1cb5-475a-ac66-2d8e10d2493c-00%40eu-central-1.amazonses.com.

Re: [Django] #28553: Querysets: annotate() columns are forced into a certain position which may disrupt union()

[Django]

#28553: Querysets: annotate() columns are forced into a certain position which 
may
disrupt union()
-+-
 Reporter:  David Sanders|Owner:  David
 |  Wobrock
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Simon Charette):

 #28900 seems to be an even more complex case where none of the combined
 queries use explicit `values` but the result of the query combination
 does.

 In the comment:3 example both queries use `values` but happen to mix field
 references and annotations which is not covered by the test included in
 d6b6e5d0fd4e6b6d0183b4cf6e4bd4f9afc7bf67.

 I'm bringing this up because most if not all of the changes made to
 `sql.Query` for change the type of `annotation_mask` are unnecessary to
 solve #28553 entirely.

-- 
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/0107018715472445-066c51be-eed9-49e0-9eae-ec533d20233f-00%40eu-central-1.amazonses.com.

Re: [Django] #28553: Querysets: annotate() columns are forced into a certain position which may disrupt union()

[Django]

#28553: Querysets: annotate() columns are forced into a certain position which 
may
disrupt union()
-+-
 Reporter:  David Sanders|Owner:  David
 |  Wobrock
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak):

 Replying to [comment:12 Simon Charette]:
 > Small note that the cases reported in comment:3 is not fixed, ...

 Yes, but this case is described in #28900. Am I right?

-- 
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/01070187153b8605-81adf2f4-11b2-4711-9961-d10d67dcf282-00%40eu-central-1.amazonses.com.

Re: [Django] #34316: Visual regressions in admin's change password form

[Django]

#34316: Visual regressions in admin's change password form
-+-
 Reporter:  Mariusz Felisiak |Owner:  Sarah
 |  Boyce
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  4.2
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"ded3334af6de74214ba3f985e68749e3c47ffd16" ded3334]:
 {{{
 #!CommitTicketReference repository=""
 revision="ded3334af6de74214ba3f985e68749e3c47ffd16"
 [4.2.x] Refs #34316 -- Fixed layout of admin password change forms and
 help texts for RTL languages.

 Regression in 96a598356a9ea8c2c05b22cadc12e256a3b295fd.

 Follow up to e67804668115fd388e7554c6a809bd409f70adfe and
 39d1e45227e060746ed461fddde80fa2b6cf0dcd.
 Backport of f5c5c571d3b87a78d005ea6f21959388d1747696 from main
 }}}

-- 
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/01070187152b7fdc-18665e2b-8f38-4a0b-8c58-a0089b6add54-00%40eu-central-1.amazonses.com.

Re: [Django] #34316: Visual regressions in admin's change password form

[Django]

#34316: Visual regressions in admin's change password form
-+-
 Reporter:  Mariusz Felisiak |Owner:  Sarah
 |  Boyce
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  4.2
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by GitHub ):

 In [changeset:"f5c5c571d3b87a78d005ea6f21959388d1747696" f5c5c57]:
 {{{
 #!CommitTicketReference repository=""
 revision="f5c5c571d3b87a78d005ea6f21959388d1747696"
 Refs #34316 -- Fixed layout of admin password change forms and help texts
 for RTL languages.

 Regression in 96a598356a9ea8c2c05b22cadc12e256a3b295fd.

 Follow up to e67804668115fd388e7554c6a809bd409f70adfe and
 39d1e45227e060746ed461fddde80fa2b6cf0dcd.
 }}}

-- 
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/010701871529bdfd-ec09df7f-be89-4f08-8ce2-0a09b365408d-00%40eu-central-1.amazonses.com.

Re: [Django] #28553: Querysets: annotate() columns are forced into a certain position which may disrupt union()

[Django]

#28553: Querysets: annotate() columns are forced into a certain position which 
may
disrupt union()
-+-
 Reporter:  David Sanders|Owner:  David
 |  Wobrock
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Simon Charette):

 * cc: Simon Charette (added)


Comment:

 Small note that the cases reported in comment:3 is not fixed, the merged
 patch only focuses on the case where only annotations are referenced in
 `values`/`values_list` which is a subset of the problem reported here as
 mixing field references, extra, and annotations demonstrate.

 The crux of the issue is that `SQLCompiler.get_select` ignores
 `Query.values_select` and
 
[https://github.com/django/django/blob/cffcf0ef17b2dfd744d3bc64080229c1b500508f/django/db/models/sql/compiler.py#L247-L276
 always generate selected columns as follow]
 1. Start with `Query.extra_select`
 2. Then `Query.select`
 3. End with `Query.annotation_select`

 The patch here only makes sure that the order of `annotation_select` is
 preserved. What should be done instead is adjust `get_select` to be
 `Query.values_select` aware as pointed out on the MR.

-- 
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/0107018715121612-a0b29299-83ca-4550-9d59-09749d21f7be-00%40eu-central-1.amazonses.com.

[Django] #34436: `makemigrations --check` fails with error code 1 if system checks identify warnings

[Django]

#34436: `makemigrations --check` fails with error code 1 if system checks 
identify
warnings
-+
   Reporter:  James Addison  |  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  |
-+
 In working through the upgrade steps from a Django 3.2 based system to
 Django 4.2, I encountered behaviour that breaks our github actions
 continuous integration (it is intended to fail if there are missing
 migrations needed).

 In this case, there are no missing migration files identified, but the
 `./venv/bin/python manage.py makemigrations --check` command errors out
 with `1`, presumably due to CICharField W905 and CITextField W907
 warnings:

 {{{
 # ./venv/bin/python manage.py makemigrations --check
 System check identified some issues:

 WARNINGS:
 accounts.ComplianceRegion.name: (fields.W905)
 django.contrib.postgres.fields.CICharField is deprecated. Support for it
 (except in historical migrations) will be removed in Django 5.1.
 HINT: Use CharField(db_collation="…") with a case-insensitive non-
 deterministic collation instead.
 accounts.ComplianceRegion.sub_region: (fields.W905)
 django.contrib.postgres.fields.CICharField is deprecated. Support for it
 (except in historical migrations) will be removed in Django 5.1.
 HINT: Use CharField(db_collation="…") with a case-insensitive non-
 deterministic collation instead.
 information.Degree.degree: (fields.W907)
 django.contrib.postgres.fields.CITextField is deprecated. Support for it
 (except in historical migrations) will be removed in Django 5.1.
 HINT: Use TextField(db_collation="…") with a case-insensitive non-
 deterministic collation instead.

 System check identified 3 issues (5 silenced).

 # echo $?
 1


 # /venv/bin/python manage.py check
 System check identified some issues:

 WARNINGS:
 accounts.ComplianceRegion.name: (fields.W905)
 django.contrib.postgres.fields.CICharField is deprecated. Support for it
 (except in historical migrations) will be removed in Django 5.1.
 HINT: Use CharField(db_collation="…") with a case-insensitive non-
 deterministic collation instead.
 accounts.ComplianceRegion.sub_region: (fields.W905)
 django.contrib.postgres.fields.CICharField is deprecated. Support for it
 (except in historical migrations) will be removed in Django 5.1.
 HINT: Use CharField(db_collation="…") with a case-insensitive non-
 deterministic collation instead.
 information.Degree.degree: (fields.W907)
 django.contrib.postgres.fields.CITextField is deprecated. Support for it
 (except in historical migrations) will be removed in Django 5.1.
 HINT: Use TextField(db_collation="…") with a case-insensitive non-
 deterministic collation instead.

 System check identified 3 issues (5 silenced).

 # echo $?
 0
 }}}

 Note that both `manage.py makemigrations --check` and `manage.py check`
 are provided above for clarity.

 These are deprecation warnings (to be removed in Django 5.1). I think this
 management command should not be erroring out in relation to these at this
 point in time.

 I personally have time to address these CITextField and CICharField
 warnings properly by moving to the preferred `db_collation=...` collation
 approach, but wanted to raise this as a 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/0107018714724b10-7b6b941e-b507-4074-a66a-3c7da5ab7172-00%40eu-central-1.amazonses.com.

Re: [Django] #34433: OneToOneField can only be saved one way

[Django]

#34433: OneToOneField can only be saved one way
-+-
 Reporter:  Alexis Lesieur   |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  4.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  duplicate
 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 Alexis Lesieur):

 First off apologies for missing the older ticket. I searched for similar
 problems but...

 Replying to [comment:3 Mariusz Felisiak]:
 > > It's also problematic as foreigh keys work this way: (from my work
 example)
 >
 > That's not true, on foreign keys you also cannot assign to a **reverse**
 side.
 You cannot "assign" as I may not just be able to do
 `me.authored_pinnedmessage = ...` (to reference my earlier example) but I
 can definitely do:
 {{{
 ❯ PinnedMessage.objects.get(id=1).author
 

 ❯ me = ExternalUser.objects.get(id=1)
 ❯ me.authored_pinnedmessages.add(p)
 ❯ me.save()

 ❯ PinnedMessage.objects.get(id=1).author
 
 }}}
 And this works. So I can definitely use the reverse relationship.

 Replying to [comment:3 Mariusz Felisiak]:
 > > `.save()` "fails" silently, there is no way to know that the change
 didn't take, especially when this happens:
 >
 > `save()` doesn't fail silently. By assigning an object to the
 `.restaurant` you override a lazy reverse side of `OneToOneField` to a
 "static" instance so it's not recognize as a relationship anymore.
 I wholeheartedly disagree. Not only does it recognize the relationship
 still as this proves:
 {{{
 ❯ p1 = Place(name="1st place", address="1st address")
 ❯ p1.save()
 ❯ r1 = Restaurant(place=p1)
 ❯ r1.save()
 ❯ r2 = Restaurant(place=p2)
 ❯ r2.save()

 ❯ p1.restaurant = r2
 ❯ r2.place
 
 }}}
 It is clearly reflected. The relationship is definitely recognized.
 It is just being ignored on save.

 When as we showed it's being honored for ForeignKeys. Which the
 documentation claims behaves the same.

 I understand that from a pure implementation pov you're telling me that
 doing `model.related_set.add(...)` is different than doing
 `place.restaurant = new_place` here.
 But that's really besides the point. From a user POV, the behavior is
 highly unexpected, and really the main problem IMO (assuming you do keep
 the current behavior) the documentation is really not addressing this
 issue in any way.
 In addition to the "OneToOneFields are just ForeignKeys with unique=True"
 the documentation on how to use them clearly says:

 > Set the place using assignment notation. Because place is the primary
 key on Restaurant, the save will create a new restaurant:
 {{{
 >>> r.place = p2
 >>> r.save()
 >>> p2.restaurant
 
 >>> r.place
 
 }}}

 >Set the place back again, using assignment in the reverse direction:
 {{{
 >>> p1.restaurant = r
 >>> p1.restaurant
 
 }}}

 Without addressing anywhere that you can't do p1.save() here. Which is
 very counterintuitive. It is extremely expected that if I do
 `p1.restaurant = r`, to apply/save that change, I should be doing
 `p1.save()`.
 If we're saying this is not applicable, please do call it out in the
 documentation :-)

-- 
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/0107018713ef9337-7d6fa10c-81e7-462b-949a-456fb53d2409-00%40eu-central-1.amazonses.com.

Re: [Django] #32539: Support accessing the current filtered queryset from within SimpleListFilter.lookups()

[Django]

#32539: Support accessing the current filtered queryset from within
SimpleListFilter.lookups()
-+-
 Reporter:  Simon Willison   |Owner:  Sarah
 |  Boyce
 Type:  New feature  |   Status:  closed
Component:  contrib.admin|  Version:  3.1
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by GitHub ):

 In [changeset:"cffcf0ef17b2dfd744d3bc64080229c1b500508f" cffcf0e]:
 {{{
 #!CommitTicketReference repository=""
 revision="cffcf0ef17b2dfd744d3bc64080229c1b500508f"
 Refs #32539 -- Fixed hide counts icon for RTL languages.

 Bug in 868e2fcddae6720d5713924a785339d1665f1bb9.
 }}}

-- 
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/0107018713a48dd0-ab38f451-65c7-4b80-8de4-ed14fc4893b9-00%40eu-central-1.amazonses.com.

Re: [Django] #34435: JSONField with string default raises fields.E010 warning. (was: JSONField with default='' raises warning "JSONField default should be a callable")

[Django]

#34435: JSONField with string default raises fields.E010 warning.
--+
 Reporter:  Tobias Krönke |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Core (System checks)  |  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 Mariusz Felisiak):

 * cc: Sage Abdullah (added)
 * type:  Uncategorized => Bug
 * component:  Uncategorized => Core (System checks)
 * stage:  Unreviewed => Accepted


Comment:

 Thanks for the report. Agreed, we should fix this, especially since it is
 clearly
 [https://docs.djangoproject.com/en/stable/ref/models/fields/#jsonfield
 documented] as correct:
 > ''"If you give the field a `default`, ensure it’s an immutable object,
 **such as a `str`**, or a callable object that returns ..."''

-- 
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/0107018713a00bf6-64b7d8a0-cc10-4ae2-a8dc-e5895a47df6f-00%40eu-central-1.amazonses.com.

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

[Django]

#34077: Make BoundField renderable.
-+-
 Reporter:  David Smith  |Owner:  David Smith
 Type:  New feature  |   Status:  closed
Component:  Forms|  Version:  4.1
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"cad376f844c7bd7607a7c0ea8ae52061309b" cad376f8]:
 {{{
 #!CommitTicketReference repository=""
 revision="cad376f844c7bd7607a7c0ea8ae52061309b"
 Fixed #34077 -- Added form field rendering.
 }}}

-- 
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/01070187136e3a59-ef6af19e-b047-4a8e-82ab-dcb14b759da1-00%40eu-central-1.amazonses.com.

[Django] #34435: JSONField with default='' raises warning "JSONField default should be a callable"

[Django]

#34435: JSONField with default='' raises warning "JSONField default should be a
callable"
-+
   Reporter:  Tobias Krönke  |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Uncategorized  |Version:  4.1
   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  |
-+
 Hi! I have a model with this field:


 {{{
 message = models.JSONField(editable=False, default='')
 }}}

 When running

 {{{
 manage.py check
 }}}

 I receive a warning, that IMO should not be triggered:

 {{{
 message: (fields.E010) JSONField default should be a callable instead of
 an instance so that it's not shared between all field instances.
 HINT: Use a callable instead, e.g., use `dict` instead of `{}`.
 }}}

 django should check, if the default is mutable and only if so issue that
 warning.

-- 
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/010701871367e350-0f965a55-1a24-47cc-95fa-b4aa06db36ed-00%40eu-central-1.amazonses.com.

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

[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:  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):

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


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018712e872ae-df430d2c-2b6f-4874-90e2-12f82aa9f6d3-00%40eu-central-1.amazonses.com.

Re: [Django] #34431: DateTimeField.input_formats change from Django 3.1 is documented improperly

[Django]

#34431: DateTimeField.input_formats change from Django 3.1 is documented 
improperly
--+
 Reporter:  stefan6419846 |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  3.1
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by Mariusz Felisiak):

 * cc: Claude Paroz (added)
 * type:  Uncategorized => Cleanup/optimization
 * component:  Uncategorized => Documentation
 * stage:  Unreviewed => Accepted


Comment:

 Thanks for the report. We should update the docs.

-- 
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/0107018712721f12-afdd1bd1-e33c-4c5b-8cab-bf1f2a13d422-00%40eu-central-1.amazonses.com.

Re: [Django] #28900: QuerySet.values() and values_list() for compound queries fails with annotation.

[Django]

#28900: QuerySet.values() and values_list() for compound queries fails with
annotation.
-+-
 Reporter:  elliott-omosheye |Owner:  David
 |  Wobrock
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  union, values| 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 Wobrock):

 * owner:  nobody => David Wobrock
 * 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/01070187126e6eeb-1d9c65b6-64ea-427e-bfbc-a0669d55ffbc-00%40eu-central-1.amazonses.com.

Re: [Django] #34434: psycopg 3 cursor.execute no longer accepts Python tuple binding

[Django]

#34434: psycopg 3 cursor.execute no longer accepts Python tuple binding
-+-
 Reporter:  David Burke  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  4.2
  (models, ORM)  |
 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):

 * cc: Florian Apolloner, Simon Charette (added)
 * status:  new => closed
 * resolution:   => invalid


Comment:

 Replying to [ticket:34434 David Burke]:
 > This may be a bug or a missing feature of psycopg 3. If expected, it may
 be worth mentioning as a breaking change when using psycopg3.

 Thanks for the ticket. This is a backward incompatibility change
 explicitly stated in `psycopg`
 [https://www.psycopg.org/psycopg3/docs/basic/from_pg2.html#you-cannot-use-
 in-s-with-a-tuple docs] (there are other small
 [https://www.psycopg.org/articles/2020/11/24/psycopg3-adaptation/ caveats]
 when using raw SQL statements). It's not something that we want/can change
 in Django itself. Moreover, it crashes with other backends so it's now
 more consistent.

 We normally don't document backward incompatibility changes in database
 adapters, especially on a low-level of executing raw SQL statements. We
 don't want to copy `psycopg` 3 docs here. I think your ticket will be
 enough to raise awareness on this small inconvenience.

-- 
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/01070187124b146c-fd9b54ec-8985-449a-baab-19968fd2843e-00%40eu-central-1.amazonses.com.