Re: [Django] #34944: Missing or misinferred attributes in output fields of generated fields

[Django]

#34944: Missing or misinferred attributes in output fields of generated fields
-+-
 Reporter:  Paolo Melchiorre |Owner:  Mariusz
 |  Felisiak
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  5.0
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:  field, database, | Triage Stage:  Accepted
  generated, output_field|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * owner:  Om Dahale => Mariusz Felisiak


Comment:

 [https://github.com/django/django/pull/17470 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/0107018bc7a178c3-f9135726-5125-40f8-b4c2-afffa55bf5b1-00%40eu-central-1.amazonses.com.

Re: [Django] #34967: Queries not generating GROUP BY clause with static annotation crashes on SQLite

[Django]

#34967: Queries not generating GROUP BY clause with static annotation crashes on
SQLite
-+-
 Reporter:  Simon Legtenborg |Owner:  David
 |  Sanders
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  4.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  sqlite   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by David Sanders):

 Jacob & Simon discovered this is only for SQLite <= 3.39.0 which allowed a
 HAVING clause without a GROUP BY:
 https://www.sqlite.org/releaselog/3_39_0.html

-- 
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/0107018bc6965601-a0320d82-9b87-4dc5-9454-4920b8bc85d7-00%40eu-central-1.amazonses.com.

Re: [Django] #34963: Recursive and other "combinator" queries broken in django-cte

[Django]

#34963: Recursive and other "combinator" queries broken in django-cte
---+--
 Reporter:  Daniel Miller  |Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Uncategorized  |  Version:  4.2
 Severity:  Normal |   Resolution:  invalid
 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):

 Hello Daniel!

 I sympathize with the desire to avoid duplicating large chunks of code in
 django-cte and I appreciate that you maintain such a solution but asking
 for the development team to maintain compatibility with its internal
 interface when adjusting bugs of the interface it maintains is not
 sustainable particularly for regressions in versions that have been
 released for a few months already. When making these changes we try to
 think of ways that are not too invasive but there's only so much we can do
 to account for all cases.

 I'm very much open to reviewing patches that would reduce the maintenance
 burden that you face (is there a kwarg that can be passed? a different
 function breakdown be used?) in `main` or that implements smarter way of
 doing things that avoids unnecessary aliasing such as proper `ORDER BY
 $index` support but stability of the ORM internals cannot be guaranteed by
 team in its current state.

 > Is there a way to implement a fix so that it only affects queries where
 aliases are needed?

 I believe that if you build and maintain a package that relies on the
 stability of ORM internals you must be prepared to deal with regressions
 against `main` and suggest alternative solutions when they happen. I'm
 afraid the ship has already sailed for the 4.2 backport support window and
 I'm not even sure it would qualify given the internal nature of SQL
 compilation.

-- 
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/0107018bc5244ed3-d2c062cd-8aa7-4960-b54e-0e4a4e8d11d6-00%40eu-central-1.amazonses.com.

Re: [Django] #34964: Reversing the order of Q objects in a CheckConstraint generates a migration

[Django]

#34964: Reversing the order of Q objects in a CheckConstraint generates a 
migration
-+-
 Reporter:  Jacob Walls  |Owner:  Jacob
 Type:   |  Walls
  Cleanup/optimization   |   Status:  assigned
Component:  Migrations   |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  noop | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by David Wobrock):

 * cc: David Wobrock (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/0107018bc4de736a-269f3068-e1c4-497f-bda9-203e8c75fe52-00%40eu-central-1.amazonses.com.

Re: [Django] #34955: Make Concat() use the database operator `||` on PostgreSQL.

[Django]

#34955: Make Concat() use the database operator `||` on PostgreSQL.
-+-
 Reporter:  Paolo Melchiorre |Owner:  Simon
 Type:   |  Charette
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  field, database, | Triage Stage:  Accepted
  generated, output_field|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by David Wobrock):

 * cc: David Wobrock (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/0107018bc4dc9519-1e1b18d7-3c69-4821-99d1-f079e93a0ce7-00%40eu-central-1.amazonses.com.

Re: [Django] #34964: Reversing the order of Q objects in a CheckConstraint generates a migration

[Django]

#34964: Reversing the order of Q objects in a CheckConstraint generates a 
migration
-+-
 Reporter:  Jacob Walls  |Owner:  Jacob
 Type:   |  Walls
  Cleanup/optimization   |   Status:  assigned
Component:  Migrations   |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  noop | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Jacob Walls):

 Thanks Simon. I just checked more carefully and found that I wasn't able
 to come up with a test case that creates a migration for an existing
 project. (Sorry!)

-- 
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/0107018bc4c6f6a6-51738e1e-76c7-4858-a52c-0cadc77d50e6-00%40eu-central-1.amazonses.com.

Re: [Django] #34954: Improve `output_field` resolution of `Concat` (was: Improve `output_field` resolution in `GenerateField`)

[Django]

#34954: Improve `output_field` resolution of `Concat`
-+-
 Reporter:  Paolo Melchiorre |Owner:  Simon
 Type:   |  Charette
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  field, database, | Triage Stage:  Accepted
  generated, output_field|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Simon Charette):

 * owner:  nobody => Simon Charette
 * status:  new => assigned


Comment:

 Renaming the ticket as it cannot be done generically for `GeneratedField`.
 Each expression must be adapted to do a better job at dealing with mixed
 input and my comment was solely for concat which is straight forward to
 resolve.

-- 
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/0107018bc4a08a7b-09a1a46c-fdaf-4808-9dfb-a48a04da5cbf-00%40eu-central-1.amazonses.com.

Re: [Django] #34958: Intermittent `messages_tests.tests.TestLevelTags.test_lazy` test failure

[Django]

#34958: Intermittent `messages_tests.tests.TestLevelTags.test_lazy` test failure
-+-
 Reporter:  bcail|Owner:  Natalia
 |  Bidart
 Type:  Bug  |   Status:  assigned
Component:  Core (Other) |  Version:  dev
 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 Jacob Walls):

 * 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/0107018bc48aa117-bfe30444-1c5d-4d3a-966a-069f655d1ec0-00%40eu-central-1.amazonses.com.

Re: [Django] #34964: Reversing the order of Q objects in a CheckConstraint generates a migration

[Django]

#34964: Reversing the order of Q objects in a CheckConstraint generates a 
migration
-+-
 Reporter:  Jacob Walls  |Owner:  Jacob
 Type:   |  Walls
  Cleanup/optimization   |   Status:  assigned
Component:  Migrations   |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  noop | 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):

 The creation of new migrations could be avoided entirely by performing the
 sorting only during `__eq__`

 {{{#!diff
 diff --git a/django/db/models/constraints.py
 b/django/db/models/constraints.py
 index 56d547e6b0..e221bebd8b 100644
 --- a/django/db/models/constraints.py
 +++ b/django/db/models/constraints.py
 @@ -152,14 +152,22 @@ def __repr__(self):
  )

  def __eq__(self, other):
 -if isinstance(other, CheckConstraint):
 -return (
 -self.name == other.name
 -and self.check == other.check
 -and self.violation_error_code ==
 other.violation_error_code
 -and self.violation_error_message ==
 other.violation_error_message
 -)
 -return super().__eq__(other)
 +if not isinstance(other, CheckConstraint):
 +return super().__eq__(other)
 +# Relax check equality to equivalence comparisons to allow
 +# re-ordering of components.
 +if isinstance(self.check, Q):
 +if not isinstance(other.check, Q) or not
 self.check.equivalent_to(
 +other.check
 +):
 +return False
 +elif self.check != other.check:
 +return False
 +return (
 +self.name == other.name
 +and self.violation_error_code == other.violation_error_code
 +and self.violation_error_message ==
 other.violation_error_message
 +)

  def deconstruct(self):
  path, args, kwargs = super().deconstruct()
 }}}

-- 
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/0107018bc47bee52-04705b86-8aca-44c7-9043-e481b866e539-00%40eu-central-1.amazonses.com.

Re: [Django] #34964: Reversing the order of Q objects in a CheckConstraint generates a migration

[Django]

#34964: Reversing the order of Q objects in a CheckConstraint generates a 
migration
-+-
 Reporter:  Jacob Walls  |Owner:  Jacob
 Type:   |  Walls
  Cleanup/optimization   |   Status:  assigned
Component:  Migrations   |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  noop | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Jacob Walls):

 Simon's suggestion on the PR was to sort Q objects in the constructor of
 `CheckConstraint` so that we wouldn't even get into a situation where the
 autodetector would be remaining quiet even with SQL changes. I see that
 this would come at the cost of causing migrations to be emitted for
 existing projects, though, so we might want a release note.

 The case that originally prompted me to open a ticket was for a migration
 dropping and recreating a constraint with the exact same SQL, e.g.
 changing `Q(A) & Q(B)` to `Q(A, B)` . I just added a regression test for
 this case.

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018bc45cbc40-b2022723-8fb0-405e-b982-616bf6231cd3-00%40eu-central-1.amazonses.com.

Re: [Django] #34967: Queries not generating GROUP BY clause with static annotation crashes on SQLite

[Django]

#34967: Queries not generating GROUP BY clause with static annotation crashes on
SQLite
-+-
 Reporter:  Simon Legtenborg |Owner:  David
 |  Sanders
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  4.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  sqlite   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by David Sanders):

 * owner:  nobody => David Sanders
 * status:  new => assigned
 * 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/0107018bc3d1d6c4-0f10c259-6d03-4e2b-ac1d-7a016fd242ab-00%40eu-central-1.amazonses.com.

Re: [Django] #34967: Queries not generating GROUP BY clause with static annotation crashes on SQLite (was: Django ORM not generating GROUP BY clause with static annotation)

[Django]

#34967: Queries not generating GROUP BY clause with static annotation crashes on
SQLite
-+-
 Reporter:  Simon Legtenborg |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  4.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  sqlite   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by David Sanders):

 * keywords:   => sqlite


Comment:

 This appears to only affect SQLite.

 I haven't tested on Oracle.

-- 
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/0107018bc3a84958-461de9ad-3486-4f77-a6a5-8679808a6f58-00%40eu-central-1.amazonses.com.

Re: [Django] #34967: Django ORM not generating GROUP BY clause with static annotation

[Django]

#34967: Django ORM not generating GROUP BY clause with static annotation
-+-
 Reporter:  Simon Legtenborg |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  4.2
  (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 David Sanders):

 * stage:  Unreviewed => Accepted


Comment:

 Thanks 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/0107018bc3935153-b1c4418b-3363-4985-9175-2a2a59106917-00%40eu-central-1.amazonses.com.

[Django] #34967: Django ORM not generating GROUP BY clause with static annotation

[Django]

#34967: Django ORM not generating GROUP BY clause with static annotation
-+-
   Reporter:  Simon  |  Owner:  nobody
  Legtenborg |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  4.2
  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  |
-+-
 Django ORM is not generating a GROUP BY clause with static annotation.
 After filtering, Django ORM inserts a HAVING clause, but GROUP BY is
 missing.

 **Expected Behavior**
 The Django ORM should generate a SQL query with a GROUP_BY clause when
 using `.values()` and `.annotate()` methods on a queryset.

 **Actual Behvaior**
 The ORM is not generating a GROUP BY clause when a static annotation is
 used. However, it does generate it when a non-trivial annotation is used.


 **Steps to reproduce**

 With a small model
 {{{
 class Book(models.Model):
 title = models.CharField(max_length=100)
 pages = models.IntegerField(default=0)
 }}}

 and the corresponding view


 {{{
 def bug_view(request):
 queryset = Book.objects.all()
 print(f"query: {queryset.query}")

 # trivial annotation
 annotated_queryset = queryset.annotate(group=Value('all'))
 print(f"annotated_query: {annotated_queryset.query}")

 # grouped_and_annotated_query won't have a GROUP BY clause
 grouped_and_annotated_queryset =
 annotated_queryset.values('group').annotate(sum=models.Sum('pages'))
 print(f"grouped_and_annotated_query:
 {grouped_and_annotated_queryset.query}")

 # filtered_query contains HAVING clause but no GROUP BY clause
 filtered_queryset = grouped_and_annotated_queryset.filter(sum__gt=10)
 print(f"filtered_query: {filtered_queryset.query}")
 return HttpResponse(filtered_queryset)
 }}}

 Django raises a django.db.utils.OperationalError. The (printed) querries
 are


 {{{
 query: SELECT "books_book"."id", "books_book"."title",
 "books_book"."pages" FROM "books_book"

 annotated_query: SELECT "books_book"."id", "books_book"."title",
 "books_book"."pages", all AS "group" FROM "books_book"

 grouped_and_annotated_query: SELECT all AS "group",
 SUM("books_book"."pages") AS "sum" FROM "books_book"

 filtered_query: SELECT all AS "group", SUM("books_book"."pages") AS "sum"
 FROM "books_book" HAVING SUM("books_book"."pages") > 10
 }}}

 As you can see, there is no GROUP BY keyword in the
 grouped_and_annotated_query. But after filtering, a HAVING keyword is
 inserted, without a GROUP BY.  This is the main reason for this error.
 This happens only to static annotations. If i evaluate a more complex
 annotation, the grouping works as intended:

 {{{
 def without_bug_view(request):
 queryset = Book.objects.all()
 print(f"query: {queryset.query}")

 # non-trivial annotation
 annotated_queryset = queryset.annotate(large=Case(
 When(pages__gt=650, then=Value(True)),
 default=Value(False),
 output_field=BooleanField()))
 print(f"annotated_query: {annotated_queryset.query}")
 grouped_and_annotated_queryset =
 annotated_queryset.values('large').annotate(sum=models.Sum('pages'))
 print(f"grouped_and_annotated_query:
 {grouped_and_annotated_queryset.query}")
 filtered_queryset = grouped_and_annotated_queryset.filter(sum__gt=0)
 print(f"filtered_query: {filtered_queryset.query}")
 return HttpResponse(filtered_queryset)
 }}}

 querries:
 {{{
 query: SELECT "books_book"."id", "books_book"."title",
 "books_book"."pages" FROM "books_book"

 annotated_query: SELECT "books_book"."id", "books_book"."title",
 "books_book"."pages", CASE WHEN "books_book"."pages" > 650 THEN True ELSE
 False END AS "large" FROM "books_book"

 grouped_and_annotated_query: SELECT CASE WHEN "books_book"."pages" > 650
 THEN True ELSE False END AS "large", SUM("books_book"."pages") AS "sum"
 FROM "books_book" GROUP BY 1

 filtered_query: SELECT CASE WHEN "books_book"."pages" > 650 THEN True ELSE
 False END AS "large", SUM("books_book"."pages") AS "sum" FROM "books_book"
 GROUP BY 1 HAVING SUM("books_book"."pages") > 0
 }}}

 The GROUP BY keyword is inserted as is should.


 Here is the Stack Trace for completeness:


 {{{
 Error
 Traceback (most recent call last):
   File
 "/home/simonlegtenborg/PycharmProjects/djangoProject/venv/lib/python3.11
 /site-packages/django/db/backends/utils.py", line 89, in _execute
 return self.cursor.execute(sql, params)

   File
 "/home/simonlegtenborg/PycharmProjects/djangoProject/venv/lib/python3.11
 

Re: [Django] #34966: Add a check for ModelAdmin.actions functions not taking three arguments (was: add checks for ModelAdmin.actions functions not taking three arguments)

[Django]

#34966: Add a check for ModelAdmin.actions functions not taking three arguments
-+-
 Reporter:  Riccardo |Owner:  nobody
  Magliocchetti  |
 Type:  New feature  |   Status:  new
Component:  contrib.admin|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  admin actions| Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/0107018bc33120b6-aa205203-6d78-46b6-b48c-c8680ab3d715-00%40eu-central-1.amazonses.com.

[Django] #34966: add checks for ModelAdmin.actions functions not taking three arguments

[Django]

#34966: add checks for ModelAdmin.actions functions not taking three arguments
-+-
   Reporter:  Riccardo   |  Owner:  nobody
  Magliocchetti  |
   Type:  New| Status:  new
  feature|
  Component: |Version:  dev
  contrib.admin  |
   Severity:  Normal |   Keywords:  admin actions
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Recently I've introduced a runtime exception because after a refactoring a
 function implementing an action got renamed but the old name stayed as an
 helper with 1 parameter. Setting in ModelAdmin.actions a function that
 does not take 3 arguments will raise an exception in
 BaseModelAdmin.response_action.
 A check that will throw an error in that case could have saved me some
 embarassament in production :)

 A rough untested implementation could look something like that:

 {{{
 diff --git a/django/contrib/admin/checks.py
 b/django/contrib/admin/checks.py
 index 1665023434..9c4f7f125a 100644
 --- a/django/contrib/admin/checks.py
 +++ b/django/contrib/admin/checks.py
 @@ -1,4 +1,5 @@
  import collections
 +import inspect
  from itertools import chain

  from django.apps import apps
 @@ -1244,6 +1245,31 @@ class ModelAdminChecks(BaseModelAdminChecks):
  )
  return errors

 +def _check_actions_parameters(self, obj):
 +"""Check that every action takes the correct number of
 parameters."""
 +errors = []
 +actions = obj._get_base_actions()
 +expected_func_parameters = 3
 +for func, name, _ in actions:
 +params = inspect.signature(func).parameters.values()
 +# TODO: does people define actions functions with more
 parameters with a default?
 +if len(params) != expected_func_parameters:
 +errors.append(
 +checks.Error(
 +"action %r used in %s has an invalid number of
 parameters. Expected %d got %d."
 +% (
 +name,
 +obj.__class__.__name__,
 +expected_func_parameters,
 +len(params),
 +),
 +obj=obj.__class__,
 +id="admin.E131",
 +)
 +)
 +return errors
 +
 +

  class InlineModelAdminChecks(BaseModelAdminChecks):
  def check(self, inline_obj, **kwargs):

 }}}

-- 
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/0107018bc330d0d0-94519ddf-f3a6-4e4a-9cc1-5472dc4642d9-00%40eu-central-1.amazonses.com.

Re: [Django] #34965: @sensitive_variables for coroutine func are not recursive

[Django]

#34965: @sensitive_variables for coroutine func are not recursive
-+-
 Reporter:  vagi8|Owner:  vageeshan
 Type:  Bug  |   Status:  assigned
Component:  Uncategorized|  Version:  5.0
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
  @sensitive_variables,  |  Unreviewed
  @sensitive_post_parameters |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by vagi8):

 * 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/0107018bc309aeb9-b2b01996-5405-41c5-946e-7fcd1c49d4ba-00%40eu-central-1.amazonses.com.

Re: [Django] #34965: @sensitive_variables for coroutine func are not recursive

[Django]

#34965: @sensitive_variables for coroutine func are not recursive
-+-
 Reporter:  Vageeshan Mankala|Owner:  vageeshan
 Type:  Bug  |   Status:  assigned
Component:  Uncategorized|  Version:  5.0
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
  @sensitive_variables,  |  Unreviewed
  @sensitive_post_parameters |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Vageeshan Mankala):

 * cc: Vageeshan Mankala (removed)
 * type:  Uncategorized => Bug


-- 
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/0107018bc307f180-ee0763ac-110a-4e27-8c80-6a112a38e3d8-00%40eu-central-1.amazonses.com.

Re: [Django] #34965: @sensitive_variables for coroutine func are not recursive

[Django]

#34965: @sensitive_variables for coroutine func are not recursive
-+-
 Reporter:  vagi8|Owner:  vageeshan
 Type:  Uncategorized|   Status:  assigned
Component:  Uncategorized|  Version:  5.0
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
  @sensitive_variables,  |  Unreviewed
  @sensitive_post_parameters |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by vagi8):

 * cc: vagi8 (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/0107018bc3068049-02412f52-958d-4c4e-91f9-f713fc7f8648-00%40eu-central-1.amazonses.com.

Re: [Django] #34965: @sensitive_variables for coroutine func are not recursive

[Django]

#34965: @sensitive_variables for coroutine func are not recursive
-+-
 Reporter:  vagi8|Owner:  vageeshan
 Type:  Uncategorized|   Status:  assigned
Component:  Uncategorized|  Version:  5.0
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
  @sensitive_variables,  |  Unreviewed
  @sensitive_post_parameters |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by vagi8):

 * owner:  nobody => vageeshan
 * 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/0107018bc3065ba1-a4e452c4-8a9f-4a8b-9167-ddd250d896ac-00%40eu-central-1.amazonses.com.

[Django] #34965: @sensitive_variables for coroutine func are not recursive

[Django]

#34965: @sensitive_variables for coroutine func are not recursive
-+-
   Reporter:  vagi8  |  Owner:  nobody
   Type: | Status:  new
  Uncategorized  |
  Component: |Version:  5.0
  Uncategorized  |   Keywords:
   Severity:  Normal |  @sensitive_variables,
   Triage Stage: |  @sensitive_post_parameters
  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 There is a difference in functionality of how
 @sensitive_variables/sensitive_post_parameters work for synchronous
 functions and asynchronous functions.

 Sync funcs. - It recursively hides the variables from all frames in the
 stack until new sensitive variables are defined for a frame. Example,
 Wrappers to nested function calls, variables are hidden.
 Async funcs. - It only hides the variables in the top most frame of the
 stack. Example, If there is view func with sensitive variables, and it
 also has a decorator, it hides only in the wrapper and not in the actual
 view.

 I would expect both to work in similar way. I am also deeply invested in
 the idea so I willing to contribute a 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/0107018bc2fdc327-7b371f16-7924-4cef-b78f-f27b7527cd6d-00%40eu-central-1.amazonses.com.

Re: [Django] #34229: "no such column" when combining FilteredRelation and multi-table inheritance models

[Django]

#34229: "no such column" when combining FilteredRelation and multi-table
inheritance models
-+-
 Reporter:  Javier Ayres |Owner:  Turonbek
 |  Kuzibaev
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  4.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  filteredrelation | Triage Stage:  Accepted
  such column|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Turonbek Kuzibaev):

 * owner:  nobody => Turonbek Kuzibaev
 * 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/0107018bc2a4181a-ba515816-3927-4f16-b9f2-e3f7be69109e-00%40eu-central-1.amazonses.com.