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

[Django]

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

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


Comment:

 In [changeset:"d6b6e5d0fd4e6b6d0183b4cf6e4bd4f9afc7bf67" d6b6e5d0]:
 {{{
 #!CommitTicketReference repository=""
 revision="d6b6e5d0fd4e6b6d0183b4cf6e4bd4f9afc7bf67"
 Fixed #28553 -- Fixed annotation mismatch with
 QuerySet.values()/values_list() on compound queries.

 Co-authored-by: Matthias Kestenholz 
 }}}

-- 
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/0107018712254d04-d64c0af5-cc3f-44e6-a6ea-5ed268a6dee9-00%40eu-central-1.amazonses.com.

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

[Django]

#34433: OneToOneField can only be saved one way
-+-
 Reporter:  Alexis Lesieur   |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  4.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak):

 > It's also problematic as foreigh keys work this way: (from my work
 example)

 That's not true, on foreign keys you also cannot assign to a **reverse**
 side.

 > `.save()` "fails" silently, there is no way to know that the change
 didn't take, especially when this happens:

 `save()` doesn't fail silently. By assigning an object to the
 `.restaurant` you override a lazy reverse side of `OneToOneField` to a
 "static" instance so it's not recognize as a relationship anymore.

-- 
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/010701871220bd42-3742e1a8-3227-4fe9-9b43-f4cc092d9eaf-00%40eu-central-1.amazonses.com.

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

[Django]

#34433: OneToOneField can only be saved one way
-+-
 Reporter:  Alexis Lesieur   |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  4.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * status:  new => closed
 * type:  Bug => New feature
 * resolution:   => duplicate


Comment:

 Duplicate of #18638. You can comment in the original ticket. If you don't
 agree with the decision made in #18638 please
 ​[https://docs.djangoproject.com/en/stable/internals/contributing
 /triaging-tickets/#closing-tickets ​follow triaging guidelines with
 regards to wontfix tickets].

-- 
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/01070187121a2fbf-fa1a3d95-2ed9-4066-9cfe-2add302b4690-00%40eu-central-1.amazonses.com.

Re: [Django] #18638: Reverse OneToOne relationship does not save properly.

[Django]

#18638: Reverse OneToOne relationship does not save properly.
-+-
 Reporter:  David Hatch  |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  1.4
  (models, ORM)  |
 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
-+-

Comment (by Mariusz Felisiak):

 #34433 was closed as a duplicate.

-- 
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/010701871219fe75-e177e849-476b-47c7-b219-a731efd9cf1f-00%40eu-central-1.amazonses.com.

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

[Django]

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

 * needs_better_patch:  1 => 0
 * needs_tests:  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/010701871212ead2-06b0055f-36ff-415d-a289-2c67cc1ace9c-00%40eu-central-1.amazonses.com.

Re: [Django] #28900: QuerySet.values() and values_list() for compound queries fails with annotation. (was: QuerySet.values() and values_list() for union(), difference(), and intersection() queries fai

[Django]

#28900: QuerySet.values() and values_list() for compound queries fails with
annotation.
-+-
 Reporter:  elliott-omosheye |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.11
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  union, values| Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * cc: David Wobrock (added)
 * status:  closed => new
 * resolution:  duplicate =>
 * stage:  Unreviewed => Accepted


Comment:

 We [https://github.com/django/django/pull/16649#issuecomment-1481387207
 decided] to treat it as a separate issue.

-- 
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/0107018711ff9952-6cfd7f7d-0353-40a1-9aee-71ffe24d72fe-00%40eu-central-1.amazonses.com.

Re: [Django] #34383: Layout error in Admin when using help_text

[Django]

#34383: Layout error in Admin when using help_text
-+-
 Reporter:  Antonio Candido  |Owner:  Tom
  Nazareth junior|  Carrick
 Type:  Bug  |   Status:  assigned
Component:  Template system  |  Version:  4.2
 Severity:  Release blocker  |   Resolution:
 Keywords:  help_text| 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):

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


Comment:

 [https://github.com/django/django/pull/16678 PR]

-- 
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/010701870ff1aca0-60deed87-e21c-4032-b5e9-7941b4732916-00%40eu-central-1.amazonses.com.

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

[Django]

#34434: psycopg 3 cursor.execute no longer accepts Python tuple binding
-+-
   Reporter:  David  |  Owner:  nobody
  Burke  |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  4.2
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 This may be a bug or a missing feature of psycopg 3. If expected, it may
 be worth mentioning as a breaking change when using psycopg3.

 The following Django code works with psycopg2. Notice the usage of a tuple
 with the "in" statement.

 cursor.execute("select 1 where 1 in %s", ((1,),)

 But in psycopg 3 it gives an error

 django.db.utils.ProgrammingError: syntax error at or near "'{1}'"
 LINE 1: select 1 where 1 in '{1}'::int2[]

 A fix is to use ANY with a list. It must specifically be a list and not a
 tuple.

 cursor.execute("select 1 where 1 = ANY(%s)", ([1],))

 With a tuple, we get the error

 django.db.utils.ProgrammingError: syntax error at or near "'(1)'"
 LINE 1: select 1 where 1 in '(1)'

 I would expect execute to treat a Python list and tuple the same when
 binding to a postgresql parameter. But this is not so.

-- 
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/010701870fee944c-1961dbd3-fa00-43e7-906f-43a0345cb450-00%40eu-central-1.amazonses.com.

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

[Django]

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

Old description:

> Hi!
> I encountered this unexpected (to me) behavior for work, and I have been
> able to replicate on a bare django app (albeit with slightly different
> symptoms).
>
> The TLDR is that is model A has a OneToOneField to model B. The field had
> to be saved from the instance of model A, and that's not only not
> documented anywhere I could find, but counter-intuitive, and contradicts
> how other fields like ForeignKeys work.
>
> **Setup:**
> {{{
> ❯ python --version
> Python 3.11.2
>
> ❯ pip freeze | grep -i django
> Django==4.1.7
>
> ❯ django-admin startproject mysite
>
> ❯ cd mysyte/
> ❯ django-admin startapp myapp
> ❯ vim myapp/models.py
> # partially re-using your example from
> https://docs.djangoproject.com/en/4.1/topics/db/examples/one_to_one/
> ```
> from django.db import models
>
> class Place(models.Model):
> name = models.CharField(max_length=50)
> address = models.CharField(max_length=80)
>
> def __str__(self):
> return "%s the place" % self.name
>
> class Restaurant(models.Model):
> place = models.OneToOneField(
> Place,
> on_delete=models.CASCADE,
> )
> serves_hot_dogs = models.BooleanField(default=False)
> serves_pizza = models.BooleanField(default=False)
>
> def __str__(self):
> return "%s the restaurant" % self.place.name
> ```
>
> ❯ vim mysite/settings.py
>
> [...]
> INSTALLED_APPS = [
> 'myapp.apps.MyappConfig',
> [...]
>
> ❯ python manage.py makemigrations
> ❯ python manage.py migrate
> }}}
>
> Creating the initial objects:
> {{{
> ❯ python manage.py shell
> ❯ from myapp.models import Place
> ❯ from myapp.models import Restaurant
>
> ❯ p1 = Place(name="1st place", address="1st address")
> ❯ p2 = Place(name="2nd place", address="2nd address")
> ❯ r1 = Restaurant(place=p1)
> ❯ r2 = Restaurant(place=p2)
> ❯ p1.save()
> ❯ p2.save()
> ❯ r1.save()
> ❯ r2.save()
> ❯ p3 = Place(name="3rd place", address="3rd address")
> ❯ p3.save()
> }}}
>
> This should give us a two restaurants with their respective places, and
> an additional place we can use to play.
>
> First, what works:
> {{{
> ❯ r1.place = p3
> ❯ r1.save()
>
> ❯ Restaurant.objects.get(id=1).place
> 
>
> ❯ p3.restaurant
> 
>
> ❯ Place.objects.get(id=1).restaurant
> [...]
> RelatedObjectDoesNotExist: Place has no restaurant.
> }}}
> This is all expected. `r1` now uses `p3`, which means that `p1` has no
> restaurant assigned.
>
> Now I would expect, to be able to do the other way. Assign a new
> restaurant to a place, save, and be all good.
> However that doesn't work.
> First using plain `.save()` which fails silently:
> {{{
> ❯ p1 = Place.objects.get(id=1)
> ❯ p1.restaurant = r1
> ❯ p1.save()
>
> ❯ Restaurant.objects.get(id=1).place
>   # this should be p1
> }}}
>
> And when explicitly asking to save the field:
> {{{
> ❯ p1.save(update_fields=["restaurant"])
> ❯ ValueError: The following fields do not exist in this model, are m2m
> fields, or are non-concrete fields: restaurant
> }}}
>
> NB: on my use case for work (django 3.2.18) I was also getting the
> following error:
> {{{
> UniqueViolation: duplicate key value violates unique constraint
> "response_timelineevent_pkey"
> DETAIL:  Key (id)=(91) already exists.
> }}}
> I'm not sure why it's different, but it doesn't work either way.
>
> This is problematic for a few reasons IMO:
> - Unless I missed it, the docs really don't advertise this limitation.
> - `.save()` "fails" silently, there is no way to know that the change
> didn't take, especially when this happens:
> {{{
> ❯ p1 = Place(name="1st place", address="1st address")
> ❯ p2 = Place(name="2nd place", address="2nd address")
> ❯ p3 = Place(name="3rd place", address="3rd address")
> ❯ p1.save()
> ❯ p2.save()
> ❯ p3.save()
> ❯ r1 = Restaurant(place=p1)
> ❯ r1.save()
> ❯ r2 = Restaurant(place=p2)
> ❯ r2.save()
>
> ❯ r1.place
> 
> ❯ p3.restaurant = r1
> ❯ r1.place
> 
> ❯ p3.save()
> ❯ Restaurant.objects.get(id=1).place
> 
> }}}
> which leads to thinking the change is working and affecting both objects,
> when it's not.
>
> It's also problematic as foreigh keys work this way: (from my 

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

[Django]

#34433: OneToOneField can only be saved one way
-+-
   Reporter:  Alexis |  Owner:  nobody
  Lesieur|
   Type:  Bug| Status:  new
  Component:  Database   |Version:  4.1
  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  |
-+-
 Hi!
 I encountered this unexpected (to me) behavior for work, and I have been
 able to replicate on a bare django app (albeit with slightly different
 symptoms).

 The TLDR is that is model A has a OneToOneField to model B. The field had
 to be saved from the instance of model A, and that's not only not
 documented anywhere I could find, but counter-intuitive, and contradicts
 how other fields like ForeignKeys work.

 **Setup:**
 {{{
 ❯ python --version
 Python 3.11.2

 ❯ pip freeze | grep -i django
 Django==4.1.7

 ❯ django-admin startproject mysite

 ❯ cd mysyte/
 ❯ django-admin startapp myapp
 ❯ vim myapp/models.py
 # partially re-using your example from
 https://docs.djangoproject.com/en/4.1/topics/db/examples/one_to_one/
 ```
 from django.db import models

 class Place(models.Model):
 name = models.CharField(max_length=50)
 address = models.CharField(max_length=80)

 def __str__(self):
 return "%s the place" % self.name

 class Restaurant(models.Model):
 place = models.OneToOneField(
 Place,
 on_delete=models.CASCADE,
 )
 serves_hot_dogs = models.BooleanField(default=False)
 serves_pizza = models.BooleanField(default=False)

 def __str__(self):
 return "%s the restaurant" % self.place.name
 ```

 ❯ vim mysite/settings.py

 [...]
 INSTALLED_APPS = [
 'myapp.apps.MyappConfig',
 [...]

 ❯ python manage.py makemigrations
 ❯ python manage.py migrate
 }}}

 Creating the initial objects:
 {{{
 ❯ python manage.py shell
 ❯ from myapp.models import Place
 ❯ from myapp.models import Restaurant

 ❯ p1 = Place(name="1st place", address="1st address")
 ❯ p2 = Place(name="2nd place", address="2nd address")
 ❯ r1 = Restaurant(place=p1)
 ❯ r2 = Restaurant(place=p2)
 ❯ p1.save()
 ❯ p2.save()
 ❯ r1.save()
 ❯ r2.save()
 ❯ p3 = Place(name="3rd place", address="3rd address")
 ❯ p3.save()
 }}}

 This should give us a two restaurants with their respective places, and an
 additional place we can use to play.

 First, what works:
 {{{
 ❯ r1.place = p3
 ❯ r1.save()

 ❯ Restaurant.objects.get(id=1).place
 

 ❯ p3.restaurant
 

 ❯ Place.objects.get(id=1).restaurant
 [...]
 RelatedObjectDoesNotExist: Place has no restaurant.
 }}}
 This is all expected. `r1` now uses `p3`, which means that `p1` has no
 restaurant assigned.

 Now I would expect, to be able to do the other way. Assign a new
 restaurant to a place, save, and be all good.
 However that doesn't work.
 First using plain `.save()` which fails silently:
 {{{
 ❯ p1 = Place.objects.get(id=1)
 ❯ p1.restaurant = r1
 ❯ p1.save()

 ❯ Restaurant.objects.get(id=1).place
   # this should be p1
 }}}

 And when explicitly asking to save the field:
 {{{
 ❯ p1.save(update_fields=["restaurant"])
 ❯ ValueError: The following fields do not exist in this model, are m2m
 fields, or are non-concrete fields: restaurant
 }}}

 NB: on my use case for work (django 3.2.18) I was also getting the
 following error:
 {{{
 UniqueViolation: duplicate key value violates unique constraint
 "response_timelineevent_pkey"
 DETAIL:  Key (id)=(91) already exists.
 }}}
 I'm not sure why it's different, but it doesn't work either way.

 This is problematic for a few reasons IMO:
 - Unless I missed it, the docs really don't advertise this limitation.
 - `.save()` "fails" silently, there is no way to know that the change
 didn't take, especially when this happens:
 {{{
 ❯ p1 = Place(name="1st place", address="1st address")
 ❯ p2 = Place(name="2nd place", address="2nd address")
 ❯ p3 = Place(name="3rd place", address="3rd address")
 ❯ p1.save()
 ❯ p2.save()
 ❯ p3.save()
 ❯ r1 = Restaurant(place=p1)
 ❯ r1.save()
 ❯ r2 = Restaurant(place=p2)
 ❯ r2.save()

 ❯ r1.place
 
 ❯ p3.restaurant = r1
 ❯ r1.place
 
 ❯ p3.save()
 ❯ Restaurant.objects.get(id=1).place
 
 }}}
 which leads to thinking the change is working and affecting both objects,
 when it's not.

 It's also problematic as foreigh keys work this way: (from my work
 example)
 {{{
 ❯ me = ExternalUser.objects.get(id=1)
 ❯ other = ExternalUser.objects.get(id=2)
 ❯ p = PinnedMessage.objects.get(id=11)

 ❯ p.author
   # i.e. `me`

 ❯ [p.id for p in me.authored_pinnedmessage.all()]
 [1, 3, 5, 11]

 ❯ p.author = other
 ❯ p.save()

 ❯ [p.id for p 

Re: [Django] #34432: autoreloader does not reload when a Thread is running and there is no way to notify the Thread to stop

[Django]

#34432: autoreloader does not reload when a Thread is running and there is no 
way
to notify the Thread to stop
---+--
 Reporter:  David Greaves  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Utilities  |  Version:  4.1
 Severity:  Normal |   Resolution:  needsinfo
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--
Changes (by Carlton Gibson):

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


Comment:

 Closing pending the [https://forum.djangoproject.com/t/id-like-to-add-an-
 autoreload-stopping-signal-to-the-autloloader/19741 discussion on forum].

-- 
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/010701870e9f03eb-cda29833-8539-406f-bb51-08e7f8d0bd8c-00%40eu-central-1.amazonses.com.

[Django] #34432: autoreloader does not reload when a Thread is running and there is no way to notify the Thread to stop

[Django]

#34432: autoreloader does not reload when a Thread is running and there is no 
way
to notify the Thread to stop
-+
   Reporter:  David Greaves  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Utilities  |Version:  4.1
   Severity:  Normal |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+
 A running Thread prevents the autoloader from restarting.

 Follow page 1 of the tutorial to create a polls app.
 Add 'polls.apps.PollsConfig' to  INSTALLED_APPS

 Use this minimal apps.py in mysite/polls/:
 {{{
 import logging
 import threading
 import os
 from django.apps import AppConfig


 class PollsConfig(AppConfig):
 default_auto_field = 'django.db.models.BigAutoField'
 name = 'polls'

 def ready(self):
 logging.warning("In polls.ready")

 if os.environ.get("RUN_MAIN") == "true":
 logging.warning("Starting Thread")
 ev = threading.Event()
 self._thread = threading.Thread(target=ev.wait)
 self._thread.start()
 def stopper(**kwargs):  # receiver needs **kwargs
 logging.warning("Stopping the Thread")
 ev.set()
 try:
 from django.utils.autoreload import autoreload_stopping
 autoreload_stopping.connect(stopper)
 except ImportError:
 pass
 }}}
 run python manage.py runserver

 make a change to apps.py

 Result is that runserver hangs like so:

 {{{
 Quit the server with CONTROL-C.
 /everything/devel/ad-hoc/django/mysite/polls/apps.py changed, reloading.
 INFO:django.utils.autoreload:/everything/devel/ad-
 hoc/django/mysite/polls/apps.py changed, reloading.
 }}}

 Apply patch:

 
https://github.com/django/django/pull/16674/commits/c07a1f35ac7bec04243f10a90df52e9ed0b77d0b

 Result is correct reloading:
 {{{
 Quit the server with CONTROL-C.
 /everything/devel/ad-hoc/django/mysite/polls/apps.py changed, reloading.
 INFO:django.utils.autoreload:/everything/devel/ad-
 hoc/django/mysite/polls/apps.py changed, reloading.
 WARNING:root:Stopping the Thread
 WARNING:root:In polls.ready
 WARNING:root:Starting Thread
 Watching for file changes with StatReloader
 INFO:django.utils.autoreload:Watching for file changes with StatReloader
 }}}

 This bug is real and is intended to facilitate discussion of the 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/010701870e61e2da-67bfbd1f-8f65-437b-a1ff-34ee542c304a-00%40eu-central-1.amazonses.com.

Re: [Django] #34383: Layout error in Admin when using help_text

[Django]

#34383: Layout error in Admin when using help_text
-+-
 Reporter:  Antonio Candido  |Owner:  Tom
  Nazareth junior|  Carrick
 Type:  Bug  |   Status:  assigned
Component:  Template system  |  Version:  4.2
 Severity:  Release blocker  |   Resolution:
 Keywords:  help_text| Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tom Carrick):

 * owner:  nobody => Tom Carrick
 * 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/010701870e345645-2322971f-3b96-4df0-aea6-d07120748e3a-00%40eu-central-1.amazonses.com.

Re: [Django] #34429: Allow to set unusable password via admin UI

[Django]

#34429: Allow to set unusable password via admin UI
-+
 Reporter:  Tobias Bengfort  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  contrib.auth |  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):

 * cc: Carlton Gibson, Sarah Boyce (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/010701870e068041-9a5eba10-4f97-4925-b728-22b35e55e32a-00%40eu-central-1.amazonses.com.

Re: [Django] #34429: Allow to set unusable password via admin UI

[Django]

#34429: Allow to set unusable password via admin UI
-+
 Reporter:  Tobias Bengfort  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  contrib.auth |  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):

 * version:  4.1 => dev
 * stage:  Unreviewed => Accepted


Comment:

 Thanks for the ticket. I agree that it would nice to add an option to
 create users with an unusable password in the admin, however, any implicit
 logic can be confusing here (see
 [https://code.djangoproject.com/ticket/4170#comment:4 comment]).
 Therefore, I'm not in favor of your proposal to:
 > ''... make the password fields optional in the Admin UI and set an
 unusable password if they are blank.''

 Maybe a checkbox in the "Add user" form e.g. ''"Usable password"''
 (checked by default) that would hide password fields when unchecked 樂, or
 sth similar.

 Tentatively 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/010701870e064a9b-9915c56b-030c-4261-bab3-e815f684b745-00%40eu-central-1.amazonses.com.

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

[Django]

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

Comment (by Mariusz Felisiak ):

 In [changeset:"b85dd83194878cb520f1cb152db4e5f524ffbcf0" b85dd83]:
 {{{
 #!CommitTicketReference repository=""
 revision="b85dd83194878cb520f1cb152db4e5f524ffbcf0"
 [4.2.x] Refs #34316 -- Fixed displaying error lists in admin password
 change forms on small screens.

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

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/010701870ddb5d9d-599a1e2b-33d6-49ed-9eb8-ffae0133dc5f-00%40eu-central-1.amazonses.com.

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

[Django]

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

Comment (by GitHub ):

 In [changeset:"39d1e45227e060746ed461fddde80fa2b6cf0dcd" 39d1e45]:
 {{{
 #!CommitTicketReference repository=""
 revision="39d1e45227e060746ed461fddde80fa2b6cf0dcd"
 Refs #34316 -- Fixed displaying error lists in admin password change forms
 on small screens.

 Follow up to e67804668115fd388e7554c6a809bd409f70adfe.
 }}}

-- 
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/010701870ddabadc-9936158e-215a-4dc4-bd64-69e273346bd5-00%40eu-central-1.amazonses.com.

Re: [Django] #33781: Timezone warning visual regression.

[Django]

#33781: Timezone warning visual regression.
-+-
 Reporter:  Mariusz Felisiak |Owner:  Carlton
 |  Gibson
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  dev
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"12561b70212cfc8035e4ea7c05bf23ca468d96a3" 12561b70]:
 {{{
 #!CommitTicketReference repository=""
 revision="12561b70212cfc8035e4ea7c05bf23ca468d96a3"
 [4.2.x] Refs #33781 -- Restored alignment for admin split-field timezone
 warnings for RTL languages.

 Regression in f3e2bb0833105f43efc0cc6f19c8465bc1b1a785.
 Backport of 73ae8545ae620469550f1adcfe63fb9b9e4f3eb3 from main
 }}}

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/010701870dd14956-739b6101-83b3-4d86-9746-8f8fe06f24d2-00%40eu-central-1.amazonses.com.

Re: [Django] #33781: Timezone warning visual regression.

[Django]

#33781: Timezone warning visual regression.
-+-
 Reporter:  Mariusz Felisiak |Owner:  Carlton
 |  Gibson
 Type:  Bug  |   Status:  closed
Component:  contrib.admin|  Version:  dev
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-

Comment (by GitHub ):

 In [changeset:"73ae8545ae620469550f1adcfe63fb9b9e4f3eb3" 73ae854]:
 {{{
 #!CommitTicketReference repository=""
 revision="73ae8545ae620469550f1adcfe63fb9b9e4f3eb3"
 Refs #33781 -- Restored alignment for admin split-field timezone warnings
 for RTL languages.

 Regression in f3e2bb0833105f43efc0cc6f19c8465bc1b1a785.
 }}}

-- 
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/010701870dd0f97f-1468b0ba-5067-48f8-a322-0240dc246e0c-00%40eu-central-1.amazonses.com.

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

[Django]

#34431: DateTimeField.input_formats change from Django 3.1 is documented 
improperly
-+
   Reporter:  stefan6419846  |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Uncategorized  |Version:  3.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:  0  |
-+
 In
 
https://github.com/django/django/commit/188b003014dc727ca22f7fafb21cf2fa0b3472d2,
 `django.forms.fields.DateTimeField.input_formats` has been changed to be a
 generator instead of the previous list. This type change does not seem to
 have been documented anywhere, leading to unexpected errors during
 migration and does not match the type of the `input_formats` for the other
 datetime-related fields.

-- 
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/010701870d98b948-1f55451a-888c-4bb7-b541-6f2f33ff4281-00%40eu-central-1.amazonses.com.

Re: [Django] #28384: ModelAdmin.lookup_allowed() incorrectly raises DisallowedModelAdminLookup lookup with foreign key as primary key

[Django]

#28384: ModelAdmin.lookup_allowed() incorrectly raises 
DisallowedModelAdminLookup
lookup with foreign key as primary key
--+---
 Reporter:  elliott-omosheye  |Owner:  Sarah Boyce
 Type:  Bug   |   Status:  assigned
Component:  contrib.admin |  Version:  1.11
 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 Sarah Boyce):

 * needs_better_patch:  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/010701870d272ee2-8e9fc952-eab5-4263-b54f-672d2fedecf3-00%40eu-central-1.amazonses.com.