date:20200914

Re: [Django] #32005: Allow disabling of auto-404-redirection in LocaleMiddleware

2020-09-14 Thread Django

#32005: Allow disabling of auto-404-redirection in LocaleMiddleware
-+-
 Reporter:  Alex Vandiver|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:   |  Version:  3.1
  Internationalization   |
 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
-+-

Comment (by Carlton Gibson):

 Looks like you've just introduced this issue here
 https://github.com/zulip/zulip/commit/536bd3188e9428993fd712ed2f0df7c160b6ad60
 🤔

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

Re: [Django] #32005: Allow disabling of auto-404-redirection in LocaleMiddleware

2020-09-14 Thread Django

#32005: Allow disabling of auto-404-redirection in LocaleMiddleware
-+-
 Reporter:  Alex Vandiver|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:   |  Version:  3.1
  Internationalization   |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * type:  Uncategorized => New feature


Old description:

> This is related to the last two comments on #17734.  Specifically, if an
> application decides to return an explicit 404, there is no way to prevent
> the LocaleMiddleware from overriding this and trying the language
> redirect.
>
> In those comments, it was about catch-all URL patterns.  I'm running into
> something related, but slightly different -- we [serve 404's for the `/`
> endpoint if the subdomain isn't
> valid](https://github.com/zulip/zulip/blob/master/zerver/middleware.py#L434),
> which the LocaleMiddleware unhelpfully redirects to (e.g.) `/en/` which
> isn't any less of a 404.
>
> Would folks be amenable to a patch which disabled the auto-404-redirect
> functionality in the middleware with a flag of some sort?

New description:

 This is related to the last two comments on #17734.  Specifically, if an
 application decides to return an explicit 404, there is no way to prevent
 the LocaleMiddleware from overriding this and trying the language
 redirect.

 In those comments, it was about catch-all URL patterns.  I'm running into
 something related, but slightly different -- we
 [https://github.com/zulip/zulip/blob/master/zerver/middleware.py#L434
 serve 404's for the `/` endpoint if the subdomain isn't valid], which the
 LocaleMiddleware unhelpfully redirects to (e.g.) `/en/` which isn't any
 less of a 404.

 Would folks be amenable to a patch which disabled the auto-404-redirect
 functionality in the middleware with a flag of some sort?

--

Comment:

 Hi Alex.

 Thanks for the report. Perhaps need an extra coffee to think through if
 it's going to be worth the complexity but... — is this not a middleware
 ordering issue? i.e. If you put your `HostDomainMiddleware` before
 `LocaleMiddleware` would the response returned in `process_request` not
 get sent back to the client before `LocaleMiddleware` ever got the chance
 to look at it?

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

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

Re: [Django] #32004: Improve documentation of request.FILES

2020-09-14 Thread Django

#32004: Improve documentation of request.FILES
--+
 Reporter:  Janos Roden   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  3.1
 Severity:  Normal|   Resolution:
 Keywords:  upload| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Carlton Gibson):

 * stage:  Unreviewed => Accepted


Comment:

 HI Janos, yes OK. Very happy to look at a suggestion to the docs here.
 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.895a41290b4a52633aaad5b5eb45f2f3%40djangoproject.com.

Re: [Django] #32002: Allow headers to be passed into HttpResponse()

2020-09-14 Thread Django

#32002: Allow headers to be passed into HttpResponse()
---+---
 Reporter:  Tom Carrick|Owner:  Tom Carrick
 Type:  New feature|   Status:  assigned
Component:  HTTP handling  |  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 Carlton Gibson):

 * stage:  Unreviewed => Accepted


Comment:

 Yes, as per discussion, certainly for the main feature.

 > I think it also makes sense to add this to django.shortcuts.render.

 I'm initially sceptical about this. I think we should be cautious about
 adding extra parameters to shortcuts.
 My inclination would be towards saying, "Either adjust the response once
 you have it, or don't use `render`" if folks need more than it currently
 offers. (Note: "...initially sceptical...".)

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

Re: [Django] #31617: Improve overall admin accessibility.

2020-09-14 Thread Django

#31617: Improve overall admin accessibility.
-+-
 Reporter:  Gustavo Siñovsky |Owner:  Bhavna
 Type:  New feature  |   Status:  assigned
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  accessibility, ui,   | Triage Stage:
  ux, admin  |  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  1
-+-
Changes (by Bhavna):

 * owner:  (none) => Bhavna
 * 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/067.06b3bcc50928466745ac9a8aa867d9ea%40djangoproject.com.

Re: [Django] #31983: Add a warning if the file system cache location is within the static or media roots

2020-09-14 Thread Django

#31983: Add a warning if the file system cache location is within the static or
media roots
--+
 Reporter:  christa   |Owner:  christa
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Core (Cache system)   |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  cache check   | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  1
  Needs tests:  1 |  Patch needs improvement:  1
Easy pickings:  1 |UI/UX:  0
--+
Changes (by felixxm):

 * owner:  Bhavna => christa


Comment:

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

 Bhavna, patch is already prepared.

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

Re: [Django] #31983: Add a warning if the file system cache location is within the static or media roots

2020-09-14 Thread Django

#31983: Add a warning if the file system cache location is within the static or
media roots
-+-
 Reporter:  christa  |Owner:  Bhavna777
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Core (Cache system)  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  cache check  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Bhavna777):

 * owner:  nobody => Bhavna777
 * 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/067.644cd3896cbf0b562d78ad00a267d76b%40djangoproject.com.

Re: [Django] #32006: Aggregation generates wrong SQL query on PostgreSQL partionned tables. (was: QuerySet with values with annotate generates wrong SQL query on PostgreSQL.)

2020-09-14 Thread Django

* resolution: invalid => wontfix

Comment:

> I have already discovered a number of side effects of this solution. Now
there is another one. It may be best to leave this ticket closed. Please
accept my apologies for the needless concern. I am ready to provide an
abbreviated version of my code here if anyone is interested

Thanks for the following report. The reason why I was asking what kind of
''table'' `rk7data_printcheck` was is that the ''group by selected table
primary key'' optimization is known to break for views, foreign tables,
and any other table-like objects that PostgreSQL cannot introspect enough
to determine this optimization is safe.

The optimization does make a huge difference when aggregating over tables
containing columns costly to join so we decided to keep it around even
with the aforementioned caveats. We did add a per-model hook to disable
though if that can be of any help to you #28107.

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

Re: [Django] #32000: Do not override "user" variable when User model is used with generic views

2020-09-14 Thread Django

#32000: Do not override "user" variable when User model is used with generic 
views
+--
 Reporter:  Stefano Vettorazzi  |Owner:  nobody
 Type:  New feature |   Status:  closed
Component:  Generic views   |  Version:  3.1
 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 Stefano Vettorazzi):

 Thank you for your time and the explanation.

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

Re: [Django] #32006: QuerySet with values with annotate generates wrong SQL query on PostgreSQL.

2020-09-14 Thread Django

Comment (by Konstantin Popov):

I just now realized what is causing the problem.

I use declarative partitioning in some tables, so the primary key must
include the partitioning key and has two fields, 'id' and 'period'.

To use such tables with Django, I developed my own versions of the
CreateModel and AddField migration operations, as well as my own version
of the ForeignKey field.

However, the Django Model class code still considers its primary key to be
a single 'id' field.
I have already discovered a number of side effects of this solution. Now
there is another one.

It may be best to leave this ticket closed. Please accept my apologies for
the needless concern.

I am ready to provide an abbreviated version of my code here if anyone is
interested.

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

Re: [Django] #32006: QuerySet with values with annotate generates wrong SQL query on PostgreSQL.

2020-09-14 Thread Django

#32006: QuerySet with values with annotate generates wrong SQL query on 
PostgreSQL.
-+-
 Reporter:  Konstantin Popov |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  QuerySet values  | Triage Stage:
  annotate GROUP BY  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Konstantin Popov):

 But this does not work properly! I receive error  from postgresql. It says
 other fields should be in GROUP BY.
 This example query is simplified, the real query includes several joined
 tables.

 {{{

 SELECT "rk7data_globalshift"."shiftdate" AS "date",
  "rk7data_restaurant"."name" AS "rest",
 "rk7data_printcheck"."check_number"
  AS "chck", "rk7data_printcheck"."moment" AS "check_mom",
  "rk7data_printcheck"."id" AS "check_id", "rk7data_printcheck"."period" AS
  "check_period", COUNT("rk7data_printcheck"."check_number") AS "qnt",
  SUM("rk7data_printcheck"."binded_sum") AS "pay" FROM "rk7data_printcheck"
  INNER JOIN "rk7data_order" ON ("rk7data_printcheck"."order_id" =
  "rk7data_order"."id" AND "rk7data_printcheck"."period" =
  "rk7data_order"."period") INNER JOIN "rk7data_globalshift" ON
  ("rk7data_order"."shift_id" = "rk7data_globalshift"."id") INNER JOIN
  "rk7data_midserver" ON ("rk7data_globalshift"."midserver_id" =
  "rk7data_midserver"."id") INNER JOIN "rk7data_restaurant" ON
  ("rk7data_midserver"."restaurant_id" = "rk7data_restaurant"."id") WHERE
  ("rk7data_printcheck"."deleted" = %s AND "rk7data_printcheck"."isbill" =
 %s
  AND "rk7data_order"."shift_id" IN (SELECT U0."id" FROM
 "rk7data_globalshift"
  U0 WHERE U0."shiftdate" BETWEEN %s AND %s) AND
 "rk7data_printcheck"."period"
  IN (%s, %s, %s)) GROUP BY "rk7data_globalshift"."shiftdate",
  "rk7data_restaurant"."name", "rk7data_printcheck"."id" ORDER BY "rest"
 ASC,
  "date" ASC, "chck" ASC

 }}}

 And the error message is

 {{{
 ERROR: column "rk7data_printcheck.check_number" must appear in GROUP BY
 clause or used in aggregate function
 LINE 1: ... AS "date", "rk7data_restaurant". "Name" AS "rest", "rk7data_p
 ...
 }}}

 I have found workaround for this, I have wrapped 'id' field with Coalesce
 function, but I don't think it is good solution.

 Will you reopen this issue now?

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

Re: [Django] #32006: QuerySet with values with annotate generates wrong SQL query on PostgreSQL. (was: QuerySet with values with annotate generates wrong SQL query)

2020-09-14 Thread Django

#32006: QuerySet with values with annotate generates wrong SQL query on 
PostgreSQL.
-+-
 Reporter:  Konstantin Popov |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  QuerySet values  | Triage Stage:
  annotate GROUP BY  |  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:

 PostgreSQL allows grouping by selected PKs, so optimized query works
 properly, see #19259.

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

[Django] #32007: AttributeError: 'WhereNode' object has no attribute 'copy'

2020-09-14 Thread Django

#32007: AttributeError: 'WhereNode' object has no attribute 'copy'
--+
   Reporter:  Gordon Wrigley  |  Owner:  nobody
   Type:  Uncategorized   | Status:  new
  Component:  Uncategorized   |Version:  3.1
   Severity:  Normal  |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+
 I think I've found a regression in 3.1, I'm seeing this across databases
 and Python versions but only on Django 3.1.
 With reference to the polls app the queryset I hit this on is essentially:
 {{{#!python
 Question.objects.values("question_text").annotate(
 pub_date__count=Count("pub_date", distinct=True),
 pub_date__is_null=ExpressionWrapper(Q(pub_date=None),
 output_field=BooleanField())
 ).values("question_text", "pub_date__count", "pub_date__is_null")
 }}}
 This results in:
 {{{
 ~\.venv\django_tutorial\lib\site-packages\django\db\models\query.py in
 annotate(self, *args, **kwargs)
1121 clone.query.group_by = True
1122 else:
 -> 1123 clone.query.set_group_by()
1124 break
1125

 ~\.venv\django_tutorial\lib\site-packages\django\db\models\sql\query.py in
 set_group_by(self, allow_aliases)
1979 if not allow_aliases or alias in column_names:
1980 alias = None
 -> 1981 group_by_cols =
 annotation.get_group_by_cols(alias=alias)
1982 group_by.extend(group_by_cols)
1983 self.group_by = tuple(group_by)

 ~\.venv\django_tutorial\lib\site-packages\django\db\models\expressions.py
 in get_group_by_cols(self, alias)
 867
 868 def get_group_by_cols(self, alias=None):
 --> 869 expression = self.expression.copy()
 870 expression.output_field = self.output_field
 871 return expression.get_group_by_cols(alias=alias)

 AttributeError: 'WhereNode' object has no attribute 'copy'
 }}}

 It's a bit of a dumb query but given my usecase https://pypi.org/project
 /django-data-browser/ that's a little beyond my control.

 Still it's kinda surprising that it worked on 3.0 and doesn't on 3.1.

 It can be simplified a bit and still get essentially the same result:
 {{{#!python
 Question.objects.annotate(
 pub_date__count=Count("pub_date", distinct=True),
 pub_date__is_null=ExpressionWrapper(Q(pub_date=None),
 output_field=BooleanField())
 )
 }}}

 Removing either of the annotate clauses "fixes" it.

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

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

[Django] #32006: QuerySet with values with annotate generates wrong SQL query

2020-09-14 Thread Django

#32006: QuerySet with values with annotate generates wrong SQL query
-+-
   Reporter: |  Owner:  nobody
  Konstantin Popov   |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  3.1
  layer (models, ORM)|   Keywords:  QuerySet values
   Severity:  Normal |  annotate GROUP BY
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 I use values and annotate on QuerySet to make query for my report.
 When I add 'id' or 'pk' field to another fields in values it becomes the
 only field in GROUP BY clause.
 This, obviously, generates an invalid SQL query.

 {{{
 
str(Currency.objects.filter(status=3).values('sifr','guid').annotate(cnt=Count('*')).query)
 }}}

 'SELECT "rk7data_currency"."sifr", "rk7data_currency"."guid", COUNT(*) AS
 "cnt" FROM "rk7data_currency" WHERE "rk7data_currency"."status" = 3 GROUP
 BY "rk7data_currency"."sifr", "rk7data_currency"."guid"'

 {{{
 
str(Currency.objects.filter(status=3).values('sifr','guid','id').annotate(cnt=Count('*')).query)
 }}}

 'SELECT "rk7data_currency"."sifr", "rk7data_currency"."guid",
 "rk7data_currency"."id", COUNT(*) AS "cnt" FROM "rk7data_currency" WHERE
 "rk7data_currency"."status" = 3 GROUP BY "rk7data_currency"."id"'

 I have checked this on several models with the same result.
 I have discovered this on django 2.2.10. Upgrade to 2.2.16 and even to 3.1
 does not solve the problem.

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

[Django] #32005: Allow disabling of auto-404-redirection in LocaleMiddleware

2020-09-14 Thread Django

#32005: Allow disabling of auto-404-redirection in LocaleMiddleware
+
Reporter: Alex Vandiver | Owner: nobody
Type: Uncategorized | Status: new
Component: Internationalization |Version: 3.1
Severity: Normal| Keywords:
Triage Stage: Unreviewed| Has patch: 0
Needs documentation: 0 |Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
+
This is related to the last two comments on #17734. Specifically, if an
application decides to return an explicit 404, there is no way to prevent
the LocaleMiddleware from overriding this and trying the language
redirect.

In those comments, it was about catch-all URL patterns. I'm running into
something related, but slightly different -- we [serve 404's for the `/`
endpoint if the subdomain isn't
valid](https://github.com/zulip/zulip/blob/master/zerver/middleware.py#L434),
which the LocaleMiddleware unhelpfully redirects to (e.g.) `/en/` which
isn't any less of a 404.

Would folks be amenable to a patch which disabled the auto-404-redirect
functionality in the middleware with a flag of some sort?

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

Re: [Django] #18855: persist a socket across reloads of the dev server

2020-09-14 Thread Django

#18855: persist a socket across reloads of the dev server
---+
 Reporter:  Dan LaMotte|Owner:  (none)
 Type:  New feature|   Status:  new
Component:  HTTP handling  |  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 felixxm):

 * owner:  Dan LaMotte => (none)
 * status:  assigned => new


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

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

Re: [Django] #13564: Provide class attributes for form fields

2020-09-14 Thread Django

#13564: Provide class attributes for form fields
-+
 Reporter:  h3   |Owner:  (none)
 Type:  New feature  |   Status:  new
Component:  Forms|  Version:  1.2-beta
 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 felixxm):

 * owner:  Robert Lujo => (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/060.294afc17685711851fafa6d5fa4b4a17%40djangoproject.com.

Re: [Django] #31990: QuerySet.ordered property is incorrect for GROUP BY queries on models with Meta.ordering.

2020-09-14 Thread Django

#31990: QuerySet.ordered property is incorrect for GROUP BY queries on models 
with
Meta.ordering.
-+-
 Reporter:  Julien Dutriaux  |Owner:  felixxm
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by GitHub ):

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


Comment:

 In [changeset:"e11d05e0b488a3ff2b3c9d8f2e1e50f471750d6e" e11d05e0]:
 {{{
 #!CommitTicketReference repository=""
 revision="e11d05e0b488a3ff2b3c9d8f2e1e50f471750d6e"
 Fixed #31990 -- Fixed QuerySet.ordered for GROUP BY queries on models with
 Meta.ordering.

 Regression in 0ddb4ebf7bfcc4730c80a772dd146a49ef6895f6.

 Thanks Julien Dutriaux for the report.
 }}}

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

Re: [Django] #31990: QuerySet.ordered property is incorrect for GROUP BY queries on models with Meta.ordering.

2020-09-14 Thread Django

#31990: QuerySet.ordered property is incorrect for GROUP BY queries on models 
with
Meta.ordering.
-+-
 Reporter:  Julien Dutriaux  |Owner:  felixxm
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"a3bb80dc3186bd4d11b7864268beb88595ab00fd" a3bb80dc]:
 {{{
 #!CommitTicketReference repository=""
 revision="a3bb80dc3186bd4d11b7864268beb88595ab00fd"
 [3.1.x] Fixed #31990 -- Fixed QuerySet.ordered for GROUP BY queries on
 models with Meta.ordering.

 Regression in 0ddb4ebf7bfcc4730c80a772dd146a49ef6895f6.

 Thanks Julien Dutriaux for the report.
 Backport of e11d05e0b488a3ff2b3c9d8f2e1e50f471750d6e from master
 }}}

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

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

Re: [Django] #13539: The delete confirmation page does not check for object-level permissions when building the related list

2020-09-14 Thread Django

#13539: The delete confirmation page does not check for object-level permissions
when building the related list
-+-
 Reporter:  Ion Scerbatiuc   |Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:  delete object-level  | Triage Stage:  Accepted
  permissions|
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by felixxm):

 IMO it is not a proper solution because user can have a permission but
 without access to the specific object.

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

Re: [Django] #32001: Pass obj to user.has_perm() in ModelAdmin (was: RFE: Pass obj in user.has_perm() in ModelAdmin)

2020-09-14 Thread Django

#32001: Pass obj to user.has_perm() in ModelAdmin
---+--
 Reporter:  Alexander Todorov  |Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  contrib.admin  |  Version:  3.1
 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 felixxm):

 * status:  new => closed
 * has_patch:  1 => 0
 * resolution:   => duplicate


Comment:

 Agreed, passing `obj` will fix #13539, so we can close it as a duplicate.

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

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

Re: [Django] #32004: Improve documentation of request.FILES

2020-09-14 Thread Django

#32004: Improve documentation of request.FILES
-+-
 Reporter:  Janos Roden  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  Version:  3.1
 Severity:  Normal   |   Resolution:
 Keywords:  upload   | 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 Janos Roden:

Old description:

> Regarding `request.FILES` and `multipart/form-data` requests I think it
> worth to mention that the `filename` parameter of the `content-
> disposition` header of the part is
> [https://github.com/django/django/blob/master/django/http/multipartparser.py#L625
> crutial] to handle the part as a file.
>
> I used a low level library to generate requests and I thought Django will
> use a temporary file (and file name) for this content.
> Of course after I found out how it works it's make sense, but read about
> it in the docs would have help me to fix my code much quicker.

New description:

 Regarding `request.FILES` and `multipart/form-data` requests I think it
 worth to mention in the doc that the `filename` parameter of the `content-
 disposition` header of the part is
 
[https://github.com/django/django/blob/master/django/http/multipartparser.py#L625
 crucial] to handle the part as a file.

 I used a low level library to generate requests and I thought Django will
 use a temporary file (and file name) for this content.
 Of course after I found out how it works it's make sense, but read about
 it in the docs would have help me to fix my code much quicker.

--

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

Re: [Django] #32004: Improve documentation of request.FILES

2020-09-14 Thread Django

#32004: Improve documentation of request.FILES
-+-
 Reporter:  Janos Roden  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  Version:  3.1
 Severity:  Normal   |   Resolution:
 Keywords:  upload   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Janos Roden):

 * cc: Janos Roden (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.cac434491c4b9ea20bc7020e61dc82f1%40djangoproject.com.

[Django] #32004: Improve documentation of request.FILES

2020-09-14 Thread Django

#32004: Improve documentation of request.FILES
+
   Reporter:  Janos Roden   |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Documentation |Version:  3.1
   Severity:  Normal|   Keywords:  upload
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 Regarding `request.FILES` and `multipart/form-data` requests I think it
 worth to mention that the `filename` parameter of the `content-
 disposition` header of the part is
 
[https://github.com/django/django/blob/master/django/http/multipartparser.py#L625
 crutial] to handle the part as a file.

 I used a low level library to generate requests and I thought Django will
 use a temporary file (and file name) for this content.
 Of course after I found out how it works it's make sense, but read about
 it in the docs would have help me to fix my code much quicker.

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

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

Re: [Django] #32001: RFE: Pass obj in user.has_perm() in ModelAdmin

2020-09-14 Thread Django

#32001: RFE: Pass obj in user.has_perm() in ModelAdmin
---+--
 Reporter:  Alexander Todorov  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  contrib.admin  |  Version:  3.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 Alexander Todorov):

 Yet another related comment
 https://code.djangoproject.com/ticket/13539#comment:21. This ticket should
 probably be closed as a duplicate to 13539 b/c they seem to be the same
 root cause in the end.

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

Re: [Django] #13539: The delete confirmation page does not check for object-level permissions when building the related list

2020-09-14 Thread Django

Comment (by Alexander Todorov):

Scratch my previous comment.

I think I've figured out the reasoning behind returning empty set when obj
is passed: if you want to get all perms for the specified object then this
is an empty set() because the ModelBackend doesn't support object-level
permissions. Sounds reasonable to me but took some time to figure it out.

Replying to [comment:19 Virtosu Bogdan]:
> Can't the check be changed to `user.has_perm(p) or user.has_perm(p,
obj)` ?

I've tried this approach in https://github.com/django/django/pull/13418
and all local tests passed for me.

@felixxm I'm sorry for cross posting but these tickets are probably one
and the same issue and the latest approach seems to work. Can you comment
on that ?

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

Re: [Django] #32001: RFE: Pass obj in user.has_perm() in ModelAdmin

2020-09-14 Thread Django

#32001: RFE: Pass obj in user.has_perm() in ModelAdmin
---+--
 Reporter:  Alexander Todorov  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  contrib.admin  |  Version:  3.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 Alexander Todorov):

 Related comment https://code.djangoproject.com/ticket/13539#comment:20

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

Re: [Django] #13539: The delete confirmation page does not check for object-level permissions when building the related list

2020-09-14 Thread Django

#13539: The delete confirmation page does not check for object-level permissions
when building the related list
-+-
 Reporter:  Ion Scerbatiuc   |Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  1.8
 Severity:  Normal   |   Resolution:
 Keywords:  delete object-level  | Triage Stage:  Accepted
  permissions|
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Alexander Todorov):

 Replying to [comment:15 Claude Paroz]:
 > I took some time today to examine this issue and found that we're still
 confronted to the problem mentioned by cyrus on comment:6. If we suddenly
 pass an object to `has_perm`, `False` is returned because the default
 behavior of the `ModelBackend` is to return `False` when any object is
 passed (see #12462).
 >
 > So the first step to solve this issue would be to revert that, which
 might bring backwards incompatibilities. Unfortunately, ticket #12462
 doesn't explain the rationale behind that code.


 I'm working on a related ticket
 https://code.djangoproject.com/ticket/32001 and trying out the following
 patch doesn't seem to break any current tests:

 {{{
 --- a/django/contrib/auth/backends.py
 +++ b/django/contrib/auth/backends.py
 @@ -70,7 +70,7 @@ class ModelBackend(BaseBackend):
  be either "group" or "user" to return permissions from
  `_get_group_permissions` or `_get_user_permissions` respectively.
  """
 -if not user_obj.is_active or user_obj.is_anonymous or obj is not
 None:
 +if not user_obj.is_active or user_obj.is_anonymous:
  return set()

 }}}

 Can anyone of the Django maintainers comment why the `or obj is not None`
 part of this if condition is needed ?  Can we remove it so we can work
 towards checking object level permissions in ModelAdmin ?

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

Re: [Django] #31636: BooleanFieldListFilter doesn't respect field choices.

2020-09-14 Thread Django

#31636: BooleanFieldListFilter doesn't respect field choices.
---+-
 Reporter:  Maxence G  |Owner:  Manav Agarwal
 Type:  Bug|   Status:  assigned
Component:  contrib.admin  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  1
Easy pickings:  1  |UI/UX:  0
---+-
Changes (by felixxm):

 * needs_better_patch:  0 => 1


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

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

Re: [Django] #32000: Do not override "user" variable when User model is used with generic views (was: Suggestion: Do not override "user" variable when User model is used with generic views)

2020-09-14 Thread Django

#32000: Do not override "user" variable when User model is used with generic
views
+--
Reporter: Stefano Vettorazzi |Owner: nobody
Type: New feature | Status: closed
Component: Generic views | Version: 3.1
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 |UI/UX: 0
+--
Changes (by felixxm):

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

Comment:

Thanks for this ticket. It was discussed recently via @django-security
(see also #25397) and we decided that a note in docs in enough.

Florian's reply at @django-security:
> "I am open to suggestions on how to improve the situation; but a
blacklist of certain context variables would IMO go to far… In general I
also think that the issue isn't that bad. The global user object is mostly
used in navigation bars etc to show the username. Even if it is used for
permission checks it usually is just to determine whether a link should be
shown or not. All in all I think the fallout shouldn't be that bad ... I
think a documentation update would be fine."

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

Re: [Django] #32003: Signature of mocked has_perm() methods is outdated.

2020-09-14 Thread Django

#32003: Signature of mocked has_perm() methods is outdated.
-+-
 Reporter:  Alexander Todorov|Owner:  Alexander
 Type:   |  Todorov
  Cleanup/optimization   |   Status:  closed
Component:  Testing framework|  Version:  3.1
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by GitHub ):

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


Comment:

 In [changeset:"5fab16392fc00702a5d0288378892ec48fe67dc6" 5fab1639]:
 {{{
 #!CommitTicketReference repository=""
 revision="5fab16392fc00702a5d0288378892ec48fe67dc6"
 Fixed #32003 -- Added obj argument to has_perm() methods in tests.
 }}}

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

Re: [Django] #32003: Signature of mocked has_perm() methods is outdated.

2020-09-14 Thread Django

#32003: Signature of mocked has_perm() methods is outdated.
-+-
 Reporter:  Alexander Todorov|Owner:  Alexander
 Type:   |  Todorov
  Cleanup/optimization   |   Status:  assigned
Component:  Testing framework|  Version:  3.1
 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 felixxm):

 * owner:  nobody => Alexander Todorov
 * status:  new => assigned
 * has_patch:  0 => 1
 * stage:  Accepted => Ready for checkin


Comment:

 [https://github.com/django/django/pull/13419 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/066.cb4abf9deae63c2bb05be90d05c8b707%40djangoproject.com.

Re: [Django] #31989: Bug in posix implementation of django/core/files/locks.py

2020-09-14 Thread Django

#31989: Bug in posix implementation of django/core/files/locks.py
-+-
 Reporter:  jamercee |Owner:  Hasan
 |  Ramezani
 Type:  Bug  |   Status:  assigned
Component:  File |  Version:  3.1
  uploads/storage|
 Severity:  Normal   |   Resolution:
 Keywords:  locks| 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 felixxm):

 * 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/066.472c1e28be316a9a94e423d86217a304%40djangoproject.com.

Re: [Django] #32002: Allow headers to be passed into HttpResponse()

2020-09-14 Thread Django

#32002: Allow headers to be passed into HttpResponse()
---+---
 Reporter:  Tom Carrick|Owner:  Tom Carrick
 Type:  New feature|   Status:  assigned
Component:  HTTP handling  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+---
Changes (by Tom Carrick):

 * type:  Uncategorized => New feature


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

Re: [Django] #32003: Signature of mocked has_perm() methods is outdated. (was: tests: Signature of mocked User.has_perm() different from real implementation)

2020-09-14 Thread Django

#32003: Signature of mocked has_perm() methods is outdated.
--+
 Reporter:  Alexander Todorov |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Testing framework |  Version:  3.1
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by felixxm):

 * type:  Uncategorized => Cleanup/optimization
 * has_patch:  1 => 0
 * component:  Uncategorized => Testing framework
 * stage:  Unreviewed => Accepted


Comment:

 Patch is welcome.

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

[Django] #32003: tests: Signature of mocked User.has_perm() different from real implementation

2020-09-14 Thread Django

#32003: tests: Signature of mocked User.has_perm() different from real
implementation
-+
   Reporter:  Alexander Todorov  |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Uncategorized  |Version:  3.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  |
-+
 In particular all of the mocked methods receive 2 arguments: self, perm
 while the real one in PermissionsMixin also has a keyword agument called
 obj.

 This gets in the way of trying to work on passing the object to
 user.has_perm() in ModelAdmin because it will cause the tests to fail
 artificially.

 I have a commit at
 https://github.com/atodorov/django/commits/fix_mocked_has_perm which
 doesn't fail locally and seems to do the job.
 Let me know if you want me to open a pull request.

-- 
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/051.e1e0048fe3ecd1025757523fd2e07583%40djangoproject.com.

Re: [Django] #25068: Metaclass conflict when doing createmigrations in ModelState.render

2020-09-14 Thread Django

#25068: Metaclass conflict when doing createmigrations in ModelState.render
-+-
 Reporter:  kosz85   |Owner:  Ethan J.
 |  Howell
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  metaclass conflict   | Triage Stage:  Accepted
  createmigrations   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * needs_better_patch:  0 => 1
 * needs_tests:  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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.7fe0278a4aca39ff8d75b2a6bf4312f8%40djangoproject.com.

[Django] #32002: Allow headers to be passed into HttpResponse()

2020-09-14 Thread Django

#32002: Allow headers to be passed into HttpResponse()
-+
   Reporter:  Tom Carrick|  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  HTTP handling  |Version:  master
   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  |
-+
 [https://groups.google.com/u/2/g/django-developers/c/rlt1HhEaPaM Mailing
 list discussion]


 e.g. `HttpResponse('content', headers={'X-Foo': 'aaa'})`

 I think it also makes sense to add this to `django.shortcuts.render`.

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

Re: [Django] #32002: Allow headers to be passed into HttpResponse()

2020-09-14 Thread Django

#32002: Allow headers to be passed into HttpResponse()
---+---
 Reporter:  Tom Carrick|Owner:  Tom Carrick
 Type:  Uncategorized  |   Status:  assigned
Component:  HTTP handling  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+---
Changes (by Tom Carrick):

 * owner:  nobody => Tom Carrick
 * status:  new => assigned


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

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

Re: [Django] #31989: Bug in posix implementation of django/core/files/locks.py

2020-09-14 Thread Django

#31989: Bug in posix implementation of django/core/files/locks.py
-+-
 Reporter:  jamercee |Owner:  Hasan
 |  Ramezani
 Type:  Bug  |   Status:  assigned
Component:  File |  Version:  3.1
  uploads/storage|
 Severity:  Normal   |   Resolution:
 Keywords:  locks| Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Hasan Ramezani):

 * needs_better_patch:  1 => 0
 * needs_docs:  1 => 0


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

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

Re: [Django] #32001: RFE: Pass obj in user.has_perm() in ModelAdmin

2020-09-14 Thread Django

#32001: RFE: Pass obj in user.has_perm() in ModelAdmin
---+--
 Reporter:  Alexander Todorov  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  contrib.admin  |  Version:  3.1
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by felixxm):

 * has_patch:  1 => 0


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

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

Re: [Django] #32001: RFE: Pass obj in user.has_perm() in ModelAdmin

2020-09-14 Thread Django

#32001: RFE: Pass obj in user.has_perm() in ModelAdmin
---+--
 Reporter:  Alexander Todorov  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  contrib.admin  |  Version:  3.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
---+--
Description changed by Alexander Todorov:

Old description:

> ModelAdmin calls use.has_perm() without passing the underlying object
> when present. This is valid for
> has_change_permission(), has_delete_permission() and
> has_view_permission() methods.
>
> As-is applications which use backends providing object level permissions,
> like django-guardian can't rely on the built-in functionality of the
> admin panel (like edit/delete) to take into account the permissions
> assigned on the object.
>
> Related tickets #11383 and #13539
>

> POC PR https://github.com/django/django/pull/13414 (still WIP at the time
> of writing).

New description:

 ModelAdmin calls use.has_perm() without passing the underlying object when
 present. This is valid for
 has_change_permission(), has_delete_permission() and has_view_permission()
 methods.

 As-is applications which use backends providing object level permissions,
 like django-guardian can't rely on the built-in functionality of the admin
 panel (like edit/delete) to take into account the permissions assigned on
 the object.

 Related tickets #11383 and #13539


 POC PR https://github.com/django/django/pull/13418 (still WIP at the time
 of writing).

--

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

[Django] #32001: RFE: Pass obj in user.has_perm() in ModelAdmin

2020-09-14 Thread Django

#32001: RFE: Pass obj in user.has_perm() in ModelAdmin
-+
   Reporter:  Alexander Todorov  |  Owner:  nobody
   Type:  New feature| Status:  new
  Component:  contrib.admin  |Version:  3.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  |
-+
 ModelAdmin calls use.has_perm() without passing the underlying object when
 present. This is valid for
 has_change_permission(), has_delete_permission() and has_view_permission()
 methods.

 As-is applications which use backends providing object level permissions,
 like django-guardian can't rely on the built-in functionality of the admin
 panel (like edit/delete) to take into account the permissions assigned on
 the object.

 Related tickets #11383 and #13539


 POC PR https://github.com/django/django/pull/13414 (still WIP at the time
 of writing).

-- 
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/051.3265441e8f4e8767df2b7b35f700455b%40djangoproject.com.

Re: [Django] #31789: Add a cleaner interface for response headers

2020-09-14 Thread Django

#31789: Add a cleaner interface for response headers
-+-
 Reporter:  Tom Carrick  |Owner:  Tom
 Type:   |  Carrick
  Cleanup/optimization   |   Status:  closed
Component:  HTTP handling|  Version:  master
 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:"bcc2befd0e9c1885e45b46d0b0bcdc11def8b249" bcc2befd]:
 {{{
 #!CommitTicketReference repository=""
 revision="bcc2befd0e9c1885e45b46d0b0bcdc11def8b249"
 Fixed #31789 -- Added a new headers interface to HttpResponse.
 }}}

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

Re: [Django] #31990: QuerySet.ordered property is incorrect for GROUP BY queries on models with Meta.ordering.

2020-09-14 Thread Django

#31990: QuerySet.ordered property is incorrect for GROUP BY queries on models 
with
Meta.ordering.
-+-
 Reporter:  Julien Dutriaux  |Owner:  felixxm
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/13417 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/067.d56316b5c91dc005c9ba05bef07aa03e%40djangoproject.com.

Re: [Django] #31990: QuerySet.ordered property is incorrect for GROUP BY queries on models with Meta.ordering.

2020-09-14 Thread Django

#31990: QuerySet.ordered property is incorrect for GROUP BY queries on models 
with
Meta.ordering.
-+-
 Reporter:  Julien Dutriaux  |Owner:  felixxm
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * owner:  nobody => felixxm
 * 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/067.2f85808f8dd7a527c9985ab9a3b239a7%40djangoproject.com.

Re: [Django] #25068: Metaclass conflict when doing createmigrations in ModelState.render

2020-09-14 Thread Django

#25068: Metaclass conflict when doing createmigrations in ModelState.render
-+-
 Reporter:  kosz85   |Owner:  Ethan J.
 |  Howell
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  metaclass conflict   | Triage Stage:  Ready for
  createmigrations   |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Markus Holtermann):

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


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

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

47 matches

Mail list logo