Re: [Django] #32317: Clean up loaddata

2021-05-17 Thread Django
#32317: Clean up loaddata
-+-
 Reporter:  William Schwartz |Owner:  William
 Type:   |  Schwartz
  Cleanup/optimization   |   Status:  closed
Component:  Core (Management |  Version:  dev
  commands)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  loaddata | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"de32fe83a2e4a20887972c69a0693b94eb25a88b" de32fe83]:
 {{{
 #!CommitTicketReference repository=""
 revision="de32fe83a2e4a20887972c69a0693b94eb25a88b"
 Fixed #32317 -- Refactored loaddata command to make it extensible.

 Moved deeply nested blocks out of inner loops to improve readability
 and maintainability.

 Thanks to Mariusz Felisiak, Shreyas Ravi, and Paolo Melchiorre for
 feedback.
 }}}

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


Re: [Django] #32317: Clean up loaddata

2021-05-17 Thread Django
#32317: Clean up loaddata
-+-
 Reporter:  William Schwartz |Owner:  William
 Type:   |  Schwartz
  Cleanup/optimization   |   Status:  assigned
Component:  Core (Management |  Version:  dev
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:  loaddata | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

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


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

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


Re: [Django] #32755: Correct broken example for Model.get_absolute_url()

2021-05-17 Thread Django
#32755: Correct broken example for Model.get_absolute_url()
---+---
 Reporter:  aruseni|Owner:  Girish Sontakke
 Type:  Bug|   Status:  assigned
Component:  Documentation  |  Version:  3.2
 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 Girish Sontakke):

 * owner:  nobody => Girish Sontakke
 * 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/065.6eab3679b9be2376a339bc30ba453c47%40djangoproject.com.


Re: [Django] #32755: Correct broken example for Model.get_absolute_url() (was: Update example for get_absolute_url() in the documentation)

2021-05-17 Thread Django
#32755: Correct broken example for Model.get_absolute_url()
---+
 Reporter:  aruseni|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Documentation  |  Version:  3.2
 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 Tim Graham):

 * type:  Uncategorized => Bug
 * component:  Uncategorized => Documentation
 * easy:  0 => 1
 * 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/065.df33a74df941a83fb8c0433587ec2c54%40djangoproject.com.


Re: [Django] #32740: Running colorama.init() at import time causes deployment error

2021-05-17 Thread Django
#32740: Running colorama.init() at import time causes deployment error
-+
 Reporter:  Leon Matthews|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Other) |  Version:  3.2
 Severity:  Release blocker  |   Resolution:
 Keywords:  apache mod_wsgi  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by Leon Matthews):

 Replying to [comment:6 Carlton Gibson]:
 > Can you give the PR on https://github.com/django/django/pull/14386 a go.
 > That should at least enable you to get past this with
 `WSGIRestrictedStdout` still on.

 That seems to have done the trick!

 BTW, it's a moot point now but I found out why ''colorama'' was getting
 installed in the first place. It wasn't a 3rd-party dependency like I
 thought it was. It turns out that Ubuntu 20.04 LTS installs a bunch of
 [https://bugs.launchpad.net/ubuntu/+source/python-virtualenv/+bug/1904945
 libraries into every Python virtualenv by default].

 Thank you so much for your work on this Carlton, it's very much
 appreciated!

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


Re: [Django] #32744: Template changes cause dev server to reload

2021-05-17 Thread Django
#32744: Template changes cause dev server to reload
-+-
 Reporter:  Ryan P Kilby |Owner:  Hasan
 |  Ramezani
 Type:  Bug  |   Status:  assigned
Component:  Template system  |  Version:  3.2
 Severity:  Release blocker  |   Resolution:
 Keywords:  autoreload   | 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:

 [https://github.com/django/django/pull/14407 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/065.d6024fe3b0143fa1f8a49d6450e39656%40djangoproject.com.


Re: [Django] #32755: Update example for get_absolute_url() in the documentation

2021-05-17 Thread Django
#32755: Update example for get_absolute_url() in the documentation
---+--
 Reporter:  aruseni|Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  Uncategorized  |  Version:  3.2
 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 aruseni:

Old description:

> Currently, in the example for `get_absolute_url()`
> [https://docs.djangoproject.com/en/3.2/ref/models/instances/#get-
> absolute-url in the documentation], a view path string is passed to
> `reverse()`. But this not supported since Django 1.10.

New description:

 Currently, in the example for `get_absolute_url()`
 [https://docs.djangoproject.com/en/3.2/ref/models/instances/#get-absolute-
 url in the documentation], a view path string is passed to `reverse()`.
 But this is not supported since Django 1.10.

--

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


[Django] #32755: Update example for get_absolute_url() in the documentation

2021-05-17 Thread Django
#32755: Update example for get_absolute_url() in the documentation
-+
   Reporter:  aruseni|  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Uncategorized  |Version:  3.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  |
-+
 Currently, in the example for `get_absolute_url()`
 [https://docs.djangoproject.com/en/3.2/ref/models/instances/#get-absolute-
 url in the documentation], a view path string is passed to `reverse()`.
 But this not supported since Django 1.10.

-- 
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/050.fa1008983db45cdd4c6e79bbd4eef582%40djangoproject.com.


Re: [Django] #32740: Running colorama.init() at import time causes deployment error

2021-05-17 Thread Django
#32740: Running colorama.init() at import time causes deployment error
-+
 Reporter:  Leon Matthews|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Other) |  Version:  3.2
 Severity:  Release blocker  |   Resolution:
 Keywords:  apache mod_wsgi  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by Leon Matthews):

 Replying to [comment:6 Carlton Gibson]:
 > Can you give the PR on https://github.com/django/django/pull/14386 a go.
 > That should at least enable you to get past this with
 `WSGIRestrictedStdout` still on.

 Thank you Carlton, I'm back at work now, so I'll check that out and get
 back to you soon.

 > We're looking into whether we can move the `colorama.init()` off the
 import-time path.

 I agree that that would be cleanest approach.  It would be entirely
 reasonable to hit this error if my production configuration used the
 feature (as my development configuration does).

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


Re: [Django] #18448: Rename all documentation files to have .rst extension

2021-05-17 Thread Django
#18448: Rename all documentation files to have .rst extension
-+-
 Reporter:  Marc Tamlyn  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  1.4
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mike Lissner):

 I just did some work on documentation today and I found the use if txt
 extensions instead of rst extension to be a bit frustrating. For example,
 my editor couldn't treat these as ReStructured Text, and then when I was
 writing my pull request, I couldn't review my work in Github either.
 Similarly, for whomever reviews my PR, they won't be able to review it on
 Github either, and will have to do so on their laptop, which is an extra
 step for them.

 I guess I understand the explanation from nine years ago that some people
 won't be able to open rst files in their editor, but I think if Github
 supports these natively, we can assume that just about everybody
 contributing documentation would support them natively too.

 Should we reconsider this one? I'd happily make a little PR to rename
 files if so.

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

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


Re: [Django] #32744: Template changes cause dev server to reload

2021-05-17 Thread Django
#32744: Template changes cause dev server to reload
-+-
 Reporter:  Ryan P Kilby |Owner:  Hasan
 |  Ramezani
 Type:  Bug  |   Status:  assigned
Component:  Template system  |  Version:  3.2
 Severity:  Release blocker  |   Resolution:
 Keywords:  autoreload   | 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/065.4c5d34a73f74a20b0079ebe20578ce56%40djangoproject.com.


Re: [Django] #10686: Add class name interpolation in Meta.permissions codenames

2021-05-17 Thread Django
#10686: Add class name interpolation in Meta.permissions codenames
-+-
 Reporter:  faldridge|Owner:  (none)
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  permissions  | Triage Stage:  Accepted
  inheritance|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * owner:  Sergei Maertens => (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.4af0f6aae66bc3981ab4caab365bbe7e%40djangoproject.com.


Re: [Django] #25671: Arrange models and apps order in Admin.

2021-05-17 Thread Django
#25671: Arrange models and apps order in Admin.
+-
 Reporter:  Hasan Ramezani  |Owner:  Roman
 Type:  New feature |   Status:  closed
Component:  contrib.admin   |  Version:  dev
 Severity:  Normal  |   Resolution:  duplicate
 Keywords:  | Triage Stage:  Accepted
Has patch:  1   |  Needs documentation:  1
  Needs tests:  1   |  Patch needs improvement:  1
Easy pickings:  0   |UI/UX:  1
+-
Changes (by Mariusz Felisiak):

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


Comment:

 Duplicate of #7497.

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


Re: [Django] #9388: Year navigation in admin's date widgets' calendar

2021-05-17 Thread Django
#9388: Year navigation in admin's date widgets' calendar
-+-
 Reporter:  Fidel Ramos  |Owner:  (none)
 Type:  New feature  |   Status:  new
Component:  contrib.admin|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  admin calendar year  | Triage Stage:  Accepted
  previous next widget ui|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  1
-+-
Changes (by Mariusz Felisiak):

 * owner:  Javier de la Rosa => (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/064.c1ffc684a3bee84ecd9d083e95b73c9c%40djangoproject.com.


Re: [Django] #32750: ExtractMonth from OuterRef in Subquery don't work

2021-05-17 Thread Django
#32750: ExtractMonth from OuterRef in Subquery don't work
-+-
 Reporter:  Chiorufarewerin  |Owner:
 |  Chiorufarewerin
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"3954bf50fb814e7362e69f1020a747e601cc73fe" 3954bf50]:
 {{{
 #!CommitTicketReference repository=""
 revision="3954bf50fb814e7362e69f1020a747e601cc73fe"
 Fixed #32750 -- Fixed crash of Extract() transform on OuterRef()
 expressions.

 Thanks Simon Charette for the review.
 }}}

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

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


Re: [Django] #32316: Access __file__ lazily rather than at module level

2021-05-17 Thread Django
#32316: Access __file__ lazily rather than at module level
-+-
 Reporter:  William Schwartz |Owner:  William
 Type:   |  Schwartz
  Cleanup/optimization   |   Status:  closed
Component:  Core (Other) |  Version:  dev
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  freezers | 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 William Schwartz):

 I'm cleaning up random files on my desktop and I came across these notes I
 left for myself while working on this bug. I'm leaving them here for
 posterity.

 = Appendix: Other modules that use `__file__`.
 From `master` at b41d38ae26b1da9519a6cd765bc2f2ce7d355007:
 {{{#!console
 $ git grep --files-with-matches -e "__file__" b41d38a -- django | wc -l
 b41d38a:django/apps/config.py
 b41d38a:django/conf/__init__.py
 b41d38a:django/conf/project_template/project_name/settings.py-tpl
 b41d38a:django/contrib/auth/password_validation.py
 b41d38a:django/core/management/commands/makemessages.py
 b41d38a:django/db/migrations/loader.py
 b41d38a:django/db/migrations/questioner.py
 b41d38a:django/forms/renderers.py
 b41d38a:django/utils/autoreload.py
 b41d38a:django/utils/module_loading.py
 b41d38a:django/utils/translation/trans_real.py
 b41d38a:django/utils/version.py
 b41d38a:django/views/debug.py
 }}}

 The remainder of the files listed in the `git grep` output above do
 **not** need to be addressed in this ticket at this time. This section
 explains why.

 The following modules access `__file__` only through proper `getattr` or
 `hasattr` guards:
 * `django.apps.config` to compute `AppConfig.path` from its `module`
 * `django.db.migrations.loader` (see #32302)
 * `django.db.migrations.questioner` in `MigrationQuestioner.ask_initial`
 * `django.utils.module_loading` in `module_dir`
 `django.utils.autoreload` doesn't access `__file__` at the module level.
 `iter_modules_and_files` has a proper `hasattr` guard but `is_django_path`
 would need different semantics. #32314 addresses `get_child_arguments`.

 `django.conf.LazySettings.PASSWORD_RESET_TIMEOUT_DAYS` uses `__file__`
 only to avoid warning about this deprecated setting. Frozen applications
 can avoid crashes simply by upgrading away from
 `PASSWORD_RESET_TIMEOUT_DAYS`.

 `django/conf/project_template/project_name/settings.py-tpl` is the
 template settings module. Django projects are supposed to edit this
 anyway.

 Finally the `makemessages` command has no use for projects with
 `USE_I18N=False`, which is necessary for frozen projects to work around
 the issue with `trans_real` described above.

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


Re: [Django] #32749: PyMemcacheCache uses default_noreply=False although pymemcache recommends to set to True

2021-05-17 Thread Django
#32749: PyMemcacheCache uses default_noreply=False although pymemcache 
recommends
to set to True
-+-
 Reporter:  yakirsudry   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  Version:  3.2
 Severity:  Normal   |   Resolution:
 Keywords:  pymemcache   | Triage Stage:  Accepted
  PyMemcacheCache|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Simon Charette):

 Thanks for the extra details Nick.

 In the light of these failures I think the only way we could get tests
 passing/ensure the backend is fully functional without turning reply on
 per client would be to adjust all the methods that require a reply from MC
 to work properly to explicitly pass `noreply=False` but I'm not sure there
 would be much benefit from that.

 Documenting to turn the option as is would simply break the backend so I'm
 not convinced we should even do that anymore. Were you aware of that
 yakirsudry?

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


Re: [Django] #32751: Add link from Session object to User object

2021-05-17 Thread Django
#32751: Add link from Session object to User object
--+--
 Reporter:  David |Owner:  nobody
 Type:  New feature   |   Status:  closed
Component:  contrib.sessions  |  Version:  4.0
 Severity:  Normal|   Resolution:  duplicate
 Keywords:| Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+--

Comment (by David):

 Sorry about that, hadn't been able to find an original issue and hadn't
 thought about non-DB backends.

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


Re: [Django] #32749: PyMemcacheCache uses default_noreply=False although pymemcache recommends to set to True

2021-05-17 Thread Django
#32749: PyMemcacheCache uses default_noreply=False although pymemcache 
recommends
to set to True
-+-
 Reporter:  yakirsudry   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  Version:  3.2
 Severity:  Normal   |   Resolution:
 Keywords:  pymemcache   | Triage Stage:  Accepted
  PyMemcacheCache|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Nick Pope):

 * type:  Bug => Cleanup/optimization
 * component:  Core (Cache system) => Documentation
 * easy:  0 => 1
 * stage:  Unreviewed => Accepted


Comment:

 Thank you for dredging up my comment Simon.

 As mentioned there, I was trying to ensure that the new `pymemcache`
 backend was compatible with the expectations of Django by
 
[https://github.com/django/django/blob/0851933cba7b40e22f5e424c95763dbc27c40aa9/django/core/cache/backends/memcached.py#L238-L240
 setting various options].

 If I remove `'default_noreply': False,` then a heap of tests fail because
 `pymemcache` always returns `True` for some operations:

 {{{
 $ python runtests.py --settings=test_sqlite --parallel=1 --timing
 cache.tests.PyMemcacheCacheTests
 Testing against Django installed in '/home/pope1ni/Sources/django/django'
 Found 58 tests.
 Creating test database for alias 'default'...
 System check identified no issues (0 silenced).
 FF..F..ss.F..FF.s.
 ==
 FAIL: test_add (cache.tests.PyMemcacheCacheTests)
 --
 Traceback (most recent call last):
   File "/home/pope1ni/Sources/django/tests/cache/tests.py", line 306, in
 test_add
 self.assertIs(cache.add("addkey1", "newvalue"), False)
 AssertionError: True is not False

 ==
 FAIL: test_cache_versioning_add (cache.tests.PyMemcacheCacheTests)
 --
 Traceback (most recent call last):
   File "/home/pope1ni/Sources/django/tests/cache/tests.py", line 767, in
 test_cache_versioning_add
 self.assertIs(cache.add('answer1', 37, version=2), False)
 AssertionError: True is not False

 ==
 FAIL: test_cache_versioning_get_set_many
 (cache.tests.PyMemcacheCacheTests)
 --
 Traceback (most recent call last):
   File "/home/pope1ni/Sources/django/tests/cache/tests.py", line 900, in
 test_cache_versioning_get_set_many
 self.assertEqual(cache.get_many(['ford3', 'arthur3'], version=2),
 {'ford3': 37, 'arthur3': 42})
 AssertionError: {'ford3': 37} != {'ford3': 37, 'arthur3': 42}
 - {'ford3': 37}
 + {'arthur3': 42, 'ford3': 37}

 ==
 FAIL: test_delete_nonexistent (cache.tests.PyMemcacheCacheTests)
 --
 Traceback (most recent call last):
   File "/home/pope1ni/Sources/django/tests/cache/tests.py", line 344, in
 test_delete_nonexistent
 self.assertIs(cache.delete('nonexistent_key'), False)
 AssertionError: True is not False

 ==
 FAIL: test_forever_timeout (cache.tests.PyMemcacheCacheTests)
 Passing in None into timeout results in a value that is cached forever
 --
 Traceback (most recent call last):
   File "/home/pope1ni/Sources/django/tests/cache/tests.py", line 597, in
 test_forever_timeout
 self.assertIs(cache.add('key1', 'new eggs', None), False)
 AssertionError: True is not False

 ==
 FAIL: test_touch (cache.tests.PyMemcacheCacheTests)
 --
 Traceback (most recent call last):
   File "/home/pope1ni/Sources/django/tests/cache/tests.py", line 484, in
 test_touch
 self.assertIs(cache.touch('nonexistent'), False)
 AssertionError: True is not False

 --
 Ran 58 tests in 12.032s

 FAILED (failures=6, skipped=3)
 Destroying test database for alias 'default'...
 Total database setup took 0.090s
   Creating 'default' took 0.090s
 Total database teardown took 0.000s
 Total run took 12.187s
 }}}

Re: [Django] #32739: Enable timezone handling by default (USE_TZ=True in global settings)

2021-05-17 Thread Django
#32739: Enable timezone handling by default (USE_TZ=True in global settings)
-+-
 Reporter:  Claude Paroz |Owner:  Claude
 Type:   |  Paroz
  Cleanup/optimization   |   Status:  assigned
Component:  Core (Other) |  Version:  dev
 Severity:  Normal   |   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 Claude Paroz):

 * needs_docs:  1 => 0
 * needs_tests:  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/065.b9d11ce5d84c0804ab6d15f7f59bb4fb%40djangoproject.com.


Re: [Django] #32754: catch_all_view() does not support FORCE_SCRIPT_NAME.

2021-05-17 Thread Django
#32754: catch_all_view() does not support FORCE_SCRIPT_NAME.
-+-
 Reporter:  SlavaSkvortsov   |Owner:
 |  SlavaSkvortsov
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  Version:  3.2
 Severity:  Release blocker  |   Resolution:
 Keywords:  FORCE_SCRIPT_NAME| Triage Stage:  Accepted
  catch_all_view |
  final_catch_all_view   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by SlavaSkvortsov):

 Thank you for a quick answer!

 I wrote a patch [https://github.com/django/django/pull/14404 here]

-- 
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/072.276e5a79454a10307e0df9a559e8877e%40djangoproject.com.


Re: [Django] #32754: catch_all_view() does not support FORCE_SCRIPT_NAME.

2021-05-17 Thread Django
#32754: catch_all_view() does not support FORCE_SCRIPT_NAME.
-+-
 Reporter:  SlavaSkvortsov   |Owner:
 |  SlavaSkvortsov
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  Version:  3.2
 Severity:  Release blocker  |   Resolution:
 Keywords:  FORCE_SCRIPT_NAME| Triage Stage:  Accepted
  catch_all_view |
  final_catch_all_view   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by SlavaSkvortsov:

Old description:

> `catch_all_view` returns redirect to `'%s/' % request.path_info` (script
> name cut off there) instead of `'%s/' % request.path` (with the script
> name)

New description:

 `catch_all_view` returns redirect to `'%s/' % request.path_info` (script
 name cut off there) instead of `'%s/' % request.path` (with the script
 name)

 Patch - https://github.com/django/django/pull/14404

--

-- 
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/072.48e2faa2009f080011b096c4c7e2372c%40djangoproject.com.


Re: [Django] #32754: catch_all_view() does not support FORCE_SCRIPT_NAME. (was: catch_all_view from admin does not support FORCE_SCRIPT_NAME)

2021-05-17 Thread Django
#32754: catch_all_view() does not support FORCE_SCRIPT_NAME.
-+-
 Reporter:  SlavaSkvortsov   |Owner:
 |  SlavaSkvortsov
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  Version:  3.2
 Severity:  Release blocker  |   Resolution:
 Keywords:  FORCE_SCRIPT_NAME| Triage Stage:  Accepted
  catch_all_view |
  final_catch_all_view   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * status:  new => assigned
 * severity:  Normal => Release blocker
 * cc: Jon Dufresne (added)
 * owner:  nobody => SlavaSkvortsov
 * stage:  Unreviewed => Accepted


Comment:

 Thanks for the report, good catch! Bug in
 ba31b0103442ac891fb3cb98f316781254e366c3.

-- 
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/072.61b263ac7edb8a60019760f8900c2a6f%40djangoproject.com.


Re: [Django] #32752: Annotation yields ProgrammingError error when migrating from 2.2 to 3.x

2021-05-17 Thread Django
#32752: Annotation yields ProgrammingError error when migrating from 2.2 to 3.x
-+-
 Reporter:  Maarten van Keulen   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Maarten van Keulen):

 Replying to [comment:1 Mariusz Felisiak]:
 > Duplicate of #31135. You should use `p_user=F('authors__user')`.

 Good fit, m.b. thank you reviewing the issue swiftly.

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


[Django] #32754: catch_all_view from admin does not support FORCE_SCRIPT_NAME

2021-05-17 Thread Django
#32754: catch_all_view from admin does not support FORCE_SCRIPT_NAME
-+-
   Reporter: |  Owner:  nobody
  SlavaSkvortsov |
   Type:  Bug| Status:  new
  Component: |Version:  3.2
  contrib.admin  |   Keywords:  FORCE_SCRIPT_NAME
   Severity:  Normal |  catch_all_view final_catch_all_view
   Triage Stage: |  Has patch:  1
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 `catch_all_view` returns redirect to `'%s/' % request.path_info` (script
 name cut off there) instead of `'%s/' % request.path` (with the script
 name)

-- 
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/057.ceb7937c931e4a8c04dfe320886503d8%40djangoproject.com.


Re: [Django] #32749: PyMemcacheCache uses default_noreply=False although pymemcache recommends to set to True

2021-05-17 Thread Django
#32749: PyMemcacheCache uses default_noreply=False although pymemcache 
recommends
to set to True
-+-
 Reporter:  yakirsudry   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Cache system)  |  Version:  3.2
 Severity:  Normal   |   Resolution:
 Keywords:  pymemcache   | Triage Stage:
  PyMemcacheCache|  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: Nick Pope (added)
 * component:  Uncategorized => Core (Cache system)


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


Re: [Django] #32753: Object of type Pacific/Honolulu is not JSON serializable

2021-05-17 Thread Django
#32753: Object of type Pacific/Honolulu is not JSON serializable
--+--
 Reporter:  hellorahulnarang  |Owner:  nobody
 Type:  Uncategorized |   Status:  closed
Component:  Uncategorized |  Version:  3.2
 Severity:  Normal|   Resolution:  needsinfo
 Keywords:| Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by Mariusz Felisiak):

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


Comment:

 Hi, I don't think you've explained the issue in enough detail to confirm a
 bug in Django. Please reopen the ticket if you can debug your issue and
 provide details about why and where Django is at fault. If you're having
 trouble understanding how Django works, see
 TicketClosingReasons/UseSupportChannels for ways to get help.

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

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


Re: [Django] #32752: Annotation yields ProgrammingError error when migrating from 2.2 to 3.x

2021-05-17 Thread Django
#32752: Annotation yields ProgrammingError error when migrating from 2.2 to 3.x
-+-
 Reporter:  Maarten van Keulen   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

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


Comment:

 Duplicate of #31135. You should use `p_user=F('authors__user')`.

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


[Django] #32753: Object of type Pacific/Honolulu is not JSON serializable

2021-05-17 Thread Django
#32753: Object of type Pacific/Honolulu is not JSON serializable
+--
   Reporter:  hellorahulnarang  |  Owner:  nobody
   Type:  Uncategorized | Status:  assigned
  Component:  Uncategorized |Version:  3.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 |
+--


-- 
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/059.93840d36d2002ce7cf643232b94937ee%40djangoproject.com.


Re: [Django] #32750: ExtractMonth from OuterRef in Subquery don't work

2021-05-17 Thread Django
#32750: ExtractMonth from OuterRef in Subquery don't work
-+-
 Reporter:  Chiorufarewerin  |Owner:
 |  Chiorufarewerin
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * stage:  Accepted => Ready for checkin


Comment:

 [https://github.com/django/django/pull/14400 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/073.b9bdeda4501a2029c8832025b770aa95%40djangoproject.com.


Re: [Django] #32720: Add configuration for Sphinx linkcheck builder.

2021-05-17 Thread Django
#32720: Add configuration for Sphinx linkcheck builder.
-+-
 Reporter:  Nick Pope|Owner:  Nick Pope
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  dev
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  linkcheck| Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"cb91b2d9e3e28d0ede24dbb052faa6e7fead5897" cb91b2d]:
 {{{
 #!CommitTicketReference repository=""
 revision="cb91b2d9e3e28d0ede24dbb052faa6e7fead5897"
 [3.2.x] Refs #32720 -- Updated various links in docs to avoid redirects
 and use HTTPS.

 Backport of c156e369553c75a30c78b8ed54a57b1101865105 from main
 }}}

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

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


Re: [Django] #32720: Add configuration for Sphinx linkcheck builder.

2021-05-17 Thread Django
#32720: Add configuration for Sphinx linkcheck builder.
-+-
 Reporter:  Nick Pope|Owner:  Nick Pope
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  dev
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  linkcheck| Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"80cf193d32eae3a5250a5d195aefbb4fe9211d7a" 80cf193]:
 {{{
 #!CommitTicketReference repository=""
 revision="80cf193d32eae3a5250a5d195aefbb4fe9211d7a"
 [3.2.x] Refs #32720 -- Used :commit: and :source: role in old release
 notes.

 Backport of 8c4caee76a5571c6c8050660a6a9fc30ece6678d from main
 }}}

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

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


Re: [Django] #32720: Add configuration for Sphinx linkcheck builder.

2021-05-17 Thread Django
#32720: Add configuration for Sphinx linkcheck builder.
-+-
 Reporter:  Nick Pope|Owner:  Nick Pope
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  dev
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  linkcheck| Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"55b89e8cac2f8cc7cf3f96dfa138b3b9fda81160" 55b89e8]:
 {{{
 #!CommitTicketReference repository=""
 revision="55b89e8cac2f8cc7cf3f96dfa138b3b9fda81160"
 [3.2.x] Refs #32720 -- Fixed some broken links in docs.

 Backport of 7c4ee487c7392a3a394caf62efad355fad639655 from main
 }}}

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

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


Re: [Django] #32720: Add configuration for Sphinx linkcheck builder.

2021-05-17 Thread Django
#32720: Add configuration for Sphinx linkcheck builder.
-+-
 Reporter:  Nick Pope|Owner:  Nick Pope
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  dev
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  linkcheck| Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"0c19b075b239bc99886979c9af706b18e634ed69" 0c19b075]:
 {{{
 #!CommitTicketReference repository=""
 revision="0c19b075b239bc99886979c9af706b18e634ed69"
 [3.2.x] Refs #32720 -- Used full hashes in security archive.

 Backport of 1c3bbcf802e661fc599365a097532ed3b362d16b from main
 }}}

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

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


Re: [Django] #32720: Add configuration for Sphinx linkcheck builder.

2021-05-17 Thread Django
#32720: Add configuration for Sphinx linkcheck builder.
-+-
 Reporter:  Nick Pope|Owner:  Nick Pope
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Documentation|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  linkcheck| Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"7c4ee487c7392a3a394caf62efad355fad639655" 7c4ee48]:
 {{{
 #!CommitTicketReference repository=""
 revision="7c4ee487c7392a3a394caf62efad355fad639655"
 Refs #32720 -- Fixed some broken links in docs.
 }}}

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


Re: [Django] #32720: Add configuration for Sphinx linkcheck builder.

2021-05-17 Thread Django
#32720: Add configuration for Sphinx linkcheck builder.
-+-
 Reporter:  Nick Pope|Owner:  Nick Pope
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  dev
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  linkcheck| 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 Mariusz Felisiak ):

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


Comment:

 In [changeset:"0851933cba7b40e22f5e424c95763dbc27c40aa9" 0851933]:
 {{{
 #!CommitTicketReference repository=""
 revision="0851933cba7b40e22f5e424c95763dbc27c40aa9"
 Fixed #32720 -- Added configuration and docs for Sphinx link checker.

 We explicitly ignore checking anchors for line-range anchors on GitHub
 which are dynamically generated and, otherwise, show up as broken links.

 See https://github.com/sphinx-
 doc/sphinx/issues/7388#issuecomment-739961689.

 We also ignore links to resources that require authentication.
 }}}

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


Re: [Django] #32720: Add configuration for Sphinx linkcheck builder.

2021-05-17 Thread Django
#32720: Add configuration for Sphinx linkcheck builder.
-+-
 Reporter:  Nick Pope|Owner:  Nick Pope
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Documentation|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  linkcheck| Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"1c3bbcf802e661fc599365a097532ed3b362d16b" 1c3bbcf]:
 {{{
 #!CommitTicketReference repository=""
 revision="1c3bbcf802e661fc599365a097532ed3b362d16b"
 Refs #32720 -- Used full hashes in security archive.
 }}}

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


Re: [Django] #32720: Add configuration for Sphinx linkcheck builder.

2021-05-17 Thread Django
#32720: Add configuration for Sphinx linkcheck builder.
-+-
 Reporter:  Nick Pope|Owner:  Nick Pope
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Documentation|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  linkcheck| Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"c156e369553c75a30c78b8ed54a57b1101865105" c156e369]:
 {{{
 #!CommitTicketReference repository=""
 revision="c156e369553c75a30c78b8ed54a57b1101865105"
 Refs #32720 -- Updated various links in docs to avoid redirects and use
 HTTPS.
 }}}

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


Re: [Django] #32720: Add configuration for Sphinx linkcheck builder.

2021-05-17 Thread Django
#32720: Add configuration for Sphinx linkcheck builder.
-+-
 Reporter:  Nick Pope|Owner:  Nick Pope
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Documentation|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  linkcheck| Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"8c4caee76a5571c6c8050660a6a9fc30ece6678d" 8c4caee7]:
 {{{
 #!CommitTicketReference repository=""
 revision="8c4caee76a5571c6c8050660a6a9fc30ece6678d"
 Refs #32720 -- Used :commit: and :source: role in old release notes.
 }}}

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


Re: [Django] #32751: Add link from Session object to User object

2021-05-17 Thread Django
#32751: Add link from Session object to User object
--+--
 Reporter:  David |Owner:  nobody
 Type:  New feature   |   Status:  closed
Component:  contrib.sessions  |  Version:  4.0
 Severity:  Normal|   Resolution:  duplicate
 Keywords:| Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+--
Changes (by Mariusz Felisiak):

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


Comment:

 Duplicate of #19449.

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


[Django] #32752: Annotation yields ProgrammingError error when migrating from 2.2 to 3.x

2021-05-17 Thread Django
#32752: Annotation yields ProgrammingError error when migrating from 2.2 to 3.x
-+
   Reporter:  mjvkeulen  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Uncategorized  |Version:  3.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  |
-+
 I am in the process of migrating from Django 2.2 to 3.2. After fixing most
 deprecation issues, an annotation I rely on throughout my project is
 throwing a syntax error.

 This is a bit of a mystery to me since the upgrade path lists nothing on
 this topic. Also, it does not appear to matter which 3.x version I use,
 BUT this annotation has worked throughout most of 2.2.x's versions.

 {{{
 Journal.objects.annotate(
 p_user=F('assignment__courses__participation__user'),
 
can_have_journal=F('assignment__courses__participation__role__can_have_journal'),
 ).filter(
 Q(assignment__is_group_assignment=True) |
 Q(p_user__in=F('authors__user'), can_have_journal=True),
 )
 }}}

 Here is a diff of the generated SQL: https://www.diffchecker.com/fjlO30AD

 This is the errror:

 {{{
 django.db.utils.ProgrammingError: syntax error at or near
  "VLE_assignmentparticipation""
 LINE 1: ...ave_journal" AND "VLE_participation"."user_id" IN "VLE_assig...
 }}}

 Part of the trace:

 {{{
 venv/lib/python3.8/site-packages/django/db/models/query.py:317: in
 __getitem__
 qs._fetch_all()
 venv/lib/python3.8/site-packages/django/db/models/query.py:1324: in
 _fetch_all
 self._result_cache = list(self._iterable_class(self))
 venv/lib/python3.8/site-packages/django/db/models/query.py:51: in __iter__
 results = compiler.execute_sql(chunked_fetch=self.chunked_fetch,
 chunk_size=self.chunk_size)
 venv/lib/python3.8/site-packages/django/db/models/sql/compiler.py:1169: in
 execute_sql
 cursor.execute(sql, params)
 venv/lib/python3.8/site-
 packages/sentry_sdk/integrations/django/__init__.py:434: in execute
 return real_execute(self, sql, params)
 venv/lib/python3.8/site-packages/django/db/backends/utils.py:66: in
 execute
 return self._execute_with_wrappers(sql, params, many=False,
 executor=self._execute)
 venv/lib/python3.8/site-packages/django/db/backends/utils.py:75: in
 _execute_with_wrappers
 return executor(sql, params, many, context)
 venv/lib/python3.8/site-packages/django/db/backends/utils.py:84: in
 _execute
 return self.cursor.execute(sql, params)
 venv/lib/python3.8/site-packages/django/db/utils.py:90: in __exit__
 raise dj_exc_value.with_traceback(traceback) from exc_value
 }}}

 I attempted to dress down our repo so it would be more straightforward to
 reproduce the issue: https://github.com/eJourn-al/bug_report
 The single test should pass on Django 2.2.x and fail from Django 3.x.

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


Re: [Django] #26430: Coalesce in Aggregations ignored when EmptyResultSet returned

2021-05-17 Thread Django
#26430: Coalesce in Aggregations ignored when EmptyResultSet returned
-+-
 Reporter:  Ryan Prater  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  1.9
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  aggregation  | Triage Stage:  Accepted
  coalesce in queryset   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Anton Agestam):

 * cc: Anton Agestam (added)


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

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


[Django] #32751: Add link from Session object to User object

2021-05-17 Thread Django
#32751: Add link from Session object to User object
+
   Reporter:  David |  Owner:  nobody
   Type:  Uncategorized | Status:  new
  Component:  contrib.sessions  |Version:  4.0
   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 |
+
 When designing web apps, a common pattern is presenting users with a list
 of existing sessions (and the subsequent ability to end any or all of
 their existing open sessions). This is useful for a number of security
 reasons, and allows users to make sure there are no open sessions they
 don't recognize.

 However, currently Django has no direct link from a `Session` to  an
 authenticated `User`. There are multiple projects (`django-user-sessions`
 and `django-qsessions`) that exist largely to add this functionality, and
 a series of blog and Stackoverflow threads advocating various other
 solutions including the use of a secondary `UserSession` model with
 `ForeignKey` fields linking to the current session and current user. This
 method is the least disruptive to stock Django, although not perfect
 either since the session isn't always saved by the time the `logged_in`
 signal fires.

 Adding a `user` field to the existing `Session` model would add this
 significant functionality and remove the need for external packages and
 user workarounds. Systems that wanted to track additional information
 about sessions could still override and extend the model, but for many
 users a simple link from sessions to users would likely be sufficient. An
 additional field in the Session would would maintain backward
 compatibility as sessions could be updated to save the field as they were
 accessed again, and/or developers could be advised to clear existing
 sessions if they want to use this functionality from the start.

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


Re: [Django] #32723: Add a GitHub action to run the Sphinx linkcheck builder.

2021-05-17 Thread Django
#32723: Add a GitHub action to run the Sphinx linkcheck builder.
-+-
 Reporter:  Nick Pope|Owner:  Sarah
 Type:   |  Abderemane
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  linkcheck, github,   | Triage Stage:
  action |  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Sarah Abderemane):

 * owner:  nobody => Sarah Abderemane
 * 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/065.0a44004893df0c0699619013dd925ccf%40djangoproject.com.


Re: [Django] #32733: DEFAULT_AUTO_FIELD feature leads `AbstractModel.check()` to fail with AttributeError

2021-05-17 Thread Django
#32733: DEFAULT_AUTO_FIELD feature leads `AbstractModel.check()` to fail with
AttributeError
-+-
 Reporter:  amureki  |Owner:  amureki
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by amureki):

 * 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/065.4d76a8d2a8fcd26072da8bae6ed64cb4%40djangoproject.com.


Re: [Django] #32720: Add configuration for Sphinx linkcheck builder.

2021-05-17 Thread Django
#32720: Add configuration for Sphinx linkcheck builder.
-+-
 Reporter:  Nick Pope|Owner:  Nick Pope
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Documentation|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  linkcheck| 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 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/065.5b680e7c86a20ef1d8b4dfbcb90063c5%40djangoproject.com.