date:20201027

Re: [Django] #22841: ModelChoiceField does not make it easy to reuse querysets

2020-10-27 Thread Django

#22841: ModelChoiceField does not make it easy to reuse querysets
-+
 Reporter:  Marc Tamlyn  |Owner:  (none)
 Type:  New feature  |   Status:  new
Component:  Forms|  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 powderflask):

 +1
 I run into this a fair bit with ModelFormsets that include
 ModelChoiceFields.  Work arounds are clunky and largely undocumented.
 Thanks to anyone who has a clever idea.

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

Re: [Django] #32153: Support for list arguments inside exclusive required groups

2020-10-27 Thread Django

#32153: Support for list arguments inside exclusive required groups
-+-
 Reporter:  Mark Gajdosik|Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Uncategorized|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  call_command,| Triage Stage:
  exclusive group, nargs, error  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mark Gajdosik):

 Replying to [comment:3 Hasan Ramezani]:
 > I think we need to add proper handling for `required` arguments with
 `nargs` as well.

 That would always be neat. I couldn't get it to work with the current
 {}={} syntax and the list comprehension:
 {{{
 # Any required arguments which are passed in via **options must be passed
 # to parse_args().
 for opt in parser_actions:
 if (
 opt.dest in options and
 (opt.required or opt in mutually_exclusive_required_options)
 ):
 parse_args.append(min(opt.option_strings))
 value = arg_options[opt.dest]
 if isinstance(value, (list, tuple)):
 parse_args += map(str, value)
 else:
 parse_args.append(str(value))
 }}}

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

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

Re: [Django] #11707: limit_choices_to on a ForeignKey can render duplicate options in formfield

2020-10-27 Thread Django

#11707: limit_choices_to on a ForeignKey can render duplicate options in 
formfield
-+-
 Reporter:  Chris.Wesseling@…|Owner:  Crowley
 |  Shaita
 Type:  Bug  |   Status:  closed
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  ForeingKey   | Triage Stage:  Ready for
  limit_choices_to, dceu2011 |  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:  new => closed
 * resolution:   => fixed


Comment:

 In [changeset:"556fa4bbba5ba86bc1646a86fb11ab55405d4aa4" 556fa4bb]:
 {{{
 #!CommitTicketReference repository=""
 revision="556fa4bbba5ba86bc1646a86fb11ab55405d4aa4"
 Fixed #1891, Fixed #11707 -- Prevented duplicates with limit_choices_to on
 multi-value relations.
 }}}

-- 
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/080.c1e81ba2c837d3ab787e576550c9f58c%40djangoproject.com.

Re: [Django] #1891: ForeignKey with m2m filter can duplicate foreign model entries in ModelForm/ModelChoiceField

2020-10-27 Thread Django

#1891: ForeignKey with m2m filter can duplicate foreign model entries in
ModelForm/ModelChoiceField
-+-
 Reporter:  mattimustang@…   |Owner:  Crowley
 |  Shaita
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"556fa4bbba5ba86bc1646a86fb11ab55405d4aa4" 556fa4bb]:
 {{{
 #!CommitTicketReference repository=""
 revision="556fa4bbba5ba86bc1646a86fb11ab55405d4aa4"
 Fixed #1891, Fixed #11707 -- Prevented duplicates with limit_choices_to on
 multi-value relations.
 }}}

-- 
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/080.04ac48bf237ece5b0867ff0028fd52d7%40djangoproject.com.

Re: [Django] #32152: Aggregation over subquery annotation GROUP BY produces wrong results

2020-10-27 Thread Django

#32152: Aggregation over subquery annotation GROUP BY produces wrong results
-+-
 Reporter:  Christian Klus   |Owner:  Christian
 |  Klus
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.0
  (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 Mariusz Felisiak):

 * owner:  nobody => Christian Klus
 * status:  new => assigned
 * version:  3.1 => 3.0
 * severity:  Normal => Release blocker


Comment:

 Regression in 42c08ee46539ef44f8658ebb1cbefb408e0d03fe.

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

Re: [Django] #32152: Aggregation over subquery annotation GROUP BY produces wrong results (was: Groupby after aggregation and subquery produces subtly wrong results)

2020-10-27 Thread Django

#32152: Aggregation over subquery annotation GROUP BY produces wrong results
-+-
 Reporter:  Christian Klus   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 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
-+-

Comment (by Simon Charette):

 Patch could likely be simplified a bit but it captures the essence of the
 issue. Thanks a lot for the report and investigation Christian.

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

Re: [Django] #32151: Invalid query SQL created when combining in and F() in filter (was: invalid query SQL created when combining in and F() in filter)

2020-10-27 Thread Django

#32151: Invalid query SQL created when combining __in and F() in filter
-+-
 Reporter:  Beda Kosata  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

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


Comment:

 Duplicate of #31135.

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

Re: [Django] #32152: Groupby after aggregation and subquery produces subtly wrong results

2020-10-27 Thread Django

#32152: Groupby after aggregation and subquery produces subtly wrong results
-+-
 Reporter:  Christian Klus   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 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 Christian Klus):

 * has_patch:  0 => 1


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

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

Re: [Django] #32153: Support for list arguments inside exclusive required groups

2020-10-27 Thread Django

#32153: Support for list arguments inside exclusive required groups
-+-
 Reporter:  Mark Gajdosik|Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Uncategorized|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  call_command,| Triage Stage:
  exclusive group, nargs, error  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Mark Gajdosik:

Old description:

> Are there any plans to add support for the following?
>
> {{{
> from django.core.management import BaseCommand
>
> class Command(BaseCommand):
> def add_arguments(self, parser):
> group = parser.add_mutually_exclusive_group(required=True)
> group.add_argument('--foo', nargs='+', type=int)
>
> def handle(self, *args, **options):
> pass
> }}}
>
> When calling the above using `call_command`:
>
> {{{
> call_command('call_command_test', foo=[1, 2, 3])
> # Raises: django.core.management.base.CommandError: Error: one of the
> arguments --foo is required
>
> call_command('call_command_test', '--foo=1', '--foo=2', '--foo=3')
> # Option 'foo' will be of value [3]
> }}}
>
> I can't think of any workarounds other than setting `type=str` (somehow,
> that works fine) and coercing manually. Thank you!

New description:

 Are there any plans to add support for the following?

 {{{
 from django.core.management import BaseCommand

 class Command(BaseCommand):
 def add_arguments(self, parser):
 group = parser.add_mutually_exclusive_group(required=True)
 group.add_argument('--foo', nargs='+', type=int)

 def handle(self, *args, **options):
 pass
 }}}

 When calling the above using `call_command`:

 {{{
 call_command('call_command_test', foo=[1, 2, 3])
 # Raises: django.core.management.base.CommandError: Error: argument --foo:
 invalid int value: '[1, 2, 3]'

 call_command('call_command_test', '--foo=1', '--foo=2', '--foo=3')
 # Option 'foo' will be of value [3]
 }}}

 I can't think of any workarounds other than setting `type=str` (somehow,
 that works fine) and coercing manually. Thank you!

--

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

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

Re: [Django] #32153: Support for list arguments inside exclusive required groups

2020-10-27 Thread Django

#32153: Support for list arguments inside exclusive required groups
-+-
 Reporter:  Mark Gajdosik|Owner:  nobody
 Type:  Uncategorized|   Status:  new
Component:  Uncategorized|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  call_command,| Triage Stage:
  exclusive group, nargs, error  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Mark Gajdosik:

Old description:

> Are there any plans to add support for the following?
>
> {{{
> from django.core.management import BaseCommand
>
> class Command(BaseCommand):
> def add_arguments(self, parser):
> group = parser.add_mutually_exclusive_group(required=True)
> group.add_argument('--foo', nargs='+', type=int)
>
> def handle(self, *args, **options):
> pass
> }}}
>
> When calling the above using `call_command`:
>
> {{{
> call_command('call_command_test', foo=[1, 2, 3])
> # Raises: django.core.management.base.CommandError: Error: one of the
> arguments --foo is required
>
> call_command('call_command_test', '--foo=1', '--foo=2', '--foo=3')
> # Option 'foo' will be of value [3]
> }}}
>
> I can't think of any workarounds. Thank you!

New description:

 Are there any plans to add support for the following?

 {{{
 from django.core.management import BaseCommand

 class Command(BaseCommand):
 def add_arguments(self, parser):
 group = parser.add_mutually_exclusive_group(required=True)
 group.add_argument('--foo', nargs='+', type=int)

 def handle(self, *args, **options):
 pass
 }}}

 When calling the above using `call_command`:

 {{{
 call_command('call_command_test', foo=[1, 2, 3])
 # Raises: django.core.management.base.CommandError: Error: one of the
 arguments --foo is required

 call_command('call_command_test', '--foo=1', '--foo=2', '--foo=3')
 # Option 'foo' will be of value [3]
 }}}

 I can't think of any workarounds other than setting `type=str` (somehow,
 that works fine) and coercing manually. Thank you!

--

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

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

Re: [Django] #29712: Add warning in makemessages command if the localecode with `l` flag is not correct

2020-10-27 Thread Django

#29712: Add warning in makemessages command if the localecode with `l` flag is 
not
correct
-+-
 Reporter:  Sanyam Khurana   |Owner:  Manav
 Type:   |  Agarwal
  Cleanup/optimization   |   Status:  assigned
Component:   |  Version:  master
  Internationalization   |
 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
-+-

Comment (by Manav Agarwal):

 [https://github.com/django/django/pull/13615 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/072.fa53c40fd08450a289ae41bdff2c2772%40djangoproject.com.

Re: [Django] #32152: Groupby after aggregation and subquery produces subtly wrong results

2020-10-27 Thread Django

#32152: Groupby after aggregation and subquery produces subtly wrong results
-+-
 Reporter:  Christian Klus   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 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):

 * stage:  Unreviewed => Accepted


Comment:

 Thanks for the report and test Christian, I think you analysis is right;
 all members of the `SELECT` clause should be considered.

 Could you submit a PR on Github including your test and the following
 changes

 {{{#!diff
 diff --git a/django/db/models/sql/query.py b/django/db/models/sql/query.py
 index ee98984826..96819803c0 100644
 --- a/django/db/models/sql/query.py
 +++ b/django/db/models/sql/query.py
 @@ -2205,8 +2205,10 @@ def set_values(self, fields):
  field_names.append(f)
  self.set_extra_mask(extra_names)
  self.set_annotation_mask(annotation_names)
 +selected = frozenset(field_names + extra_names +
 annotation_names)
  else:
  field_names = [f.attname for f in
 self.model._meta.concrete_fields]
 +selected = frozenset(field_names)
  # Selected annotations must be known before setting the GROUP BY
  # clause.
  if self.group_by is True:
 @@ -2220,7 +,7 @@ def set_values(self, fields):
  # the selected fields anymore.
  group_by = []
  for expr in self.group_by:
 -if isinstance(expr, Ref) and expr.refs not in
 field_names:
 +if isinstance(expr, Ref) and expr.refs not in selected:
  expr = self.annotations[expr.refs]
  group_by.append(expr)
  self.group_by = tuple(group_by)
 }}}

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

Re: [Django] #32151: invalid query SQL created when combining __in and F() in filter

2020-10-27 Thread Django

#32151: invalid query SQL created when combining __in and F() in filter
-+-
 Reporter:  Beda Kosata  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 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 Simon Charette):

 Not sure if this was ever explicitly supported, any reason you don't use
 `author=F('publisher__authors')`?

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

Re: [Django] #32152: Groupby after aggregation and subquery produces subtly wrong results

2020-10-27 Thread Django

#32152: Groupby after aggregation and subquery produces subtly wrong results
-+-
 Reporter:  Christian Klus   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Christian Klus:

Old description:

> Starting in django 3.0.7, specifically after patch #31566 I noticed some
> of my more complex queries returning incorrect results. I think I've
> narrowed it down to a simpler test case:
>
> Example query:
> {{{
> Book.objects.all().annotate(
> pub_year=TruncYear('pubdate')
> ).order_by().values('pub_year').annotate(
> total_pages=Sum('pages'),
> top_rating=Subquery(
> Book.objects.filter(
> pubdate__year=OuterRef('pub_year')
> ).order_by('rating').values('rating')[:1]
> )
> ).values('pub_year', 'total_pages', 'top_rating')
> }}}
>
> Generated SQL on 3.0.6:
>
> {{{
> SELECT
>   django_date_trunc('year', "aggregation_regress_book"."pubdate") AS
> "pub_year",
>   SUM("aggregation_regress_book"."pages") AS "total_pages",
>   (
> SELECT U0."rating"
> FROM "aggregation_regress_book" U0
> WHERE
>   django_date_extract('year', U0."pubdate") =
> django_date_trunc('year', "aggregation_regress_book"."pubdate")
> ORDER BY U0."rating" ASC LIMIT 1
>   ) AS "top_rating"
> FROM "aggregation_regress_book"
> GROUP BY
>   django_date_trunc('year', "aggregation_regress_book"."pubdate"),
>   "top_rating"
> }}}
>
> Generated SQL on current master:
>
> {{{
> SELECT
>   django_date_trunc('year', "aggregation_regress_book"."pubdate", NULL,
> NULL) AS "pub_year",
>   SUM("aggregation_regress_book"."pages") AS "total_pages",
>   (
> SELECT U0."rating"
> FROM "aggregation_regress_book" U0
> WHERE
>   django_date_extract('year', U0."pubdate") =
> django_date_trunc('year', "aggregation_regress_book"."pubdate", NULL,
> NULL)
> ORDER BY U0."rating" ASC LIMIT 1
>   ) AS "top_rating"
> FROM "aggregation_regress_book"
> GROUP BY
>   django_date_trunc('year', "aggregation_regress_book"."pubdate", NULL,
> NULL),
>   (
> SELECT U0."rating"
> FROM "aggregation_regress_book" U0
> WHERE
>   django_date_extract('year', U0."pubdate") =
> django_date_trunc('year', "aggregation_regress_book"."pubdate", NULL,
> NULL)
> ORDER BY U0."rating" ASC LIMIT 1
>   ),
>   "aggregation_regress_book"."pubdate"
> }}}
>
> 
>
> I see two separate issues here:
>   - {{{"aggregation_regress_book"."pubdate"}}} is being added to the
> group by clause incorrectly (this issue probably predates the patch
> mentioned above)
>   - Even though the subquery is in the select statement, the alias is not
> being used and instead the subquery is reevaluated. This nearly doubles
> the cost of one of my queries that is experiencing this problem.
>
> 
>
> I don't know much about the ORM internals, but here is my naive patch for
> the second issue:
>
> {{{
> diff --git a/django/db/models/sql/query.py
> b/django/db/models/sql/query.py
> index ee98984826..6ea287d6cb 100644
> --- a/django/db/models/sql/query.py
> +++ b/django/db/models/sql/query.py
> @@ -2220,7 +2220,7 @@ class Query(BaseExpression):
>  # the selected fields anymore.
>  group_by = []
>  for expr in self.group_by:
> -if isinstance(expr, Ref) and expr.refs not in
> field_names:
> +if isinstance(expr, Ref) and expr.refs not in
> field_names + annotation_names:
>  expr = self.annotations[expr.refs]
>  group_by.append(expr)
>  self.group_by = tuple(group_by)
> }}}
>
> I'd appreciate anyone with deeper knowlege of the ORM to chime in and let
> me know if I'm on the right track. Tests are passing locally.
>
> The resulting query on master:
>
> {{{
> SELECT
>   django_date_trunc('year', "aggregation_regress_book"."pubdate", NULL,
> NULL) AS "pub_year",
>   SUM("aggregation_regress_book"."pages") AS "total_pages",
>   (
> SELECT U0."rating"
> FROM "aggregation_regress_book" U0
> WHERE
>   django_date_extract('year', U0."pubdate") =
> django_date_trunc('year', "aggregation_regress_book"."pubdate", NULL,
> NULL)
> ORDER BY U0."rating" ASC LIMIT 1
>   ) AS "top_rating"
> FROM "aggregation_regress_book"
> GROUP BY
>   django_date_trunc('year', "aggregation_regress_book"."pubdate",

Re: [Django] #32152: Groupby after aggregation and subquery produces subtly wrong results

2020-10-27 Thread Django

#32152: Groupby after aggregation and subquery produces subtly wrong results
-+-
 Reporter:  Christian Klus   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 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 Christian Klus):

 Here's the test case I used (not sure if it's in the right location). It
 succeeds on 3.0.6 and fails on subsequent releases.

 {{{
 diff --git a/tests/aggregation_regress/tests.py
 b/tests/aggregation_regress/tests.py
 index 7604335257..dac995e1fc 100644
 --- a/tests/aggregation_regress/tests.py
 +++ b/tests/aggregation_regress/tests.py
 @@ -8,9 +8,10 @@ from django.contrib.contenttypes.models import
 ContentType
  from django.core.exceptions import FieldError
  from django.db import connection
  from django.db.models import (
 -Aggregate, Avg, Case, Count, DecimalField, F, IntegerField, Max, Q,
 StdDev,
 -Sum, Value, Variance, When,
 +Aggregate, Avg, Case, Count, DecimalField, F, IntegerField, Max,
 OuterRef,
 +Q, StdDev, Subquery, Sum, Value, Variance, When
  )
 +from django.db.models.functions import TruncYear
  from django.test import TestCase, skipUnlessAnyDBFeature,
 skipUnlessDBFeature
  from django.test.utils import Approximate

 @@ -102,6 +103,21 @@ class AggregationTests(TestCase):
  s2.books.add(cls.b1, cls.b3, cls.b5, cls.b6)
  s3.books.add(cls.b3, cls.b4, cls.b6)

 +def test_groupby_after_aggregation_and_subquery(self):
 +self.assertEqual(
 +Book.objects.all().annotate(
 +pub_year=TruncYear('pubdate')
 +).order_by().values('pub_year').annotate(
 +total_pages=Sum('pages'),
 +top_rating=Subquery(
 +Book.objects.filter(
 +pubdate__year=OuterRef('pub_year')
 +).order_by('rating').values('rating')[:1]
 +)
 +).values('pub_year', 'total_pages', 'top_rating').count(),
 +4
 +)
 +
  def assertObjectAttrs(self, obj, **kwargs):
  for attr, value in kwargs.items():
  self.assertEqual(getattr(obj, attr), value)
 }}}

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

[Django] #32152: Groupby after aggregation and subquery produces subtly wrong results

2020-10-27 Thread Django

#32152: Groupby after aggregation and subquery produces subtly wrong results
-+-
   Reporter:  Christian  |  Owner:  nobody
  Klus   |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  3.1
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Starting in django 3.0.7, specifically after patch #31566 I noticed some
 of my more complex queries returning incorrect results. I think I've
 narrowed it down to a simpler test case:

 Example query:
 {{{
 Book.objects.all().annotate(
 pub_year=TruncYear('pubdate')
 ).order_by().values('pub_year').annotate(
 total_pages=Sum('pages'),
 top_rating=Subquery(
 Book.objects.filter(
 pubdate__year=OuterRef('pub_year')
 ).order_by('rating').values('rating')[:1]
 )
 ).values('pub_year', 'total_pages', 'top_rating')
 }}}

 Generated SQL on 3.0.6:

 {{{
 SELECT
   django_date_trunc('year', "aggregation_regress_book"."pubdate") AS
 "pub_year",
   SUM("aggregation_regress_book"."pages") AS "total_pages",
   (
 SELECT U0."rating"
 FROM "aggregation_regress_book" U0
 WHERE
   django_date_extract('year', U0."pubdate") =
 django_date_trunc('year', "aggregation_regress_book"."pubdate")
 ORDER BY U0."rating" ASC LIMIT 1
   ) AS "top_rating"
 FROM "aggregation_regress_book"
 GROUP BY
   django_date_trunc('year', "aggregation_regress_book"."pubdate"),
   "top_rating"
 }}}

 Generated SQL on current master:

 {{{
 SELECT
   django_date_trunc('year', "aggregation_regress_book"."pubdate", NULL,
 NULL) AS "pub_year",
   SUM("aggregation_regress_book"."pages") AS "total_pages",
   (
 SELECT U0."rating"
 FROM "aggregation_regress_book" U0
 WHERE
   django_date_extract('year', U0."pubdate") =
 django_date_trunc('year', "aggregation_regress_book"."pubdate", NULL,
 NULL)
 ORDER BY U0."rating" ASC LIMIT 1
   ) AS "top_rating"
 FROM "aggregation_regress_book"
 GROUP BY
   django_date_trunc('year', "aggregation_regress_book"."pubdate", NULL,
 NULL),
   (
 SELECT U0."rating"
 FROM "aggregation_regress_book" U0
 WHERE
   django_date_extract('year', U0."pubdate") =
 django_date_trunc('year', "aggregation_regress_book"."pubdate", NULL,
 NULL)
 ORDER BY U0."rating" ASC LIMIT 1
   ),
   "aggregation_regress_book"."pubdate"
 }}}

 

 I see two separate issues here:
   - {{{"aggregation_regress_book"."pubdate"}}} is being added to the group
 by clause incorrectly (this issue probably predates the patch mentioned
 above)
   - Even though the subquery is in the select statement, the alias is not
 being used and instead the subquery is reevaluated. This nearly doubles
 the cost of one of my queries that is experiencing this problem.

 

 I don't know much about the ORM internals, but here is my naive patch for
 the second issue:

 {{{
 diff --git a/django/db/models/sql/query.py b/django/db/models/sql/query.py
 index ee98984826..6ea287d6cb 100644
 --- a/django/db/models/sql/query.py
 +++ b/django/db/models/sql/query.py
 @@ -2220,7 +2220,7 @@ class Query(BaseExpression):
  # the selected fields anymore.
  group_by = []
  for expr in self.group_by:
 -if isinstance(expr, Ref) and expr.refs not in
 field_names:
 +if isinstance(expr, Ref) and expr.refs not in field_names
 + annotation_names:
  expr = self.annotations[expr.refs]
  group_by.append(expr)
  self.group_by = tuple(group_by)
 }}}

 I'd appreciate anyone with deeper knowlege of the ORM to chime in and let
 me know if I'm on the right track. Tests are passing locally.

 The resulting query on master:

 {{{
 SELECT
   django_date_trunc('year', "aggregation_regress_book"."pubdate", NULL,
 NULL) AS "pub_year",
   SUM("aggregation_regress_book"."pages") AS "total_pages",
   (
 SELECT U0."rating"
 FROM "aggregation_regress_book" U0
 WHERE
   django_date_extract('year', U0."pubdate") =
 django_date_trunc('year', "aggregation_regress_book"."pubdate", NULL,
 NULL)
 ORDER BY U0."rating" ASC LIMIT 1
   ) AS "top_rating"
 FROM "aggregation_regress_book"
 GROUP BY
   django_date_trunc('year', "aggregation_regress_book"."pubdate", NULL,
 NULL),
   "top_rating"
 }}}

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

-- 
You received this message because you are subscribed to

Re: [Django] #32151: invalid query SQL created when combining __in and F() in filter

2020-10-27 Thread Django

#32151: invalid query SQL created when combining __in and F() in filter
-+-
 Reporter:  Beda Kosata  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Beda Kosata:

Old description:

> When a query contains an `__in` filter with `F()` on the right side (I
> observed it with a ManyToMany relationship), the generated SQL is not
> correct and causes a SyntaxError. At least for PostgreSQL 12.
>
> Here is a sample project to reproduce the issue:
>
> **models.py**
>
> {{{#!python
> from django.db import models
>
> class Author(models.Model):
> name = models.CharField(max_length=32)
>

> class Publisher(models.Model):
> authors = models.ManyToManyField(Author)
>

> class Book(models.Model):
> publisher = models.ForeignKey(Publisher, on_delete=models.CASCADE)
> author = models.ForeignKey(Author, on_delete=models.CASCADE)
> }}}
>
> This query:
>
> {{{#!python
> list(Book.objects.filter(author__in=F('publisher__authors')))
> }}}
>

> then fails with `psycopg2.errors.SyntaxError: syntax error at or near
> ""ferror_publisher_authors""`
>

> The problem is that the generated query looks like this:
>
> {{{#!sql
> SELECT "ferror_book"."id", "ferror_book"."publisher_id",
> "ferror_book"."author_id"
>   FROM "ferror_book"
>   INNER JOIN "ferror_publisher" ON ("ferror_book"."publisher_id" =
> "ferror_publisher"."id")
>   INNER JOIN "ferror_publisher_authors" ON ("ferror_publisher"."id" =
> "ferror_publisher_authors"."publisher_id")
> WHERE "ferror_book"."author_id" IN "ferror_publisher_authors"."author_id"
> }}}
>
> This issue is present in both 3.0.10 and 3.1.5. When the same code is run
> in Django 2.2.16, a correct query is created with brackets around the
> `"ferror_publisher_authors"."author_id"` part at the end.
>
> {{{#!sql
> SELECT "ferror_book"."id", "ferror_book"."publisher_id",
> "ferror_book"."author_id"
>   FROM "ferror_book"
>   INNER JOIN "ferror_publisher" ON ("ferror_book"."publisher_id" =
> "ferror_publisher"."id")
>   INNER JOIN "ferror_publisher_authors" ON ("ferror_publisher"."id" =
> "ferror_publisher_authors"."publisher_id")
> WHERE "ferror_book"."author_id" IN
> ("ferror_publisher_authors"."author_id")
> }}}

New description:

 When a query contains an `__in` filter with `F()` on the right side (I
 observed it with a ManyToMany relationship), the generated SQL is not
 correct and causes a SyntaxError. At least for PostgreSQL 12.

 Here is a sample project to reproduce the issue:

 **models.py**

 {{{#!python
 from django.db import models

 class Author(models.Model):
 name = models.CharField(max_length=32)


 class Publisher(models.Model):
 authors = models.ManyToManyField(Author)


 class Book(models.Model):
 publisher = models.ForeignKey(Publisher, on_delete=models.CASCADE)
 author = models.ForeignKey(Author, on_delete=models.CASCADE)
 }}}

 This query:

 {{{#!python
 list(Book.objects.filter(author__in=F('publisher__authors')))
 }}}


 then fails with `psycopg2.errors.SyntaxError: syntax error at or near
 ""ferror_publisher_authors""`


 The problem is that the generated query looks like this:

 {{{#!sql
 SELECT "ferror_book"."id", "ferror_book"."publisher_id",
 "ferror_book"."author_id"
   FROM "ferror_book"
   INNER JOIN "ferror_publisher" ON ("ferror_book"."publisher_id" =
 "ferror_publisher"."id")
   INNER JOIN "ferror_publisher_authors" ON ("ferror_publisher"."id" =
 "ferror_publisher_authors"."publisher_id")
 WHERE "ferror_book"."author_id" IN "ferror_publisher_authors"."author_id"
 }}}

 This issue is present in both 3.0.10 and 3.1.2. When the same code is run
 in Django 2.2.16, a correct query is created with brackets around the
 `"ferror_publisher_authors"."author_id"` part at the end.

 {{{#!sql
 SELECT "ferror_book"."id", "ferror_book"."publisher_id",
 "ferror_book"."author_id"
   FROM "ferror_book"
   INNER JOIN "ferror_publisher" ON ("ferror_book"."publisher_id" =
 "ferror_publisher"."id")
   INNER JOIN "ferror_publisher_authors" ON ("ferror_publisher"."id" =
 "ferror_publisher_authors"."publisher_id")
 WHERE "ferror_book"."author_id" IN
 ("ferror_publisher_authors"."author_id")
 }}}

--

-- 
Ticket URL: 
Django 
The Web framework for

[Django] #32151: invalid query SQL created when combining __in and F() in filter

2020-10-27 Thread Django

#32151: invalid query SQL created when combining __in and F() in filter
-+-
   Reporter:  Beda   |  Owner:  nobody
  Kosata |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  3.1
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 When a query contains an `__in` filter with `F()` on the right side (I
 observed it with a ManyToMany relationship), the generated SQL is not
 correct and causes a SyntaxError. At least for PostgreSQL 12.

 Here is a sample project to reproduce the issue:

 **models.py**

 {{{#!python
 from django.db import models

 class Author(models.Model):
 name = models.CharField(max_length=32)


 class Publisher(models.Model):
 authors = models.ManyToManyField(Author)


 class Book(models.Model):
 publisher = models.ForeignKey(Publisher, on_delete=models.CASCADE)
 author = models.ForeignKey(Author, on_delete=models.CASCADE)
 }}}

 This query:

 {{{#!python
 list(Book.objects.filter(author__in=F('publisher__authors')))
 }}}


 then fails with `psycopg2.errors.SyntaxError: syntax error at or near
 ""ferror_publisher_authors""`


 The problem is that the generated query looks like this:

 {{{#!sql
 SELECT "ferror_book"."id", "ferror_book"."publisher_id",
 "ferror_book"."author_id"
   FROM "ferror_book"
   INNER JOIN "ferror_publisher" ON ("ferror_book"."publisher_id" =
 "ferror_publisher"."id")
   INNER JOIN "ferror_publisher_authors" ON ("ferror_publisher"."id" =
 "ferror_publisher_authors"."publisher_id")
 WHERE "ferror_book"."author_id" IN "ferror_publisher_authors"."author_id"
 }}}

 This issue is present in both 3.0.10 and 3.1.5. When the same code is run
 in Django 2.2.16, a correct query is created with brackets around the
 `"ferror_publisher_authors"."author_id"` part at the end.

 {{{#!sql
 SELECT "ferror_book"."id", "ferror_book"."publisher_id",
 "ferror_book"."author_id"
   FROM "ferror_book"
   INNER JOIN "ferror_publisher" ON ("ferror_book"."publisher_id" =
 "ferror_publisher"."id")
   INNER JOIN "ferror_publisher_authors" ON ("ferror_publisher"."id" =
 "ferror_publisher_authors"."publisher_id")
 WHERE "ferror_book"."author_id" IN
 ("ferror_publisher_authors"."author_id")
 }}}

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

Re: [Django] #32127: textareas are cut off with the admin navigation sidebar.

2020-10-27 Thread Django

#32127: textareas are cut off with the admin navigation sidebar.
-+-
 Reporter:  Mariusz Felisiak |Owner:  Josh
 Type:   |  Santos
  Cleanup/optimization   |   Status:  closed
Component:  contrib.admin|  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
-+-

Comment (by Carlton Gibson ):

 In [changeset:"b3d667f20dace1ec34525a423467f16e2f3dda51" b3d667f2]:
 {{{
 #!CommitTicketReference repository=""
 revision="b3d667f20dace1ec34525a423467f16e2f3dda51"
 [3.1.x] Fixed #32127 -- Fixed admin change-form textarea layout for mid-
 sized displays.

 Backport of 36bc47069ce071e80c8129500de3b8664d2058a7 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/065.d5f9c63ec94ec9f1b3386af795be974e%40djangoproject.com.

Re: [Django] #32127: textareas are cut off with the admin navigation sidebar.

2020-10-27 Thread Django

#32127: textareas are cut off with the admin navigation sidebar.
-+-
 Reporter:  Mariusz Felisiak |Owner:  Josh
 Type:   |  Santos
  Cleanup/optimization   |   Status:  closed
Component:  contrib.admin|  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 Carlton Gibson ):

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


Comment:

 In [changeset:"36bc47069ce071e80c8129500de3b8664d2058a7" 36bc4706]:
 {{{
 #!CommitTicketReference repository=""
 revision="36bc47069ce071e80c8129500de3b8664d2058a7"
 Fixed #32127 -- Fixed admin change-form textarea layout for mid-sized
 displays.
 }}}

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

Re: [Django] #32150: Admin Docs No reverse match error

2020-10-27 Thread Django

#32150: Admin Docs No reverse match error
-+-
 Reporter:  Yovel Cohen  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  contrib.admindocs|  Version:  3.0
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  Admin admin-docs | Triage Stage:
  docs ,reverse-url  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

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


Comment:

 The admin URLs are matching first, then looking for a `docs` model (which
 doesn't exist).

 Swap the order round:

 {{{
 urlpatterns = [
 path('admin/doc/', include('django.contrib.admindocs.urls')),
 path('admin/', consumer_admin.urls),
 ]
 }}}

 Please don't use the issue tracker as a support channel. See
 TicketClosingReasons/UseSupportChannels.
 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.7bb22da205899fa9c7eed43774fb6982%40djangoproject.com.

Re: [Django] #32150: Admin Docs No reverse match error

2020-10-27 Thread Django

#32150: Admin Docs No reverse match error
-+-
 Reporter:  Yovel Cohen  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admindocs|  Version:  3.0
 Severity:  Normal   |   Resolution:
 Keywords:  Admin admin-docs | Triage Stage:
  docs ,reverse-url  |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Yovel Cohen:

Old description:

> I'm trying to install the Admin Docs:
> my urls:
> ```python
>
> urlpatterns = [
> # ADMIN
> path('admin/', consumer_admin.urls),
> path('admin/doc/', include('django.contrib.admindocs.urls')),
> # rest of urls...
> ]
> ```
> installed apps:
> ```python
> installed_apps = [
> 'django.contrib.admindocs',
> 'django.contrib.admin',
># rest of apps
> ]
> ```
> when I try to access the docs from the admin I get the following error:
> ```python
> NoReverseMatch at /admin/doc/
> Reverse for 'app_list' with keyword arguments '{'app_label': 'auth'}' not
> found. 1 pattern(s) tried:
> ['admin/(?Pconsumer_api|users|authtoken)/$']
> ```
> all the model's admins in my app (including users and auth token) reside
> in my custom consumer admin,
> not sure if it is related to the issue or not

New description:

 I'm trying to install the Admin Docs:
 my urls:

 ```
 urlpatterns = [
 # ADMIN
 path('admin/', consumer_admin.urls),
 path('admin/doc/', include('django.contrib.admindocs.urls')),
 # rest of urls...
 ]
 ```
 installed apps:

 ```
 installed_apps = [
 'django.contrib.admindocs',
 'django.contrib.admin',
# rest of apps
 ]
 ```
 when I try to access the docs from the admin I get the following error:

 ```
 NoReverseMatch at /admin/doc/
 Reverse for 'app_list' with keyword arguments '{'app_label': 'auth'}' not
 found. 1 pattern(s) tried:
 ['admin/(?Pconsumer_api|users|authtoken)/$']
 ```

 all the model's admins in my app (including users and auth token) reside
 in my custom consumer admin,
 not sure if it is related to the issue or not

--

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

[Django] #32150: Admin Docs No reverse match error

2020-10-27 Thread Django

#32150: Admin Docs No reverse match error
-+-
   Reporter:  Yovel  |  Owner:  nobody
  Cohen  |
   Type:  Bug| Status:  new
  Component: |Version:  3.0
  contrib.admindocs  |   Keywords:  Admin admin-docs
   Severity:  Normal |  docs ,reverse-url
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 I'm trying to install the Admin Docs:
 my urls:
 ```python

 urlpatterns = [
 # ADMIN
 path('admin/', consumer_admin.urls),
 path('admin/doc/', include('django.contrib.admindocs.urls')),
 # rest of urls...
 ]
 ```
 installed apps:
 ```python
 installed_apps = [
 'django.contrib.admindocs',
 'django.contrib.admin',
# rest of apps
 ]
 ```
 when I try to access the docs from the admin I get the following error:
 ```python
 NoReverseMatch at /admin/doc/
 Reverse for 'app_list' with keyword arguments '{'app_label': 'auth'}' not
 found. 1 pattern(s) tried:
 ['admin/(?Pconsumer_api|users|authtoken)/$']
 ```
 all the model's admins in my app (including users and auth token) reside
 in my custom consumer admin,
 not sure if it is related to the issue or not

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

Re: [Django] #32147: timezone error when casting a naive date in a Daylight Saving Time Change

2020-10-27 Thread Django

#32147: timezone error when casting a naive date in a Daylight Saving Time 
Change
+--
 Reporter:  WolfTammer  |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  Utilities   |  Version:  3.1
 Severity:  Normal  |   Resolution:  invalid
 Keywords:  timezone| Triage Stage:  Unreviewed
Has patch:  0   |  Needs documentation:  0
  Needs tests:  0   |  Patch needs improvement:  0
Easy pickings:  0   |UI/UX:  0
+--

Comment (by WolfTammer):

 Replying to [comment:5 Aymeric Augustin]:
 > I can confirm. "Don't use pytz" will eventually lead to "assume the
 value is in DST / not in DST", which we want to avoid. The error is raised
 on purpose because the input is ambiguous.
 >
 > If you care about such values, you should write an input that includes
 time zone information. No one does this in practice because the problem
 only happens one hour per year.
 >
 > If you want the whole history, look at #2626 and related mailing-list
 discussions.

 I should write another ticket or modify this with other unittest. My
 problem is not when you create an object with an aware datetime, I can
 understand you waypoint in that case, BUT the error comes when I **save a
 datetime with timezone**, then I try to retrieve the datetime **from DB**.
 It should work, because I specified the timezone in the database settings.
 I don't think doing a timezone.localize() is a good idea, instead it
 should be done a replace(tzinfo=timezone) because we are sure that
 database data is in that timezone. Should I open another ticket or modify
 this? Or is also a correct behaviour this one?

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

Re: [Django] #1891: ForeignKey with m2m filter can duplicate foreign model entries in ModelForm/ModelChoiceField

2020-10-27 Thread Django

#1891: ForeignKey with m2m filter can duplicate foreign model entries in
ModelForm/ModelChoiceField
-+-
 Reporter:  mattimustang@…   |Owner:  Crowley
 |  Shaita
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * owner:  Chris Wilson => Crowley Shaita
 * needs_better_patch:  1 => 0
 * stage:  Accepted => Ready for checkin


Comment:

 [https://github.com/django/django/pull/13315 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/080.1c65a9457df98c959f0a10c39909d25c%40djangoproject.com.

Re: [Django] #11707: limit_choices_to on a ForeignKey can render duplicate options in formfield

2020-10-27 Thread Django

#11707: limit_choices_to on a ForeignKey can render duplicate options in 
formfield
-+-
 Reporter:  Chris.Wesseling@…|Owner:  Crowley
 |  Shaita
 Type:  Bug  |   Status:  new
Component:  Forms|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  ForeingKey   | Triage Stage:  Ready for
  limit_choices_to, dceu2011 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * stage:  Accepted => Ready for checkin


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

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

Re: [Django] #32145: Unclear error raised by makemessages when /locale does not exist under app directory

2020-10-27 Thread Django

#32145: Unclear error raised by makemessages when /locale does not exist under 
app
directory
-+-
 Reporter:  boxed|Owner:  Josh
 Type:   |  Santos
  Cleanup/optimization   |   Status:  assigned
Component:  Core (Management |  Version:  master
  commands)  |
 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 Josh Santos):

 * owner:  nobody => Josh Santos
 * status:  new => assigned


Comment:

 Looking into this 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/063.cd49ebac831e8e22be1ba3fac24f4949%40djangoproject.com.

Re: [Django] #6135: Introduce a short-cut for template filters that has needs_autoescape = True

2020-10-27 Thread Django

#6135: Introduce a short-cut for template filters that has needs_autoescape = 
True
-+
 Reporter:  anonymous|Owner:  Seth Thoburn
 Type:  New feature  |   Status:  assigned
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  autoescape   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by Carlton Gibson):

 * needs_docs:  0 => 1
 * needs_tests:  0 => 1


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

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

Re: [Django] #32140: `startTest` result hook not called until after tests already started when `--parallel` used

2020-10-27 Thread Django

#32140: `startTest` result hook not called until after tests already started 
when
`--parallel` used
-+-
 Reporter:  Bob Whitelock|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Testing framework|  Version:  3.1
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  startTest parallel   | Triage Stage:
  test runner|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

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


Comment:

 Given Adam's comment, I'm going to mark this as `needsinfo` — that info
 being a Proof of concept for what a patch might look like here.

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

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

Re: [Django] #32128: Issue with asgiref dependency installing Django 3.1.x

2020-10-27 Thread Django

#32128: Issue with asgiref dependency installing Django 3.1.x
-+-
 Reporter:  Carlton Gibson   |Owner:  Carlton
 Type:   |  Gibson
  Cleanup/optimization   |   Status:  closed
Component:  Core (Other) |  Version:  3.1
 Severity:  Release blocker  |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Carlton Gibson ):

 In [changeset:"d00127ccab69e8c76d1e3de068d1bd2d20e274c2" d00127c]:
 {{{
 #!CommitTicketReference repository=""
 revision="d00127ccab69e8c76d1e3de068d1bd2d20e274c2"
 [3.1.x] Fixed #32128 -- Added asgiref 3.3 compatibility.

 Thread sensitive parameter is True by default from asgiref v3.3.0.
 Added an explicit thread_sensitive=False to previously implicit uses.

 Backport of e17ee4468875077b90b70bb6a589ebad7493f757 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/071.df6cb1693fc37d64589b1d4e8a7c1493%40djangoproject.com.

Re: [Django] #32128: Issue with asgiref dependency installing Django 3.1.x

2020-10-27 Thread Django

#32128: Issue with asgiref dependency installing Django 3.1.x
-+-
 Reporter:  Carlton Gibson   |Owner:  Carlton
 Type:   |  Gibson
  Cleanup/optimization   |   Status:  closed
Component:  Core (Other) |  Version:  3.1
 Severity:  Release blocker  |   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 Carlton Gibson ):

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


Comment:

 In [changeset:"e17ee4468875077b90b70bb6a589ebad7493f757" e17ee446]:
 {{{
 #!CommitTicketReference repository=""
 revision="e17ee4468875077b90b70bb6a589ebad7493f757"
 Fixed #32128 -- Added asgiref 3.3 compatibility.

 Thread sensitive parameter is True by default from asgiref v3.3.0.
 Added an explicit thread_sensitive=False to previously implicit uses.
 }}}

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

Re: [Django] #32127: textareas are cut off with the admin navigation sidebar.

2020-10-27 Thread Django

#32127: textareas are cut off with the admin navigation sidebar.
-+-
 Reporter:  Mariusz Felisiak |Owner:  Josh
 Type:   |  Santos
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.admin|  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 Carlton Gibson):

 * stage:  Accepted => Ready for checkin


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

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

Re: [Django] #30348: Add superuser_required decorator

2020-10-27 Thread Django

#30348: Add superuser_required decorator
--+---
 Reporter:  Sultan Iman   |Owner:  Sultan Iman
 Type:  New feature   |   Status:  closed
Component:  contrib.auth  |  Version:  master
 Severity:  Normal|   Resolution:  wontfix
 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 Carlton Gibson):

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


Comment:

 Hi all. On review I think we should close this as wontfix.

 I agree with David's comment:5. It's questionable whether you should this
 at all: to the extent that it's possible, you should avoid creating and
 having superusers — use the permissions system.

 Then, if you really do want this, it's a one-liner with
 `user_passes_test()`. (Given the previous point, I'm not inclined to add
 that example to the docs. Folks who want it will work it out.)

 I hope that makes sense.

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

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

Re: [Django] #32128: Issue with asgiref dependency installing Django 3.1.x

2020-10-27 Thread Django

#32128: Issue with asgiref dependency installing Django 3.1.x
-+-
 Reporter:  Carlton Gibson   |Owner:  Carlton
 Type:   |  Gibson
  Cleanup/optimization   |   Status:  assigned
Component:  Core (Other) |  Version:  3.1
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

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


Comment:

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

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

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

Re: [Django] #32143: Use EXISTS to exclude multi-valued relationships

2020-10-27 Thread Django

#32143: Use EXISTS to exclude multi-valued relationships
-+-
 Reporter:  Simon Charette   |Owner:  Simon
 Type:   |  Charette
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * owner:  nobody => Simon Charette
 * status:  new => assigned
 * 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/067.5779a8a03144b4aa33c1bdf8e4ac4045%40djangoproject.com.

Re: [Django] #22841: ModelChoiceField does not make it easy to reuse querysets

Re: [Django] #32153: Support for list arguments inside exclusive required groups

Re: [Django] #11707: limit_choices_to on a ForeignKey can render duplicate options in formfield

Re: [Django] #1891: ForeignKey with m2m filter can duplicate foreign model entries in ModelForm/ModelChoiceField

Re: [Django] #32152: Aggregation over subquery annotation GROUP BY produces wrong results

Re: [Django] #32152: Aggregation over subquery annotation GROUP BY produces wrong results (was: Groupby after aggregation and subquery produces subtly wrong results)

Re: [Django] #32151: Invalid query SQL created when combining in and F() in filter (was: invalid query SQL created when combining in and F() in filter)

Re: [Django] #32152: Groupby after aggregation and subquery produces subtly wrong results

Re: [Django] #32153: Support for list arguments inside exclusive required groups

Re: [Django] #32153: Support for list arguments inside exclusive required groups

Re: [Django] #29712: Add warning in makemessages command if the localecode with `l` flag is not correct

Re: [Django] #32152: Groupby after aggregation and subquery produces subtly wrong results

Re: [Django] #32151: invalid query SQL created when combining __in and F() in filter

Re: [Django] #32152: Groupby after aggregation and subquery produces subtly wrong results

Re: [Django] #32152: Groupby after aggregation and subquery produces subtly wrong results

[Django] #32152: Groupby after aggregation and subquery produces subtly wrong results

Re: [Django] #32151: invalid query SQL created when combining __in and F() in filter

[Django] #32151: invalid query SQL created when combining __in and F() in filter

Re: [Django] #32127: textareas are cut off with the admin navigation sidebar.

Re: [Django] #32127: textareas are cut off with the admin navigation sidebar.

Re: [Django] #32150: Admin Docs No reverse match error

Re: [Django] #32150: Admin Docs No reverse match error

[Django] #32150: Admin Docs No reverse match error

Re: [Django] #32147: timezone error when casting a naive date in a Daylight Saving Time Change

Re: [Django] #1891: ForeignKey with m2m filter can duplicate foreign model entries in ModelForm/ModelChoiceField

Re: [Django] #11707: limit_choices_to on a ForeignKey can render duplicate options in formfield

Re: [Django] #32145: Unclear error raised by makemessages when /locale does not exist under app directory

Re: [Django] #6135: Introduce a short-cut for template filters that has needs_autoescape = True

Re: [Django] #32140: `startTest` result hook not called until after tests already started when `--parallel` used

Re: [Django] #32128: Issue with asgiref dependency installing Django 3.1.x

Re: [Django] #32128: Issue with asgiref dependency installing Django 3.1.x

Re: [Django] #32127: textareas are cut off with the admin navigation sidebar.

Re: [Django] #30348: Add superuser_required decorator

Re: [Django] #32128: Issue with asgiref dependency installing Django 3.1.x

Re: [Django] #32143: Use EXISTS to exclude multi-valued relationships

35 matches

Site Navigation

Mail list logo

Footer information