Re: [Django] #34167: Set a reasonable default for EMAIL_TIMEOUT

[Django]

#34167: Set a reasonable default for EMAIL_TIMEOUT
-+-
 Reporter:  Federico Capoano |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Core (Mail)  |  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:

 > Why there's no default for `EMAIL_TIMEOUT`?

 If timeout is unspecified,
 [https://docs.djangoproject.com/en/stable/topics/email/#smtp-backend SMTP
 backend] will use `socket.getdefaulttimeout()`, so adding a default value
 for `EMAIL_TIMEOUT` would be backward incompatible for all projects that
 set a default timeout for sockets.

 Initially closing as "wontfix". Please first start a discussion on the
 DevelopersMailingList., where you'll reach a wider audience and see what
 other think, and
 [https://docs.djangoproject.com/en/stable/internals/contributing/triaging-
 tickets/#closing-tickets follow triaging guidelines with regards to
 wontfix tickets.] If you can get consensus on a proposal on the
 DevelopersMailingList, we can reopen the ticket. 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/0107018483ec77be-2d7a9785-e05a-43ff-a0bd-09253399f266-00%40eu-central-1.amazonses.com.

Re: [Django] #26056: ArrayField does not work with ValueListQuerySet

[Django]

#26056: ArrayField does not work with ValueListQuerySet
--+
 Reporter:  Przemek   |Owner:  (none)
 Type:  New feature   |   Status:  new
Component:  contrib.postgres  |  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 bcail):

 * needs_better_patch:  1 => 0


Comment:

 New PR: https://github.com/django/django/pull/16303

-- 
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/01070184824a4de5-9f6eb61f-afc2-4f65-891b-a9c1f28b5dfb-00%40eu-central-1.amazonses.com.

Re: [Django] #14094: Cannot define CharField with unlimited length

[Django]

#14094: Cannot define CharField with unlimited length
-+-
 Reporter:  Daniel Miller|Owner:  Adrian
 |  Torres
 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:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Adrian Torres):

 * cc: Adrian Torres (added)
 * needs_better_patch:  1 => 0
 * owner:  Aron Podrigal => Adrian Torres


Comment:

 I have submitted a patch at https://github.com/django/django/pull/16302

-- 
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/0107018481dfac4c-9db6b26c-432b-412e-9f46-37107ab7b730-00%40eu-central-1.amazonses.com.

Re: [Django] #34166: UniqueConstraint with condition not validated if the condition field is not editable. (was: UniqueConstraint with condition not validated if the condition field is not editable)

[Django]

#34166: UniqueConstraint with condition not validated if the condition field is 
not
editable.
-+-
 Reporter:  Márton Salomváry |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  4.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  model validation | Triage Stage:
  unique constraint condition|  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
 * type:  Bug => New feature
 * resolution:   => wontfix


Comment:

 Thanks for the ticket. This is
 [https://docs.djangoproject.com/en/stable/topics/forms/modelforms
 /#interaction-with-model-validation the documented behavior for forms] and
 it was [https://github.com/django/django/pull/14625#discussion_r946747147
 discussed] shortly in the original PR (as you've already noticed).

 Unfortunately, changing this would be backward incompatible so please
 first start a discussion on the DevelopersMailingList, where you'll reach
 a wider audience and see what other think, and
 [https://docs.djangoproject.com/en/stable/internals/contributing/bugs-and-
 features/#requesting-features follow the guidelines with regards to
 requesting features].

-- 
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/0107018481d64d5a-3fb1f6f6-9baf-45f5-9198-f857dbf74c43-00%40eu-central-1.amazonses.com.

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

[Django]

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

Comment (by Martin Lehoux):

 I can confirm `inventory_count = models.SmallIntegerField()`

-- 
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/0107018481d012d9-89954194-18af-4bb3-933b-61f9ac36a319-00%40eu-central-1.amazonses.com.

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

[Django]

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

Comment (by Simon Charette):

 What I believe is happening here is that `F("inventory_count") + Value(1)`
 has its `output_field` resolved to `IntegerField` because it's the common
 base of `inventory_count` (which I assume is a `SmallIntegerField` since
 the models were not provided).

 While `CombinedExpression._resolve_output_field` resolving logic deals
 with subclassing properly `BaseExpression._resolve_output_field`
 
[https://github.com/django/django/blob/2848e5d0ce5cf3c31fe87525536093b21d570f69/django/db/models/expressions.py#L327-L329
 isn't smart enough] to resolve a mix of `IntegerField` subclasses to the
 largest denominator.

 The three ways we could be fixing that would be:
 1. Document this requirement the usage of explicit `output_field` either
 to `Value` [https://docs.djangoproject.com/en/4.1/releases/3.2/ beyond the
 3.2 release notes].
 2. Make `Value._resolve_field` use different kind of `IntegerField`
 subclasses when dealing with smaller/larger values. This could have the
 unintended side effect of surfacing even more errors for mixed type as
 `Value(n < 255)`  would resolve to `SmallIntegerField` so I think this is
 a bad idea.
 3. Actually make `BasExpression._resolve_output_field` smarter with the
 deprecation period it requires.

-- 
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/0107018481b3bbca-a528cd77-ac7d-4976-bb80-b8e40b8ab4c9-00%40eu-central-1.amazonses.com.

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

[Django]

#34162: Wrong URL generated by get_admin_url in admin index "Recent Actions" 
panel
in custom Django Admin Site
+--
 Reporter:  Rigoberto Villalta  |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  contrib.admin   |  Version:  4.0
 Severity:  Normal  |   Resolution:  duplicate
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--

Comment (by Mariusz Felisiak):

 Replying to [comment:2 Rigoberto Villalta]:
 > I don´t think is duplicate.

 It's not exactly the same but resolving URLs to a proper admin site would
 fix both issues.

-- 
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/0107018481ac875c-2cb4fc85-832a-4d39-84a0-9b10b02a6d5e-00%40eu-central-1.amazonses.com.

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

[Django]

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

Comment (by Martin Lehoux):

 Isn't it the `Case` that has an issue computing it's `output_field`? If
 it's the case, I'm not sure that the files you pointed to me were the
 right ones.
 ''django/db/models/expressions.py''

 {{{
 @deconstructible(path="django.db.models.Case")
 class Case(SQLiteNumericMixin, Expression):
 """
 An SQL searched CASE expression:

 CASE
 WHEN n > 0
 THEN 'positive'
 WHEN n < 0
 THEN 'negative'
 ELSE 'zero'
 END
 """

 template = "CASE %(cases)s ELSE %(default)s END"
 case_joiner = " "

 def __init__(self, *cases, default=None, output_field=None, **extra):
 if not all(isinstance(case, When) for case in cases):
 raise TypeError("Positional arguments must all be When
 objects.")
 super().__init__(output_field)
 self.cases = list(cases)
 self.default = self._parse_expressions(default)[0]
 self.extra = extra
 }}}

-- 
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/010701848189cfe7-5ccf35d5-05c8-4a88-b5d4-e3f13e4f8a8b-00%40eu-central-1.amazonses.com.

Re: [Django] #34166: UniqueConstraint with condition not validated if the condition field is not editable

[Django]

#34166: UniqueConstraint with condition not validated if the condition field is 
not
editable
-+-
 Reporter:  Márton Salomváry |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  4.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  model validation | Triage Stage:
  unique constraint condition|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Márton Salomváry):

 The problem seems to be that the non-editable field is passed down as part
 of `excludes`, which is right, we do not want to validate the value of the
 non-editable field.

 However this is not about validating the value of the non-editable field,
 but conditionally validating the value of a *different* field, if the non-
 editable field's value matches the condition.

 The documentation on the semantics of `excludes` seems to confirm this:
 
https://docs.djangoproject.com/en/4.1/ref/models/instances/#django.db.models.Model.full_clean
 "ModelForm uses this argument to exclude fields that aren’t present on
 your form from being validated since any errors raised could not be
 corrected by the user."

 I'm a little confused however because I found a test that seems to
 specifically verify this (but there is no explanation for the "why" or
 "for what purpose").
 
https://github.com/django/django/blob/e14d08cd894e9d91cb5d9f44ba7532c1a223f458/tests/constraints/tests.py#L698-L703

 I've also done a bit of Git archeology and found this conversation around
 the same problem which ends with "That's a suitable workaround, but I feel
 like it should not be necessary."
 https://github.com/django/django/pull/14625#pullrequestreview-1074071130

 Would a patch be accepted that makes the workaround unnecessary?

-- 
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/010701848189b839-738366bd-19a8-4559-bba1-8a811c8e37f7-00%40eu-central-1.amazonses.com.

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

[Django]

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

 * owner:  nobody => Martin Lehoux
 * 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/01070184818306fd-55adaf35-2b1d-402e-9acd-27e8400a637f-00%40eu-central-1.amazonses.com.

[Django] #34167: Set a reasonable default for EMAIL_TIMEOUT

[Django]

#34167: Set a reasonable default for EMAIL_TIMEOUT
+
   Reporter:  Federico Capoano  |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Core (Mail)   |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 |
+
 Why there's no default for EMAIL_TIMEOUT?

 Applications built in Django can potentially stall indefinitely if email
 sending starts to hang (eg: if the SMTP server is overloaded), when this
 happens, since there's no timeout, there's also no error being logged, so
 it's very hard and time consuming to debug.

 Wouldn't it be better to set a timeout? Some high value like 2 minutes
 which wouldn't really make sense to wait any longer, so at least if and
 when this happens, developers will find error traces in the logs and
 quickly understand where the problem is coming from, instead of spending
 hours to debug it like I did in the past week.

-- 
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/01070184815e678d-3e2a5d95-8460-4ed9-85f0-ccd180f50748-00%40eu-central-1.amazonses.com.

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

[Django]

#34162: Wrong URL generated by get_admin_url in admin index "Recent Actions" 
panel
in custom Django Admin Site
+--
 Reporter:  Rigoberto Villalta  |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  contrib.admin   |  Version:  4.0
 Severity:  Normal  |   Resolution:  duplicate
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--

Comment (by Rigoberto Villalta):

 I don´t think is duplicate.
 What the ticket [https://code.djangoproject.com/ticket/17726 #17726]
 alleges is that if you change a {{{Model}}} A in a custom {{{Admin Site}}}
 and this {{{Model}}} is not register in other {{{Admin Site}}} instance,
 this shouldn't appear in the index of the other {{{Admin Site}}} instance.

 What I am trying to fix is that at least to point the {{{Logentry}}} in
 the index to the current {{{Admin Site}}}.
 I most said this bug only happens if you register the Default Admin Site
 in the project's {{{url.py}}} file:
 {{{
 path("super_admin/", admin.site.urls)
 }}}

-- 
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/010701848156362d-6c7be2c6-c900-4d5f-8215-9944e2eb95e8-00%40eu-central-1.amazonses.com.

Re: [Django] #34166: UniqueConstraint with condition not validated if the condition field is not editable

[Django]

#34166: UniqueConstraint with condition not validated if the condition field is 
not
editable
-+-
 Reporter:  Márton Salomváry |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  4.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  model validation | Triage Stage:
  unique constraint condition|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Márton Salomváry):

 * Attachment "Screen Shot 2022-11-16 at 16.18.53.png" added.

 Actual error

-- 
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/0107018481551ede-b7af80cb-ec65-414a-bc37-225f52e1f39d-00%40eu-central-1.amazonses.com.

Re: [Django] #34166: UniqueConstraint with condition not validated if the condition field is not editable

[Django]

#34166: UniqueConstraint with condition not validated if the condition field is 
not
editable
-+-
 Reporter:  Márton Salomváry |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  4.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  model validation | Triage Stage:
  unique constraint condition|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Márton Salomváry):

 * Attachment "Screen Shot 2022-11-16 at 16.16.17.png" added.

 Expected error

-- 
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/010701848154da62-ea6ef05e-b6b1-4175-9e68-6027292b16be-00%40eu-central-1.amazonses.com.

[Django] #34166: UniqueConstraint with condition not validated if the condition field is not editable

[Django]

#34166: UniqueConstraint with condition not validated if the condition field is 
not
editable
-+-
   Reporter:  Márton |  Owner:  nobody
  Salomváry  |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  4.1
  layer (models, ORM)|   Keywords:  model validation
   Severity:  Normal |  unique constraint condition
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Given a model with a UniqueConstraint that has a condition with a field
 that is not editable
 when I try to save this model with an (admin) form with an invalid value
 for the  UniqueConstraint
 I expect to get a (Django) validation error.

 What I get instead is a database-level integrity error.

 If the condition field is editable, I do get a validation error (although
 a form level one, not a field level one, which might be another bug).
 If there is no condition on the field, I do get the expected field level
 validation error.

 Example:


 {{{
 class Thing(models.Model):
 name = models.CharField(max_length=10)

 status = models.CharField(max_length=10, blank=True, editable=False)

 class Meta:
 constraints = [
 models.UniqueConstraint(
 fields=["name"],
 name="thing_unique_name",
 condition=~Q(status="archived"),
 )
 ]
 }}}


 Small test case repo:
 https://github.com/salomvary/django_partial_constraint_bug
 (To reproduce, go to http://127.0.0.1:8000/admin/thing/thing/add/ and try
 to add two Things with the same name.)

 I've tried the latest dev version of Django, which has same problem.

-- 
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/0107018481544240-3097252b-b2c5-4259-adcd-48f3ea2c46e3-00%40eu-central-1.amazonses.com.

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

[Django]

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

Comment (by Mariusz Felisiak):

 Replying to [comment:6 Martin Lehoux]:
 > Hi, I'd be happy to! I will have a look tonight, and will ask a few
 questions if I have trouble understanding what to do (but from what I read
 the infrastructure is already there for this feature)

 Thanks, it should be enough to add extra
 
[https://github.com/django/django/blob/2848e5d0ce5cf3c31fe87525536093b21d570f69/django/db/models/expressions.py#L532-L547
 combinations for integer fields] (a regression test is also required, see
 
[https://github.com/django/django/blob/2848e5d0ce5cf3c31fe87525536093b21d570f69/tests/expressions/tests.py#L2411-L2437
 test_resolve_output_field_number()]).

-- 
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/01070184814312b4-75f0cb6d-8cde-48b8-896a-c0887b26b8cd-00%40eu-central-1.amazonses.com.

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

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

 This patch resolves the problem at my end. I hope it can be added in the
 4.1.4 since #29843 seems to be not actively worked on at the moment.

-- 
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/010701848117ec13-c9c373e7-421a-4531-a5c1-33d9fad93345-00%40eu-central-1.amazonses.com.

Re: [Django] #33308: Add psycopg3 backend

[Django]

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

 * cc: Sage Abdullah (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/0107018480f2af11-0843a52a-c85e-4492-bb78-48511762c607-00%40eu-central-1.amazonses.com.

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

[Django]

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

Comment (by Martin Lehoux):

 Hi, I'd be happy to! I will have a look tonight, and will ask a few
 questions if I have trouble understanding what to do (but from what I read
 the infrastructure is already there for this feature)

-- 
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/0107018480a7891b-a6a2be0d-958f-4640-b15a-629e97fcc552-00%40eu-central-1.amazonses.com.

Re: [Django] #34165: migrate management command does not respect database parameter when adding Permissions. (was: migrate management command does not respect database parameter for all DB calls)

[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
--+
Changes (by Mariusz Felisiak):

 * component:  Migrations => contrib.auth
 * stage:  Unreviewed => Accepted


Comment:

 Thanks for this report, it's related with adding missing permissions. I
 was able to fix this by setting `_state.db`, however I'm not convinced
 that it's the best solution:
 {{{#!diff
 diff --git a/django/contrib/auth/management/__init__.py
 b/django/contrib/auth/management/__init__.py
 index 0b5a982617..27fe0df1d7 100644
 --- a/django/contrib/auth/management/__init__.py
 +++ b/django/contrib/auth/management/__init__.py
 @@ -94,12 +94,15 @@ def create_permissions(
  )
  .values_list("content_type", "codename")
  )
 -
 -perms = [
 -Permission(codename=codename, name=name, content_type=ct)
 -for ct, (codename, name) in searched_perms
 -if (ct.pk, codename) not in all_perms
 -]
 +perms = []
 +for ct, (codename, name) in searched_perms:
 +if (ct.pk, codename) not in all_perms:
 +permission = Permission()
 +permission._state.db = using
 +permission.codename = codename
 +permission.name = name
 +permission.content_type = ct
 +perms.append(permission)
  Permission.objects.using(using).bulk_create(perms)
  if verbosity >= 2:
  for perm in perms:

 }}}

 Partly related to #29843.

-- 
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/01070184809c57fb-8c8f470a-d323-4f69-a43e-00f6ac512cf7-00%40eu-central-1.amazonses.com.

Re: [Django] #17726: Admin's Recent Actions broken for multiple admin site instances with unique registered models

[Django]

#17726: Admin's Recent Actions broken for multiple admin site instances with 
unique
registered models
-+-
 Reporter:  Steven MacLeod   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  1.3
 Severity:  Normal   |   Resolution:
 Keywords:  admin, multiple  | Triage Stage:  Accepted
  admin sites, recent actions|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak):

 #34162 was a duplicate for resolving URLs for a custom admin site.

-- 
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/010701848067375a-c106acab-abeb-4aae-8c55-1063c35d8700-00%40eu-central-1.amazonses.com.

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

[Django]

#34162: Wrong URL generated by get_admin_url in admin index "Recent Actions" 
panel
in custom Django Admin Site
+--
 Reporter:  Rigoberto Villalta  |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  contrib.admin   |  Version:  4.0
 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:

 Thanks for the ticket, I think we can mark this as a duplicate of #17726.
 Resolving URLs to a proper admin site should fix both issues.

-- 
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/010701848065b83c-e8b5e860-5eff-4a1d-80fc-833440988bf0-00%40eu-central-1.amazonses.com.

Re: [Django] #34165: migrate management command does not respect database parameter for all DB calls

[Django]

#34165: migrate management command does not respect database parameter for all 
DB
calls
+--
 Reporter:  Vasanth |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  4.1
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Description changed by Vasanth:

Old description:

> When invoking migrate with a database parameter, the migration runs
> successfully. However, there seems to be a DB read request that runs
> after the migration. This call does not respect the db param and invokes
> the db router .
>
> When naming the db as a parameter, all DB calls in the context of the
> migrate command are expected to use the database specified.
>
> I came across this as I am currently using a thread-local variable to get
> the active DB with a custom DB router for a multi-tenant service .
>
> **''Minimal example''**
>
> Setup the custom middleware and custom DB Router as show below. Then run
> any DB migration. Ideally none of this code must be called as the DB was
> specified during management command.
>

> {{{
>
> from threading import local
> from django.conf import settings
>
> local_state = local()
>

> class InvalidTenantException(Exception):
> pass
>

> class TenantSubdomainMiddleware:
> def __init__(self, get_response):
> self.get_response = get_response
>
> def __call__(self, request):
> ## Get Subdomain
> host = request.get_host().split(":")[0]
> local_state.subdomain = (
> # We assume single level of subdomain : app.service.com
> # HOST_IP : used to for local dev.
> host if host in settings.HOST_IP else host.split(".")[0]
> )
> response = self.get_response(request)
> return response
>

> class TenantDatabaseRouter:
> def _default_db(self):
> subdomain = getattr(local_state, "subdomain", None)
> if subdomain is not None and subdomain in settings.TENANT_MAP:
> db_name = settings.TENANT_MAP[local_state.subdomain]
> return db_name
> else:
> raise InvalidTenantException()
>
> def db_for_read(self, model, **hints):
> return self._default_db()
>
> def db_for_write(self, model, **hints):
> return self._default_db()
>
> def allow_relation(self, obj1, obj2, **hints):
> return True
>
> def allow_migrate(self, db, app_label, model_name=None, **hints):
> return True
>
> ## settings.py
>

>
> MIDDLEWARE = [
> "utils.tenant_db_router.TenantSubdomainMiddleware",
> "django.middleware.security.SecurityMiddleware",
> ...
> ]
>
> TENANT_MAP = {"localhost":"default", "tenant_1":"default"}
> DATABASE_ROUTERS = ["utils.tenant_db_router.TenantDatabaseRouter"]
> }}}

New description:

 When invoking migrate with a database parameter, the migration runs
 successfully. However, there seems to be a DB read request that runs after
 the migration. This call does not respect the db param and invokes the db
 router .

 When naming the db as a parameter, all DB calls in the context of the
 migrate command are expected to use the database specified.

 I came across this as I am currently using a thread-local variable to get
 the active DB with a custom DB router for a multi-tenant service .

 **''Minimal example''**

 Setup the custom middleware and custom DB Router as show below. Then run
 any DB migration. We see that "read {}" is being printed before the
 exception message.

 Ideally none of this code must be called as the DB was specified during
 management command.


 {{{

 from threading import local
 from django.conf import settings

 local_state = local()


 class InvalidTenantException(Exception):
 pass


 class TenantSubdomainMiddleware:
 def __init__(self, get_response):
 self.get_response = get_response

 def __call__(self, request):
 ## Get Subdomain
 host = request.get_host().split(":")[0]
 local_state.subdomain = (
 # We assume single level of subdomain : app.service.com
 # HOST_IP : used to for local dev.
 host if host in settings.HOST_IP else host.split(".")[0]
 )
 response = self.get_response(request)
 return response


 class TenantDatabaseRouter:
 def _default_db(self):
 subdomain = getattr(local_state, "subdomain", None)
 if subdomain is not None and subdomain in settings.TENANT_MAP:
 db_name = settings.TENANT_MAP[local_state.subdomain]
 return db_name
 else:
 

Re: [Django] #34118: Python 3.12 compatibility

[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:"2848e5d0ce5cf3c31fe87525536093b21d570f69" 2848e5d]:
 {{{
 #!CommitTicketReference repository=""
 revision="2848e5d0ce5cf3c31fe87525536093b21d570f69"
 Refs #34118 -- Used smtplib's context parameter instead of keyfile and
 certfile.

 keyfile and certfile parameters were removed in Python 3.12, see
 
https://github.com/python/cpython/commit/ef0e72b31d22f780d3a165d7d0471806061fe380
 }}}

-- 
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/010701847ffe71f2-2ab52d09-439b-4090-9fc1-0ef78dea7387-00%40eu-central-1.amazonses.com.

Re: [Django] #34165: migrate management command does not respect database parameter for all DB calls

[Django]

#34165: migrate management command does not respect database parameter for all 
DB
calls
+--
 Reporter:  Vasanth |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Migrations  |  Version:  4.1
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Description changed by Vasanth:

Old description:

> When invoking migrate with a database parameter, the migration runs
> successfully. However, there seems to be a DB read request that runs
> after the migration. This call does not respect the db param and invokes
> the db router .
>
> When naming the db as a parameter, all DB calls in the context of the
> migrate command are expected to use the database specified.
>
> I came across this as I am currently using a thread-local variable to get
> the active DB with a custom DB router for a multi-tenant service .
>
> **''Minimal example''**
>

> {{{
>
> from threading import local
> from django.conf import settings
>
> local_state = local()
>

> class InvalidTenantException(Exception):
> pass
>

> class TenantSubdomainMiddleware:
> def __init__(self, get_response):
> self.get_response = get_response
>
> def __call__(self, request):
> ## Get Subdomain
> host = request.get_host().split(":")[0]
> local_state.subdomain = (
> # We assume single level of subdomain : app.service.com
> # HOST_IP : used to for local dev.
> host if host in settings.HOST_IP else host.split(".")[0]
> )
> response = self.get_response(request)
> return response
>

> class TenantDatabaseRouter:
> def _default_db(self):
> subdomain = getattr(local_state, "subdomain", None)
> if subdomain is not None and subdomain in settings.TENANT_MAP:
> db_name = settings.TENANT_MAP[local_state.subdomain]
> return db_name
> else:
> raise InvalidTenantException()
>
> def db_for_read(self, model, **hints):
> return self._default_db()
>
> def db_for_write(self, model, **hints):
> return self._default_db()
>
> def allow_relation(self, obj1, obj2, **hints):
> return True
>
> def allow_migrate(self, db, app_label, model_name=None, **hints):
> return True
>
> ## settings.py
>

>
> MIDDLEWARE = [
> "utils.tenant_db_router.TenantSubdomainMiddleware",
> "django.middleware.security.SecurityMiddleware",
> ...
> ]
>
> TENANT_MAP = {"localhost":"default", "tenant_1":"default"}
> DATABASE_ROUTERS = ["utils.tenant_db_router.TenantDatabaseRouter"]
> }}}

New description:

 When invoking migrate with a database parameter, the migration runs
 successfully. However, there seems to be a DB read request that runs after
 the migration. This call does not respect the db param and invokes the db
 router .

 When naming the db as a parameter, all DB calls in the context of the
 migrate command are expected to use the database specified.

 I came across this as I am currently using a thread-local variable to get
 the active DB with a custom DB router for a multi-tenant service .

 **''Minimal example''**

 Setup the custom middleware and custom DB Router as show below. Then run
 any DB migration. Ideally none of this code must be called as the DB was
 specified during management command.


 {{{

 from threading import local
 from django.conf import settings

 local_state = local()


 class InvalidTenantException(Exception):
 pass


 class TenantSubdomainMiddleware:
 def __init__(self, get_response):
 self.get_response = get_response

 def __call__(self, request):
 ## Get Subdomain
 host = request.get_host().split(":")[0]
 local_state.subdomain = (
 # We assume single level of subdomain : app.service.com
 # HOST_IP : used to for local dev.
 host if host in settings.HOST_IP else host.split(".")[0]
 )
 response = self.get_response(request)
 return response


 class TenantDatabaseRouter:
 def _default_db(self):
 subdomain = getattr(local_state, "subdomain", None)
 if subdomain is not None and subdomain in settings.TENANT_MAP:
 db_name = settings.TENANT_MAP[local_state.subdomain]
 return db_name
 else:
 raise InvalidTenantException()

 def db_for_read(self, model, **hints):
 return self._default_db()

 def db_for_write(self, model, **hints):
 return self._default_db()

 def allow_relation(self, obj1, obj2, **hints):
  

[Django] #34165: migrate management command does not respect database parameter for all DB calls

[Django]

#34165: migrate management command does not respect database parameter for all 
DB
calls
--+
   Reporter:  Vasanth |  Owner:  nobody
   Type:  Bug | Status:  new
  Component:  Migrations  |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 invoking migrate with a database parameter, the migration runs
 successfully. However, there seems to be a DB read request that runs after
 the migration. This call does not respect the db param and invokes the db
 router .

 When naming the db as a parameter, all DB calls in the context of the
 migrate command are expected to use the database specified.

 I came across this as I am currently using a thread-local variable to get
 the active DB with a custom DB router for a multi-tenant service .

 **''Minimal example''**


 {{{

 from threading import local
 from django.conf import settings

 local_state = local()


 class InvalidTenantException(Exception):
 pass


 class TenantSubdomainMiddleware:
 def __init__(self, get_response):
 self.get_response = get_response

 def __call__(self, request):
 ## Get Subdomain
 host = request.get_host().split(":")[0]
 local_state.subdomain = (
 # We assume single level of subdomain : app.service.com
 # HOST_IP : used to for local dev.
 host if host in settings.HOST_IP else host.split(".")[0]
 )
 response = self.get_response(request)
 return response


 class TenantDatabaseRouter:
 def _default_db(self):
 subdomain = getattr(local_state, "subdomain", None)
 if subdomain is not None and subdomain in settings.TENANT_MAP:
 db_name = settings.TENANT_MAP[local_state.subdomain]
 return db_name
 else:
 raise InvalidTenantException()

 def db_for_read(self, model, **hints):
 return self._default_db()

 def db_for_write(self, model, **hints):
 return self._default_db()

 def allow_relation(self, obj1, obj2, **hints):
 return True

 def allow_migrate(self, db, app_label, model_name=None, **hints):
 return True

 ## settings.py



 MIDDLEWARE = [
 "utils.tenant_db_router.TenantSubdomainMiddleware",
 "django.middleware.security.SecurityMiddleware",
 ...
 ]

 TENANT_MAP = {"localhost":"default", "tenant_1":"default"}
 DATABASE_ROUTERS = ["utils.tenant_db_router.TenantDatabaseRouter"]
 }}}

-- 
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/010701847ff9d58f-be9e4c36-f612-40f8-b30c-a4fc3e84-00%40eu-central-1.amazonses.com.

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

[Django]

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

Comment (by Mariusz Felisiak):

 Martin, 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/010701847fcc5f6c-87bd537b-e53a-4460-adcf-38c205858068-00%40eu-central-1.amazonses.com.

Re: [Django] #28056: Reverse migration for model rename with cross-app ForeignKey fails

[Django]

#28056: Reverse migration for model rename with cross-app ForeignKey fails
--+
 Reporter:  Paul Tiplady  |Owner:  (none)
 Type:  Bug   |   Status:  assigned
Component:  Migrations|  Version:  1.10
 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 Bhuvnesh):

 I think this issue was solved in
 
[https://github.com/django/django/pull/12688/commits/aa4acc164d1247c0de515c959f7b09648b57dc42
 aa4acc164d1247c0de515c959f7b09648b57dc42] and can be closed now.

-- 
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/010701847fb4c10f-fed6dfe1-add8-4df7-a2f4-bafb14afc5e7-00%40eu-central-1.amazonses.com.

Re: [Django] #34164: django-graphql-auth 0.3.16 && django-mongoengine 0.5.4 dont work with django-4.1.3

[Django]

#34164: django-graphql-auth 0.3.16 && django-mongoengine 0.5.4 dont work with
django-4.1.3
---+--
 Reporter:  ata|Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Uncategorized  |  Version:  4.1
 Severity:  Normal |   Resolution:  invalid
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Mariusz Felisiak):

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


Comment:

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

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/010701847f9e261d-5dd5995f-329d-42b2-b04e-d10be40f101d-00%40eu-central-1.amazonses.com.

Re: [Django] #34164: django-graphql-auth 0.3.16 && django-mongoengine 0.5.4 dont work with django-4.1.3

[Django]

#34164: django-graphql-auth 0.3.16 && django-mongoengine 0.5.4 dont work with
django-4.1.3
---+--
 Reporter:  abdul060606|Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  4.1
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by abdul060606):

 * Attachment "2022-11-16 09_29_30-Window.png" added.

 error pip

-- 
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/010701847f96560b-55a51934-5bdb-4bec-a107-da1e62dc3f33-00%40eu-central-1.amazonses.com.

[Django] #34164: django-graphql-auth 0.3.16 && django-mongoengine 0.5.4 dont work with django-4.1.3

[Django]

#34164: django-graphql-auth 0.3.16 && django-mongoengine 0.5.4 dont work with
django-4.1.3
-+
   Reporter:  abdul060606|  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Uncategorized  |Version:  4.1
   Severity:  Normal |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 Hello,

 i get pip install error when I install django 4.1.3 even though I use the
 latest versions of django-graphql-auth and django-mongoengine. I dont have
 this problem with django 3.2.16.

 ERROR: pip's dependency resolver does not currently take into account all
 the packages that are installed. This behaviour is the source of the
 following dependency conflicts.
 django-mongoengine 0.5.4 requires Django<4.1,>3.1, but you have django
 4.1.3 which is incompatible.
 django-graphql-auth 0.3.16 requires django-graphql-jwt==0.3.0, but you
 have django-graphql-jwt 0.3.4 which is incompatible.
 django-graphql-auth 0.3.16 requires PyJWT<2.0.0, but you have pyjwt 2.6.0
 which is incompatible.


 Is this a known issue ?=

 Best regards

 Ata

-- 
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/010701847f95fca9-010b792d-8f1e-4bcf-98f5-38d10817d9a0-00%40eu-central-1.amazonses.com.