Re: [Django] #32665: caches.W002 check does not support tuples in STATICFILES_DIRS

[Django]

#32665: caches.W002 check does not support tuples in STATICFILES_DIRS
-+-
 Reporter:  Jared Lockhart   |Owner:  Mariusz
 |  Felisiak
 Type:  Bug  |   Status:  assigned
Component:  Core (System |  Version:  3.2
  checks)|
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * 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/071.8fa8a9917172f7183f28cbc0b0890b54%40djangoproject.com.

Re: [Django] #32647: Select multiple action checkboxes with shift+mouseclick in django admin

[Django]

#32647: Select multiple action checkboxes with shift+mouseclick in django admin
-+-
 Reporter:  varicocelehealing|Owner:  Carlton
 |  Gibson
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  Version:  3.2
 Severity:  Release blocker  |   Resolution:
 Keywords:  Admin, Changelist,   | Triage Stage:  Ready for
  Shift Click|  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * stage:  Accepted => Ready for checkin


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

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

Re: [Django] #32665: caches.W002 check does not support tuples in STATICFILES_DIRS

[Django]

#32665: caches.W002 check does not support tuples in STATICFILES_DIRS
-+-
 Reporter:  Jared Lockhart   |Owner:  Mariusz
 |  Felisiak
 Type:  Bug  |   Status:  assigned
Component:  Core (System |  Version:  3.2
  checks)|
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/14291 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/071.6879aa530ca7ced2f4f77a608667bfd1%40djangoproject.com.

Re: [Django] #32665: caches.W002 check does not support tuples in STATICFILES_DIRS

[Django]

#32665: caches.W002 check does not support tuples in STATICFILES_DIRS
-+-
 Reporter:  Jared Lockhart   |Owner:  Mariusz
 |  Felisiak
 Type:  Bug  |   Status:  assigned
Component:  Core (System |  Version:  3.2
  checks)|
 Severity:  Release blocker  |   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 => Mariusz Felisiak
 * 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/071.1df3bc8fa61950087dbc40cb36abcec4%40djangoproject.com.

Re: [Django] #32650: Cannot combine two queryset in a subquery

[Django]

#32650: Cannot combine two queryset in a subquery
-+-
 Reporter:  Raffaele Salmaso |Owner:  Simon
 |  Charette
 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 Simon Charette):

 * 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/066.f599cbf391e7b3cba7dc4e6b83f51a3e%40djangoproject.com.

Re: [Django] #32668: Separate test-collection setup from runtests.py's setup() for use in get_app_test_labels()

[Django]

#32668: Separate test-collection setup from runtests.py's setup() for use in
get_app_test_labels()
-+-
 Reporter:  Chris Jerdonek   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Testing framework|  Version:  dev
 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 Chris Jerdonek:

Old description:

> This is another clean-up follow-up to
> [https://github.com/django/django/pull/4106 PR #4106], similar to
> ([https://github.com/django/django/pull/14276 PR #14276].
>
> TLDR: Refactor out from `runtests.py`'s
> [https://github.com/django/django/blob/54e94640ace261b14cf8cdb1fae3dc6f068a5f87/tests/runtests.py#L135
> setup()] and
> [https://github.com/django/django/blob/54e94640ace261b14cf8cdb1fae3dc6f068a5f87/tests/runtests.py#L263
> teardown()] simpler `setup_test_collection()` and
> `teardown_test_collection()` functions for use in the new
> [https://github.com/django/django/blob/54e94640ace261b14cf8cdb1fae3dc6f068a5f87/tests/runtests.py#L337-L342
> get_app_test_labels()] (used for `bisect_tests()` and `paired_tests()`).
> (The exact names aren't so important.)
>
> Longer version:
>
> Currently, `runtests.py`'s `setup()` function and its role in getting the
> list of default test labels for `bisect_tests()`, `paired_tests()`, and
> [https://github.com/django/django/blob/413c15ef2e3d3958fb641a023bc1e2d15fb2b228/tests/runtests.py#L332
> test_runner.run_tests()] is a bit complicated and harder to understand
> than it needs to be.
>
> There are a couple reasons for this. First, `setup()` is actually doing
> two kinds of setup: one for collecting the default test labels (always
> needed), and one for setting up the test run (needed only for
> [https://github.com/django/django/blob/54e94640ace261b14cf8cdb1fae3dc6f068a5f87/tests/runtests.py#L301
> django_tests()] but not `bisect_tests()` and `paired_tests()`). Second,
> the way the list of default test labels is obtained is a bit roundabout.
> Namely, a bunch of apps are added to `INSTALLED_APPS`, and then
> `runtests.py`'s `get_installed()` is called to read from
> `INSTALLED_APPS`. However, for test-collection, `INSTALLED_APPS` doesn't
> actually need to be modified. You can see a side effect of this in the
> fact that `get_installed()` doesn't just return test labels. It also
> returns the following modules, which no longer contain any tests (this is
> the thing that [https://github.com/django/django/pull/4106 PR #4106] from
> six years ago fixed):
> `django.contrib.admin`, `django.contrib.auth`,
> `django.contrib.contenttypes`, `django.contrib.flatpages`,
> `django.contrib.messages`, `django.contrib.redirects`,
> `django.contrib.sessions`, `django.contrib.sites`,
> `django.contrib.staticfiles`.
>
> By extracting out from `setup()` a `setup_test_collection()` function
> that just collects and returns the test labels, I think things will
> become a lot easier to understand and work with -- not just for
> `bisect_tests()` and `paired_tests()`, but also for the main
> `django_tests()` case.

New description:

 This is another clean-up follow-up to
 [https://github.com/django/django/pull/4106 PR #4106], similar to
 [https://github.com/django/django/pull/14276 PR #14276].

 TLDR: Refactor out from `runtests.py`'s 125-line
 
[https://github.com/django/django/blob/54e94640ace261b14cf8cdb1fae3dc6f068a5f87/tests/runtests.py#L135
 setup()] and
 
[https://github.com/django/django/blob/54e94640ace261b14cf8cdb1fae3dc6f068a5f87/tests/runtests.py#L263
 teardown()] simpler `setup_test_collection()` and
 `teardown_test_collection()` functions for use in the new
 
[https://github.com/django/django/blob/54e94640ace261b14cf8cdb1fae3dc6f068a5f87/tests/runtests.py#L337-L342
 get_app_test_labels()] (used for `bisect_tests()` and `paired_tests()`).
 (The exact names aren't so important.)

 Longer version:

 Currently, `runtests.py`'s `setup()` function and its role in getting the
 list of default test labels for `bisect_tests()`, `paired_tests()`, and
 
[https://github.com/django/django/blob/413c15ef2e3d3958fb641a023bc1e2d15fb2b228/tests/runtests.py#L332
 test_runner.run_tests()] is a bit complicated and harder to understand
 than it needs to be.

 There are a couple reasons for this. First, `setup()` is actually doing
 two kinds of setup: one for collecting the default test labels, and one
 for setting up the test run (needed only for
 
[https://github

[Django] #32668: Separate test-collection setup from runtests.py's setup() for use in get_app_test_labels()

[Django]

#32668: Separate test-collection setup from runtests.py's setup() for use in
get_app_test_labels()
+
   Reporter:  Chris Jerdonek|  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Testing framework |Version:  dev
   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 |
+
 This is another clean-up follow-up to
 [https://github.com/django/django/pull/4106 PR #4106], similar to
 ([https://github.com/django/django/pull/14276 PR #14276].

 TLDR: Refactor out from `runtests.py`'s
 
[https://github.com/django/django/blob/54e94640ace261b14cf8cdb1fae3dc6f068a5f87/tests/runtests.py#L135
 setup()] and
 
[https://github.com/django/django/blob/54e94640ace261b14cf8cdb1fae3dc6f068a5f87/tests/runtests.py#L263
 teardown()] simpler `setup_test_collection()` and
 `teardown_test_collection()` functions for use in the new
 
[https://github.com/django/django/blob/54e94640ace261b14cf8cdb1fae3dc6f068a5f87/tests/runtests.py#L337-L342
 get_app_test_labels()] (used for `bisect_tests()` and `paired_tests()`).
 (The exact names aren't so important.)

 Longer version:

 Currently, `runtests.py`'s `setup()` function and its role in getting the
 list of default test labels for `bisect_tests()`, `paired_tests()`, and
 
[https://github.com/django/django/blob/413c15ef2e3d3958fb641a023bc1e2d15fb2b228/tests/runtests.py#L332
 test_runner.run_tests()] is a bit complicated and harder to understand
 than it needs to be.

 There are a couple reasons for this. First, `setup()` is actually doing
 two kinds of setup: one for collecting the default test labels (always
 needed), and one for setting up the test run (needed only for
 
[https://github.com/django/django/blob/54e94640ace261b14cf8cdb1fae3dc6f068a5f87/tests/runtests.py#L301
 django_tests()] but not `bisect_tests()` and `paired_tests()`). Second,
 the way the list of default test labels is obtained is a bit roundabout.
 Namely, a bunch of apps are added to `INSTALLED_APPS`, and then
 `runtests.py`'s `get_installed()` is called to read from `INSTALLED_APPS`.
 However, for test-collection, `INSTALLED_APPS` doesn't actually need to be
 modified. You can see a side effect of this in the fact that
 `get_installed()` doesn't just return test labels. It also returns the
 following modules, which no longer contain any tests (this is the thing
 that [https://github.com/django/django/pull/4106 PR #4106] from six years
 ago fixed):
 `django.contrib.admin`, `django.contrib.auth`,
 `django.contrib.contenttypes`, `django.contrib.flatpages`,
 `django.contrib.messages`, `django.contrib.redirects`,
 `django.contrib.sessions`, `django.contrib.sites`,
 `django.contrib.staticfiles`.

 By extracting out from `setup()` a `setup_test_collection()` function that
 just collects and returns the test labels, I think things will become a
 lot easier to understand and work with -- not just for `bisect_tests()`
 and `paired_tests()`, but also for the main `django_tests()` case.

-- 
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.d31a0b499475a65dde3882a8faba0bea%40djangoproject.com.

Re: [Django] #29843: Create permissions using migration operations rather than using the post_migrate signal

[Django]

#29843: Create permissions using migration operations rather than using the
post_migrate signal
-+-
 Reporter:  Petter Strandmark|Owner:  Arthur
 Type:   |  Rio
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.auth |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  contenttypes | Triage Stage:  Accepted
  permissions post_migrate   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Taylor H):

 Hi everyone 👋🏻

 Copying the following from the mailing list for cross-reference (Arthur
 and I are working together). Hoping to get some feedback from everyone .

 > After some experiments and discussions it felt like while the
 implementation might solve the initial problem, it's a bit under the hood
 and will be hard to debug if something goes wrong. The idea was to inject
 operations at the time of running `migrate`.
 >
 > So... we went back to the idea of having hooks during the
 `makemigrations` process instead, so that the operations would be written
 to the migration files, which would make it more explicit and less risky.
 Here is a first draft of how it would look like:
 https://github.com/django/django/pull/14229.
 >
 > 1. We know that the `makemigrations` process is complicated, so before
 we invest more time down that path, is there something obvious we might be
 missing?
 > 2. What do you think of this approach with hooks (pre and post
 "add_operation")?
 > 3. Do you think it would be a useful feature for other third party apps
 as well (not just content types and permissions)?

-- 
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/065.86dda4d76c77ee9aa031f7a476ba7831%40djangoproject.com.

Re: [Django] #25287: Multiplying and dividing connectors for duration expressions are not supported on SQLite and MySQL.

[Django]

#25287: Multiplying and dividing connectors for duration expressions are not
supported on SQLite and MySQL.
-+-
 Reporter:  Ahmet DAL|Owner:  (none)
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  sqlite3, mysql,  | Triage Stage:  Accepted
  combine_duration_expression, F |
  expressions,   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * owner:  Tobias Bengfort => (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/066.9397c69f2aa94a34480f95973b18e858%40djangoproject.com.

Re: [Django] #24822: Autodetector crashes on add/removal of tzinfo from DateTimeField default

[Django]

#24822: Autodetector crashes on add/removal of tzinfo from DateTimeField default
-+-
 Reporter:  Camilo Ernesto   |Owner:  nobody
  Forero |
 Type:  Bug  |   Status:  closed
Component:  Documentation|  Version:  1.8
 Severity:  Normal   |   Resolution:  invalid
 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):

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


Comment:

 This ticket is not valid anymore. Python 3.5+ no longer raises `TypeError`
 when comparing naive and aware `datetimes`:
 {{{
 Python 3.5.10 (default, Jan 25 2021, 09:05:45)
 [GCC 9.3.0] on linux
 Type "help", "copyright", "credits" or "license" for more information.
 >>> from datetime import datetime
 >>> import pytz
 >>> default=datetime(2015, 7, 4, 8, 0 )
 >>> default2=datetime(2015, 7, 4, 8, 0, tzinfo=pytz.UTC)
 >>> default != default2
 True
 }}}

-- 
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/070.1b6c61dbb8090e6db5da03def7e3355d%40djangoproject.com.

Re: [Django] #25287: Multiplying and dividing connectors for duration expressions are not supported on SQLite and MySQL.

[Django]

#25287: Multiplying and dividing connectors for duration expressions are not
supported on SQLite and MySQL.
-+-
 Reporter:  Ahmet DAL|Owner:  Tobias
 |  Bengfort
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  sqlite3, mysql,  | Triage Stage:  Accepted
  combine_duration_expression, F |
  expressions,   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

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

Re: [Django] #25287: Multiplying and dividing connectors for duration expressions are not supported on SQLite and MySQL.

[Django]

#25287: Multiplying and dividing connectors for duration expressions are not
supported on SQLite and MySQL.
-+-
 Reporter:  Ahmet DAL|Owner:  Tobias
 |  Bengfort
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  sqlite3, mysql,  | Triage Stage:  Accepted
  combine_duration_expression, F |
  expressions,   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * stage:  Ready for checkin => Accepted


Comment:

 MySQL part is missing.

-- 
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.08de2aff242530b0cb773b4a1be1a1ec%40djangoproject.com.

Re: [Django] #25287: Multiplying and dividing connectors for duration expressions are not supported on SQLite and MySQL.

[Django]

#25287: Multiplying and dividing connectors for duration expressions are not
supported on SQLite and MySQL.
-+-
 Reporter:  Ahmet DAL|Owner:  Tobias
 |  Bengfort
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  sqlite3, mysql,  | Triage Stage:  Ready for
  combine_duration_expression, F |  checkin
  expressions,   |
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:"54e94640ace261b14cf8cdb1fae3dc6f068a5f87" 54e94640]:
 {{{
 #!CommitTicketReference repository=""
 revision="54e94640ace261b14cf8cdb1fae3dc6f068a5f87"
 Refs #25287 -- Added support for multiplying and dividing DurationField by
 scalar values on SQLite.
 }}}

-- 
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.82114160039f84a16dfb41fe09b649ae%40djangoproject.com.

Re: [Django] #25287: Multiplying and dividing connectors for duration expressions are not supported on SQLite and MySQL.

[Django]

#25287: Multiplying and dividing connectors for duration expressions are not
supported on SQLite and MySQL.
-+-
 Reporter:  Ahmet DAL|Owner:  Tobias
 |  Bengfort
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  sqlite3, mysql,  | Triage Stage:  Ready for
  combine_duration_expression, F |  checkin
  expressions,   |
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:"9e1ccd7283e8544d86cba35c820a7d741f5d2712" 9e1ccd72]:
 {{{
 #!CommitTicketReference repository=""
 revision="9e1ccd7283e8544d86cba35c820a7d741f5d2712"
 Refs #25287 -- Added _sqlite_prepare_dtdelta_param() hook.
 }}}

-- 
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.0ca8bedc3eb73e235877a0088ad691d8%40djangoproject.com.

Re: [Django] #32647: Select multiple action checkboxes with shift+mouseclick in django admin

[Django]

#32647: Select multiple action checkboxes with shift+mouseclick in django admin
-+-
 Reporter:  varicocelehealing|Owner:  Carlton
 |  Gibson
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  Version:  3.2
 Severity:  Release blocker  |   Resolution:
 Keywords:  Admin, Changelist,   | Triage Stage:  Accepted
  Shift Click|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * has_patch:  0 => 1


Comment:

 
[https://github.com/django/django/pull/14288https://github.com/django/django/pull/14288
 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/075.ef00aff10349b4e17cd6f6df7971fbbf%40djangoproject.com.

Re: [Django] #32667: Clarify about tags on BaseCommand.require_system_checks

[Django]

#32667: Clarify about tags on BaseCommand.require_system_checks
--+
 Reporter:  Abhyudai  |Owner:  Abhyudai
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Core (System checks)  |  Version:  3.2
 Severity:  Normal|   Resolution:
 Keywords:  documentation | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by Abhyudai):

 * owner:  nobody => Abhyudai


-- 
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.f6b7d47b7dbe219ebfcae961af63be96%40djangoproject.com.

Re: [Django] #21859: clarify Django docs re: email addresses and ascii

[Django]

#21859: clarify Django docs re: email addresses and ascii
-+
 Reporter:  Chris Jerdonek   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Documentation|  Version:  1.6
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  email,ascii,unicode  | 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):

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


Comment:

 The "Email" section was removed from the
 [https://docs.djangoproject.com/en/dev/ref/unicode/ Unicode] docs in
 d4d812cb567d1f84ef7a569672fdf3c0b83e6fdd. I don't think there is anything
 left to clarify.

-- 
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.0a4692dc2259dae482818889507c20f4%40djangoproject.com.

Re: [Django] #21993: Messages documentation is topic style, there is no ref

[Django]

#21993: Messages documentation is topic style, there is no ref
-+-
 Reporter:  Marc Tamlyn  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  dev
 Severity:  Normal   |   Resolution:  needsinfo
 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):

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


-- 
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.846a00947b331305f9278d39f418b632%40djangoproject.com.

Re: [Django] #32667: Clarify about tags on BaseCommand.require_system_checks

[Django]

#32667: Clarify about tags on BaseCommand.require_system_checks
--+
 Reporter:  Abhyudai  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Core (System checks)  |  Version:  3.2
 Severity:  Normal|   Resolution:
 Keywords:  documentation | 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):

 * keywords:   => documentation
 * component:  Documentation => Core (System checks)
 * stage:  Unreviewed => Accepted


Comment:

 IMO it should be enough to add a link to the
 [https://docs.djangoproject.com/en/dev/topics/checks/#registering-and-
 labeling-checks Registering and labeling checks], e.g.
 {{{
 diff --git a/docs/howto/custom-management-commands.txt b/docs/howto
 /custom-management-commands.txt
 index 5d1a8ddd2d..e80540afaa 100644
 --- a/docs/howto/custom-management-commands.txt
 +++ b/docs/howto/custom-management-commands.txt
 @@ -218,9 +218,10 @@ All attributes can be set in your derived class and
 can be used in
  .. attribute:: BaseCommand.requires_system_checks

  A list or tuple of tags, e.g. ``[Tags.staticfiles, Tags.models]``.
 System
 -checks registered in the chosen tags will be checked for errors prior
 to
 -executing the command. The value ``'__all__'`` can be used to specify
 -that all system checks should be performed. Default value is
 ``'__all__'``.
 +checks :ref:`registered in the chosen tags `
 +will be checked for errors prior to executing the command. The value
 +``'__all__'`` can be used to specify that all system checks should be
 +performed. Default value is ``'__all__'``.

  .. versionchanged:: 3.2

 diff --git a/docs/topics/checks.txt b/docs/topics/checks.txt
 index 438139ad31..1a5594fc27 100644
 --- a/docs/topics/checks.txt
 +++ b/docs/topics/checks.txt
 @@ -77,6 +77,8 @@ implied by the class name.
  * :class:`Error`
  * :class:`Critical`

 +.. _registering-labeling-checks:
 +
  Registering and labeling checks
  ---

 }}}

-- 
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.a403ccdb5bc035cd60ba326477b89ad8%40djangoproject.com.

[Django] #32667: Clarify about tags on BaseCommand.require_system_checks

[Django]

#32667: Clarify about tags on BaseCommand.require_system_checks
+--
   Reporter:  abhiabhi94|  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  assigned
  Component:  Documentation |Version:  3.2
   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 |
+--
 The current documentation regarding
 [https://docs.djangoproject.com/en/3.2/howto/custom-management-
 commands/#django.core.management.BaseCommand.requires_system_checks/
 requires_system_checks] mention `Tags` but it isn't very clear where
 `Tags` come from. I'm just quoting the documentation here for easy of
 conversation.

 > A list or tuple of tags, e.g. [Tags.staticfiles, Tags.models]. System
 checks registered in the chosen tags will be checked for errors prior to
 executing the command. The value '__all__' can be used to specify that all
 system checks should be performed. Default value is '__all__'.

 I didn't exactly find a definition on that page.

 Digging into the source, I found that `Tags` actually come from
 `django.core.registry.check`. I think it would be worthwhile mentioning
 the actual reference here. I could potentially make the documentation more
 clear.

 If acceptable, I would be willing to make the patch for it.

-- 
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.5bc9a938697e5967f5f3a9f5a2a3edd2%40djangoproject.com.

Re: [Django] #24989: Introduce contributor facing documentation for django.db.migrations

[Django]

#24989: Introduce contributor facing documentation for django.db.migrations
---+
 Reporter:  Markus Holtermann  |Owner:  (none)
 Type:  New feature|   Status:  new
Component:  Documentation  |  Version:  dev
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by Mariusz Felisiak):

 * owner:  Markus Holtermann => (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/065.1275680be59bdf93ade0324d30e13335%40djangoproject.com.

Re: [Django] #18596: Documentation of JavaScriptCatalog isn't very clear

[Django]

#18596: Documentation of JavaScriptCatalog isn't very clear
--+
 Reporter:  Aymeric Augustin  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  closed
Component:  Documentation |  Version:  dev
 Severity:  Normal|   Resolution:  fixed
 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):

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


Comment:

 `JavaScriptCatalog` documentation was improved in
 de40cfbe74642df1e94c131e1adaa3363173c0cf.

-- 
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.30ed5af26fae846ea77ca775d708616b%40djangoproject.com.

Re: [Django] #31543: Default output buffering on in tests

[Django]

#31543: Default output buffering on in tests
---+--
 Reporter:  Adam Johnson   |Owner:  Aly yasser
 Type:  New feature|   Status:  closed
Component:  Testing framework  |  Version:  dev
 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):

 * cc: Carlton Gibson (added)
 * status:  assigned => closed
 * resolution:   => wontfix
 * stage:  Accepted => Unreviewed


Comment:

 IMO we shouldn't change the current behavior, it's consistent with
 Python's `unittest`. Folks who are concerned here can add the `--buffer`
 flag (it's not much of a burden.)

-- 
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.1a035771529773c34e1428e1575f9cee%40djangoproject.com.

Re: [Django] #32666: Clarify mysite/urls.py location for tutorial-01

[Django]

#32666: Clarify mysite/urls.py location for tutorial-01
-+-
 Reporter:  Johnson  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  3.2
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  tutorial | Triage Stage:
  clarification  |  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:  Uncategorized => Cleanup/optimization
 * resolution:   => invalid


Comment:

 Thanks for the suggestion, however it's explained multiple times in this
 tutorial, e.g.

 - ''"The outer **mysite/** root directory is a container for your project.
 Its name doesn’t matter to Django; you can rename it to anything you
 like."''
 - ''"**mysite/urls.py**: The URL declarations for this Django project; a
 “table of contents” of your Django-powered site. You can read more about
 URLs in URL dispatcher."''

 The tutorial also instructs reader to modify an existing **
 mysite/urls.py** and not to create a new file:

 -  "In** mysite/urls.py**, add an import for django.urls.include and
 insert an include() in the urlpatterns list, so you have: "

 I don't think any further explanation is needed.

-- 
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.0305bcde2277b5275589388f50b45a37%40djangoproject.com.

[Django] #32666: Clarify mysite/urls.py location for tutorial-01

[Django]

#32666: Clarify mysite/urls.py location for tutorial-01
-+-
   Reporter:  j3soon |  Owner:  nobody
   Type: | Status:  new
  Uncategorized  |
  Component: |Version:  3.2
  Documentation  |   Keywords:  tutorial
   Severity:  Normal |  clarification
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 According to [this answer on
 StackOverflow](https://stackoverflow.com/a/29657129/), 82 people
 accidentally created the `mysite/urls.py` in the outer `mysite` directory
 (`mysite/mysite/urls.py`) instead of modifying the inner `mysite`
 directory (`mysite/urls.py`) when following
 [tutorial-01](https://docs.djangoproject.com/en/3.1/intro/tutorial01/).

 This PR adds a hint to ask readers to double check the file location. This
 can help future readers who encounters this issue to follow the tutorial
 more smoothly (instead of searching on Google to see the StackOverflow
 post)

 Django's [contribution
 guideline](https://github.com/django/django/blob/main/CONTRIBUTING.rst)
 suggests to create a Trac ticket here beforehand, so I created a fake PR
 here: https://github.com/j3soon-pr/django/pull/1

 If this clarification is approved, I'll create the formal PR on GitHub.

-- 
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/049.e92ca00881013e68db09d214f8a8df0a%40djangoproject.com.

Re: [Django] #25287: Multiplying and dividing connectors for duration expressions are not supported on SQLite and MySQL.

[Django]

#25287: Multiplying and dividing connectors for duration expressions are not
supported on SQLite and MySQL.
-+-
 Reporter:  Ahmet DAL|Owner:  Tobias
 |  Bengfort
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  sqlite3, mysql,  | Triage Stage:  Ready for
  combine_duration_expression, F |  checkin
  expressions,   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * needs_better_patch:  1 => 0
 * stage:  Accepted => Ready for checkin
 * needs_tests:  1 => 0
 * needs_docs:  1 => 0


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

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

Re: [Django] #25287: Multiplying and dividing connectors for duration expressions are not supported on SQLite and MySQL. (was: Multiplying and dividing connectors for duration expressions are not supp

[Django]

#25287: Multiplying and dividing connectors for duration expressions are not
supported on SQLite and MySQL.
-+-
 Reporter:  Ahmet DAL|Owner:  Tobias
 |  Bengfort
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  sqlite3, mysql,  | Triage Stage:  Accepted
  combine_duration_expression, F |
  expressions,   |
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  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/066.d6f81c4be06f299aaafaf289cb3c4b6d%40djangoproject.com.