Re: [Django] #32532: Provide friendlier error if a file path is passed as a test label when running tests

[Django]

#32532: Provide friendlier error if a file path is passed as a test label when
running tests
-+-
 Reporter:  Chris Jerdonek   |Owner:  Chris
 Type:   |  Jerdonek
  Cleanup/optimization   |   Status:  assigned
Component:  Testing framework|  Version:  3.1
 Severity:  Normal   |   Resolution:
 Keywords:  DiscoverRunner,test  | Triage Stage:  Accepted
  labels |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Chris Jerdonek):

 * easy:  1 => 0


Comment:

 With my posted patch, the new error will look like this:

 {{{
 $ ./runtests.py test_runner/tests.py
 Testing against Django installed in '.../django/django' with up to 8
 processes
 Traceback (most recent call last):
   ...
 RuntimeError: One of the test labels is a path to a file:
 'test_runner/tests.py'
 Test labels that are paths but not importable as names can only be
 directories.
 }}}

 (By the way, I unchecked "easy" because this wasn't necessarily so easy
 given that `is_discoverable()` had to be broken up to get the info needed
 for the patch.)

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

Re: [Django] #32596: Add a method to CsrfViewMiddleware to encapsulate its referer logic

[Django]

#32596: Add a method to CsrfViewMiddleware to encapsulate its referer logic
-+-
 Reporter:  Chris Jerdonek   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  CSRF |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
  CsrfViewMiddleware,referer |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Chris Jerdonek:

Old description:

> The `CsrfViewMiddleware` class's
> [https://github.com/django/django/blob/cac9ec73db35a6d38d33f271f4724da486c60e9f/django/middleware/csrf.py#L259-L379
> process_view()`] method currently clocks in at 120 lines. If a method
> were added that encapsulates its HTTP referer logic (similar to how
> `CsrfViewMiddleware._origin_verified()` encapsulates its origin logic),
> its length could be cut in half. I think this would make the method a lot
> easier to maintain and understand. For example, in addition to being
> shorter, one optimization I'm thinking of would be easier to implement.
> This is because there's no way to "jump out" of an if-block, whereas with
> a method, you can return early.
>
> Given that the reason string for rejecting a request can vary in the
> referer case, I would suggest a method that raises an exception internal
> to the module, rather than returning a value. The call could then look
> something like this (it would go here:
> https://github.com/django/django/blob/cac9ec73db35a6d38d33f271f4724da486c60e9f/django/middleware/csrf.py#L283):
>
> {{{#!python
> elif request.is_secure():
> try:
> self._check_referer(request)
> except _RejectRequest as exc:
> return self._reject(request, exc.reason)
> }}}

New description:

 The `CsrfViewMiddleware` class's
 
[https://github.com/django/django/blob/cac9ec73db35a6d38d33f271f4724da486c60e9f/django/middleware/csrf.py#L259-L379
 process_view()] method currently clocks in at 120 lines. If a method were
 added that encapsulates its HTTP referer logic (similar to how
 `CsrfViewMiddleware._origin_verified()` encapsulates its origin logic),
 its length could be cut in half. I think this would make the method a lot
 easier to maintain and understand. For example, in addition to being
 shorter, one optimization I'm thinking of would be easier to implement.
 This is because there's no way to "jump out" of an if-block, whereas with
 a method, you can return early.

 Given that the reason string for rejecting a request can vary in the
 referer case, I would suggest a method that raises an exception internal
 to the module, rather than returning a value. The call could then look
 something like this (it would go here:
 
https://github.com/django/django/blob/cac9ec73db35a6d38d33f271f4724da486c60e9f/django/middleware/csrf.py#L283):

 {{{#!python
 elif request.is_secure():
 try:
 self._check_referer(request)
 except _RejectRequest as exc:
 return self._reject(request, exc.reason)
 }}}

--

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

[Django] #32596: Add a method to CsrfViewMiddleware to encapsulate its referer logic

[Django]

#32596: Add a method to CsrfViewMiddleware to encapsulate its referer logic
-+-
   Reporter:  Chris  |  Owner:  nobody
  Jerdonek   |
   Type: | Status:  new
  Cleanup/optimization   |
  Component:  CSRF   |Version:  dev
   Severity:  Normal |   Keywords:
   Triage Stage: |  CsrfViewMiddleware,referer
  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 The `CsrfViewMiddleware` class's
 
[https://github.com/django/django/blob/cac9ec73db35a6d38d33f271f4724da486c60e9f/django/middleware/csrf.py#L259-L379
 process_view()`] method currently clocks in at 120 lines. If a method were
 added that encapsulates its HTTP referer logic (similar to how
 `CsrfViewMiddleware._origin_verified()` encapsulates its origin logic),
 its length could be cut in half. I think this would make the method a lot
 easier to maintain and understand. For example, in addition to being
 shorter, one optimization I'm thinking of would be easier to implement.
 This is because there's no way to "jump out" of an if-block, whereas with
 a method, you can return early.

 Given that the reason string for rejecting a request can vary in the
 referer case, I would suggest a method that raises an exception internal
 to the module, rather than returning a value. The call could then look
 something like this (it would go here:
 
https://github.com/django/django/blob/cac9ec73db35a6d38d33f271f4724da486c60e9f/django/middleware/csrf.py#L283):

 {{{#!python
 elif request.is_secure():
 try:
 self._check_referer(request)
 except _RejectRequest as exc:
 return self._reject(request, exc.reason)
 }}}

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

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

Re: [Django] #31840: Add Support for Cross-Origin Opener Policy header (was: Adding Support for Cross-Origin Opener Policy)

[Django]

#31840: Add Support for Cross-Origin Opener Policy header
-+-
 Reporter:  meggles711   |Owner:
 |  meggles711
 Type:  New feature  |   Status:  assigned
Component:  HTTP handling|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  COOP, security,  | Triage Stage:  Accepted
  headers|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * needs_better_patch:  1 => 0


Comment:

 [https://github.com/django/django/pull/14189 Updated PR]

 I addressed Adam's comment and made edits based on my own review.

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

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

Re: [Django] #32595: mysql DatabaseSchemaEditor can't `quote_value` on byte strings

[Django]

#32595: mysql DatabaseSchemaEditor can't `quote_value` on byte strings
-+-
 Reporter:  Ryan Siemens |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
-+-
Changes (by Ryan Siemens):

 * cc: Ryan Siemens (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/066.93644b89ba08b6e5081e633b784e166d%40djangoproject.com.

Re: [Django] #32595: mysql DatabaseSchemaEditor can't `quote_value` on byte strings

[Django]

#32595: mysql DatabaseSchemaEditor can't `quote_value` on byte strings
-+-
 Reporter:  Ryan Siemens |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
-+-
Changes (by Ryan Siemens):

 * Attachment "example.tar.gz" added.

 example app to recreate 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/066.8dda0514ebd90aa1d8a554392a0c4802%40djangoproject.com.

[Django] #32595: mysql DatabaseSchemaEditor can't `quote_value` on byte strings

[Django]

#32595: mysql DatabaseSchemaEditor can't `quote_value` on byte strings
-+-
   Reporter:  Ryan   |  Owner:  nobody
  Siemens|
   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  |
-+-
 Using the the `django.db.backends.mysql` backend with `mysqlclient` fails
 to render the schema migration with `sqlmigrate` when using a
 `BinaryField` with a binary string default value.

 You can recreate this with a simple app using the following model or see
 the attached sample project (MD5 = 2be52a23a4001e90728d3b0f5276e087):

 {{{
 class TestModel(models.Model):
 ok = models.BinaryField(default=b'some-blob')
 # add this after the initial migration
 # not_ok = models.BinaryField(default=b'some-other-blob')
 }}}

 Then perform the following steps:

 1. run initial `manage.py makemigrations`
 2. uncomment the `not_ok = models.BinaryField(default=b'some-other-blob')`
 3. run `manage.py makemigrations` again to generate the alter table
 migration
 4. run `manage.py sqlmigrate  0002`
 5. assert the following `TypeError` is raised

 {{{
 Traceback (most recent call last):
   File "manage.py", line 22, in 
 main()
   File "manage.py", line 18, in main
 execute_from_command_line(sys.argv)
   File "/Users/rsiemens/sandbox/quote_value_bug/.venv/lib/python3.8/site-
 packages/django/core/management/__init__.py", line 401, in
 execute_from_command_line
 utility.execute()
   File "/Users/rsiemens/sandbox/quote_value_bug/.venv/lib/python3.8/site-
 packages/django/core/management/__init__.py", line 395, in execute
 self.fetch_command(subcommand).run_from_argv(self.argv)
   File "/Users/rsiemens/sandbox/quote_value_bug/.venv/lib/python3.8/site-
 packages/django/core/management/base.py", line 330, in run_from_argv
 self.execute(*args, **cmd_options)
   File "/Users/rsiemens/sandbox/quote_value_bug/.venv/lib/python3.8/site-
 packages/django/core/management/commands/sqlmigrate.py", line 29, in
 execute
 return super().execute(*args, **options)
   File "/Users/rsiemens/sandbox/quote_value_bug/.venv/lib/python3.8/site-
 packages/django/core/management/base.py", line 371, in execute
 output = self.handle(*args, **options)
   File "/Users/rsiemens/sandbox/quote_value_bug/.venv/lib/python3.8/site-
 packages/django/core/management/commands/sqlmigrate.py", line 65, in
 handle
 sql_statements = loader.collect_sql(plan)
   File "/Users/rsiemens/sandbox/quote_value_bug/.venv/lib/python3.8/site-
 packages/django/db/migrations/loader.py", line 345, in collect_sql
 state = migration.apply(state, schema_editor, collect_sql=True)
   File "/Users/rsiemens/sandbox/quote_value_bug/.venv/lib/python3.8/site-
 packages/django/db/migrations/migration.py", line 124, in apply
 operation.database_forwards(self.app_label, schema_editor, old_state,
 project_state)
   File "/Users/rsiemens/sandbox/quote_value_bug/.venv/lib/python3.8/site-
 packages/django/db/migrations/operations/fields.py", line 104, in
 database_forwards
 schema_editor.add_field(
   File "/Users/rsiemens/sandbox/quote_value_bug/.venv/lib/python3.8/site-
 packages/django/db/backends/mysql/schema.py", line 89, in add_field
 super().add_field(model, field)
   File "/Users/rsiemens/sandbox/quote_value_bug/.venv/lib/python3.8/site-
 packages/django/db/backends/base/schema.py", line 487, in add_field
 self.execute(sql, params)
   File "/Users/rsiemens/sandbox/quote_value_bug/.venv/lib/python3.8/site-
 packages/django/db/backends/base/schema.py", line 137, in execute
 self.collected_sql.append((sql % tuple(map(self.quote_value, params)))
 + ending)
   File "/Users/rsiemens/sandbox/quote_value_bug/.venv/lib/python3.8/site-
 packages/django/db/backends/mysql/schema.py", line 55, in quote_value
 quoted = self.connection.connection.escape(value,
 self.connection.connection.encoders)
 TypeError: bytes() argument 2 must be str, not dict
 }}}

 The error seems to be raised from the mysqlclient `connection.escape`, but
 interestingly this works if you alter the
 `self.connection.connection.encoders` right before escaping
 
(https://github.com/django/django/blob/main/django/db/backends/mysql/schema.py#L57)
 by doing `self.connection.connection.encoders.pop(bytes)`. Looking at the
 default converters mysqlclient sets up
 
(https://github.com/PyMySQL/mysqlclient/blob/v2.0.1/MySQLdb/converters.py#L106-L139)
 I don't see a `bytes` one being added, so 

Re: [Django] #13659: Make the request accessible in callables used in ModelAdmin.list_display

[Django]

#13659: Make the request accessible in callables used in ModelAdmin.list_display
-+
 Reporter:  Sebastian Noack  |Owner:  Paulo
 Type:  New feature  |   Status:  assigned
Component:  contrib.admin|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+

Comment (by Tim Graham):

 No, storing state on the `ModelAdmin` class isn't thread-safe.

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

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

Re: [Django] #13659: Make the request accessible in callables used in ModelAdmin.list_display

[Django]

#13659: Make the request accessible in callables used in ModelAdmin.list_display
-+
 Reporter:  Sebastian Noack  |Owner:  Paulo
 Type:  New feature  |   Status:  assigned
Component:  contrib.admin|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+

Comment (by dbartenstein):

 As callables in list_display don’t get the request object, is it safe to
 add the request object as attribute to the admin class object? In the
 callable it would then be possible to access the request via self.request
 to e.g. check if the current user has permission to edit the object.

 Code sample:
 {{{
 def changelist_view(self, request, extra_context=None):
 self.request = request  # Is it safe to store the request?
 return super().changelist_view(request, extra_context)

 }}}

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

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

Re: [Django] #32594: Signal.disconnect() returns None when passing sender as string

[Django]

#32594: Signal.disconnect() returns None when passing sender as string
-+-
 Reporter:  Hugo Cachitas|Owner:  Hugo
 |  Cachitas
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  4.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  signals  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * cc: Alex Hill (added)
 * stage:  Unreviewed => Accepted


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

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

Re: [Django] #31003: Suggesting: Documentation update for bulk_create method

[Django]

#31003: Suggesting: Documentation update for bulk_create method
-+-
 Reporter:  Peter Vlasveld   |Owner:  Adam
 Type:   |  Johnson
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  3.0
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  bulk_create, | Triage Stage:  Accepted
  database, query,   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"3eb72ad30f89e6774bfbf0f1223442493955fd74" 3eb72ad3]:
 {{{
 #!CommitTicketReference repository=""
 revision="3eb72ad30f89e6774bfbf0f1223442493955fd74"
 [3.2.x] Refs #31003 -- Moved note about return value of
 QuerySet.bulk_create() to the first paragraph.

 Backport of cac9ec73db35a6d38d33f271f4724da486c60e9f from main.
 }}}

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

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

Re: [Django] #31003: Suggesting: Documentation update for bulk_create method

[Django]

#31003: Suggesting: Documentation update for bulk_create method
-+-
 Reporter:  Peter Vlasveld   |Owner:  Adam
 Type:   |  Johnson
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  3.0
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  bulk_create, | Triage Stage:  Accepted
  database, query,   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"cac9ec73db35a6d38d33f271f4724da486c60e9f" cac9ec73]:
 {{{
 #!CommitTicketReference repository=""
 revision="cac9ec73db35a6d38d33f271f4724da486c60e9f"
 Refs #31003 -- Moved note about return value of QuerySet.bulk_create() to
 the first paragraph.
 }}}

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

Re: [Django] #32593: Cast() to DecimalField() raises DataError.

[Django]

#32593: Cast() to DecimalField() raises DataError.
+--
 Reporter:  Charles Cunningham  |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  Migrations  |  Version:  3.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 Mariusz Felisiak):

 Replying to [comment:3 Charles Cunningham]:
 > Wouldn't that result in integer division?

 True, it depends on a database but on PostgreSQL you need to `Cast()` at
 least one of them.

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

Re: [Django] #18597: `BaseInlineFormSet` should attempt to get it's queryset from it's instance related manager before falling back to it's model's default manager

[Django]

#18597: `BaseInlineFormSet` should attempt to get it's queryset from it's 
instance
related manager before falling back to it's model's default manager
--+
 Reporter:  Simon Charette|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Forms |  Version:  3.2
 Severity:  Normal|   Resolution:
 Keywords:  model formset inline  | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  1 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Andreas Galazis):

 * needs_better_patch:  1 => 0


Comment:

 added a PR related to the code cleanup needed to support custom inlines :
 https://github.com/django/django/pull/14188

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

Re: [Django] #32593: Cast() to DecimalField() raises DataError.

[Django]

#32593: Cast() to DecimalField() raises DataError.
+--
 Reporter:  Charles Cunningham  |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  Migrations  |  Version:  3.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 Charles Cunningham):

 Replying to [comment:1 Mariusz Felisiak]:
 > You cannot `Cast()` to `DecimalField`, or use it in `output_field`,
 without providing `decimal_places` and `max_digits` arguments, e.g.
 `DecimalField(decimal_places=2, max_digits=10)` works for me. Also, as far
 as I'm aware there is no need to use `Cast()` in your case:
 > {{{
 > ...
 > then=F("registration_volume") / F("capacity"),
 > ...
 > }}}

 Wouldn't that result in integer division? Or if the output_field is
 DecimalField, will it do decimal division?

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

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

[Django]

#32316: Access __file__ lazily rather than at module level
-+-
 Reporter:  William Schwartz |Owner:  William
 Type:   |  Schwartz
  Cleanup/optimization   |   Status:  assigned
Component:  Core (Other) |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  freezers | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by William Schwartz):

 * needs_better_patch:  1 => 0


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

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

Re: [Django] #14845: Document connection-creation process

[Django]

#14845: Document connection-creation process
---+
 Reporter:  Christophe Pettus  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Documentation  |  Version:  dev
 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 GwynBleidD):

 * cc: GwynBleidD (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/061.ba92711a7ca411389e95bab469ac8cb8%40djangoproject.com.

Re: [Django] #32594: Signal.disconnect() returns None when passing sender as string

[Django]

#32594: Signal.disconnect() returns None when passing sender as string
-+-
 Reporter:  Hugo Cachitas|Owner:  Hugo
 |  Cachitas
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  4.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  signals  | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Hugo Cachitas):

 * keywords:   => signals


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

Re: [Django] #32594: Signal.disconnect() returns None when passing sender as string

[Django]

#32594: Signal.disconnect() returns None when passing sender as string
-+-
 Reporter:  Hugo Cachitas|Owner:  Hugo
 |  Cachitas
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  4.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Hugo Cachitas):

 * 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/066.31cfccb015f37a71467e6bc2888a4821%40djangoproject.com.

Re: [Django] #32594: Signal.disconnect() returns None when passing sender as string

[Django]

#32594: Signal.disconnect() returns None when passing sender as string
-+-
 Reporter:  Hugo Cachitas|Owner:  Hugo
 |  Cachitas
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  4.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Hugo Cachitas):

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

 The solution involved touching the app registry.
 Tests are passing, but I am not entirely sure of the implications the new
 intermediary returned values may have.

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

[Django] #32594: Signal.disconnect() returns None when passing sender as string

[Django]

#32594: Signal.disconnect() returns None when passing sender as string
-+-
   Reporter:  Hugo   |  Owner:  Hugo Cachitas
  Cachitas   |
   Type:  Bug| Status:  assigned
  Component:  Database   |Version:  4.0
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+-
 According to the documentation on `Signal.disconnect(receiver=None,
 sender=None, dispatch_uid=None)`

   The method returns True if a receiver was disconnected and False if not.

 I am having this issue where `disconnect()` returns `None` when I specify
 the sender as a string model reference, i.e., passing
 `sender="myapp.MyModel"` instead of `sender=MyModel`.

 The sender may be lazily specified as a string as documented in
 `django.db.models.signals.ModelSignal`.
 To achieve this functionality, a `_lazy_method` is implemented where we
 can find that the return value is not properly set.

 {{{
 #!python
 if isinstance(sender, str):
 apps = apps or Options.default_apps
 apps.lazy_model_operation(partial_method, make_model_tuple(sender))
 else:
 return partial_method(sender)
 }}}

 I already have a failing test at
 `tests/signals/tests.py:LazyModelRefTests` that could use your input.

 {{{
 #!python
 @isolate_apps('signals', kwarg_name='apps')
 def test_disconnect_return_value(self, apps):
 """
 Signal.disconnect() return value should be consistent if we
 use the Model or its string reference.
 """

 class Created(models.Model):
 pass

 def receiver(**kwargs):
 pass

 sender = Created
 signals.post_init.connect(receiver, sender=sender, apps=apps)
 self.assertTrue(
 signals.post_init.disconnect(receiver, sender=sender, apps=apps)
 )
 self.assertFalse(
 signals.post_init.disconnect(receiver, sender=sender, apps=apps)
 )

 sender = 'signals.Created'
 signals.post_init.connect(receiver, sender=sender, apps=apps)
 self.assertTrue(
 signals.post_init.disconnect(receiver, sender=sender, apps=apps)
 )
 self.assertFalse(
 signals.post_init.disconnect(receiver, sender=sender, apps=apps)
 )
 }}}

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

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

Re: [Django] #32578: Handle request.get_host() raising DisallowedHost in CsrfViewMiddleware._origin_verified()

[Django]

#32578: Handle request.get_host() raising DisallowedHost in
CsrfViewMiddleware._origin_verified()
-+-
 Reporter:  Chris Jerdonek   |Owner:  Chris
 |  Jerdonek
 Type:  Bug  |   Status:  closed
Component:  CSRF |  Version:  dev
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
  CsrfViewMiddleware,DisallowedHost  |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"ff514309e178e3955012050ead9b8fc66dc21a5b" ff514309]:
 {{{
 #!CommitTicketReference repository=""
 revision="ff514309e178e3955012050ead9b8fc66dc21a5b"
 Fixed #32578 -- Fixed crash in CsrfViewMiddleware when a request with
 Origin header has an invalid host.
 }}}

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

Re: [Django] #31487: Add support for precision argument to Round

[Django]

#31487: Add support for precision argument to Round
-+-
 Reporter:  Baptiste Mispelon|Owner:  Nick Pope
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  database function,   | Triage Stage:  Accepted
  round, precision, decimal places   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Nick Pope):

 * keywords:   => database function, round, precision, decimal places
 * owner:  (none) => Nick Pope
 * has_patch:  0 => 1
 * version:  3.0 => dev
 * status:  new => assigned


Comment:

 For once, I can't remember exactly why we didn't do this, hence my opening
 of the duplicate ticket #32592 yesterday looking to fix exactly this
 issue.

 I can think of a number of possible reasons based on the discussions and
 looking at the existing code:

 - Something to do with the rounding issue around `0.5`. ''(I don't think
 this should stop us supporting the second argument. We already mention it
 in the [https://docs.djangoproject.com/en/3.1/ref/models/database-
 functions/#round documentation].)''
 - Something to do with `Round` being a `Transform` which sets `arity = 1`.
 ''(This can be overridden back to `None` while still allowing the
 transform to work.)''
 - Something to do with SpatiaLite. I'm not sure what that comment was
 about as SQLite and SpatialLite behave the same and the function is
 available in SQLite.
 - The SQLite version of `ROUND()` does not support negative precision
 values.

 Anyway, here is a [https://github.com/django/django/pull/14182 PR].

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

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

Re: [Django] #32592: Add places argument to Round database function.

[Django]

#32592: Add places argument to Round database function.
-+-
 Reporter:  Nick Pope|Owner:  Nick Pope
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  database function,   | Triage Stage:
  round, decimal places  |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Nick Pope):

 Sorry for the duplicate, my search in Trac came up with nothing.

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

Re: [Django] #18597: `BaseInlineFormSet` should attempt to get it's queryset from it's instance related manager before falling back to it's model's default manager

[Django]

#18597: `BaseInlineFormSet` should attempt to get it's queryset from it's 
instance
related manager before falling back to it's model's default manager
--+
 Reporter:  Simon Charette|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Forms |  Version:  3.2
 Severity:  Normal|   Resolution:
 Keywords:  model formset inline  | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  1 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Andreas Galazis):

 * 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/067.b94125e79483c0d0721d119dbef589bd%40djangoproject.com.

Re: [Django] #18597: `BaseInlineFormSet` should attempt to get it's queryset from it's instance related manager before falling back to it's model's default manager

[Django]

#18597: `BaseInlineFormSet` should attempt to get it's queryset from it's 
instance
related manager before falling back to it's model's default manager
--+
 Reporter:  Simon Charette|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Forms |  Version:  3.2
 Severity:  Normal|   Resolution:
 Keywords:  model formset inline  | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  1 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Andreas Galazis):

 * version:  1.4 => 3.2
 * type:  Bug => Cleanup/optimization


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

Re: [Django] #18597: `BaseInlineFormSet` should attempt to get it's queryset from it's instance related manager before falling back to it's model's default manager

[Django]

#18597: `BaseInlineFormSet` should attempt to get it's queryset from it's 
instance
related manager before falling back to it's model's default manager
--+
 Reporter:  Simon Charette|Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Forms |  Version:  1.4
 Severity:  Normal|   Resolution:
 Keywords:  model formset inline  | Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  1 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Andreas Galazis):

 This would help support prefetching configuration on parent admin's
 queryset.
 This is not sufficient to support prefetching since there are multiple (I
 have found at least 3) instances in inline admin and inline formset where
 `self.get_queryset()[i]` paradigm is used.

 At least perform some code cleanup?

 Even if this issue a won't fix for any reason at least abstract fetching
 instance by in index in a `ge_instance_by_index` method so that we can
 implement admins that do what we want of top of current base classes. If
 this is done then we will be able to overwrite ge_instance_by_index to
 return `list(self.get_queryset())[i]`   instead of
 `self.get_queryset()[i]` on inlines that support prefetching

 Also I believe that the logic about preparing queryset in
 BaseInlineFormSet should exist in a separate function called
 `prepare_queryset`:


 {{{
 def prepare_queryset(queryset):
 if queryset is None:
 queryset = self.model._default_manager
 if self.instance.pk is not None:
 qs = queryset.filter(**{self.fk.name: self.instance})
 else:
 qs = queryset.none()
 return qs
 }}}
 instead if throwing it `__init__`. Init could just call the above to get
 the value . This way filtering wouldn't be enforced in the case of related
 manager querysets since we could overwrite the method.

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

Re: [Django] #32587: Use RelatedManager of parent object in get_queryset of inlines and support prefetching

[Django]

#32587: Use RelatedManager of parent object in get_queryset of inlines and 
support
prefetching
-+-
 Reporter:  Andreas Galazis  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  contrib.admin|  Version:  3.2
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  admin, prefetch, | Triage Stage:
  inline |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Andreas Galazis):

 Yes but that issue  doesn't mention other areas that need refactoring.
 Either way I will move my concerns to that issue...

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

Re: [Django] #32532: Provide friendlier error if a file path is passed as a test label when running tests

[Django]

#32532: Provide friendlier error if a file path is passed as a test label when
running tests
-+-
 Reporter:  Chris Jerdonek   |Owner:  Chris
 Type:   |  Jerdonek
  Cleanup/optimization   |   Status:  assigned
Component:  Testing framework|  Version:  3.1
 Severity:  Normal   |   Resolution:
 Keywords:  DiscoverRunner,test  | Triage Stage:  Accepted
  labels |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Chris Jerdonek):

 * has_patch:  0 => 1


Comment:

 PR: https://github.com/django/django/pull/14180

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

Re: [Django] #32578: Handle request.get_host() raising DisallowedHost in CsrfViewMiddleware._origin_verified()

[Django]

#32578: Handle request.get_host() raising DisallowedHost in
CsrfViewMiddleware._origin_verified()
-+-
 Reporter:  Chris Jerdonek   |Owner:  Chris
 |  Jerdonek
 Type:  Bug  |   Status:  assigned
Component:  CSRF |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
  CsrfViewMiddleware,DisallowedHost  |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Chris Jerdonek):

 * has_patch:  0 => 1


Comment:

 PR: https://github.com/django/django/pull/14179

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

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

[Django]

#32316: Access __file__ lazily rather than at module level
-+-
 Reporter:  William Schwartz |Owner:  William
 Type:   |  Schwartz
  Cleanup/optimization   |   Status:  assigned
Component:  Core (Other) |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  freezers | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * needs_better_patch:  0 => 1


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

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

Re: [Django] #32591: Change DiscoverRunner always to run _FailedTest "tests" first

[Django]

#32591: Change DiscoverRunner always to run _FailedTest "tests" first
-+-
 Reporter:  Chris Jerdonek   |Owner:  Chris
 Type:   |  Jerdonek
  Cleanup/optimization   |   Status:  assigned
Component:  Testing framework|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
  DiscoverRunner,_FailedTest |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Chris Jerdonek):

 * owner:  nobody => Chris Jerdonek
 * status:  new => assigned


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

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

Re: [Django] #32591: Change DiscoverRunner always to run _FailedTest "tests" first

[Django]

#32591: Change DiscoverRunner always to run _FailedTest "tests" first
-+-
 Reporter:  Chris Jerdonek   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Testing framework|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
  DiscoverRunner,_FailedTest |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * stage:  Unreviewed => Accepted


Comment:

 Hey Chris — I'm happy to accept this.

 With pytest I find the `-x --lf` combo to be quite effective. (That's not
 quite what you're proposing here I think, since `--lf` will select only
 the tests that previously failed — but "Carry on if all those passed" is
 probably better behaviour...)

 I don't know if folks will have ''thoughts'' on the exact behaviour
 they're  after, but I suspect we'll find out in review 

 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/067.6078e2f74e7d5973645eb8adc0e6462b%40djangoproject.com.

Re: [Django] #32579: Two outdated code comments in CsrfViewMiddleware.process_view()

[Django]

#32579: Two outdated code comments in CsrfViewMiddleware.process_view()
-+-
 Reporter:  Chris Jerdonek   |Owner:  Chris
 Type:   |  Jerdonek
  Cleanup/optimization   |   Status:  closed
Component:  CSRF |  Version:  dev
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  CsrfViewMiddleware   | 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


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

Re: [Django] #32579: Two outdated code comments in CsrfViewMiddleware.process_view()

[Django]

#32579: Two outdated code comments in CsrfViewMiddleware.process_view()
-+-
 Reporter:  Chris Jerdonek   |Owner:  Chris
 Type:   |  Jerdonek
  Cleanup/optimization   |   Status:  assigned
Component:  CSRF |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  CsrfViewMiddleware   | 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 Mariusz Felisiak ):

 In [changeset:"f3825248a2327b47798b358c96cfb183dcb49418" f382524]:
 {{{
 #!CommitTicketReference repository=""
 revision="f3825248a2327b47798b358c96cfb183dcb49418"
 Refs #32579 -- Fixed cookie domain comment in
 CsrfViewMiddleware.process_view().
 }}}

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

Re: [Django] #32579: Two outdated code comments in CsrfViewMiddleware.process_view()

[Django]

#32579: Two outdated code comments in CsrfViewMiddleware.process_view()
-+-
 Reporter:  Chris Jerdonek   |Owner:  Chris
 Type:   |  Jerdonek
  Cleanup/optimization   |   Status:  assigned
Component:  CSRF |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  CsrfViewMiddleware   | 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 Mariusz Felisiak ):

 In [changeset:"70332e6c431dc5988230dd3d91d3d8108b9aa0f0" 70332e6c]:
 {{{
 #!CommitTicketReference repository=""
 revision="70332e6c431dc5988230dd3d91d3d8108b9aa0f0"
 Refs #32579 -- Optimized good_hosts creation in
 CsrfViewMiddleware.process_view().
 }}}

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

Re: [Django] #32587: Use RelatedManager of parent object in get_queryset of inlines and support prefetching

[Django]

#32587: Use RelatedManager of parent object in get_queryset of inlines and 
support
prefetching
-+-
 Reporter:  Andreas Galazis  |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  contrib.admin|  Version:  3.2
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  admin, prefetch, | Triage Stage:
  inline |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

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


Comment:

 The non-reuse of prefetched relationship for inlines is tracked in #18597.

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

Re: [Django] #14845: Document connection-creation process

[Django]

#14845: Document connection-creation process
---+
 Reporter:  Christophe Pettus  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Documentation  |  Version:  dev
 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 Carlton Gibson):

 #32589 was a duplicate ref documenting the need for calling
 close_old_connections in long-running management commands.

 Ostensibly this ticket here is about connection creation, but (a decade
 later) a general overview of the connection life-cycle would be a nice
 improvement.

-- 
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/061.27cdda2cb9404d25adcf5e968d006175%40djangoproject.com.

Re: [Django] #32589: Document the need for calling close_old_connections in long-running management commands.

[Django]

#32589: Document the need for calling close_old_connections in long-running
management commands.
---+--
 Reporter:  GwynBleidD |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Documentation  |  Version:  3.1
 Severity:  Normal |   Resolution:  duplicate
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Carlton Gibson):

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


Comment:

 I'm inclined to think this should be part of #14845, connections
 management in general being a little under-documented.

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

Re: [Django] #32076: Adding async methods to BaseCache

[Django]

#32076: Adding async methods to BaseCache
-+-
 Reporter:  Andrew Chen Wang |Owner:  Andrew
 |  Chen Wang
 Type:  New feature  |   Status:  assigned
Component:  Core (Cache system)  |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  cache| Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * needs_better_patch:  0 => 1
 * needs_docs:  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/074.94c9dd88c8dc5011b92c6f8531c1bdc3%40djangoproject.com.

Re: [Django] #32593: Cast() to DecimalField() raises DataError. (was: Functional Index Based on Newly Created Field, invalid input syntax for type integer: "none")

[Django]

#32593: Cast() to DecimalField() raises DataError.
-+--
 Reporter:  mureytasroc  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  3.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
-+--

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

Re: [Django] #32593: Functional Index Based on Newly Created Field, invalid input syntax for type integer: "none"

[Django]

#32593: Functional Index Based on Newly Created Field, invalid input syntax for
type integer: "none"
-+--
 Reporter:  mureytasroc  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Migrations   |  Version:  3.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
-+--
Changes (by Mariusz Felisiak):

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


Comment:

 You cannot `Cast()` to `DecimalField`, or use it in `output_field`,
 without providing `decimal_places` and `max_digits` arguments, e.g.
 `DecimalField(decimal_places=2, max_digits=10)` works for me. Also, as far
 as I'm aware there is no need to use `Cast()` in your case:
 {{{
 ...
 then=F("registration_volume") / F("capacity"),
 ...
 }}}

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

[Django] #32593: Functional Index Based on Newly Created Field, invalid input syntax for type integer: "none"

[Django]

#32593: Functional Index Based on Newly Created Field, invalid input syntax for
type integer: "none"
---+
   Reporter:  mureytasroc  |  Owner:  nobody
   Type:  Bug  | Status:  new
  Component:  Migrations   |Version:  3.2
   Severity:  Normal   |   Keywords:
   Triage Stage:  Unreviewed   |  Has patch:  0
Needs documentation:  0|Needs tests:  0
Patch needs improvement:  0|  Easy pickings:  0
  UI/UX:  0|
---+
 I'm trying to create a functional index based on a newly created field,
 but keep getting the following error when migrations are run (using
 postgres):

 {{{
 psycopg2.errors.InvalidTextRepresentation: invalid input syntax for type
 integer: "none"
 }}}


 The relevant code (creating a new field "registration_volume" and a
 functional index "raw_demand" which should equal
 registration_volume/capacity if [capacity is not null and capacity>0],
 capacity being another field of the model), in a model called "Section":

 {{{
 registration_volume = models.PositiveIntegerField(
 default=0, help_text="The number of active PCA registrations
 watching this section."
 )
 class Meta:
 indexes = [
 Index(
 Case(
 When(
 Q(capacity__isnull=False) & Q(capacity__gt=0),
 then=(
 Cast("registration_volume",
 models.DecimalField())
 / Cast("capacity", models.DecimalField())
 ),
 ),
 default=None,
 output_field=models.DecimalField(null=True,
 blank=True),
 ),
 name="raw_demand",
 ),
 ]
 }}}


 The auto-generated migration:

 {{{
 class Migration(migrations.Migration):

 dependencies = [
 ("courses", "0031_userprofile_push_notifications"),
 ]

 operations = [
 migrations.AddField(
 model_name="section",
 name="registration_volume",
 field=models.PositiveIntegerField(
 default=0, help_text="The number of active PCA
 registrations watching this section."
 ),
 ),
 migrations.AddIndex(
 model_name="section",
 index=models.Index(
 django.db.models.expressions.Case(
 django.db.models.expressions.When(
 models.Q(("capacity__isnull", False),
 ("capacity__gt", 0)),
 then=django.db.models.expressions.CombinedExpression(
 django.db.models.functions.comparison.Cast(
 "registration_volume",
 models.DecimalField()
 ),
 "/",
 django.db.models.functions.comparison.Cast(
 "capacity", models.DecimalField()
 ),
 ),
 ),
 default=None,
 output_field=models.DecimalField(blank=True,
 null=True),
 ),
 name="raw_demand",
 ),
 ),
 ]
 }}}


 It seems to have an issue with this part of the AddIndex migration inside
 models.Index(...):

 {{{
 django.db.models.functions.comparison.Cast(
 "registration_volume", models.DecimalField()
 )
 }}}

 The full traceback:

 {{{
 Run cd backend
 cd backend
 pipenv run coverage run --concurrency=multiprocessing manage.py test
 --settings=PennCourses.settings.ci --parallel
 pipenv run coverage combine
 shell: sh -e {0}
 env: DATABASE_URL: ***postgres:5432/postgres
 }}}



 {{{
 Creating test database for alias 'default'...
 Traceback (most recent call last):
   File "/github/home/.local/share/virtualenvs/backend-
 6EUeMQ8O/lib/python3.8/site-packages/django/db/backends/utils.py", line
 82, in _execute
 return self.cursor.execute(sql)
 psycopg2.errors.InvalidTextRepresentation: invalid input syntax for type
 integer: "none"
 LINE 1: ...apacity" > 0) THEN (CAST("registration_volume" AS numeric(No...
  ^


 The above exception was the direct cause of the following exception:

 Traceback (most recent call last):
   File "manage.py", line 21, in 
 main()
   File "manage.py", line 17, in main
 execute_from_command_line(sys.argv)
   File "/github/home/.local/share/virtualenvs/backend-
 6EUeMQ8O/lib/python3.8/site-packages/django/core/management/__init__.py",
 line 419, in execute_from_command_line
 utility.execute()
   File "/github/home/.local/share/virtualenvs/backend-