[Django] #30285: The domain in broken link emails can be spoofed

[Django]

#30285: The domain in broken link emails can be spoofed
+
   Reporter:  orlnub123 |  Owner:  nobody
   Type:  Bug   | Status:  new
  Component:  Core (Other)  |Version:  master
   Severity:  Normal|   Keywords:  middleware
   Triage Stage:  Unreviewed|  Has patch:  1
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 When using BrokenLinkEmailsMiddleware, if an incoming request with a
 spoofed HTTP Host header 404s it'll use the spoofed header in the email
 subject.
 This isn't a big issue because the HTTP Host header gets validated against
 settings.ALLOWED_HOSTS, so it's only applicable on sites with multiple
 domains or with multiple settings.ALLOWED_HOSTS values.

 Here's a demo on a site with multiple settings.ALLOWED_HOSTS values:

 ''We start the server.''
 {{{
 [orlnub123@orlnub123 mysite]$ ./manage.py runserver
 Performing system checks...

 System check identified no issues (0 silenced).
 March 24, 2019 - 05:38:46
 Django version 2.1.7, using settings 'mysite.settings'
 Starting development server at http://127.0.0.1:8000/
 Quit the server with CONTROL-C.
 }}}

 ''Then send a normal request. The referer header here is important;
 without it the email won't get sent.''
 {{{
 [orlnub123@orlnub123 mysite]$ curl -H 'Referer:
 http://example.com/referrer' -w '\n' localhost:8000
 Not FoundThe requested resource was not found on this
 server.
 }}}

 ''We get the email; everything looks good.''
 {{{
 Content-Type: text/plain; charset="utf-8"
 MIME-Version: 1.0
 Content-Transfer-Encoding: 7bit
 Subject: [Django] Broken link on localhost:8000
 From: root@localhost
 To: j...@example.com
 Date: Sun, 24 Mar 2019 05:38:49 -
 Message-ID:
 <155340592942.14004.17031704219271235623@orlnub123.localdomain>

 Referrer: http://example.com/referrer
 Requested URL: /
 User agent: curl/7.64.0
 IP address: 127.0.0.1

 ---
 [24/Mar/2019 05:38:49] "GET / HTTP/1.1" 404 77
 }}}

 ''We send another request; this time with a spoofed host header.''
 {{{
 [orlnub123@orlnub123 mysite]$ curl -H 'Referer:
 http://example.com/referrer' -H 'Host: example.com' -w '\n' localhost:8000
 Not FoundThe requested resource was not found on this
 server.
 }}}

 ''Oh no! The subject contains our spoofed header and presents the link as
 an internal one.''
 {{{
 Content-Type: text/plain; charset="utf-8"
 MIME-Version: 1.0
 Content-Transfer-Encoding: 7bit
 Subject: [Django] Broken INTERNAL link on example.com
 From: root@localhost
 To: j...@example.com
 Date: Sun, 24 Mar 2019 05:38:59 -
 Message-ID:
 <155340593990.14004.12227248404736375101@orlnub123.localdomain>

 Referrer: http://example.com/referrer
 Requested URL: /
 User agent: curl/7.64.0
 IP address: 127.0.0.1

 ---
 [24/Mar/2019 05:38:59] "GET / HTTP/1.1" 404 77
 }}}

 I've fixed it by replacing the `request.get_host()` call with
 `get_current_site(request).domain`. This approach falls back to using
 `request.get_host()` internally on sites that don't use the sites
 framework. It isn't perfect, but it replicates what many other components
 do.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/052.f89411e5085bd05ea6a66ad1483628c6%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30284: Redundant is_active check in auth.backends.ModelBackend

[Django]

#30284: Redundant is_active check in auth.backends.ModelBackend
-+-
 Reporter:  Tobias Bengfort  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  contrib.auth |  Version:  master
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham):

 [https://groups.google.com/d/topic/django-
 developers/LC67za083Gw/discussion django-developers discussion]

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/060.6868d3bf7fac822df57188d235f12015%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30226: Add base authentication backend to ease custom backend creation.

[Django]

#30226: Add base authentication backend to ease custom backend creation.
-+
 Reporter:  Tobias Bengfort  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  contrib.auth |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by Tobias Bengfort):

 * 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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/060.29ca2ce2dd5100297c5b115db580addb%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29791: Engine.render_to_string() should honor the autoescape attribute

[Django]

#29791: Engine.render_to_string() should honor the autoescape attribute
-+
 Reporter:  Claude Paroz |Owner:  Claude Paroz
 Type:  Bug  |   Status:  assigned
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by Simon Charette):

 * cc: Claude Paroz (added)


Comment:

 I think it's safe to re-assign yourself the ticket to you at this point.
 Are you still planing on working on this in the near future Claude?

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.fb281875121ea904e9a530aa930dfd24%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30284: Redundant is_active check in auth.backends.ModelBackend

[Django]

#30284: Redundant is_active check in auth.backends.ModelBackend
-+-
 Reporter:  Tobias Bengfort  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  contrib.auth |  Version:  master
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

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


Comment:

 Both Mariusz and I raised doubts that this is a good idea. Please raise
 the issue on the DevelopersMailingList to see if there's consensus
 otherwise. If it's accepted (at which point we could reopen this ticket),
 the commit should be in a separate PR rather than lumped in with other
 features. Thanks.

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

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

Re: [Django] #30284: Redundant is_active check in auth.backends.ModelBackend

[Django]

#30284: Redundant is_active check in auth.backends.ModelBackend
-+-
 Reporter:  Tobias Bengfort  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  contrib.auth |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Tobias Bengfort:

Old description:

> See https://github.com/django/django/pull/11037
>
> `User.is_active` is checked in `ModelBackend.get_all_permissions()`,
> `ModelBackend.has_perm()` and `ModelBackend.has_module_perms()`. I think
> the last two are redundant and should be removed.
>
> timgraham had
> [https://github.com/django/django/pull/11037#pullrequestreview-217534553
> concerns] though:
>
> > I'm unsure about removing the "redundant" is_active checks. It might be
> that some ModelBackend sublcasses rely on them. For example, if you
> subclass get_all_permissions() and omitting the is_active check (which
> wasn't there prior to Django 1.8
> [https://github.com/django/django/commit/c33447a50c1b0a96c6e2261f7c45d2522a3fe28d
> c33447a])... then your application would still have is_active checks in
> the other methods. This needs careful consideration and perhaps a
> discussion on the mailing list as to whether the benefits are worth the
> possible security issues. At least a release note is required. I'm not
> sure if this is required as part of the "BaseBackend" change, but I think
> it merits its own ticket.
>
> My opinion is exactly the opposite: If a ModelBackend subclass does not
> check `is_active` in `get_all_permissions()` that is a bug and
> potentially even a security issue. The redundand checks  hide these
> issues and therefore make it harder to find them.
>
> I also think that the different methods should be consitent: If a
> permission is returned by `get_all_permissions()`, then checking that
> permission with `has_perm()` should return `True`. The only reason to do
> anything special in `has_perm()` is for performance optimizations.

New description:

 See https://github.com/django/django/pull/11037

 `User.is_active` is checked in `ModelBackend` on all of these methods:

 - `get_user_permissions()`
 - `get_group_permissions()`
 - `get_all_permissions()`
 - `has_perm()`
 - `has_module_perms()`

 I think the last three are redundant and should be removed.

 timgraham had
 [https://github.com/django/django/pull/11037#pullrequestreview-217534553
 concerns] though:

 > I'm unsure about removing the "redundant" is_active checks. It might be
 that some ModelBackend sublcasses rely on them. For example, if you
 subclass get_all_permissions() and omitting the is_active check (which
 wasn't there prior to Django 1.8
 
[https://github.com/django/django/commit/c33447a50c1b0a96c6e2261f7c45d2522a3fe28d
 c33447a])... then your application would still have is_active checks in
 the other methods. This needs careful consideration and perhaps a
 discussion on the mailing list as to whether the benefits are worth the
 possible security issues.

 My opinion is exactly the opposite: If a ModelBackend subclass does not
 check `is_active` in `get_all_permissions()` that is a bug and potentially
 even a security issue. The redundand checks hide these issues and
 therefore make it harder to find them.

 I also think that the different methods should be consitent: If a
 permission is returned by `get_all_permissions()`, then checking that
 permission with `has_perm()` should return `True`. The only reason to do
 anything special in `has_perm()` is for performance optimizations.

--

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/060.2cab0b4206494f4ff543300993392972%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29539: Cannot use Aggregation function in Model.Meta.ordering

[Django]

#29539: Cannot use Aggregation function in Model.Meta.ordering
-+-
 Reporter:  wilhelmhb|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  ordering, query  | Triage Stage:  Accepted
  expression, aggregation function   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

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


Comment:

 From Simon on the pull request:
  I think this feature would be hard to get right for the rare case where
 it's useful. It also go against our stance on trying to disconnect
 Meta.ordering from aggregation (#14357) as this PR demonstrates. I'd be in
 favour of won't fixing the ticket as well for these reasons. It feels
 incoherent with the ongoing deprecation motivated by observed user
 confusion over the years from the interactions between these two features.

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

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

[Django] #30284: Redundant is_active check in auth.backends.ModelBackend

[Django]

#30284: Redundant is_active check in auth.backends.ModelBackend
+
   Reporter:  Tobias Bengfort   |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  contrib.auth  |Version:  master
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  1
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 See https://github.com/django/django/pull/11037

 `User.is_active` is checked in `ModelBackend.get_all_permissions()`,
 `ModelBackend.has_perm()` and `ModelBackend.has_module_perms()`. I think
 the last two are redundant and should be removed.

 timgraham had
 [https://github.com/django/django/pull/11037#pullrequestreview-217534553
 concerns] though:

 > I'm unsure about removing the "redundant" is_active checks. It might be
 that some ModelBackend sublcasses rely on them. For example, if you
 subclass get_all_permissions() and omitting the is_active check (which
 wasn't there prior to Django 1.8
 
[https://github.com/django/django/commit/c33447a50c1b0a96c6e2261f7c45d2522a3fe28d
 c33447a])... then your application would still have is_active checks in
 the other methods. This needs careful consideration and perhaps a
 discussion on the mailing list as to whether the benefits are worth the
 possible security issues. At least a release note is required. I'm not
 sure if this is required as part of the "BaseBackend" change, but I think
 it merits its own ticket.

 My opinion is exactly the opposite: If a ModelBackend subclass does not
 check `is_active` in `get_all_permissions()` that is a bug and potentially
 even a security issue. The redundand checks  hide these issues and
 therefore make it harder to find them.

 I also think that the different methods should be consitent: If a
 permission is returned by `get_all_permissions()`, then checking that
 permission with `has_perm()` should return `True`. The only reason to do
 anything special in `has_perm()` is for performance optimizations.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/045.4112ceabd5a3384a84a2ebee6ea8bd86%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29918: Add support for checking object permissions in PermissionRequiredMixin

[Django]

#29918: Add support for checking object permissions in PermissionRequiredMixin
-+--
 Reporter:  Tobias Bengfort  |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  contrib.auth |  Version:  2.1
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--

Comment (by Tobias Bengfort):

 I strongly disagree on the idea that django-guardian is the only relevant
 backend. Another well known one is django-rules. People can also write
 their own, non-reusable backends. I don't see why you should need to
 depend on django-guardian in these cases.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/060.198a3b188e4cda7601f33f0da1e04b65%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30272: get_language_from_path not respecting i18n_patterns prefix_default_language=False

[Django]

#30272: get_language_from_path not respecting i18n_patterns
prefix_default_language=False
-+-
 Reporter:  Stefan Wehrmeyer |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:   |  Version:  2.1
  Internationalization   |
 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 Stefan Wehrmeyer):

 Sorry, some more details about the use case.

 I'm running a Django CMS instance with their URLs included via
 `i18n_patterns` and `prefix_default_language=False`. I want the URL path
 to determine what language to serve (and `LocaleMiddleware` set this
 language correctly!).

 The problem is that Django CMS relies on `get_language_from_request`
 ([https://github.com/divio/django-
 cms/blob/eeb1e4712b3866e243daf800c142e2199e4be9df/cms/views.py#L85 e.g.
 here]) to detect which language to serve without the additional logic that
 is included in `LocaleMiddleware` to special case
 `prefix_default_language=False`.

 Example URLs with default language "en":
 - `/de/ueber/` – `LocaleMiddleware` sets "de", `get_language_from_request`
 with `check_path=True` returns "de"
 - `/about/` – `LocaleMiddleware` sets "en", `get_language_from_request`
 with `check_path=True` returns whatever is in session, language cookie or
 HTTP `Accept-Language` header, but should return "en" like
 `LocaleMiddleware`

 This leads in turn to the wrong language being served. This could
 certainly be solved in Django CMS as well.

 But currently there are cases when `LocaleMiddleware` will set a different
 language on the request than is returned by `get_language_from_request` –
 which makes this public API inconsistent IMHO.

 Thanks for taking the time to look into this. I can try to provide a test
 case if this makes it clearer.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.6f0b8f81edb173f7931fb5560f69dfdc%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30226: Add base authentication backend to ease custom backend creation.

[Django]

#30226: Add base authentication backend to ease custom backend creation.
-+
 Reporter:  Tobias Bengfort  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  contrib.auth |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+
Changes (by Tim Graham):

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


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

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

Re: [Django] #30267: GeoDjango does not create correct PostGIS index for 3D geometry fields

[Django]

#30267: GeoDjango does not create correct PostGIS index for 3D geometry fields
--+
 Reporter:  Casper van der Wel|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  GIS   |  Version:  1.11
 Severity:  Normal|   Resolution:
 Keywords:  geodjango, postgis| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Tim Graham):

 * stage:  Unreviewed => Accepted


Comment:

 Tentatively accepting, however as I'm not a GeoDjango user, I'd like to
 see a consensus on the [https://groups.google.com/forum/#!forum/geodjango
 geodjango mailing list] before work proceeds.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.f545809f97f723e2bd21c04017b6c4c2%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28477: Strip unused annotations from count queries

[Django]

#28477: Strip unused annotations from count queries
-+-
 Reporter:  Tom Forbes   |Owner:  Tom
 Type:   |  Forbes
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Reupen Shah):

 Just a note to say that the behaviour I was describing was rectified in
 https://github.com/django/django/pull/11062.

 The third case from above now executes the following SQL query:

 {{{
 SELECT COUNT(*) FROM (
 SELECT CONCAT("people_person"."first_name", CONCAT(' ',
 "people_person"."last_name")) AS "full_name" FROM "people_person"
 ) subquery
 }}}

 Although the original ticket was about eliminating unneeded annotations
 completely, the result above is good enough for me, as the group by has
 been eliminated which was the real performance killer.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/061.b2341b4e81a7e803838c69b39ed81c54%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29791: Engine.render_to_string() should honor the autoescape attribute

[Django]

#29791: Engine.render_to_string() should honor the autoescape attribute
-+
 Reporter:  Claude Paroz |Owner:  Claude Paroz
 Type:  Bug  |   Status:  assigned
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+

Comment (by Nathan Gaberel):

 I'd like to give this a try. Is it OK to reassign to myself since there's
 been no update in 6 months?

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.f74bda2c5363deaa9afc0e87f4f6995a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30272: get_language_from_path not respecting i18n_patterns prefix_default_language=False

[Django]

#30272: get_language_from_path not respecting i18n_patterns
prefix_default_language=False
-+-
 Reporter:  Stefan Wehrmeyer |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:   |  Version:  2.1
  Internationalization   |
 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 Carlton Gibson):

 Why wouldn't `get_language_from_path() or settings.LANGUAGE_CODE` do you?
 (Just trying to understand the use-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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.276ac17a5f3c55260ca3eedf5edbcee6%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #27360: Make it easier to track down the offending models for AlreadyRegistered exceptions

[Django]

#27360: Make it easier to track down the offending models for AlreadyRegistered
exceptions
-+-
 Reporter:  Ed Morley|Owner:  Quentin
 Type:   |  Fulsher
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.admin|  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Hasan Ramezani):

 * 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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.f218fba153927298b8ac2a73fbc310f9%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29539: Cannot use Aggregation function in Model.Meta.ordering

[Django]

#29539: Cannot use Aggregation function in Model.Meta.ordering
-+-
 Reporter:  wilhelmhb|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  ordering, query  | Triage Stage:  Accepted
  expression, aggregation function   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Can Sarıgöl):

 * 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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.26bbdd38eb0424b9610e194fc8bbc8b3%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29700: Document ModelAdmin.autocomplete_view() and AutocompleteJsonView (as customisation point).

[Django]

#29700: Document ModelAdmin.autocomplete_view() and AutocompleteJsonView (as
customisation point).
-+-
 Reporter:  David W. Lloyd   |Owner:  Alexandru
 Type:   |  Balan
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * needs_better_patch:  0 => 1


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

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

Re: [Django] #30283: Lint errors in django_bash_completion script

[Django]

#30283: Lint errors in django_bash_completion script
-+-
 Reporter:  albertyw |Owner:  albertyw
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Utilities|  Version:  2.1
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"2ee1e1a1744c4d0679058124eb7ceba78a0a5a84" 2ee1e1a]:
 {{{
 #!CommitTicketReference repository=""
 revision="2ee1e1a1744c4d0679058124eb7ceba78a0a5a84"
 Fixed #30283 -- Fixed shellcheck warnings in django_bash_completion.
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.00e7d2820a25b344b58a5dbdbcb0c4c3%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30188: Aggregate annotation, Case() - When(): AssertionError No exception message supplied

[Django]

#30188: Aggregate annotation, Case() - When(): AssertionError No exception 
message
supplied
-+-
 Reporter:  Lukas Klement|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  query, aggregate,| Triage Stage:  Accepted
  case/when  |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"3f32154f40a855afa063095e3d091ce6be21f2c5" 3f32154]:
 {{{
 #!CommitTicketReference repository=""
 revision="3f32154f40a855afa063095e3d091ce6be21f2c5"
 Refs #30188 -- Avoided GROUP BY when aggregating over non-aggregates.
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/070.daf9864f2a8060cf51d25042e1fc4795%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30188: Aggregate annotation, Case() - When(): AssertionError No exception message supplied

[Django]

#30188: Aggregate annotation, Case() - When(): AssertionError No exception 
message
supplied
-+-
 Reporter:  Lukas Klement|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  query, aggregate,| Triage Stage:  Accepted
  case/when  |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"bdc07f176eb7c099ac3fdc42ebaadd48b7f67409" bdc07f1]:
 {{{
 #!CommitTicketReference repository=""
 revision="bdc07f176eb7c099ac3fdc42ebaadd48b7f67409"
 Fixed #30188 -- Fixed a crash when aggregating over a subquery annotation.
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/070.240923805aadeab8d776b01a33527d87%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30246: Using an annotated field calculated with django.db.models.functions.Extract in aggregate results in ProgrammingError

[Django]

#30246: Using an annotated field calculated with 
django.db.models.functions.Extract
in aggregate results in ProgrammingError
-+-
 Reporter:  Jan Baryła   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  query, aggregate,| Triage Stage:  Accepted
  extract, annotate, postgresql  |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"1ca825e4dc186da2b93292b5c848a3e5445968d7" 1ca825e]:
 {{{
 #!CommitTicketReference repository=""
 revision="1ca825e4dc186da2b93292b5c848a3e5445968d7"
 Fixed #30246 -- Reused annotation aliases references in aggregation
 filters.

 Thanks Jan Baryła for the detailed report and the reduced test 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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.326b4a16f67c0aebcd3c59880e6fdd1a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #21703: `exclude` query with `F` object across relationship fails

[Django]

#21703: `exclude` query with `F` object across relationship fails
-+-
 Reporter:  anonymous|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  1.6
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"f19a4945e1191e1696f1ad8e6cdc6f939c702728" f19a4945]:
 {{{
 #!CommitTicketReference repository=""
 revision="f19a4945e1191e1696f1ad8e6cdc6f939c702728"
 Fixed #21703 -- Fixed a crash when excluding a related field with a F().
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.66eff3648dc28df65d5ce5e91e82578a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30188: Aggregate annotation, Case() - When(): AssertionError No exception message supplied

[Django]

#30188: Aggregate annotation, Case() - When(): AssertionError No exception 
message
supplied
-+-
 Reporter:  Lukas Klement|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  query, aggregate,| Triage Stage:  Accepted
  case/when  |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"d1e9c25162eecb24dee50fcfe834a2735e53fb0e" d1e9c25]:
 {{{
 #!CommitTicketReference repository=""
 revision="d1e9c25162eecb24dee50fcfe834a2735e53fb0e"
 Refs #30188 -- Prevented double annotation of subquery when aggregated
 over.

 Thanks Can Sarıgöl for the suggested trimming approach.
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/070.11d7b77a2e90361679222fb51e1d812a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29539: Cannot use Aggregation function in Model.Meta.ordering

[Django]

#29539: Cannot use Aggregation function in Model.Meta.ordering
-+-
 Reporter:  wilhelmhb|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  ordering, query  | Triage Stage:  Accepted
  expression, aggregation function   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * needs_better_patch:  0 => 1


Comment:

 Removing the deprecation from #14357 isn't appropriate.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.8c3bd563894fd11eb130c5d4b287c2f1%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29706: RenameContentType._rename() doesn't save the content type on the correct database

[Django]

#29706: RenameContentType._rename() doesn't save the content type on the correct
database
-+-
 Reporter:  Tyler Morgan |Owner:  Hasan
 |  Ramezani
 Type:  Bug  |   Status:  assigned
Component:   |  Version:  master
  contrib.contenttypes   |
 Severity:  Normal   |   Resolution:
 Keywords:  RenameContentType| Triage Stage:  Accepted
  transaction atomic content_type|
  update_fields using|
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
 * has_patch:  1 => 0
 * needs_tests:  1 => 0


Comment:

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

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.1096a00220160120b8b8b76a9ccaab26%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30282: CSRF token invalid after DELETE request

[Django]

#30282: CSRF token invalid after DELETE request
-+-
 Reporter:  my-tien  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  CSRF |  Version:  2.1
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  CSRF RESTful-API | Triage Stage:
  DELETE |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

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


Comment:

 It looks like a support issue, not a bug in Django. Please use one of
 [https://code.djangoproject.com/wiki/TicketClosingReasons/UseSupportChannels
 support channels].

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.4be28182ddd7aa0a28a180f3189a409c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30272: get_language_from_path not respecting i18n_patterns prefix_default_language=False

[Django]

#30272: get_language_from_path not respecting i18n_patterns
prefix_default_language=False
-+-
 Reporter:  Stefan Wehrmeyer |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:   |  Version:  2.1
  Internationalization   |
 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 Stefan Wehrmeyer):

 Hey Carlton, thanks for reviewing.

 The problem with `get_language_from_request` is that the browser `Accept-
 Language` header is very likely set and will determine the language.
 However, I want the language to be determined by the path – even when
 `prefix_default_language=False`. This works with
 `prefix_default_language=True`.

 `LocaleMiddleware` actually does this, but does it around
 `get_language_from_request`:

 
https://github.com/django/django/blob/cbf7e71558c94ce1c327b683768a18a25d82d197/django/middleware/locale.py#L19-L24

 So maybe an idea could be to move these lines into
 `get_language_from_request` in order to make this logic available to other
 Django apps that rely on this API (in my case django cms). Not sure if
 this would be a backwards-incompatible change though.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.b33b494652b4e264b4bbecb0acd9167e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30283: Lint errors in django_bash_completion script

[Django]

#30283: Lint errors in django_bash_completion script
-+-
 Reporter:  albertyw |Owner:  albertyw
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Utilities|  Version:  2.1
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by albertyw):

 PR at https://code.djangoproject.com/ticket/30283

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.256c813fc097522333607af3e1beb94e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #30283: Lint errors in django_bash_completion script

[Django]

#30283: Lint errors in django_bash_completion script
+--
   Reporter:  albertyw  |  Owner:  albertyw
   Type:  Cleanup/optimization  | Status:  assigned
  Component:  Utilities |Version:  2.1
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  1
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+--
 The django_bash_completion script has a few bash lint warnings from
 shellcheck.  None of the errors are likely to affect users, except for
 using `grep -E` instead of `egrep` which should increase compatibility
 with different systems.

 {{{

 In extras/django_bash_completion line 1:
 #
 #
 ^-- SC2148: Tips depend on target shell and yours is unknown. Add a
 shebang.


 In extras/django_bash_completion line 46:
 echo $PYTHON_EXE | egrep "python([3-9]\.[0-9])?" >/dev/null 2>&1
  ^-- SC2086: Double quote to prevent globbing and word
 splitting.
^-- SC2196: egrep is non-standard and
 deprecated. Use grep -E instead.


 In extras/django_bash_completion line 47:
 if [[ $? == 0 ]]; then
   ^-- SC2181: Check exit code directly with e.g. 'if mycmd;',
 not indirectly with $?.


 In extras/django_bash_completion line 49:
 echo $PYTHON_SCRIPT | egrep "manage\.py|django-admin(\.py)?"
 >/dev/null 2>&1
  ^-- SC2086: Double quote to prevent globbing and word
 splitting.
   ^-- SC2196: egrep is non-standard and
 deprecated. Use grep -E instead.


 In extras/django_bash_completion line 50:
 if [[ $? == 0 ]]; then
   ^-- SC2181: Check exit code directly with e.g. 'if
 mycmd;', not indirectly with $?.


 In extras/django_bash_completion line 51:
 COMPREPLY=( $( COMP_WORDS="${COMP_WORDS[*]:1}" \
^-- SC2097: This assignment is only seen by
 the forked process.


 In extras/django_bash_completion line 53:
DJANGO_AUTO_COMPLETE=1 ${COMP_WORDS[*]} ) )
   ^-- SC2098: This
 expansion will not see the mentioned assignment.


 In extras/django_bash_completion line 67:
 pythons=$(echo $pythons | tr " " "\n" | sort -u | tr "\n" " ")
^-- SC2086: Double quote to prevent globbing and word
 splitting.
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/051.a5280910f6fba29a42c7a87f3ec8592b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.