Re: [Django] #35336: Adding GeneratedField fails with ProgrammingError when using When on CharField

2024-03-27 Thread Django 
#35336: Adding GeneratedField fails with ProgrammingError when using When on
CharField
-+-
 Reporter:  Adrian Garcia|Owner:  Simon
 |  Charette
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  postgres,| Triage Stage:  Accepted
  generatedfield, contains   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Simon Charette):

 * component:  Migrations => Database layer (models, ORM)
 * keywords:  postgres, generatedfield, _split_query => postgres,
 generatedfield, contains
 * owner:  nobody => Simon Charette
 * severity:  Normal => Release blocker
 * stage:  Unreviewed => Accepted
 * status:  new => assigned

Comment:

 This can be reproduced on `psycopg2` and `psycopg>=3` and is reminiscent
 of the series of issues we had to fix with `Constraint`'s usage of
 `__contains` lookup which require proper `%` escaping (#30408, #34553,
 #32369)

 {{{#!diff
 diff --git a/tests/schema/tests.py b/tests/schema/tests.py
 index f8e314d270..3b2d7bf03c 100644
 --- a/tests/schema/tests.py
 +++ b/tests/schema/tests.py
 @@ -886,6 +886,27 @@ class Meta:
  with connection.schema_editor() as editor:
  editor.create_model(GeneratedFieldOutputFieldModel)

 +@isolate_apps("schema")
 +@skipUnlessDBFeature("supports_stored_generated_columns")
 +def test_add_generated_field_contains(self):
 +class GeneratedFieldContainsModel(Model):
 +text = TextField()
 +
 +class Meta:
 +app_label = "schema"
 +
 +field = GeneratedField(
 +expression=Q(text__icontains="FOO"),
 +db_persist=True,
 +output_field=BooleanField(),
 +)
 +field.contribute_to_class(GeneratedFieldContainsModel,
 "some_field")
 +
 +with connection.schema_editor() as editor:
 +editor.create_model(GeneratedFieldContainsModel)
 +editor.add_field(GeneratedFieldContainsModel, field)
 +
 +
  @isolate_apps("schema")
  def test_add_auto_field(self):
  class AddAutoFieldModel(Model):
 }}}
-- 
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/0107018e834d2bbe-6e75c9da-3384-48e6-9244-f60b5908204b-00%40eu-central-1.amazonses.com.

Re: [Django] #34977: Turn link to change password form in admin user change form into a button

2024-03-27 Thread Django 
#34977: Turn link to change password form in admin user change form into a 
button
-+-
 Reporter:  Fabian Braun |Owner:  Fabian
 Type:   |  Braun
  Cleanup/optimization   |   Status:  closed
Component:  contrib.auth |  Version:  dev
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  accessibility| Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  1
-+-
Changes (by Natalia <124304+nessita@…>):

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

Comment:

 In [changeset:"944745afe2ec45aed30cef799c250107f1364ca7" 944745af]:
 {{{#!CommitTicketReference repository=""
 revision="944745afe2ec45aed30cef799c250107f1364ca7"
 Fixed #34977 -- Improved accessibility in the UserChangeForm by replacing
 the reset password link with a button.

 Co-authored-by: Natalia <124304+ness...@users.noreply.github.com>
 }}}
-- 
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/0107018e82bfe593-b0caf272-ea41-4938-ab93-40a593b19fd0-00%40eu-central-1.amazonses.com.

Re: [Django] #35337: argument of type 'NoneType' is not iterable, when show facets and change_view is overwritten in ModelAdmin

2024-03-27 Thread Django 
#35337: argument of type 'NoneType' is not iterable, when show facets and
change_view is overwritten in ModelAdmin
+--
 Reporter:  dz  |Owner:  nobody
 Type:  Uncategorized   |   Status:  new
Component:  contrib.admin   |  Version:  5.0
 Severity:  Normal  |   Resolution:
 Keywords:  facets change view  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Description changed by dz:

Old description:

> Hello,
>
> {{{
> Django==5.0.3
> }}}
>
> {{{
> @admin.register(LicitacionItem)
> class LicitacionItemAdmin(admin.ModelAdmin):
>
> list_select_related = ('licitacion', 'categoria',
>'proveedor', 'producto', 'licitacion_detalle')
>
> raw_id_fields = ('licitacion', 'categoria',
>  'proveedor', 'producto', 'licitacion_detalle')
>
> search_fields = ["CodigoExterno", 'search']
>
> show_facets = admin.ShowFacets.ALLOW
>
> list_filter = [
> ('ordencompra__date', admin.DateFieldListFilter),
> ('ordencompra_detalle__Fechas_FechaCreacion',
> admin.DateFieldListFilter),
> 'ordencompra_detalle__CodigoEstado',
> 'ordencompra_detalle__CodigoEstadoProveedor',
> 'active',
> ('licitacion', admin.EmptyFieldListFilter),
> ('categoria', admin.EmptyFieldListFilter),
> 'ordencompra_detalle__CodigoTipo',
> 'ordencompra_detalle__Tipo']
>
> def change_view(self, request, object_id, extra_context=None):
> self.exclude = ('active', 'analizado', 'touch', 'search')
> return super(LicitacionItemAdmin, self).change_view(request,
> object_id, extra_context)
> }}}
>
> when clicking on an item (enter change view), without activating show
> facets: there are no errors.
>
> when clicking on an item (enter change view), with show facets activated:
> argument of type 'NoneType' is not iterable (see attached file with the
> trace)
>
> By completely removing the change_view function, the error does not occur
> (even if show facets is activated).
>
> Regards
>

> {{{
>
> }}}

New description:

 Hello,

 {{{
 Django==5.0.3
 }}}

 {{{
 @admin.register(LicitacionItem)
 class LicitacionItemAdmin(admin.ModelAdmin):

 list_select_related = ('licitacion', 'categoria',
'proveedor', 'producto', 'licitacion_detalle')

 raw_id_fields = ('licitacion', 'categoria',
  'proveedor', 'producto', 'licitacion_detalle')

 search_fields = ["CodigoExterno", 'search']

 show_facets = admin.ShowFacets.ALLOW

 list_filter = [
 ('licitacion__date', admin.DateFieldListFilter),
 ('licitacion__FechaCierre', admin.DateFieldListFilter),
 'licitacion__CodigoEstado',
 'active',
 'licitacion_detalle__CodigoTipo',
 'licitacion_detalle__Tipo',
 'licitacion_detalle__TipoConvocatoria',
 'licitacion_detalle__CodigoTipo']

 def change_view(self, request, object_id, extra_context=None):
 self.exclude = ('active', 'analizado', 'touch', 'search')
 return super(LicitacionItemAdmin, self).change_view(request,
 object_id, extra_context)
 }}}

 when clicking on an item (enter change view), without activating show
 facets: there are no errors.

 when clicking on an item (enter change view), with show facets activated:
 argument of type 'NoneType' is not iterable (see attached file with the
 trace)

 By completely removing the change_view function, the error does not occur
 (even if show facets is activated).

 Regards


 {{{

 }}}

--
-- 
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/0107018e82831e64-748674b0-5781-4d5b-a5b6-95e4dcde3a27-00%40eu-central-1.amazonses.com.

Re: [Django] #35337: argument of type 'NoneType' is not iterable, when show facets and change_view is overwritten in ModelAdmin

2024-03-27 Thread Django 
#35337: argument of type 'NoneType' is not iterable, when show facets and
change_view is overwritten in ModelAdmin
+--
 Reporter:  dz  |Owner:  nobody
 Type:  Uncategorized   |   Status:  new
Component:  contrib.admin   |  Version:  5.0
 Severity:  Normal  |   Resolution:
 Keywords:  facets change view  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Description changed by dz:

Old description:

> Hello,
>
> {{{
> Django==5.0.3
> }}}
>
> {{{
> @admin.register(LicitacionItem)
> class LicitacionItemAdmin(admin.ModelAdmin):
>
> list_select_related = ('licitacion', 'categoria',
>'proveedor', 'producto', 'licitacion_detalle')
>
> raw_id_fields = ('licitacion', 'categoria',
>  'proveedor', 'producto', 'licitacion_detalle')
>
> search_fields = ["CodigoExterno", 'search']
>
> show_facets = admin.ShowFacets.ALLOW
>
> def change_view(self, request, object_id, extra_context=None):
> self.exclude = ('active', 'analizado', 'touch', 'search')
> return super(LicitacionItemAdmin, self).change_view(request,
> object_id, extra_context)
> }}}
>
> when clicking on an item (enter change view), without activating show
> facets: there are no errors.
>
> when clicking on an item (enter change view), with show facets activated:
> argument of type 'NoneType' is not iterable (see attached file with the
> trace)
>
> By completely removing the change_view function, the error does not occur
> (even if show facets is activated).
>
> Regards
>

> {{{
>
> }}}

New description:

 Hello,

 {{{
 Django==5.0.3
 }}}

 {{{
 @admin.register(LicitacionItem)
 class LicitacionItemAdmin(admin.ModelAdmin):

 list_select_related = ('licitacion', 'categoria',
'proveedor', 'producto', 'licitacion_detalle')

 raw_id_fields = ('licitacion', 'categoria',
  'proveedor', 'producto', 'licitacion_detalle')

 search_fields = ["CodigoExterno", 'search']

 show_facets = admin.ShowFacets.ALLOW

 list_filter = [
 ('ordencompra__date', admin.DateFieldListFilter),
 ('ordencompra_detalle__Fechas_FechaCreacion',
 admin.DateFieldListFilter),
 'ordencompra_detalle__CodigoEstado',
 'ordencompra_detalle__CodigoEstadoProveedor',
 'active',
 ('licitacion', admin.EmptyFieldListFilter),
 ('categoria', admin.EmptyFieldListFilter),
 'ordencompra_detalle__CodigoTipo',
 'ordencompra_detalle__Tipo']

 def change_view(self, request, object_id, extra_context=None):
 self.exclude = ('active', 'analizado', 'touch', 'search')
 return super(LicitacionItemAdmin, self).change_view(request,
 object_id, extra_context)
 }}}

 when clicking on an item (enter change view), without activating show
 facets: there are no errors.

 when clicking on an item (enter change view), with show facets activated:
 argument of type 'NoneType' is not iterable (see attached file with the
 trace)

 By completely removing the change_view function, the error does not occur
 (even if show facets is activated).

 Regards


 {{{

 }}}

--
-- 
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/0107018e82821342-a4e2e3f7-dc14-461f-b0fa-7647d2a1bc5b-00%40eu-central-1.amazonses.com.

Re: [Django] #35337: argument of type 'NoneType' is not iterable, when show facets and change_view is overwritten in ModelAdmin

2024-03-27 Thread Django 
#35337: argument of type 'NoneType' is not iterable, when show facets and
change_view is overwritten in ModelAdmin
+--
 Reporter:  dz  |Owner:  nobody
 Type:  Uncategorized   |   Status:  new
Component:  contrib.admin   |  Version:  5.0
 Severity:  Normal  |   Resolution:
 Keywords:  facets change view  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Description changed by dz:

Old description:

> Hello,
>
> {{{
> Django==5.0.3
> }}}
>
> {{{
> @admin.register(LicitacionItem)
> class LicitacionItemAdmin(admin.ModelAdmin):
>
> list_select_related = ('licitacion', 'categoria',
>'proveedor', 'producto', 'licitacion_detalle')
>
> raw_id_fields = ('licitacion', 'categoria',
>  'proveedor', 'producto', 'licitacion_detalle')
>
> search_fields = ["CodigoExterno", 'search']
>
> show_facets = admin.ShowFacets.ALLOW
>
> def change_view(self, request, object_id, extra_context=None):
> self.exclude = ('active', 'analizado', 'touch', 'search')
> return super(LicitacionItemAdmin, self).change_view(request,
> object_id, extra_context)
> }}}
>
> when clicking on an item (enter change view), without activating show
> facets: there are no errors.
>
> when clicking on an item (enter change view), with show facets activated:
> argument of type 'NoneType' is not iterable (see attached file with the
> trace)
>
> By completely removing the change_view function, the error does not occur
> (even if showing facts is activated).
>
> Regards
>

> {{{
>
> }}}

New description:

 Hello,

 {{{
 Django==5.0.3
 }}}

 {{{
 @admin.register(LicitacionItem)
 class LicitacionItemAdmin(admin.ModelAdmin):

 list_select_related = ('licitacion', 'categoria',
'proveedor', 'producto', 'licitacion_detalle')

 raw_id_fields = ('licitacion', 'categoria',
  'proveedor', 'producto', 'licitacion_detalle')

 search_fields = ["CodigoExterno", 'search']

 show_facets = admin.ShowFacets.ALLOW

 def change_view(self, request, object_id, extra_context=None):
 self.exclude = ('active', 'analizado', 'touch', 'search')
 return super(LicitacionItemAdmin, self).change_view(request,
 object_id, extra_context)
 }}}

 when clicking on an item (enter change view), without activating show
 facets: there are no errors.

 when clicking on an item (enter change view), with show facets activated:
 argument of type 'NoneType' is not iterable (see attached file with the
 trace)

 By completely removing the change_view function, the error does not occur
 (even if show facets is activated).

 Regards


 {{{

 }}}

--
-- 
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/0107018e827555a3-fdc3dc73-c88a-4c33-b27c-ae52598df269-00%40eu-central-1.amazonses.com.

Re: [Django] #35337: argument of type 'NoneType' is not iterable, when show facets and change_view is overwritten in ModelAdmin

2024-03-27 Thread Django 
#35337: argument of type 'NoneType' is not iterable, when show facets and
change_view is overwritten in ModelAdmin
+--
 Reporter:  dz  |Owner:  nobody
 Type:  Uncategorized   |   Status:  new
Component:  contrib.admin   |  Version:  5.0
 Severity:  Normal  |   Resolution:
 Keywords:  facets change view  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Changes (by dz):

 * Attachment "error.txt" added.

 error trace
-- 
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/0107018e82743f70-e869f416-83a3-4f78-aa94-f60ad363410c-00%40eu-central-1.amazonses.com.

[Django] #35337: argument of type 'NoneType' is not iterable, when show facets and change_view is overwritten in ModelAdmin

2024-03-27 Thread Django 
#35337: argument of type 'NoneType' is not iterable, when show facets and
change_view is overwritten in ModelAdmin
-+-
   Reporter:  dz |  Owner:  nobody
   Type: | Status:  new
  Uncategorized  |
  Component: |Version:  5.0
  contrib.admin  |
   Severity:  Normal |   Keywords:  facets change view
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Hello,

 {{{
 Django==5.0.3
 }}}

 {{{
 @admin.register(LicitacionItem)
 class LicitacionItemAdmin(admin.ModelAdmin):

 list_select_related = ('licitacion', 'categoria',
'proveedor', 'producto', 'licitacion_detalle')

 raw_id_fields = ('licitacion', 'categoria',
  'proveedor', 'producto', 'licitacion_detalle')

 search_fields = ["CodigoExterno", 'search']

 show_facets = admin.ShowFacets.ALLOW

 def change_view(self, request, object_id, extra_context=None):
 self.exclude = ('active', 'analizado', 'touch', 'search')
 return super(LicitacionItemAdmin, self).change_view(request,
 object_id, extra_context)
 }}}

 when clicking on an item (enter change view), without activating show
 facets: there are no errors.

 when clicking on an item (enter change view), with show facets activated:
 argument of type 'NoneType' is not iterable (see attached file with the
 trace)

 By completely removing the change_view function, the error does not occur
 (even if showing facts is activated).

 Regards


 {{{

 }}}
-- 
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/0107018e8273d8a8-0b78a931-605e-41f8-9d70-bc9f28596f95-00%40eu-central-1.amazonses.com.

Re: [Django] #35335: Update "Enabling the sites framework" documentation to reiterate the ability to use `get_current_site`

2024-03-27 Thread Django 
#35335: Update "Enabling the sites framework" documentation to reiterate the
ability to use `get_current_site`
-+-
 Reporter:  Sam Darwin   |Owner:  sam
 Type:   |  darwin
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.sites|  Version:  5.0
 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
-+-
Comment (by Sam Darwin):

 > too opinionated, and
 > contrasts with the intentional neutrality

 In the world of software though, it's often possible that new libraries
 are introduced, new features are created, and then the general consensus
 is that you ought to tend towards the new method.  Meanwhile, the earlier
 techniques can pass through phases where they are discouraged, deprecated,
 and finally obsolete and not supported at all.

 Consider this quote, from a web search:

 > The os.system function is easy to use and interpret: simply use as input
 of the function the same command you would use in a shell. However, it is
 deprecated and it is recommended to use subprocess now.

 Is it not true, that `subprocess` is recommended, while `os.system` is
 deprecated?

 Or that Python 2 is completely unsupported, while the choice of Python 3
 is strongly recommended (compared to Python 2) ?

 It depends on the method in question. If `get_current_site(request)` is
 newer and has more robust features than `get_current()`, then it could be
 analogous to `os.system` versus `subprocess`.  Certain options actually
 can become deprecated and/or recommended. And when that occurs, it isn't
 lacking in neutrality to discuss 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/0107018e823b8b93-a3f14fdc-aa9f-44fb-b0f6-b9dac57e334c-00%40eu-central-1.amazonses.com.

[Django] #35336: Adding GeneratedField fails with ProgrammingError when using When on CharField

2024-03-27 Thread Django 
#35336: Adding GeneratedField fails with ProgrammingError when using When on
CharField
-+-
   Reporter:  Adrian |  Owner:  nobody
  Garcia |
   Type:  Bug| Status:  new
  Component: |Version:  5.0
  Migrations |   Keywords:  postgres,
   Severity:  Normal |  generatedfield, _split_query
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Forgive me if I am doing something incorrectly, but I cannot for the life
 of me add a GeneratedField to one of my models. To replicate this error, I
 created this test model:
 {{{
 from django.db import models

 class TestModel(models.Model):
 description = models.TextField()
 }}}
 Running makemigrations/migrate, then modifying the model to add this
 `contains_heck` field:
 {{{
 from django.db import models

 class TestModel(models.Model):
 description = models.TextField()
 contains_heck = models.GeneratedField(
 expression=models.Case(
 models.When(description__icontains="HECK",
 then=models.Value(True)),
 default=models.Value(False),
 output_field=models.BooleanField(),
 ),
 output_field=models.BooleanField(),
 db_persist=True,
 )
 }}}
 Which generates this migration:
 {{{
 # Generated by Django 5.0.3 on 2024-03-27 20:34

 from django.db import migrations, models


 class Migration(migrations.Migration):
 dependencies = [
 ("core", "1_initial"),
 ]

 operations = [
 migrations.AddField(
 model_name="testmodel",
 name="contains_heck",
 field=models.GeneratedField(
 db_persist=True,
 expression=models.Case(
 models.When(description__icontains="HECK",
 then=models.Value(True)), default=models.Value(False),
 output_field=models.BooleanField()
 ),
 output_field=models.BooleanField(),
 ),
 ),
 ]
 }}}

 And after running `python manage.py migrate` I get the following error:
 {{{
 Operations to perform:
   Apply all migrations: admin, auth, consumer, contenttypes, core, db,
 sessions
 Running migrations:
   Applying core.0002_testmodel_contains_heck...Traceback (most recent call
 last):
   File "/opt/project/app/manage.py", line 24, in 
 main()
   File "/opt/project/app/manage.py", line 20, in main
 execute_from_command_line(sys.argv)
   File "/usr/local/lib/python3.11/site-
 packages/django/core/management/__init__.py", line 442, in
 execute_from_command_line
 utility.execute()
   File "/usr/local/lib/python3.11/site-
 packages/django/core/management/__init__.py", line 436, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "/usr/local/lib/python3.11/site-
 packages/django/core/management/base.py", line 413, in run_from_argv
 self.execute(*args, **cmd_options)
   File "/usr/local/lib/python3.11/site-
 packages/django/core/management/base.py", line 459, in execute
 output = self.handle(*args, **options)
  ^
   File "/usr/local/lib/python3.11/site-
 packages/django/core/management/base.py", line 107, in wrapper
 res = handle_func(*args, **kwargs)
   
   File "/usr/local/lib/python3.11/site-
 packages/django/core/management/commands/migrate.py", line 356, in handle
 post_migrate_state = executor.migrate(
  ^
   File "/usr/local/lib/python3.11/site-
 packages/django/db/migrations/executor.py", line 135, in migrate
 state = self._migrate_all_forwards(
 ^^^
   File "/usr/local/lib/python3.11/site-
 packages/django/db/migrations/executor.py", line 167, in
 _migrate_all_forwards
 state = self.apply_migration(
 ^
   File "/usr/local/lib/python3.11/site-
 packages/django/db/migrations/executor.py", line 252, in apply_migration
 state = migration.apply(state, schema_editor)
 ^
   File "/usr/local/lib/python3.11/site-
 packages/django/db/migrations/migration.py", line 132, in apply
 operation.database_forwards(
   File "/usr/local/lib/python3.11/site-
 packages/django/db/migrations/operations/fields.py", line 108, in
 database_forwards
 schema_editor.add_field(
   File "/usr/local/lib/python3.11/site-
 packages/django/db/backends/base/schema.py", line 750, in add_field
 self.execute(sql, params)
   File

Re: [Django] #35167: JSONField get_db_prep_value being called with `Cast` types

2024-03-27 Thread Django 
#35167: JSONField get_db_prep_value being called with `Cast` types
-+-
 Reporter:  Samantha Hughes  |Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  4.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  JSONField| Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Comment (by HeejunShin):

 Is this ticket solved?
-- 
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/0107018e81c29925-4adecc33-015b-4f85-a632-201b87cbfba3-00%40eu-central-1.amazonses.com.

Re: [Django] #35335: Update "Enabling the sites framework" documentation to reiterate the ability to use `get_current_site` (was: "sites" framework documentation)

2024-03-27 Thread Django 
#35335: Update "Enabling the sites framework" documentation to reiterate the
ability to use `get_current_site`
-+-
 Reporter:  Sam Darwin   |Owner:  sam
 Type:   |  darwin
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.sites|  Version:  5.0
 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 Natalia Bidart):

 * component:  Documentation => contrib.sites
 * has_patch:  0 => 1
 * keywords:  documentation =>
 * needs_better_patch:  0 => 1
 * owner:  nobody => sam darwin
 * stage:  Unreviewed => Accepted
 * status:  new => assigned
 * summary:  "sites" framework documentation =>
 Update "Enabling the sites framework" documentation to reiterate the
 ability to use `get_current_site`

Comment:

 Hello Sam, thank you for your ticket. Inline some thoughts about your
 proposal.

 Replying to [ticket:35335 Sam Darwin]:
 > 1. It says "To enable the sites framework, define a SITE_ID setting".

 The docs says, way before the reference above, the following:

 > ''The SITE_ID setting specifies the database ID of the Site object
 associated with that particular settings file. If the setting is omitted,
 the get_current_site() function will try to get the current site by
 comparing the domain with the host name from the request.get_host()
 method''.

 I believe this explanation is quite accurate and explanatory. The sentence
 you mentioned appears halfway down the documentation, assuming that the
 reader has already read the preceding sections. Nevertheless, adding a
 clarification in the "Enabling the sites framework" section could help
 reinforce the previous point.

 > 2. Imagine someone is learning about the "sites" framework for the first
 time. If there is something sort of surprising or unusual about a feature,
 it would be helpful to comment on that, [...] it would be even more clear
 to state "you must run multiple actual servers.  One server isn't
 enough.".

 This is not entirely accurate. The term `server` can be interpreted
 differently by different people, leading to confusion rather than
 clarification. For instance, to me, a `server` refers simply to a hardware
 instance or compute node capable of running one or multiple websites. With
 Django's sites, each `Site` can have its own configuration, content, and
 templates. These sites can share the same (physical and virtual) server,
 or even the same Django project, depending on the requirements.

 > 3.  Include a "recommendation" to the developer.  [...] with that in
 mind, a proposed documentation update is covered in a new pull request
 https://github.com/django/django/pull/17977

 I find this item to be a bit too much opinionated, which contrasts with
 the intentional neutrality of the Django docs. Moreover, the "Example
 usage" section demonstrates various clear but distinct patterns where
 using the sites framework could be advantageous, none of which mandates
 having different servers.

 Considering these points, I believe the documentation could benefit from
 additional clarification in the "Enabling the sites framework" section.
 However, I don't advocate for further recommendations on how to use it
 unless they involve new examples that could be incorporated into the
 existing "Example usage" section. Accepting the ticket on this premise.
-- 
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/0107018e81c1eaeb-9f414de6-b778-40a7-a0cc-7e7e5060ddff-00%40eu-central-1.amazonses.com.

Re: [Django] #34977: Turn link to change password form in admin user change form into a button

2024-03-27 Thread Django 
#34977: Turn link to change password form in admin user change form into a 
button
-+-
 Reporter:  Fabian Braun |Owner:  Fabian
 Type:   |  Braun
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.auth |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  accessibility| Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  1
-+-
Changes (by Natalia Bidart):

 * 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/0107018e818c7238-e13e970d-6e0f-4e16-ac3e-b676360438b4-00%40eu-central-1.amazonses.com.

Re: [Django] #35331: Adding a new related entry using the "+" sign from M2M field doesn't update lists.

2024-03-27 Thread Django 
#35331: Adding a new related entry using the "+" sign from M2M field doesn't 
update
lists.
---+--
 Reporter:  devin13cox |Owner:  devin13cox
 Type:  Bug|   Status:  assigned
Component:  contrib.admin  |  Version:  5.0
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  1
---+--
Changes (by devin13cox):

 * has_patch:  0 => 1

Comment:

 https://github.com/django/django/pull/18026
-- 
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/0107018e815b0e74-c1a76646-0907-414a-8dd2-f120286ff3b7-00%40eu-central-1.amazonses.com.

Re: [Django] #35330: The update of related objects fails in the admin when the related model is camel case.

2024-03-27 Thread Django 
#35330: The update of related objects fails in the admin when the related model 
is
camel case.
---+--
 Reporter:  devin13cox |Owner:  devin13cox
 Type:  Bug|   Status:  assigned
Component:  contrib.admin  |  Version:  5.0
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  1
---+--
Changes (by devin13cox):

 * has_patch:  0 => 1

Comment:

 https://github.com/django/django/pull/18025
-- 
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/0107018e813decde-624d7f40-65b2-43af-9a07-35aaa96432b9-00%40eu-central-1.amazonses.com.

Re: [Django] #35330: The update of related objects fails in the admin when the related model is camel case.

2024-03-27 Thread Django 
#35330: The update of related objects fails in the admin when the related model 
is
camel case.
---+--
 Reporter:  devin13cox |Owner:  devin13cox
 Type:  Bug|   Status:  assigned
Component:  contrib.admin  |  Version:  5.0
 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:  1
---+--
Comment (by devin13cox):

 Replying to [comment:4 Natalia Bidart]:
 > Replying to [comment:3 devin13cox]:
 > > Replying to [comment:2 devin13cox]:
 > > > If I want to use the test models from the PR listed in the ticket,
 should I just wait until that PR gets eventually merged in? Or is it
 preferred to make any changes here independent of another ticket (and
 subsequently make alterations to admin to work for this ticket)?
 > >
 > > Or if there is another preferred way to approach this given the close
 relationship between this ticket, the one mentioned in the description,
 and #35331, I am open to suggestions!
 >
 > Hi! My suggestion would be to progress with this ticket independently of
 the other tickets. Have you checked if any of the existing models would
 help building your testcase?

 I think the models `Pizza` and `Topping` are usable for Ticket #35331, but
 I would need to alter `Topping` to use camel casing for this one. Or add
 another filter horizontal admin, but at that point may be easier to make
 independent additions.
-- 
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/0107018e811b8def-96b513e3-4f03-4f5b-8441-ada2c7e828c2-00%40eu-central-1.amazonses.com.

Re: [Django] #34624: RelatedFieldWidgetWrapper links toggling isn’t working for radio widgets

2024-03-27 Thread Django 
#34624: RelatedFieldWidgetWrapper links toggling isn’t working for radio widgets
---+
 Reporter:  Thibaud Colas  |Owner:  (none)
 Type:  Bug|   Status:  new
Component:  contrib.admin  |  Version:  dev
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  1
---+
Comment (by Anirudh Prabhakaran):

 Hello! What is the status of this ticket?

 I am planning to apply for GSoC, and so I think that trying to solve a
 ticket would give me a chance to get my hands dirty with the codebase. If
 this is not assigned to anyone, can I take a look?
-- 
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/0107018e80d085dc-361a2ddd-014b-41ee-8115-20317b52f9db-00%40eu-central-1.amazonses.com.

Re: [Django] #35330: The update of related objects fails in the admin when the related model is camel case.

2024-03-27 Thread Django 
#35330: The update of related objects fails in the admin when the related model 
is
camel case.
---+--
 Reporter:  devin13cox |Owner:  devin13cox
 Type:  Bug|   Status:  assigned
Component:  contrib.admin  |  Version:  5.0
 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:  1
---+--
Comment (by Natalia Bidart):

 Replying to [comment:3 devin13cox]:
 > Replying to [comment:2 devin13cox]:
 > > If I want to use the test models from the PR listed in the ticket,
 should I just wait until that PR gets eventually merged in? Or is it
 preferred to make any changes here independent of another ticket (and
 subsequently make alterations to admin to work for this ticket)?
 >
 > Or if there is another preferred way to approach this given the close
 relationship between this ticket, the one mentioned in the description,
 and #35331, I am open to suggestions!

 Hi! My suggestion would be to progress with this ticket independently of
 the other tickets. Have you checked if any of the existing models would
 help building your testcase?
-- 
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/0107018e809959c1-e3e0ae6d-9b87-496d-9a4e-d5a88beae9c1-00%40eu-central-1.amazonses.com.

Re: [Django] #32577: Add support for `UUIDAutoField` `DEFAULT_AUTO_FIELD`

2024-03-27 Thread Django 
#32577: Add support for `UUIDAutoField` `DEFAULT_AUTO_FIELD`
-+-
 Reporter:  Tomasz Wójcik|Owner:  (none)
 Type:  New feature  |   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 Olivier Dalang):

 * cc: Olivier Dalang (added)

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018e806fb5a3-babab829-7249-48d8-9a0b-d9ca22c7d0dd-00%40eu-central-1.amazonses.com.

Re: [Django] #35334: Update Oracle backend supports_sequence_reset = True

2024-03-27 Thread Django 
#35334: Update Oracle backend supports_sequence_reset = True
-+-
 Reporter:  David Sanders|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Comment (by David Sanders):

 Interestingly someone's already added the required sequence reset methods
 to `db.backends.oracle.operations.DatabaseOperations` to support flushing:
 
https://github.com/django/django/blob/d658a3162fbeb68d148d1b2fcf4da4fe1437eddb/django/db/backends/oracle/operations.py#L526

 The Oracle attribute
 
[https://github.com/django/django/blob/d658a3162fbeb68d148d1b2fcf4da4fe1437eddb/django/db/backends/oracle/operations.py#L39
 DatabaseOperations.__sequence_reset_sql()] appears to have origins way
 back to 2007 when it was first added as
 [https://github.com/django/django/commit/ac64e91a0cadc57f4bc5c#diff-
 5cae5e1a70c0f5badce41576684234d402babf2aa2546e5c2166d9041137458dR198
 _get_sequence_reset_sql()]

 It looks like that could be simplified to use the `ALTER` syntax?
-- 
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/0107018e806d61ce-60ada53c-78a3-4dff-9195-553fb457127a-00%40eu-central-1.amazonses.com.

Re: [Django] #35326: OverwritingStorageTests fail if a TemporaryUploadedFile is used

2024-03-27 Thread Django 
#35326: OverwritingStorageTests fail if a TemporaryUploadedFile is used
--+
 Reporter:  bcail |Owner:  bcail
 Type:  Bug   |   Status:  assigned
Component:  File uploads/storage  |  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
--+
Changes (by Natalia Bidart):

 * has_patch:  0 => 1
 * owner:  nobody => bcail
 * 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/0107018e806ccd73-e45a4d1e-67c8-48f2-88af-6191e5aaeb29-00%40eu-central-1.amazonses.com.

[Django] #35335: "sites" framework documentation

2024-03-27 Thread Django 
#35335: "sites" framework documentation
-+-
   Reporter:  sdarwin|  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |
  Component: |Version:  5.0
  Documentation  |
   Severity:  Normal |   Keywords:  documentation
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Hi,

 I was recently implementing the Django "sites" framework on a website, and
 encountered issues with the documentation that could likely be improved.

 1. It says "To enable the sites framework, define a SITE_ID setting".

 I believe this is factually wrong. The latest and most modern way to use
 the framework is with `get_current_site(request)`, and in that case a
 SITE_ID will interfere. So, it should at least say "(optional)" there. Or
 even go further, and discourage setting a SITE_ID.

 2. Imagine someone is learning about the "sites" framework for the first
 time. If there is something sort of surprising or unusual about a feature,
 it would be helpful to comment on that, and not leave it "implied" or
 unstated. In this case, what I think is unexpected is when you read these
 instructions about SITE_ID, and you think "ok, so how does this all
 work", is the fact you would need to run multiple app servers,
 multiple web servers. Not one server.   Not a few horizontally scaled
 replicas (which is often the scenario).  Rather, multiple distinct app
 servers, each with a separate SITE_ID. Yes, while this is "implied" by the
 current documentation, it would be even more clear to state "you must run
 multiple actual servers.  One server isn't enough.".

 At the same time, that's inconvenient, right?  Which leads to the next
 point:

 3.  Include a "recommendation" to the developer.  There is a choice
 between statically defining a SITE_ID in the config, or else dynamically
 ascertaining the SITE_ID by using  `get_current_site(request)`.  Since
 get_current_site is probably better, it wouldn't hurt to mention that.
 However the words "recommend" or "recommendation" do not appear on the
 page of documentation.

 with that in mind, a proposed documentation update is covered in a new
 pull request https://github.com/django/django/pull/17977 .

 Thanks.
-- 
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/0107018e8024405f-b0c072ae-7384-4dc9-814a-de26eb51a5b3-00%40eu-central-1.amazonses.com.

Re: [Django] #35334: Update Oracle backend supports_sequence_reset = True

2024-03-27 Thread Django 
#35334: Update Oracle backend supports_sequence_reset = True
-+-
 Reporter:  David Sanders|Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  5.0
  (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 Simon Charette):

 * stage:  Unreviewed => Accepted

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018e80178df1-c3230097-da5e-47d0-9121-e4fdbe8dd4f5-00%40eu-central-1.amazonses.com.

Re: [Django] #35233: Push templates checks down to backend engine classes

2024-03-27 Thread Django 
#35233: Push templates checks down to backend engine classes
-+-
 Reporter:  Adam Johnson |Owner:  Giannis
 Type:   |  Terzopoulos
  Cleanup/optimization   |   Status:  closed
Component:  Core (System |  Version:  dev
  checks)|
 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 ):

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

Comment:

 In [changeset:"d658a3162fbeb68d148d1b2fcf4da4fe1437eddb" d658a31]:
 {{{#!CommitTicketReference repository=""
 revision="d658a3162fbeb68d148d1b2fcf4da4fe1437eddb"
 Fixed #35233 -- Moved template engine system checks to backend methods.

 Thanks Adam Johnson for reviews.
 }}}
-- 
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/0107018e7efdf2cb-4dec2ab4-f1d0-4271-b1ec-d828cfb0c11f-00%40eu-central-1.amazonses.com.

[Django] #35334: Update Oracle backend supports_sequence_reset = True

2024-03-27 Thread Django 
#35334: Update Oracle backend supports_sequence_reset = True
-+-
   Reporter:  David  |  Owner:  nobody
  Sanders|
   Type: | Status:  new
  Cleanup/optimization   |
  Component:  Database   |Version:  5.0
  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  |
-+-
 The Oracle backend currently specifies `supports_sequence_reset = False`.
 It looks as though it's been this way since the flag was added to the
 Oracle backend since https://github.com/django/django/commit/0df4593f0ed.

 This commit appears to have been for the 1.5 release [1] which was
 released in Feb 2013. A few months later Oracle 12.1 [2] was released in
 July 2013. It's quite hard to determine when `ALTER SEQUENCE … RESTART`
 support was introduced but from some pain-staking searching I found that
 apparently 12.1 included support for it but it wasn't documented until 18c
 [3]:

 > There is a new option for altering a sequence that appeared in 12.1 but
 was not documented until 18c:
 > `alter SEQUENCE [schema_name.]{sequence_name} restart;`


 [1] https://docs.djangoproject.com/en/5.0/releases/1.5/
 [2] https://en.wikipedia.org/wiki/Oracle_Database#Releases_and_versions
 [3] https://www.red-gate.com/simple-talk/databases/oracle-databases
 /oracle-sequences-12c-features-including-identity/
-- 
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/0107018e7ee923df-bf5fddc6-4973-4dec-aba1-8bbf89b78ed2-00%40eu-central-1.amazonses.com.

Re: [Django] #34977: Turn link to change password form in admin user change form into a button

2024-03-27 Thread Django 
#34977: Turn link to change password form in admin user change form into a 
button
-+-
 Reporter:  Fabian Braun |Owner:  Fabian
 Type:   |  Braun
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.auth |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  accessibility| Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  1
-+-
Changes (by Fabian Braun):

 * needs_better_patch:  1 => 0
 * needs_docs:  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/0107018e7edc1f3e-64813385-4504-474d-a41d-23d619ed5752-00%40eu-central-1.amazonses.com.