Re: [Django] #32360: Add system check that FILE_UPLOAD_TEMP_DIR exists when set

2021-01-20 Thread Django
#32360: Add system check that FILE_UPLOAD_TEMP_DIR exists when set
-+-
 Reporter:  Tim McCurrach|Owner:  Tim
 Type:   |  McCurrach
  Cleanup/optimization   |   Status:  assigned
Component:  Core (Other) |  Version:  4.0
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by 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/071.e79705c6ea851e7b2be4a64836a607b9%40djangoproject.com.


Re: [Django] #32374: Migrations are marked applied even if deferred SQL fails to execute

2021-01-20 Thread Django
#32374: Migrations are marked applied even if deferred SQL fails to execute
+--
 Reporter:  Simon Charette  |Owner:  Simon Charette
 Type:  Bug |   Status:  closed
Component:  Migrations  |  Version:  2.2
 Severity:  Normal  |   Resolution:  fixed
 Keywords:  | Triage Stage:  Accepted
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:"6520ce5251e7d63d08bf965e5ca00e508f8a8613" 6520ce5]:
 {{{
 #!CommitTicketReference repository=""
 revision="6520ce5251e7d63d08bf965e5ca00e508f8a8613"
 [3.2.x] Fixed #32374 -- Stopped recording migration application before
 deferred SQL.

 Migrations cannot be recorded in the same transaction as its associated
 DDL operations when some of it is deferred until the schema editor
 context exits.

 Regression in c86a3d80a25acd1887319198ca21a84c451014ad.

 Backport of 0c42cdf0d2422f4c080e93594d5d15381d6e955e from master
 }}}

-- 
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/067.5105d69e177054d17ef1dce90903c0b1%40djangoproject.com.


Re: [Django] #29721: Migrations are not applied atomically

2021-01-20 Thread Django
#29721: Migrations are not applied atomically
+-
 Reporter:  Gavin Wahl  |Owner:  Sanyam Khurana
 Type:  Bug |   Status:  closed
Component:  Migrations  |  Version:  2.1
 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 Mariusz Felisiak ):

 In [changeset:"900b2ce92bd68fb4b17e923cffdbde30eb24f7d2" 900b2ce9]:
 {{{
 #!CommitTicketReference repository=""
 revision="900b2ce92bd68fb4b17e923cffdbde30eb24f7d2"
 [3.2.x] Refs #29721 -- Simplified migration used to test atomic recording.

 This makes sure atomic recording of migration application is used when
 the schema editor doesn't defer any statement.

 Backport of 533a5835784b95335c8373b6d0b9495b3834e96e from master
 }}}

-- 
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/067.ae1b03cae7cc76a308715bf983cfc6be%40djangoproject.com.


Re: [Django] #29721: Migrations are not applied atomically

2021-01-20 Thread Django
#29721: Migrations are not applied atomically
+-
 Reporter:  Gavin Wahl  |Owner:  Sanyam Khurana
 Type:  Bug |   Status:  closed
Component:  Migrations  |  Version:  2.1
 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 Mariusz Felisiak ):

 In [changeset:"533a5835784b95335c8373b6d0b9495b3834e96e" 533a583]:
 {{{
 #!CommitTicketReference repository=""
 revision="533a5835784b95335c8373b6d0b9495b3834e96e"
 Refs #29721 -- Simplified migration used to test atomic recording.

 This makes sure atomic recording of migration application is used when
 the schema editor doesn't defer any statement.
 }}}

-- 
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/067.d1eb0a8b018202b1ba17b142a279ae5c%40djangoproject.com.


Re: [Django] #32374: Migrations are marked applied even if deferred SQL fails to execute

2021-01-20 Thread Django
#32374: Migrations are marked applied even if deferred SQL fails to execute
+--
 Reporter:  Simon Charette  |Owner:  Simon Charette
 Type:  Bug |   Status:  closed
Component:  Migrations  |  Version:  2.2
 Severity:  Normal  |   Resolution:  fixed
 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 Mariusz Felisiak ):

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


Comment:

 In [changeset:"0c42cdf0d2422f4c080e93594d5d15381d6e955e" 0c42cdf0]:
 {{{
 #!CommitTicketReference repository=""
 revision="0c42cdf0d2422f4c080e93594d5d15381d6e955e"
 Fixed #32374 -- Stopped recording migration application before deferred
 SQL.

 Migrations cannot be recorded in the same transaction as its associated
 DDL operations when some of it is deferred until the schema editor
 context exits.

 Regression in c86a3d80a25acd1887319198ca21a84c451014ad.
 }}}

-- 
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/067.dae91fdc36fdc075686465ff4b084ae3%40djangoproject.com.


Re: [Django] #32372: Improve consistency in "Related objects reference" docs. (was: Clarification of "RelatedManager" class example)

2021-01-20 Thread Django
#32372: Improve consistency in "Related objects reference" docs.
--+
 Reporter:  Jack  |Owner:  Jack
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Documentation |  Version:  3.1
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by Mariusz Felisiak):

 * owner:  nobody => Jack
 * status:  new => assigned
 * easy:  0 => 1
 * stage:  Unreviewed => Accepted


Comment:

 Examples in this page use reverse relation for a `ForeignKey` not a
 `ManyToManyField`, so the be more consistent we could change change the
 `Reporter - Article` example to
 [https://docs.djangoproject.com/en/3.1/topics/db/queries/#making-queries
 Blog - Entry], e.g.:
 {{{
 class Blog(models.Model):
 # ...
 pass

 class Entry(models.Model):
 blog = models.ForeignKey(Entry, on_delete=models.CASCADE)
 }}}

-- 
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/068.79351e09689d6d216120605d6ee1ec6e%40djangoproject.com.


Re: [Django] #32373: Broken translations since the introduction of TranslationCatalog

2021-01-20 Thread Django
#32373: Broken translations since the introduction of TranslationCatalog
-+-
 Reporter:  Hristo Gatsinski |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:   |  Version:  master
  Internationalization   |
 Severity:  Normal   |   Resolution:
 Keywords:  translations | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * cc: Claude Paroz, Carlton Gibson (added)
 * easy:  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/067.64b26a91e0e34442c571d1728fa72931%40djangoproject.com.


Re: [Django] #32374: Migrations are marked applied even if deferred SQL fails to execute

2021-01-20 Thread Django
#32374: Migrations are marked applied even if deferred SQL fails to execute
+--
 Reporter:  Simon Charette  |Owner:  Simon Charette
 Type:  Bug |   Status:  assigned
Component:  Migrations  |  Version:  2.2
 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 Mariusz Felisiak):

 * owner:  nobody => Simon Charette
 * stage:  Unreviewed => Accepted


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.c853a8c375a84970ca36fbe46621cde5%40djangoproject.com.


Re: [Django] #32374: Migrations are marked applied even if deferred SQL fails to execute

2021-01-20 Thread Django
#32374: Migrations are marked applied even if deferred SQL fails to execute
+--
 Reporter:  Simon Charette  |Owner:  nobody
 Type:  Bug |   Status:  assigned
Component:  Migrations  |  Version:  2.2
 Severity:  Normal  |   Resolution:
 Keywords:  | Triage Stage:  Unreviewed
Has patch:  1   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--
Changes (by Simon Charette):

 * has_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/067.3688f5abdab9217111408635bad8f099%40djangoproject.com.


[Django] #32374: Migrations are marked applied even if deferred SQL fails to execute

2021-01-20 Thread Django
#32374: Migrations are marked applied even if deferred SQL fails to execute
--+--
   Reporter:  Simon Charette  |  Owner:  nobody
   Type:  Bug | Status:  assigned
  Component:  Migrations  |Version:  2.2
   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   |
--+--
 The changes introduced in c86a3d80a25acd1887319198ca21a84c451014ad to
 address #29721 fail to account for the possibility of the schema editor
 accumulation of deferred SQL which is run at `SchemaEditor.__exit__` time.

-- 
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/052.6dc2a73080fc5189d6c044a32367f613%40djangoproject.com.


Re: [Django] #32373: Broken translations since the introduction of TranslationCatalog

2021-01-20 Thread Django
#32373: Broken translations since the introduction of TranslationCatalog
-+-
 Reporter:  gatsinski|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:   |  Version:  master
  Internationalization   |
 Severity:  Normal   |   Resolution:
 Keywords:  translations | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Description changed by gatsinski:

Old description:

> I recently updated one of my projects from the latest patch version of
> 2.2 to 3.1 and noticed that one of the translations is broken. When I
> translate "All" to Bulgarian it should output "Всичко" but instead, I get
> "Все" which I believe is in Russian. The PO files in Django are correct,
> and I have the same string translated in my project too. Both with the
> correct msgstr.
>
> I managed to track the issue to the introduction of TranslationCatalog in
> 3.0.5 in this commit:
>
> https://github.com/django/django/commit/d9f1792c7649e9f946f4a3a35a76bddf5a412b8b
>
> Replacing _catalog from TranslationCatalog() to normal Python dict (as it
> used to be in 3.0.4 and prior) resolves the issue.
>
> The issue continues to exist in the latest 3.1 and the pre-release 3.2a1.
>
> I use Linux Mint 20.1 based on Ubuntu 20.04. For a while I suspected
> gettext. The last version available via apt is 0.19.8.1 but I also
> installed the latest from source (0.21). The issue still exists.
>
> The bug is easy to reproduce.
>
> Enter the shell of any project with Django 3.0.4 and older and execute
> the following:
>
> from django.utils import translation
> translation.activate('bg')
> translation.gettext('All')
>
> You will see "Всичко".
>
> Do the same with Django 3.0.5 and above and you will get "Все" which is
> an incorrect translation.
>
> I failed to find an existing ticket describing this problem. Forgive me
> if there is one already.

New description:

 I recently updated one of my projects from the latest patch version of 2.2
 to 3.1 and noticed that one of the translations is broken. When I
 translate "All" to Bulgarian it should output "Всичко" but instead, I get
 "Все" which I believe is in Russian. The PO files in Django are correct,
 and I have the same string translated in my project too. Both with the
 correct msgstr.

 I managed to track the issue to the introduction of TranslationCatalog in
 3.0.5 in this commit:

 
https://github.com/django/django/commit/d9f1792c7649e9f946f4a3a35a76bddf5a412b8b

 Replacing _catalog from TranslationCatalog() to normal Python dict (as it
 used to be in 3.0.4 and prior) resolves the issue.

 The issue continues to exist in the latest 3.1 and the pre-release 3.2a1.

 I use Linux Mint 20.1 based on Ubuntu 20.04. For a while I suspected
 gettext. The last version available via apt is 0.19.8.1 but I also
 installed the latest from source (0.21). The issue still exists.

 The bug is easy to reproduce.

 Enter the shell of any project with Django 3.0.4 and older and execute the
 following:

 from django.utils import translation
 translation.activate('bg')
 translation.gettext('All')

 You will see "Всичко".

 Do the same with Django 3.0.5 and above and you will get "Все" which is an
 incorrect translation. It doesn't matter if you are using gettext,
 ugettext, ugettext_lazy, etc.

 I failed to find an existing ticket describing this problem. Forgive me if
 there is one already.

--

-- 
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/067.e5be939db8d4aa579f4b38f45c2d9af8%40djangoproject.com.


[Django] #32373: Broken translations since the introduction of TranslationCatalog

2021-01-20 Thread Django
#32373: Broken translations since the introduction of TranslationCatalog
-+-
   Reporter:  gatsinski  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component: |Version:  master
  Internationalization   |
   Severity:  Normal |   Keywords:  translations
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+-
 I recently updated one of my projects from the latest patch version of 2.2
 to 3.1 and noticed that one of the translations is broken. When I
 translate "All" to Bulgarian it should output "Всичко" but instead, I get
 "Все" which I believe is in Russian. The PO files in Django are correct,
 and I have the same string translated in my project too. Both with the
 correct msgstr.

 I managed to track the issue to the introduction of TranslationCatalog in
 3.0.5 in this commit:

 
https://github.com/django/django/commit/d9f1792c7649e9f946f4a3a35a76bddf5a412b8b

 Replacing _catalog from TranslationCatalog() to normal Python dict (as it
 used to be in 3.0.4 and prior) resolves the issue.

 The issue continues to exist in the latest 3.1 and the pre-release 3.2a1.

 I use Linux Mint 20.1 based on Ubuntu 20.04. For a while I suspected
 gettext. The last version available via apt is 0.19.8.1 but I also
 installed the latest from source (0.21). The issue still exists.

 The bug is easy to reproduce.

 Enter the shell of any project with Django 3.0.4 and older and execute the
 following:

 from django.utils import translation
 translation.activate('bg')
 translation.gettext('All')

 You will see "Всичко".

 Do the same with Django 3.0.5 and above and you will get "Все" which is an
 incorrect translation.

 I failed to find an existing ticket describing this problem. Forgive me if
 there is one already.

-- 
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/052.e66b9fa2943f13ff74d26e5feb032d04%40djangoproject.com.


Re: [Django] #32371: Document thje jquery.init.js dependency for admin widgets

2021-01-20 Thread Django
#32371: Document thje jquery.init.js dependency for admin widgets
-+-
 Reporter:  Matthias Kestenholz  |Owner:  Matthias
 Type:   |  Kestenholz
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  3.1
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
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:"2a74248ecab64af6b899c14940fac44b1e8a15bb" 2a74248e]:
 {{{
 #!CommitTicketReference repository=""
 revision="2a74248ecab64af6b899c14940fac44b1e8a15bb"
 [3.1.x] Fixed #32371 -- Doc'd jquery.init.js dependency for admin widgets.

 Backport of 7b3ec6bcc8309d5b2003d355fe6f78af89cfeb52 from master
 }}}

-- 
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/067.df8e8b82f1113c509ce8d28ed08bee18%40djangoproject.com.


Re: [Django] #32371: Document thje jquery.init.js dependency for admin widgets

2021-01-20 Thread Django
#32371: Document thje jquery.init.js dependency for admin widgets
-+-
 Reporter:  Matthias Kestenholz  |Owner:  Matthias
 Type:   |  Kestenholz
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  3.1
 Severity:  Normal   |   Resolution:  fixed
 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 Mariusz Felisiak ):

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


Comment:

 In [changeset:"7b3ec6bcc8309d5b2003d355fe6f78af89cfeb52" 7b3ec6b]:
 {{{
 #!CommitTicketReference repository=""
 revision="7b3ec6bcc8309d5b2003d355fe6f78af89cfeb52"
 Fixed #32371 -- Doc'd jquery.init.js dependency for admin widgets.
 }}}

-- 
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/067.d0d7df31f75d0debd0689b52ad679fca%40djangoproject.com.


Re: [Django] #32371: Document thje jquery.init.js dependency for admin widgets

2021-01-20 Thread Django
#32371: Document thje jquery.init.js dependency for admin widgets
-+-
 Reporter:  Matthias Kestenholz  |Owner:  Matthias
 Type:   |  Kestenholz
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  3.1
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
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:"41405a0b8e527e9eef18c8dd1170932c3d585186" 41405a0b]:
 {{{
 #!CommitTicketReference repository=""
 revision="41405a0b8e527e9eef18c8dd1170932c3d585186"
 [3.2.x] Fixed #32371 -- Doc'd jquery.init.js dependency for admin widgets.

 Backport of 7b3ec6bcc8309d5b2003d355fe6f78af89cfeb52 from master
 }}}

-- 
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/067.8e44a7b4fe6aa9617cbbb5c00e4cdfee%40djangoproject.com.


Re: [Django] #29606: Validate the type of ALLOWED_HOSTS

2021-01-20 Thread Django
#29606: Validate the type of ALLOWED_HOSTS
-+-
 Reporter:  rafis|Owner:  Octavio
 |  Peri
 Type:  New feature  |   Status:  assigned
Component:  Core (System |  Version:  master
  checks)|
 Severity:  Normal   |   Resolution:
 Keywords:  allowed_hosts| Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Adam Johnson):

 See the PR linked in comment #1 for an intial implementation.

-- 
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/063.776ee1c4a65bcf6d239109c73e371963%40djangoproject.com.


Re: [Django] #32360: Add system check that FILE_UPLOAD_TEMP_DIR exists when set

2021-01-20 Thread Django
#32360: Add system check that FILE_UPLOAD_TEMP_DIR exists when set
-+-
 Reporter:  Tim McCurrach|Owner:  Tim
 Type:   |  McCurrach
  Cleanup/optimization   |   Status:  assigned
Component:  Core (Other) |  Version:  4.0
 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 Tim McCurrach):

 * has_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/071.09232983d6d9b83de81c4327daee6f0f%40djangoproject.com.


Re: [Django] #29606: Validate the type of ALLOWED_HOSTS

2021-01-20 Thread Django
#29606: Validate the type of ALLOWED_HOSTS
-+-
 Reporter:  rafis|Owner:  Octavio
 |  Peri
 Type:  New feature  |   Status:  assigned
Component:  Core (System |  Version:  master
  checks)|
 Severity:  Normal   |   Resolution:
 Keywords:  allowed_hosts| Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Marius Räsener):

 ok, so here's what I came up with for the check:
 {{{
 def check_allowedhosts(ALLOWED_HOSTS):
 if isinstance(ALLOWED_HOSTS,(list,tuple)):
 return all(isinstance(element,str) for element in ALLOWED_HOSTS)
 else:
 return False
 }}}
 sadly in this case `all([])` returns True so the if else statement is
 needed I think ... but of course I'm happy to get hints for a better
 implementation.

 Besides, where would I put the check and the test?

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.8f3728da3e8cab820a00afe92410908b%40djangoproject.com.


Re: [Django] #32371: Document thje jquery.init.js dependency for admin widgets

2021-01-20 Thread Django
#32371: Document thje jquery.init.js dependency for admin widgets
-+-
 Reporter:  Matthias Kestenholz  |Owner:  Matthias
 Type:   |  Kestenholz
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  3.1
 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 Mariusz Felisiak):

 * component:  contrib.admin => Documentation
 * stage:  Unreviewed => Accepted


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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.e058895c1053cd94a820729e735b3a42%40djangoproject.com.


Re: [Django] #32372: Clarification of "RelatedManager" class example

2021-01-20 Thread Django
#32372: Clarification of "RelatedManager" class example
-+-
 Reporter:  Jack |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  Version:  3.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 Jack):

 * type:  Uncategorized => Cleanup/optimization


-- 
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/068.deb6c6469e8806fecd110ba3487e8583%40djangoproject.com.


[Django] #32372: Clarification of "RelatedManager" class example

2021-01-20 Thread Django
#32372: Clarification of "RelatedManager" class example
-+
   Reporter:  Jack   |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Documentation  |Version:  3.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  |
-+
 I have a suggested clarification in the docs, under the "Related objects
 reference" section:
 [https://docs.djangoproject.com/en/3.1/ref/models/relations/].

 One of the first examples of a ManyToMany field relationship begins with
 an example of a Pizza model and a Toppings model, but in the shell example
 below it demonstrates this relationship with two different models: a Blog
 model and an Entry model.

 I've read through this section a few times so I apologize in advance if
 I'm incorrect in my understanding, but in my opinion it would be clearer
 to stick with one set of classes for both the examples. If choosing to
 continue with the Pizza and Toppings example, I would suggest changing the
 example shown in the shell as follows:

 {{{
 >>> t = Topping.objects.get(id=1)
 >>> p = Pizza.objects.get(id=5)
 >>> t.pizza_set.add(p) # Associates Topping t with Pizza p.
 }}}


 If this is agreeable, I would love to make this change.

-- 
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/053.3162e4f65553a9ef6368e320db83cf5c%40djangoproject.com.


Re: [Django] #29606: Validate the type of ALLOWED_HOSTS

2021-01-20 Thread Django
#29606: Validate the type of ALLOWED_HOSTS
-+-
 Reporter:  rafis|Owner:  Octavio
 |  Peri
 Type:  New feature  |   Status:  assigned
Component:  Core (System |  Version:  master
  checks)|
 Severity:  Normal   |   Resolution:
 Keywords:  allowed_hosts| Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Adam Johnson):

 The validation basically only needs to check it's an iterable of strings.

 Checking that everything looks like a hostname is very complicated - we
 also support wildcards. And it would probably break for someone out there
 using a proxy server or middleware that adds something not-quite-host-
 looking in the Host header.

-- 
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/063.f3b5575e84c223d9b1072774fd52108b%40djangoproject.com.


[Django] #32371: Document thje jquery.init.js dependency for admin widgets

2021-01-20 Thread Django
#32371: Document thje jquery.init.js dependency for admin widgets
-+-
   Reporter:  Matthias   |  Owner:  Matthias Kestenholz
  Kestenholz |
   Type: | Status:  assigned
  Cleanup/optimization   |
  Component: |Version:  3.1
  contrib.admin  |
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  1
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 [https://github.com/django/django/pull/13893 PR]

 Until now this was only documented in the 2.2 release notes. See
 https://github.com/django/django/commit/418263c4576

 I think it's worth it documenting this so people can rely on this.

-- 
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/052.64ba75495af5ff33922d9843edaacef0%40djangoproject.com.


Re: [Django] #29606: Validate the type of ALLOWED_HOSTS

2021-01-20 Thread Django
#29606: Validate the type of ALLOWED_HOSTS
-+-
 Reporter:  rafis|Owner:  Octavio
 |  Peri
 Type:  New feature  |   Status:  assigned
Component:  Core (System |  Version:  master
  checks)|
 Severity:  Normal   |   Resolution:
 Keywords:  allowed_hosts| Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Marius Räsener):

 Wouldn't it be best to check if the entries in `ALLOWED_HOSTS` are
 actually valid hosts?
 So either IPv4/IPv6 Addresses or some dot separated string with valid
 characters.

 Maybe I didn't understand how the bug appeared. Or was it something like:
 {{{
 # wrong
 ALLOWED_HOSTS="127.0.0.1"
 }}}
 vs.
 {{{
 ALLOWED_HOSTS=["127.0.0.1",]
 }}}
 also, doesn't work a tuple too?

 thx for any hints giving me a better understanding...

-- 
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/063.c1151a84dce450d524ecee51bd9e2468%40djangoproject.com.


Re: [Django] #32292: Allow postgresql database connections to use postgres services

2021-01-20 Thread Django
#32292: Allow postgresql database connections to use postgres services
-+-
 Reporter:  levihb   |Owner:  Hasan
 |  Ramezani
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  database postgresql  | Triage Stage:  Ready for
  postgres service pg_service|  checkin
  config |
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:"dcb3ad3319cad5c270a1856fd5f355e37cf9d474" dcb3ad33]:
 {{{
 #!CommitTicketReference repository=""
 revision="dcb3ad3319cad5c270a1856fd5f355e37cf9d474"
 Fixed #32292 -- Added support for connection by service name to
 PostgreSQL.
 }}}

-- 
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/064.2c06bd7c6c1ec061d3b52d7a2840469f%40djangoproject.com.


Re: [Django] #17664: {% if %} template tag silences exceptions inconsistently

2021-01-20 Thread Django
#17664: {% if %} template tag silences exceptions inconsistently
-+-
 Reporter:  Tai Lee  |Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  smart if tag | Triage Stage:  Accepted
  queryset exception silenced|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * owner:  Robert Roskam => (none)
 * status:  assigned => new


-- 
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/067.76cc10a54c23ccc5e4d58b9cde0a4672%40djangoproject.com.


Re: [Django] #17664: {% if %} template tag silences exceptions inconsistently

2021-01-20 Thread Django
#17664: {% if %} template tag silences exceptions inconsistently
-+-
 Reporter:  Tai Lee  |Owner:  Robert
 |  Roskam
 Type:  Bug  |   Status:  assigned
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  smart if tag | Triage Stage:  Accepted
  queryset exception silenced|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * has_patch:  1 => 0


Comment:

 OK, I finally got the time to get back to this. Reviewing again, I still
 can't see that we can introduce the radical breaking change. Limited
 raising of exceptions that don't reasonably pertain to variable resolution
 seems as far as we can go. I'll close the suggested PR on that basis.

-- 
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/067.496fb6e0b4c2b98627b01d774c4b54c3%40djangoproject.com.


Re: [Django] #31259: Add a dark theme to the admin module

2021-01-20 Thread Django
#31259: Add a dark theme to the admin module
-+-
 Reporter:  Michel Le Bihan  |Owner:  Michel Le
 |  Bihan
 Type:  New feature  |   Status:  closed
Component:  contrib.admin|  Version:  3.0
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  1
-+-

Comment (by Carlton Gibson ):

 In [changeset:"4cf4c2df56af806f03299a264535bc34f1b1199a" 4cf4c2df]:
 {{{
 #!CommitTicketReference repository=""
 revision="4cf4c2df56af806f03299a264535bc34f1b1199a"
 [3.2.x] Refs #31259 -- Made various dark theme adjustments.

 Backport of f054468cac325e8d8fa4d5934b939b93242a3730 from master
 }}}

-- 
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/067.4e68f9bd452dd43fb43f7e22dc11a8d4%40djangoproject.com.


Re: [Django] #31259: Add a dark theme to the admin module

2021-01-20 Thread Django
#31259: Add a dark theme to the admin module
-+-
 Reporter:  Michel Le Bihan  |Owner:  Michel Le
 |  Bihan
 Type:  New feature  |   Status:  closed
Component:  contrib.admin|  Version:  3.0
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  1
-+-

Comment (by GitHub ):

 In [changeset:"f054468cac325e8d8fa4d5934b939b93242a3730" f054468c]:
 {{{
 #!CommitTicketReference repository=""
 revision="f054468cac325e8d8fa4d5934b939b93242a3730"
 Refs #31259 -- Made various dark theme adjustments.
 }}}

-- 
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/067.af511e130f02347f3f57fc13fe451c7d%40djangoproject.com.


Re: [Django] #13883: SelectBox.js with grouping (optgroup elements)

2021-01-20 Thread Django
#13883: SelectBox.js with grouping (optgroup elements)
-+-
 Reporter:  SardarNL |Owner:  Abhiraj
 |  Chatterjee
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  admin, SelectBox,| Triage Stage:  Accepted
  optgroup, sprintdec2010|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  1
-+-

Comment (by Marius Räsener):

 Hello everybody,

 I'm trying to contribute to Django with this "easy picking" issue. The PR
 on Github was closed by Jignesh Kotadiya and currently the PR says
 `jigneshkotadiya000 wants to merge 0 commits into 'django:master' from
 'unknown repository'` - so I'm already stuck I guess.
 Is this still issue still open? If yes, should I give it a try?

-- 
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/066.9307bf12489324d38dfc77d3b12c2d72%40djangoproject.com.


Re: [Django] #32367: models.W042 is raised on inherited manually specified primary key.

2021-01-20 Thread Django
#32367: models.W042 is raised on inherited manually specified primary key.
-+-
 Reporter:  אורי |Owner:  Hasan
 |  Ramezani
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Release blocker  |   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 Hasan Ramezani):

 * has_patch:  0 => 1


Comment:

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

-- 
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/069.a07a924da39ab1a59e78a27b4c678bbd%40djangoproject.com.


Re: [Django] #32292: Allow postgresql database connections to use postgres services

2021-01-20 Thread Django
#32292: Allow postgresql database connections to use postgres services
-+-
 Reporter:  levihb   |Owner:  Hasan
 |  Ramezani
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  database postgresql  | Triage Stage:  Ready for
  postgres service pg_service|  checkin
  config |
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/064.38a9b0d2b4d98fb0675d046e1240da22%40djangoproject.com.


Re: [Django] #32367: models.W042 is raised on inherited manually specified primary key.

2021-01-20 Thread Django
#32367: models.W042 is raised on inherited manually specified primary key.
-+-
 Reporter:  אורי |Owner:  Hasan
 |  Ramezani
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.2
  (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:4 Hasan Ramezani]:
 > Shouldn't the `Child` class inherits from `Parent` in the regression
 test?
 >
 >
 > {{{
 > class Child(Parent):
 > pass
 > }}}

 True, typo.

-- 
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/069.d7a79581b6373327b6725f3d9dcb96a1%40djangoproject.com.


Re: [Django] #31765: schema.tests.SchemaTests.test_db_table fails on MacOS

2021-01-20 Thread Django
#31765: schema.tests.SchemaTests.test_db_table fails on MacOS
---+--
 Reporter:  Tom Forbes |Owner:  Tom Forbes
 Type:  Bug|   Status:  new
Component:  Uncategorized  |  Version:  master
 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 Carlton Gibson):

 OK, I found it. It's to do with the `legacy_alter_table` config option.
 ([https://www.sqlite.org/pragma.html#pragma_legacy_alter_table docs]):

 {{{
 sqlite> .dbconfig
 ...
  legacy_alter_table on
 ...
 sqlite> PRAGMA legacy_alter_table = off;
 sqlite> .dbconfig
 ...
  legacy_alter_table off
 ...
 sqlite> CREATE TABLE ATOMIC_RENAME_TEST(id INT);
 sqlite> CREATE TABLE ATOMIC_RENAME_TEST_2(one INT, FOREIGN KEY(one)
 REFERENCES ATOMIC_RENAME_TEST(id));
 sqlite> ALTER TABLE ATOMIC_RENAME_TEST RENAME TO ATOMIC_RENAME_TEST_3;
 sqlite> .schema
 CREATE TABLE IF NOT EXISTS "ATOMIC_RENAME_TEST_3"(id INT);
 CREATE TABLE ATOMIC_RENAME_TEST_2(one INT, FOREIGN KEY(one) REFERENCES
 "ATOMIC_RENAME_TEST_3"(id));
 }}}

 Not sure (yet) why (or where) this defaults to `on` for macOS but we can
 configure the connection on creation.

-- 
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/061.baa2278b3707a5538ea810a860bfab10%40djangoproject.com.


Re: [Django] #32367: models.W042 is raised on inherited manually specified primary key.

2021-01-20 Thread Django
#32367: models.W042 is raised on inherited manually specified primary key.
-+-
 Reporter:  אורי |Owner:  Hasan
 |  Ramezani
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.2
  (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 Hasan Ramezani):

 * owner:  nobody => Hasan Ramezani
 * 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/069.ce274345690251a5d9da5bbe0561414e%40djangoproject.com.


Re: [Django] #32367: models.W042 is raised on inherited manually specified primary key.

2021-01-20 Thread Django
#32367: models.W042 is raised on inherited manually specified primary key.
-+-
 Reporter:  אורי |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.2
  (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 Hasan Ramezani):

 Shouldn't the `Child` class inherits from `Parent` in the regression test?


 {{{
 class Child(Parent):
 pass
 }}}

-- 
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/069.1b3bc91f8b6f47cbf40dcb104ef28acd%40djangoproject.com.


Re: [Django] #31765: schema.tests.SchemaTests.test_db_table fails on MacOS

2021-01-20 Thread Django
#31765: schema.tests.SchemaTests.test_db_table fails on MacOS
---+--
 Reporter:  Tom Forbes |Owner:  Tom Forbes
 Type:  Bug|   Status:  new
Component:  Uncategorized  |  Version:  master
 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):

 * needs_better_patch:  1 => 0
 * has_patch:  1 => 0
 * stage:  Ready for checkin => 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/061.ce9021a33a92e5760191f276a1eabcdd%40djangoproject.com.