[Django] #34118: Python 3.12 compatibility

2022-10-24 Thread Django
#34118: Python 3.12 compatibility
+
   Reporter:  Mariusz Felisiak  |  Owner:  nobody
   Type:  New feature   | Status:  new
  Component:  Core (Other)  |Version:  dev
   Severity:  Normal|   Keywords:
   Triage Stage:  Someday/Maybe |  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 Python 3.12 final is scheduled for October 2023 (see
 [https://peps.python.org/pep-0693/ ​PEP 693]). This is a tracking ticket
 for compatibility fixes for Django submitted in the meantime.

 Django 4.2 will be the first version to support Python 3.12, because
 Django 4.1 will end the mainstream support in April 2023.

-- 
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/010701840d43de22-b0a205c5-dc70-4d75-a83b-6dacb5724fe6-00%40eu-central-1.amazonses.com.


Re: [Django] #33173: Python 3.11 compatibility

2022-10-24 Thread Django
#33173: Python 3.11 compatibility
-+-
 Reporter:  Mariusz Felisiak |Owner:  Mariusz
 |  Felisiak
 Type:  New feature  |   Status:  assigned
Component:  Core (Other) |  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:  0
-+-
Changes (by Mariusz Felisiak):

 * owner:  nobody => Mariusz Felisiak
 * status:  new => assigned
 * stage:  Someday/Maybe => Accepted


Comment:

 https://www.python.org/downloads/release/python-3110/

-- 
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/010701840d3b18fe-c5c2d71f-e394-4cd3-8f65-c6b99094bd6f-00%40eu-central-1.amazonses.com.


Re: [Django] #34117: Anomaly with makemigrations

2022-10-24 Thread Django
#34117: Anomaly with makemigrations
-+-
 Reporter:  Ismael ABBO  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  3.2
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  CustomUser, field,   | Triage Stage:
  anomaly|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * status:  new => closed
 * resolution:   => invalid
 * component:  Database layer (models, ORM) => Migrations


Comment:

 You have a trailing comma after the field's closing parenthesis which
 creates a tuple and thus it isn't detected as a field. In the future,
 please see TicketClosingReasons/UseSupportChannels for ways to get help
 debugging and create a ticket only for confirmed bugs. 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/010701840c387e5e-1fb8ac69-578b-47b0-8c6d-f46130838942-00%40eu-central-1.amazonses.com.


Re: [Django] #34117: Anomaly with makemigrations

2022-10-24 Thread Django
#34117: Anomaly with makemigrations
-+-
 Reporter:  Ismael ABBO  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  CustomUser, field,   | Triage Stage:
  anomaly|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Ismael ABBO:

Old description:

> == Problem
> Makemigrations command does not see the specific change on models related
> to this field below but produces migrations for any other fields (even in
> separated project):
>
> {{{
> gender = models.BooleanField(
> _('gender'),
> default=True,
> blank=True,
> help_text=_('Designates whether the user is a woman.'),
> ),
> }}}
>
> Adding in migration files works fine, but {{{default}}} value does not
> (while they're applied in ORM according to
> [https://docs.djangoproject.com/en/4.1/ref/migration-
> operations/#addfield])
> Then I have added {{{blank=True}}} to counter non-null constraint
> violation
>
> When I add gender field in the migration files manually, executing
> {{{makemigrations}}} command again generate a delete of that field
> {{{gender}}} while I have not removed it in the associate model. **Do we
> assume here that it does not see the field at all from the beginning? **
> **Please, why? Am I wrong somewhere? **
>
> == Steps to reproduce with my environment project (but optional because I
> have tried it in separated project aswell):
> - dockerized Postgres 14.4
> - dockerized Python 3.8
> - Use a CustomUser model by following these instructions (which works
> well) : [https://code.djangoproject.com/ticket/25313#comment:24]

New description:

 == Problem
 Makemigrations command does not see the specific change on models related
 to this field below but produces migrations for any other fields (even in
 separated project):

 {{{
 gender = models.BooleanField(
 _('gender'),
 default=True,
 blank=True,
 help_text=_('Designates whether the user is a woman.'),
 ),
 }}}

 Adding in migration files works fine, but {{{default}}} value does not
 (while they're applied in ORM according to
 [https://docs.djangoproject.com/en/4.1/ref/migration-
 operations/#addfield])
 Then I have added {{{blank=True}}} to counter non-null constraint
 violation

 When I add gender field in the migration files manually, executing
 {{{makemigrations}}} command again generate a delete of that field
 {{{gender}}} while I have not removed it in the associate model. **Do we
 assume here that it does not see the field at all from the beginning? **

 When forcefully staying with that field, trying to run a command to
 populate database produces :
 {{{
   File "/usr/local/lib/python3.9/site-packages/django/db/models/base.py",
 line 503, in __init__
 raise TypeError("%s() got an unexpected keyword argument '%s'" %
 (cls.__name__, kwarg))
 TypeError: User() got an unexpected keyword argument 'gender'
 }}}

 **Please, why? Am I wrong somewhere? **

 == Steps to reproduce with my environment project (but optional because I
 have tried it in separated project aswell):
 - dockerized Postgres 14.4
 - dockerized Python 3.8
 - Use a CustomUser model by following these instructions (which works
 well) : [https://code.djangoproject.com/ticket/25313#comment:24]

--

-- 
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/010701840bd8627a-7cbe7de8-7bd2-4edc-b5a1-3ed407907722-00%40eu-central-1.amazonses.com.


[Django] #34117: Anomaly with makemigrations

2022-10-24 Thread Django
#34117: Anomaly with makemigrations
-+-
   Reporter:  Ismael |  Owner:  nobody
  ABBO   |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  3.2
  layer (models, ORM)|   Keywords:  CustomUser, field,
   Severity:  Normal |  anomaly
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 == Problem
 Makemigrations command does not see the specific change on models related
 to this field below but produces migrations for any other fields (even in
 separated project):

 {{{
 gender = models.BooleanField(
 _('gender'),
 default=True,
 blank=True,
 help_text=_('Designates whether the user is a woman.'),
 ),
 }}}

 Adding in migration files works fine, but {{{default}}} value does not
 (while they're applied in ORM according to
 [https://docs.djangoproject.com/en/4.1/ref/migration-
 operations/#addfield])
 Then I have added {{{blank=True}}} to counter non-null constraint
 violation

 When I add gender field in the migration files manually, executing
 {{{makemigrations}}} command again generate a delete of that field
 {{{gender}}} while I have not removed it in the associate model. **Do we
 assume here that it does not see the field at all from the beginning? **
 **Please, why? Am I wrong somewhere? **

 == Steps to reproduce with my environment project (but optional because I
 have tried it in separated project aswell):
 - dockerized Postgres 14.4
 - dockerized Python 3.8
 - Use a CustomUser model by following these instructions (which works
 well) : [https://code.djangoproject.com/ticket/25313#comment:24]

-- 
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/010701840bd53010-cfcb805e-b950-468c-8614-b19de6c9070e-00%40eu-central-1.amazonses.com.


Re: [Django] #34116: custom validation error in password_validators

2022-10-24 Thread Django
#34116: custom validation error in password_validators
---+--
 Reporter:  mojtabaakbari221b  |Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  contrib.auth   |  Version:  4.1
 Severity:  Normal |   Resolution:  wontfix
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Mariusz Felisiak):

 * resolution:  invalid => wontfix


-- 
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/010701840b80d16f-88803bd2-ed43-4c2c-9363-5af8458288c2-00%40eu-central-1.amazonses.com.


Re: [Django] #34116: custom validation error in password_validators

2022-10-24 Thread Django
#34116: custom validation error in password_validators
---+--
 Reporter:  mojtabaakbari221b  |Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  contrib.auth   |  Version:  4.1
 Severity:  Normal |   Resolution:  invalid
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Mariusz Felisiak):

 * status:  assigned => closed
 * ui_ux:  1 => 0
 * resolution:   => invalid
 * easy:  1 => 0


Comment:

 You can completely overwrite the list of password validators with the
 `AUTH_PASSWORD_VALIDATORS` setting. As far as I'm aware, there is no need
 for an extended customization in Django itself. See
 TicketClosingReasons/UseSupportChannels for ways to get help.

-- 
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/010701840b7def15-d59d00e9-0df2-4f6c-9c0b-19ed555684d9-00%40eu-central-1.amazonses.com.


[Django] #34116: custom validation error in password_validators

2022-10-24 Thread Django
#34116: custom validation error in password_validators
-+--
   Reporter:  mojtabaakbari221b  |  Owner:  nobody
   Type:  New feature| Status:  assigned
  Component:  contrib.auth   |Version:  4.1
   Severity:  Normal |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  1  |
-+--
 i wanna have custom validation error in password_validators,
 I can do this by rewriting the password validator classes and adding
 desired messages through options in the settings file and the
 password_validat section.

 something like this :


 {{{
 AUTH_PASSWORD_VALIDATORS = [
 {
 'NAME':
 'django.contrib.auth.password_validation.NumericPasswordValidator',
 'OPTIONS': {
 'validation_error': 'My Custom Validation Error.',
 },
 },
 ...
 ]
 }}}


 and so on.

 Apart from that I want to return custom validation error, for example in
 our company project we want to send our language based message without
 enabling t10n and l18n. Or ux writer wants to show the user the desired
 error according to business needs,
 But it is not possible unless we directly override the password_validation
 classes and this is an extra and dirty work.

 Is it worth the time? After spending some time, can I make a pull request?

-- 
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/010701840b613bef-763057cb-edcb-4476-93c4-96ac834e4b43-00%40eu-central-1.amazonses.com.


Re: [Django] #34115: Document RUN_MAIN environment variable

2022-10-24 Thread Django
#34115: Document RUN_MAIN environment variable
-+-
 Reporter:  johnthagen   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  4.1
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

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


Comment:

 The `RUN_MAIN` environment variable is a private API, not something that
 should be used or overwritten by users.

-- 
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/010701840b2b06f5-6843a426-0aa9-47ac-a3f3-5afb1904ac02-00%40eu-central-1.amazonses.com.


[Django] #34115: Document RUN_MAIN environment variable

2022-10-24 Thread Django
#34115: Document RUN_MAIN environment variable
+
   Reporter:  johnthagen|  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Documentation |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 |
+
 When doing some research into how to control how code should run in the
 ready function, I came across a reference to the {{{RUN_MAIN}}}
 environment variable that seems to only be set when the main server is
 executed (not when the reload server is executed, or other management
 commands are run).

 When I searched for {{{RUN_MAIN}}} in the main Django documentation, I
 didn't find any hits. I was hoping there would be official documentation
 on when this environment variable is designed to be used / when it can be
 relied on.

-- 
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/010701840a957f8f-e8649875-067a-4ee9-b068-39bcb401d65d-00%40eu-central-1.amazonses.com.


Re: [Django] #29027: file_move_safe() PermissionError with SELinux

2022-10-24 Thread Django
#29027: file_move_safe() PermissionError with SELinux
-+-
 Reporter:  bhargu   |Owner:  Yuri
 |  Konotopov
 Type:  Bug  |   Status:  closed
Component:  File |  Version:  1.11
  uploads/storage|
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  selinux  | 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:"64e5ef1f17cd18cb8ca24f4e7107dfd28c18b378" 64e5ef1]:
 {{{
 #!CommitTicketReference repository=""
 revision="64e5ef1f17cd18cb8ca24f4e7107dfd28c18b378"
 Fixed #29027 -- Fixed file_move_safe() crash when moving files with
 SELinux.

 Thanks Florian Apolloner for the 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/0107018409f89ec0-4297a612-f17f-4597-8868-9e53ed02ae14-00%40eu-central-1.amazonses.com.


Re: [Django] #29027: file_move_safe() PermissionError with SELinux

2022-10-24 Thread Django
#29027: file_move_safe() PermissionError with SELinux
-+-
 Reporter:  bhargu   |Owner:  Yuri
 |  Konotopov
 Type:  Bug  |   Status:  assigned
Component:  File |  Version:  1.11
  uploads/storage|
 Severity:  Normal   |   Resolution:
 Keywords:  selinux  | 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/0107018409dad261-5d5148e5-6844-4e0d-b3ad-44fa15ae3243-00%40eu-central-1.amazonses.com.


Re: [Django] #34095: Form controls in admin should use heights in relative units

2022-10-24 Thread Django
#34095: Form controls in admin should use heights in relative units
---+
 Reporter:  Thibaud Colas  |Owner:  jer
 Type:  Bug|   Status:  assigned
Component:  contrib.admin  |  Version:  4.1
 Severity:  Normal |   Resolution:
 Keywords:  accessibility  | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  1  |UI/UX:  1
---+
Changes (by Mariusz Felisiak):

 * needs_better_patch:  0 => 1


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018409a8703e-810eb12b-5e8a-41ee-ae75-6f1da6578f29-00%40eu-central-1.amazonses.com.


Re: [Django] #34098: Filter floatformat drops precision in decimal numbers

2022-10-24 Thread Django
#34098: Filter floatformat drops precision in decimal numbers
-+-
 Reporter:  Vlastimil Zíma   |Owner:  Vlastimil
 |  Zíma
 Type:  Bug  |   Status:  closed
Component:  Template system  |  Version:  dev
 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 GitHub ):

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


Comment:

 In [changeset:"08c5a787262c1ae57f6517d4574b54a5fcaad124" 08c5a787]:
 {{{
 #!CommitTicketReference repository=""
 revision="08c5a787262c1ae57f6517d4574b54a5fcaad124"
 Fixed #34098 -- Fixed loss of precision for Decimal values in floatformat
 filter.

 Regression in 12f7928f5a455e330c0a7f19bc86b37baca12811.
 }}}

-- 
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/0107018409a62b85-277f7bed-9ca1-40cf-a3bc-f1a3ba7f917b-00%40eu-central-1.amazonses.com.


Re: [Django] #34098: Filter floatformat drops precision in decimal numbers

2022-10-24 Thread Django
#34098: Filter floatformat drops precision in decimal numbers
-+-
 Reporter:  Vlastimil Zíma   |Owner:  Vlastimil
 |  Zíma
 Type:  Bug  |   Status:  assigned
Component:  Template system  |  Version:  dev
 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):

 * stage:  Accepted => Ready for checkin


Comment:

 Regression in 12f7928f5a455e330c0a7f19bc86b37baca12811.

-- 
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/01070184099ec480-c3e2a5b8-42d3-4d79-8eaa-74195132be36-00%40eu-central-1.amazonses.com.


Re: [Django] #34114: loaddata doesn't honor auto_now_add=True when these values are missing. (was: loading fixtures (loaddata) doesn't seem to honour auto_now_add=True when these values are missing)

2022-10-24 Thread Django
#34114: loaddata doesn't honor auto_now_add=True when these values are missing.
-+-
 Reporter:  rbosch   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (Management |  Version:  4.1
  commands)  |
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  fixtures loaddata| Triage Stage:
  yaml   |  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:   => duplicate
 * component:  Uncategorized => Core (Management commands)


Comment:

 Duplicate of #28951.

-- 
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/010701840962278a-38ba84e4-61f4-49a8-a610-6a15f6acc672-00%40eu-central-1.amazonses.com.


Re: [Django] #19544: IntegrityError during ManyToMany add() on Oracle or for user-defined through relationships.

2022-10-24 Thread Django
#19544: IntegrityError during ManyToMany add() on Oracle or for user-defined
through relationships.
-+-
 Reporter:  German M. Bravo  |Owner:  (none)
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  dev
  (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 Florian Demmer):

 * cc: Florian Demmer (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/0107018409496e15-0f6d9232-1188-4c81-9efc-ab6bde4edbf4-00%40eu-central-1.amazonses.com.


[Django] #34114: loading fixtures (loaddata) doesn't seem to honour auto_now_add=True when these values are missing

2022-10-24 Thread Django
#34114: loading fixtures (loaddata) doesn't seem to honour auto_now_add=True 
when
these values are missing
-+-
   Reporter:  rbosch |  Owner:  nobody
   Type:  Bug| Status:  new
  Component: |Version:  4.1
  Uncategorized  |   Keywords:  fixtures loaddata
   Severity:  Normal |  yaml
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 In my model I have a model with a DateTime field (models.DateTimeField)
 defined as follows:

 {{{
 class MyModal(models.Model):
   key = models.CharField(max_length=20, blank=False, null=False)
   created_at = models.DateTimeField(blank=False, null=False,
 auto_now_add=True)
 }}}

 When loading the data via the fixtures and ''omitting'' the created_at
 field,  I would assume created_at will be set to ''now''

 I'm getting a error:
 {{{
 Could not load app.MyModal(pk=None): (1048, "Column 'created_at' cannot be
 null")
 }}}

 YAML:

 {{{
 - model: app.mymodal
   fields:
 key: some text value
 }}}

-- 
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/01070184094594bc-8d445284-b932-4fb4-a5b7-d47130d50a54-00%40eu-central-1.amazonses.com.


Re: [Django] #34113: max() arg is an empty sequence (was: Sitemap: max() arg is an empty sequence)

2022-10-24 Thread Django
#34113: max() arg is an empty sequence
+--
 Reporter:  Mikhail Mitrofanov  |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  contrib.sitemaps|  Version:  4.1
 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
+--
Changes (by Mariusz Felisiak):

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


Comment:

 Duplicate of #34088.

-- 
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/01070184093ed537-02ef1ab9-d487-4579-a82a-19c496e7a7d3-00%40eu-central-1.amazonses.com.


Re: [Django] #33507: Use native UUID data type on MariaDB 10.7+

2022-10-24 Thread Django
#33507: Use native UUID data type on MariaDB 10.7+
-+-
 Reporter:  Mariusz Felisiak |Owner:  raydeal
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  4.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  mariadb  | 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):

 * needs_better_patch:  0 => 1


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/01070184093d712e-1f9b6bc8-bc1b-4742-930a-4ec34bf80d36-00%40eu-central-1.amazonses.com.


[Django] #34113: Sitemap: max() arg is an empty sequence

2022-10-24 Thread Django
#34113: Sitemap: max() arg is an empty sequence
--+
   Reporter:  Mikhail Mitrofanov  |  Owner:  nobody
   Type:  Bug | Status:  new
  Component:  contrib.sitemaps|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   |
--+
 With empty items sequence Sitemap raise ValueError: max() arg is an empty
 sequence

 Sitemap example:

 {{{
 class RealtyPropertySitemap(Sitemap):
 changefreq = "monthly"

 def items(self):
 return Property.objects.filter(is_active=True).only("pk", "slug",
 "lastmodified").order_by("pk")

 def lastmod(self, obj: Property):
 return obj.lastmodified
 }}}

-- 
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/0107018409290794-a0f1e319-e584-47c2-893e-40e0622f92a3-00%40eu-central-1.amazonses.com.


Re: [Django] #34070: Add support for microseconds to Now() on MySQL and SQLite.

2022-10-24 Thread Django
#34070: Add support for microseconds to Now() on MySQL and SQLite.
-+-
 Reporter:  Mariusz Felisiak |Owner:  Lily
 |  Foote
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  dev
  (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 GitHub ):

 In [changeset:"577dbcbb4f46df02e1f85179798a1079733c5a97" 577dbcbb]:
 {{{
 #!CommitTicketReference repository=""
 revision="577dbcbb4f46df02e1f85179798a1079733c5a97"
 Refs #34070 -- Fixed date format in Now() on SQLite.

 Regression in 649b28eab6765cd6b2b40c779a18ecafc99b43d7.
 }}}

-- 
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/0107018408d5beb1-8b4da72c-d6a0-46fe-9511-e30e8c45063f-00%40eu-central-1.amazonses.com.


Re: [Django] #34111: Use sqlparse to format SQL in tests failures with debug flag

2022-10-24 Thread Django
#34111: Use sqlparse to format SQL in tests failures with debug flag
-+-
 Reporter:  Paolo Melchiorre |Owner:  Giebisch
 Type:  New feature  |   Status:  closed
Component:  Testing framework|  Version:  4.1
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  sqlparse, sql,   | Triage Stage:  Ready for
  format, test   |  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:"3283120cca5d5eba5c3619612d0de5ad49dcf054" 3283120c]:
 {{{
 #!CommitTicketReference repository=""
 revision="3283120cca5d5eba5c3619612d0de5ad49dcf054"
 Fixed #34111 -- Made test runner with --debug-sql format SQL queries.
 }}}

-- 
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/0107018408cb9986-f3a0c1fd-a3d0-4c58-b397-8a09edcca60a-00%40eu-central-1.amazonses.com.


Re: [Django] #31920: ASGI/ASYNC SessionMiddleware - SynchronousOnlyOperation exception if request.user is not unwrapped in sync code

2022-10-24 Thread Django
#31920: ASGI/ASYNC SessionMiddleware - SynchronousOnlyOperation exception if
request.user is not unwrapped in sync code
--+
 Reporter:  Michael Galler|Owner:  lirontb
 Type:  New feature   |   Status:  assigned
Component:  contrib.sessions  |  Version:  3.1
 Severity:  Normal|   Resolution:
 Keywords:  async | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  1
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Mariusz Felisiak):

 * needs_better_patch:  0 => 1
 * needs_docs:  0 => 1


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018408ae6e34-53eaf730-acc7-46f6-99b8-0ee657dc8f50-00%40eu-central-1.amazonses.com.


Re: [Django] #34111: Use sqlparse to format SQL in tests failures with debug flag

2022-10-24 Thread Django
#34111: Use sqlparse to format SQL in tests failures with debug flag
-+-
 Reporter:  Paolo Melchiorre |Owner:  Giebisch
 Type:  New feature  |   Status:  assigned
Component:  Testing framework|  Version:  4.1
 Severity:  Normal   |   Resolution:
 Keywords:  sqlparse, sql,   | Triage Stage:  Ready for
  format, test   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * 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/0107018408a68012-5e189f2f-4339-4a5c-93dd-c2788515c2c7-00%40eu-central-1.amazonses.com.