date:20221220

Re: [Django] #33961: Update admin's jQuery to 3.6.X.

2022-12-20 Thread Django

#33961: Update admin's jQuery to 3.6.X.
-+-
 Reporter:  Mariusz Felisiak |Owner:  Mariusz
 |  Felisiak
 Type:  New feature  |   Status:  assigned
Component:  contrib.admin|  Version:  dev
 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
-+-
Description changed by Mariusz Felisiak:

Old description:

> We should bump admin's jQuery to the latest 3.6.X release before 4.2
> alpha 1 release (January, 2023).
>
> See [https://blog.jquery.com/2022/08/26/jquery-3-6-1-maintenance-
> release/ 3.6.1. release notes].
> See [https://blog.jquery.com/2022/12/13/jquery-3-6-2-released/ 3.6.2.
> release notes].

New description:

 We should bump admin's jQuery to the latest 3.6.X release before 4.2 alpha
 1 release (January, 2023).

 See [https://blog.jquery.com/2022/08/26/jquery-3-6-1-maintenance-release/
 3.6.1. release notes].
 See [https://blog.jquery.com/2022/12/13/jquery-3-6-2-released/ 3.6.2.
 release notes].
 See [https://blog.jquery.com/2022/12/20/jquery-3-6-3-released-a-quick-
 selector-fix/ 3.6.3. release notes]

--

-- 
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/0107018533a94ffc-c938a624-223d-4793-b944-7a56d4c0-00%40eu-central-1.amazonses.com.

Re: [Django] #34220: Cannot import csrf_input_lazy from partially initialized module. (was: ImportError: cannot import name 'csrf_input_lazy' from partially initialized module 'django.template.backend

2022-12-20 Thread Django

#34220: Cannot import csrf_input_lazy from partially initialized module.
-+-
 Reporter:  thommy   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Template system  |  Version:  4.1
 Severity:  Normal   |   Resolution:
 Keywords:  Jinja2 TemplateView  | Triage Stage:  Accepted
  ImportError csrf_input_lazy|
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


Comment:

 Tentatively accepted (similar to the #33420). Can you confirm that the
 following patch works for you:
 {{{#!diff
 diff --git a/django/template/backends/jinja2.py
 b/django/template/backends/jinja2.py
 index 199d62b429..031278c2e2 100644
 --- a/django/template/backends/jinja2.py
 +++ b/django/template/backends/jinja2.py
 @@ -8,6 +8,7 @@ from django.utils.functional import cached_property
  from django.utils.module_loading import import_string

  from .base import BaseEngine
 +from .utils import csrf_input_lazy, csrf_token_lazy


  class Jinja2(BaseEngine):
 @@ -62,8 +63,6 @@ class Template:
  )

  def render(self, context=None, request=None):
 -from .utils import csrf_input_lazy, csrf_token_lazy
 -
  if context is None:
  context = {}
  if request is not None:
 }}}

-- 
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/0107018533a6e13a-50acae6d-8f0a-4a72-bfb4-f382fa383007-00%40eu-central-1.amazonses.com.

[Django] #34220: ImportError: cannot import name 'csrf_input_lazy' from partially initialized module 'django.template.backends.utils'

2022-12-20 Thread Django

#34220: ImportError: cannot import name 'csrf_input_lazy' from partially
initialized module 'django.template.backends.utils'
-+-
   Reporter:  thommy |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Template   |Version:  4.1
  system |   Keywords:  Jinja2 TemplateView
   Severity:  Normal |  ImportError csrf_input_lazy
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Hi,

 most of the time a TemplateView using Jinja2 is working fine, but
 sometimes I get the following exception. I wasn't able to figure out why
 it happens:

 {{{
 ImportError: cannot import name 'csrf_input_lazy' from partially
 initialized module 'django.template.backends.utils' (most likely due to a
 circular import) (/srv/pydl/env/lib/python3.9/site-
 packages/django/template/backends/utils.py)
   File "django/core/handlers/exception.py", line 55, in inner
 response = get_response(request)
   File "django/core/handlers/base.py", line 220, in _get_response
 response = response.render()
   File "django/template/response.py", line 114, in render
 self.content = self.rendered_content
   File "django/template/response.py", line 92, in rendered_content
 return template.render(context, self._request)
   File "django/template/backends/jinja2.py", line 65, in render
 from .utils import csrf_input_lazy, csrf_token_lazy
 }}}

 The view looks like this:
 {{{
 class ScriptView(TemplateView):
 """View for Tcl scripts"""

 template_engine = "jinja2"
 content_type = "text/x-tcl"

 extra_context = {"fqdn": settings.FQDN}
 }}}

 And it is used like the following:
 {{{
 path(
 "script.tcl",
 views.ScriptView.as_view(template_name="script.tcl.j2"),
 name="script",
 ),
 }}}

 Is it a race condition in conjunction with the Jinja2 template backend or
 is TemplateView not supposed to be used like this?

 Is it possible to force pre-loading the required modules?

 Best regards
 Thommy

-- 
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/0107018533986a69-5c80bbd6-4bec-4f75-86ea-5581a4eb3afa-00%40eu-central-1.amazonses.com.

Re: [Django] #34219: Collation is not preserved when field is altered on PostgreSQL and MySQL.

2022-12-20 Thread Django

#34219: Collation is not preserved when field is altered on PostgreSQL and 
MySQL.
-+-
 Reporter:  David Foster |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.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 Mariusz Felisiak):

 * Attachment "test-34219.diff" added.

 Regression test.

-- 
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/010701853391f241-d84a18f3-ad51-4bf9-91d2-88bd3e793e2e-00%40eu-central-1.amazonses.com.

Re: [Django] #34219: Collation is not preserved when field is altered on PostgreSQL and MySQL. (was: Custom field collation (db_collation) is not preserved when field is altered)

2022-12-20 Thread Django

#34219: Collation is not preserved when field is altered on PostgreSQL and 
MySQL.
-+-
 Reporter:  David Foster |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.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 Mariusz Felisiak):

 * cc: Tom Carrick, David Wobrock (added)
 * stage:  Unreviewed => Accepted


Comment:

 Thanks for the ticket. Would you like 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/01070185339169dd-c03fd018-32c1-4fe7-872e-399ae2ba422a-00%40eu-central-1.amazonses.com.

[Django] #34219: Custom field collation (db_collation) is not preserved when field is altered

2022-12-20 Thread Django

#34219: Custom field collation (db_collation) is not preserved when field is
altered
-+-
   Reporter:  David  |  Owner:  nobody
  Foster |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  3.2
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 At least for MySQL databases, if you make a change to a model field that
 has a custom db_collation, the resulting migration will run an ALTER TABLE
 statement that reverts the collation of the associated column to the
 enclosing table's default collation, rather than preserving the custom
 db_collation defined on the field.

 For example, here is a model with a field whose db_collation is
 customized:

 {{{
 class TeacherUploadedVideo(models.Model):
 filename = models.CharField(
 max_length=100,
 db_collation='utf8mb4_0900_as_cs',  # custom collation
 )
 }}}

 Django will initially create a table for that model which looks like:

 {{{
 mysql> SELECT COLUMN_NAME, COLLATION_NAME FROM information_schema.COLUMNS
 WHERE TABLE_SCHEMA = DATABASE() AND TABLE_NAME =
 'planner_teacheruploadedvideo' ORDER BY COLUMN_NAME;
 +-++
 | COLUMN_NAME | COLLATION_NAME |
 +-++
 | filename| utf8mb4_0900_as_cs |
 | id  | NULL   |
 +-++
 }}}

 But if you then alter the field slightly, such as by altering the
 max_length from 100 to 120, Django will generate a migration that does NOT
 preserve the customized db_collation.

 {{{
 $ cat planner/migrations/0086_alter_teacheruploadedvideo_filename.py
 ...
 class Migration(migrations.Migration):
 ...
 operations = [
 migrations.AlterField(
 model_name='teacheruploadedvideo',
 name='filename',
 field=models.CharField(db_collation='utf8mb4_0900_as_cs',
 max_length=120),
 ),
 ]
 }}}

 {{{
 $ python3 manage.py sqlmigrate planner 0086
 ALTER TABLE `planner_teacheruploadedvideo` MODIFY `filename` varchar(120)
 NOT NULL;
 }}}

 In particular the generated ALTER TABLE SQL statement is lacking the
 COLLATE clause that would preserve the field's collation. By omitting the
 COLLATE clause, MySQL will revert the column's collation to its table's
 default collation during the ALTER. A corrected SQL statement would be:

 {{{
 ALTER TABLE `planner_teacheruploadedvideo` MODIFY `filename` varchar(120)
 COLLATE utf8mb4_0900_as_cs NOT NULL;
 }}}

 It looks like this issue may also affect Postgres databases, since the
 [https://www.postgresql.org/docs/current/sql-altertable.html ALTER TABLE
 syntax for Postgres] also includes a COLLATE clause, although I have not
 checked myself.

-- 
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/0107018531a17cb8-74351e4e-94f8-4277-a020-4d23bd19251c-00%40eu-central-1.amazonses.com.

Re: [Django] #34218: Password mismatch on UserCreationForm not translated to the Slovenian language

2022-12-20 Thread Django

#34218: Password mismatch on UserCreationForm not translated to the Slovenian
language
-+-
 Reporter:  Nejc Ilenic  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:   |  Version:  4.1
  Internationalization   |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  translations | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Nejc Ilenic):

 Replying to [comment:1 Mariusz Felisiak]:
 > Thanks for the report, however, translations are handled at
 
[https://docs.djangoproject.com/en/dev/internals/contributing/localizing/#translations.
 Transifex] and not in this tracker.

 Ah, thanks! I will report it there

-- 
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/010701852f757e20-4302dbba-969d-4f4c-ba85-fe2efae56933-00%40eu-central-1.amazonses.com.

Re: [Django] #34218: Password mismatch on UserCreationForm not translated to the Slovenian language

2022-12-20 Thread Django

#34218: Password mismatch on UserCreationForm not translated to the Slovenian
language
-+-
 Reporter:  Nejc Ilenic  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:   |  Version:  4.1
  Internationalization   |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  translations | 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:

 Thanks for the report, however, translations are handled at
 
[https://docs.djangoproject.com/en/dev/internals/contributing/localizing/#translations.
 Transifex] and not in this tracker.

-- 
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/010701852f554687-5feabd77-ddd6-4a81-aaf2-f2c1d222fa51-00%40eu-central-1.amazonses.com.

[Django] #34218: Password mismatch on UserCreationForm not translated to the Slovenian language

2022-12-20 Thread Django

#34218: Password mismatch on UserCreationForm not translated to the Slovenian
language
-+-
   Reporter:  Nejc   |  Owner:  nobody
  Ilenic |
   Type:  Bug| Status:  new
  Component: |Version:  4.1
  Internationalization   |
   Severity:  Normal |   Keywords:  translations
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 When using the `UserCreationForm` together with `LANGUAGE_CODE = 'sl'` the
 `password_mismatch` error is not translated.

 Reproducer:
 {{{
 #!div style="font-size: 80%"
 Code highlighting:
   {{{#!python
 from django.contrib.auth.forms import UserCreationForm
 from django.utils import translation

 form = UserCreationForm()
 form.is_valid()

 with translation.override('fr'):
 translation.gettext(form.error_messages['password_mismatch'])
 # prints 'Les deux mots de passe ne correspondent pas.'

 with translation.override('sl'):
 translation.gettext(form.error_messages['password_mismatch'])
 # prints 'The two password fields didn’t match.'
   }}}
 }}}

-- 
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/010701852f3481c8-be5c6f13-155c-4708-a372-1a0178c9c0a3-00%40eu-central-1.amazonses.com.

Re: [Django] #34118: Python 3.12 compatibility

2022-12-20 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:"32d70b2f55b1f74736fd11bc8efce890ad5fa2f0" 32d70b2]:
 {{{
 #!CommitTicketReference repository=""
 revision="32d70b2f55b1f74736fd11bc8efce890ad5fa2f0"
 Refs #34118 -- Adopted asgiref coroutine detection shims.

 Thanks to Mariusz Felisiak for review.
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/010701852f046cba-5acf4d18-ff28-4907-817b-cc5aa5731cba-00%40eu-central-1.amazonses.com.

Re: [Django] #34165: migrate management command does not respect database parameter when adding Permissions.

2022-12-20 Thread Django

#34165: migrate management command does not respect database parameter when 
adding
Permissions.
--+
 Reporter:  Vasanth   |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.auth  |  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
--+

Comment (by Mariusz Felisiak):

 > Apart from that, if we don't want to set directly the internal attribute
 `_state.db`, I guess we would need a proper way to pass the `db`/`using`
 to the model instantiation.

 `_state` is
 [https://docs.djangoproject.com/en/4.1/ref/models/instances/#state
 documented] so using it is not so bad.

 > What would be the most ''Django-y'' way?
 > - Passing it through the model constructor => this has quite a large
 impact, as a keyword argument would possibly shadow existing field names:
 `Permission(..., db=using)`. Quite risky in terms of backward
 compatibility I guess.
 > - Adding a method to `Model`? Something like:
 `Permission(...).using(db)`, which could perhaps then be re-used in other
 places also.
 >
 > What do you think ? :) Or am I missing other solutions?

 Django doesn't support cross-db relationships and users were always
 responsible for assigning related objects from the same db. I don't think
 that we should add more logic to do this. The `Permission`-`content_type`
 issue is really an edge case in managing relations, as for me we don't
 need a generic solution for 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/010701852f026742-529aa951-92a0-4272-96f6-de678682e572-00%40eu-central-1.amazonses.com.

Re: [Django] #34165: migrate management command does not respect database parameter when adding Permissions.

2022-12-20 Thread Django

Comment (by David Wobrock):

Replying to [comment:10 Mariusz Felisiak]:
> Replying to [comment:8 David Wobrock]:
> > I think `bulk_create` already sets the `_state.db` to the value passed
in `.using()`, right?
>
> Yes, but it's a different issue, strictly related with `Permission` and
its `content_type`. `get_content_type()` is trying to find a content type
using `obj._state.db` so when we create a `Permission()` without
`._state.db` it will first try to find a content type in the default db.

Okay, I understand the issue now, thanks for the details!!

First thing, it makes me wonder why we require to have a DB attribute set,
at a moment where we are not (yet) interacting with the DB.
So we are currently checking, when setting the `content_type` FK, that the
router allows this relation. I guess one option is to not do that for not-
saved model instances.
Would it make sense to defer this to when we start interacting with the
DB? But it brings a whole other lot of changes and challenges, like
changing a deep behaviour of FKs and multi-tenancy :/

Apart from that, if we don't want to set directly the internal attribute
`_state.db`, I guess we would need a proper way to pass the `db`/`using`
to the model instantiation.
What would be the most ''Django-y'' way?
- Passing it through the model constructor => this has quite a large
impact, as a keyword argument would possibly shadow existing field names:
`Permission(..., db=using)`. Quite risky in terms of backward
compatibility I guess.
- Adding a method to `Model`? Something like: `Permission(...).using(db)`,
which could perhaps then be re-used in other places also.

What do you think ? :) Or am I missing other solutions?

--
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/010701852ef6b16c-5086918c-e150-45ed-b179-e9aa00151a69-00%40eu-central-1.amazonses.com.

Re: [Django] #18468: Add the ability to define comments in table / columns

2022-12-20 Thread Django

#18468: Add the ability to define comments in table / columns
-+-
 Reporter:  Marc Rechté  |Owner:
 |  KimSoungRyoul
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * owner:  Jared Chung => KimSoungRyoul


-- 
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/010701852ec6ebe0-da5215e3-1bd9-4a76-80bc-f10a703a3171-00%40eu-central-1.amazonses.com.

Re: [Django] #33961: Update admin's jQuery to 3.6.X.

Re: [Django] #34220: Cannot import csrf_input_lazy from partially initialized module. (was: ImportError: cannot import name 'csrf_input_lazy' from partially initialized module 'django.template.backend

[Django] #34220: ImportError: cannot import name 'csrf_input_lazy' from partially initialized module 'django.template.backends.utils'

Re: [Django] #34219: Collation is not preserved when field is altered on PostgreSQL and MySQL.

Re: [Django] #34219: Collation is not preserved when field is altered on PostgreSQL and MySQL. (was: Custom field collation (db_collation) is not preserved when field is altered)

[Django] #34219: Custom field collation (db_collation) is not preserved when field is altered

Re: [Django] #34218: Password mismatch on UserCreationForm not translated to the Slovenian language

Re: [Django] #34218: Password mismatch on UserCreationForm not translated to the Slovenian language

[Django] #34218: Password mismatch on UserCreationForm not translated to the Slovenian language

Re: [Django] #34118: Python 3.12 compatibility

Re: [Django] #34165: migrate management command does not respect database parameter when adding Permissions.

Re: [Django] #34165: migrate management command does not respect database parameter when adding Permissions.

Re: [Django] #18468: Add the ability to define comments in table / columns

13 matches

Site Navigation

Mail list logo

Footer information