Re: [Django] #32165: Add pre-commit Hooks

2020-11-02 Thread Django 
#32165: Add pre-commit Hooks
---+--
 Reporter:  David Smith|Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  Uncategorized  |  Version:  master
 Severity:  Normal |   Resolution:  needsinfo
 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:   => needsinfo


Comment:

 Hi David. I'd be inclined to accept this — I think pre-commit is great —
 but I think we need to go via the DevelopersMailingList first to gather
 consensus.

 Ref [https://github.com/django/deps/blob/master/accepted/0008-black.rst
 DEP 8] this would be handy to have in place.

 Can I get you to post to the list? Some thoughts...

 * Things we could set up now: the whitespace rule, flake8, isort.
 * Add black when DEP 8 is implemented.
 * What's the setup? Add to docs where?
 * ...

 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/066.4a572ed437e41bece16165a4d1460fb4%40djangoproject.com.

Re: [Django] #32162: AsyncTestClient crashes on requests with JSON data.

2020-11-02 Thread Django 
#32162: AsyncTestClient crashes on requests with JSON data.
-+-
 Reporter:  Tom Miller   |Owner:  patrick
 Type:  Bug  |   Status:  assigned
Component:  Testing framework|  Version:  3.1
 Severity:  Release blocker  |   Resolution:
 Keywords:  AsyncTestClient, | Triage Stage:  Ready for
  AsyncRequestFactory|  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * stage:  Accepted => Ready for checkin


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

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

Re: [Django] #32166: Remove redundant Greatest class in test_expression_on_aggregation

2020-11-02 Thread Django 
#32166: Remove redundant Greatest class in test_expression_on_aggregation
-+-
 Reporter:  Sicong   |Owner:  Sicong
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Core (Other) |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by GitHub ):

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


Comment:

 In [changeset:"09e1ec71dfd1e43ae422f5f9bf4525936832e0ce" 09e1ec7]:
 {{{
 #!CommitTicketReference repository=""
 revision="09e1ec71dfd1e43ae422f5f9bf4525936832e0ce"
 Fixed #32166 -- Removed redundant definition of Greatest in
 test_expression_on_aggregation.
 }}}

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

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

Re: [Django] #32166: Remove redundant Greatest class in test_expression_on_aggregation (was: test_expression_on_aggregation has an additional "class Greatest" definition)

2020-11-02 Thread Django 
#32166: Remove redundant Greatest class in test_expression_on_aggregation
-+-
 Reporter:  Sicong   |Owner:  Sicong
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Core (Other) |  Version:  master
 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 Tim Graham):

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


Comment:

 [https://github.com/django/django/pull/13634 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/063.b44ae0b7ac49213b76e0ca0b5e7142a2%40djangoproject.com.

Re: [Django] #32166: test_expression_on_aggregation has an additional "class Greatest" definition

2020-11-02 Thread Django 
#32166: test_expression_on_aggregation has an additional "class Greatest"
definition
--+
 Reporter:  Sicong|Owner:  Sicong
 Type:  Cleanup/optimization  |   Status:  assigned
Component:  Core (Other)  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Mariusz Felisiak):

 * component:  Testing framework => Core (Other)
 * stage:  Unreviewed => Accepted


Comment:

 Thanks. Please send PR via GitHub.

 Ticket is not required for such a small cleanups, by the way.

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

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

Re: [Django] #32166: test_expression_on_aggregation has an additional "class Greatest" definition

2020-11-02 Thread Django 
#32166: test_expression_on_aggregation has an additional "class Greatest"
definition
-+-
 Reporter:  Sicong   |Owner:  Sicong
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Sicong):

 * owner:  nobody => Sicong
 * status:  new => assigned


Comment:

 I have a patch ready.

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

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

[Django] #32166: test_expression_on_aggregation has an additional "class Greatest" definition

2020-11-02 Thread Django 
#32166: test_expression_on_aggregation has an additional "class Greatest"
definition
+
   Reporter:  Sicong|  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Testing framework |Version:  master
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 Function greatest now supported in **db.models.functions.comparison**,
 propose to remove `class Greatest` in the unit test.

 Refer to comment on
 
Github:[https://github.com/django/django/commit/f59fd15c4928caf3dfcbd50f6ab47be409a43b01
 #diff-
 7406fc41610281c9ff732230a859d1eb1406875841d9a5a81ab4c7090b37b6d0R920]

-- 
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/048.f64dc9dd0c81782330eb4a8a7dfa9e72%40djangoproject.com.

Re: [Django] #32132: ManyToManyField does not respect the PositiveBigIntegerField in m2m intermediate table.

2020-11-02 Thread Django 
#32132: ManyToManyField does not respect the PositiveBigIntegerField in m2m
intermediate table.
-+-
 Reporter:  Kfir Breger  |Owner:  David
 |  Wobrock
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  models, orm  | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"cfc7cd6513a72b8c5898c264d04bdf49f897a1de" cfc7cd65]:
 {{{
 #!CommitTicketReference repository=""
 revision="cfc7cd6513a72b8c5898c264d04bdf49f897a1de"
 Fixed #32132 -- Fixed column types in m2m intermediary tables for
 Positive(Big/Small)IntegerFields.
 }}}

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

Re: [Django] #32132: ManyToManyField does not respect the PositiveBigIntegerField in m2m intermediate table.

2020-11-02 Thread Django 
#32132: ManyToManyField does not respect the PositiveBigIntegerField in m2m
intermediate table.
-+-
 Reporter:  Kfir Breger  |Owner:  David
 |  Wobrock
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  models, orm  | 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:"4ebd633350ac07091a23c0f0c3eac3aa691cab05" 4ebd633]:
 {{{
 #!CommitTicketReference repository=""
 revision="4ebd633350ac07091a23c0f0c3eac3aa691cab05"
 Refs #32132 -- Added rel_db_type() tests for auto and integer fields.
 }}}

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

[Django] #32165: Add pre-commit Hooks

2020-11-02 Thread Django 
#32165: Add pre-commit Hooks
-+
   Reporter:  David Smith|  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Uncategorized  |Version:  master
   Severity:  Normal |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 To add support for pre-commit hooks via [https://pre-commit.com/ pre-
 commit]. Specifically, I propose to add the flake8 and isort hooks, with
 appropriate guidance added to the contributing docs.

 The aim is to reduce the number of PRs opened where a 'simple' lint error
 needs to be fixed, and in doing so we end up running the whole test suite
 at Jenkins twice. I appreciate this won't stop all instances as folk will
 have an extra step to install them; however, I think even if it stops the
 occasional occurrence the addition will be worthwhile.

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

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

2020-11-02 Thread Django 
#29712: Add warning in makemessages command if the localecode with `l` flag is 
not
correct
-+-
 Reporter:  Sanyam Khurana   |Owner:  Manav
 Type:   |  Agarwal
  Cleanup/optimization   |   Status:  assigned
Component:   |  Version:  master
  Internationalization   |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  0
-+-
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/072.7b4fd651aa191d0d1f0c4b669c3dfbbf%40djangoproject.com.

Re: [Django] #32162: AsyncTestClient crashes on requests with JSON data. (was: Invalid 'Content-Length' header, and printing request body raises exception in POST requests using AsyncTestClient)

2020-11-02 Thread Django 
#32162: AsyncTestClient crashes on requests with JSON data.
-+-
 Reporter:  Tom Miller   |Owner:  patrick
 Type:  Bug  |   Status:  assigned
Component:  Testing framework|  Version:  3.1
 Severity:  Release blocker  |   Resolution:
 Keywords:  AsyncTestClient, | Triage Stage:  Accepted
  AsyncRequestFactory|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * status:  new => assigned
 * severity:  Normal => Release blocker
 * cc: Andrew Godwin, Carlton Gibson (added)
 * owner:  nobody => patrick
 * has_patch:  0 => 1
 * stage:  Unreviewed => Accepted


Comment:

 Thanks for the report!

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

 #32164 was closes as a duplicate.

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

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

Re: [Django] #32164: Broken content_length header in AsyncTestClient when doing post requests with json data

2020-11-02 Thread Django 
#32164: Broken content_length header in AsyncTestClient when doing post requests
with json data
---+--
 Reporter:  patrick|Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  Testing framework  |  Version:  3.1
 Severity:  Normal |   Resolution:  duplicate
 Keywords:  aysnc  | 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
 * has_patch:  1 => 0
 * resolution:   => duplicate


Comment:

 Duplicate of #32162.

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

Re: [Django] #28821: Allow QuerySet.bulk_create() on multi-table inheritance when possible

2020-11-02 Thread Django 
#28821: Allow QuerySet.bulk_create() on multi-table inheritance when possible
-+-
 Reporter:  Joey Wilhelm |Owner:  (none)
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (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
-+-

Comment (by Daniel Alley):

 This would be an excellent feature and we would really love to be able to
 use it.

 I would like to be able to manually set the _ptr fields on the child
 records in order to affect a bulk_create without the need for automatic
 retrieval of IDs.

 In certain circumstances (think UUID PKs) it might also be possible, at
 least with Postgresql (don't know about the others), to do it the other
 way around.  Foreign key integrity checks are deferred to the end of the
 transaction, so you could save all of the child tables first, and then
 save all the parent tables.  As long as the entire operation is wrapped in
 a single transaction, it wouldn't matter that `_ptr` temporarily held an
 invalid FK.

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

Re: [Django] #32163: Admin change password is not handled gracefully (error 500)

2020-11-02 Thread Django 
#32163: Admin change password is not handled gracefully (error 500)
--+--
 Reporter:  Romain SOMMERARD  |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  contrib.admin |  Version:  3.1
 Severity:  Normal|   Resolution:  invalid
 Keywords:  admin, password   | 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:

 I cannot reproduce this issue with builtin validators, it looks that it's
 an issue in a custom password validator. Closing per
 TicketClosingReasons/UseSupportChannels.

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

Re: [Django] #32163: Admin change password is not handled gracefully (error 500)

2020-11-02 Thread Django 
#32163: Admin change password is not handled gracefully (error 500)
--+--
 Reporter:  Romain SOMMERARD  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  contrib.admin |  Version:  3.1
 Severity:  Normal|   Resolution:
 Keywords:  admin, password   | Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--

Comment (by slogan621):

 So, a quick google search indicates that the "*" is probably being
 interpreted as a regex wildcard. And two in a row is probably invalid,
 leading to the exception being raised.

 What happens if you escape the '*' characters, e.g.,  use querty123\*\*\*
 instead of querty*** ? I'm expecting that doing so would allow for the use
 of "*' in a password (or trigger some other filtering/error that might be
 in place that disallows use of "*").

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

Re: [Django] #32164: Broken content_length header in AsyncTestClient when doing post requests with json data

2020-11-02 Thread Django 
#32164: Broken content_length header in AsyncTestClient when doing post requests
with json data
---+--
 Reporter:  patrick|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Testing framework  |  Version:  3.1
 Severity:  Normal |   Resolution:
 Keywords:  aysnc  | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Description changed by patrick:

Old description:

> Hello there, this is my first formal bug report, so I hope I'm doing this
> correctly. Anyway I was working on a async view and adding a test for it
> but I got this error:
>

> {{{
> ERRORdjango.request:log.py:224 Internal Server Error: /graphql_async
> Traceback (most recent call last):
>   File "/Users/patrick/Documents/github/strawberry-
> graphql/strawberry/.venv/lib/python3.9/site-packages/asgiref/sync.py",
> line 339, in thread_handler
> raise exc_info[1]
>   File "/Users/patrick/Documents/github/strawberry-
> graphql/strawberry/.venv/lib/python3.9/site-
> packages/django/core/handlers/exception.py", line 38, in inner
> response = await get_response(request)
>   File "/Users/patrick/Documents/github/strawberry-
> graphql/strawberry/.venv/lib/python3.9/site-
> packages/django/core/handlers/base.py", line 231, in _get_response_async
> response = await wrapped_callback(request, *callback_args,
> **callback_kwargs)
>   File "/Users/patrick/Documents/github/strawberry-
> graphql/strawberry/strawberry/django/views.py", line 145, in dispatch
> operation_context = self.get_execution_context(request)
>   File "/Users/patrick/Documents/github/strawberry-
> graphql/strawberry/strawberry/django/views.py", line 51, in
> get_execution_context
> data = self.parse_body(request)
>   File "/Users/patrick/Documents/github/strawberry-
> graphql/strawberry/strawberry/django/views.py", line 42, in parse_body
> return json.loads(request.body)
>   File "/Users/patrick/Documents/github/strawberry-
> graphql/strawberry/.venv/lib/python3.9/site-
> packages/django/http/request.py", line 320, in body
> int(self.META.get('CONTENT_LENGTH') or 0) >
> settings.DATA_UPLOAD_MAX_MEMORY_SIZE):
> ValueError: invalid literal for int() with base 10:
> '\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
> }}}
>
> after digging a bit it looks like we set the content_length to
> `bytes(len(data))`, which seems to be wrong, since it produces this
> string:
>
> {{{
> '\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
> }}}
>
> Code is here:
> https://github.com/django/django/blob/d1791539a7d86739cd44c909fa8239cae7f85874/django/test/client.py#L543
>
> Also I did a patch for this which seems to work:
> https://github.com/django/django/pull/13632

New description:

 Hello there, this is my first formal bug report, so I hope I'm doing this
 correctly. Anyway I was working on a async view and adding a test for it
 but I got this error:


 {{{
 ERRORdjango.request:log.py:224 Internal Server Error: /graphql_async
 Traceback (most recent call last):
   File "/Users/patrick/Documents/github/strawberry-
 graphql/strawberry/.venv/lib/python3.9/site-packages/asgiref/sync.py",
 line 339, in thread_handler
 raise exc_info[1]
   File "/Users/patrick/Documents/github/strawberry-
 graphql/strawberry/.venv/lib/python3.9/site-
 packages/django/core/handlers/exception.py", line 38, in inner
 response = await get_response(request)
   File "/Users/patrick/Documents/github/strawberry-
 graphql/strawberry/.venv/lib/python3.9/site-
 packages/django/core/handlers/base.py", line 231, in _get_response_async
 response = await wrapped_callback(request, *callback_args,
 **callback_kwargs)
   File "/Users/patrick/Documents/github/strawberry-
 graphql/strawberry/strawberry/django/views.py", line 145, in dispatch
 operation_context = self.get_execution_context(request)
   File "/Users/patrick/Documents/github/strawberry-
 graphql/strawberry/strawberry/django/views.py", line 51, in
 get_execution_context
 data = self.parse_body(request)
   File "/Users/patrick/Documents/github/strawberry-
 graphql/strawberry/strawberry/django/views.py", line 42, in parse_body
 return json.loads(request.body)
   File "/Users/patrick/Documents/github/strawberry-
 graphql/strawberry/.venv/lib/python3.9/site-
 packages/django/http/request.py", line 320, in body
 int(self.META.get('CONTENT_LENGTH') or 0) >
 settings.DATA_UPLOAD_MAX_MEMORY_SIZE):
 ValueError: invalid literal for

[Django] #32164: Broken content_length header in AsyncTestClient when doing post requests with json data

2020-11-02 Thread Django 
#32164: Broken content_length header in AsyncTestClient when doing post requests
with json data
-+
   Reporter:  patrick|  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Testing framework  |Version:  3.1
   Severity:  Normal |   Keywords:  aysnc
   Triage Stage:  Unreviewed |  Has patch:  1
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 Hello there, this is my first formal bug report, so I hope I'm doing this
 correctly. Anyway I was working on a async view and adding a test for it
 but I got this error:


 {{{
 ERRORdjango.request:log.py:224 Internal Server Error: /graphql_async
 Traceback (most recent call last):
   File "/Users/patrick/Documents/github/strawberry-
 graphql/strawberry/.venv/lib/python3.9/site-packages/asgiref/sync.py",
 line 339, in thread_handler
 raise exc_info[1]
   File "/Users/patrick/Documents/github/strawberry-
 graphql/strawberry/.venv/lib/python3.9/site-
 packages/django/core/handlers/exception.py", line 38, in inner
 response = await get_response(request)
   File "/Users/patrick/Documents/github/strawberry-
 graphql/strawberry/.venv/lib/python3.9/site-
 packages/django/core/handlers/base.py", line 231, in _get_response_async
 response = await wrapped_callback(request, *callback_args,
 **callback_kwargs)
   File "/Users/patrick/Documents/github/strawberry-
 graphql/strawberry/strawberry/django/views.py", line 145, in dispatch
 operation_context = self.get_execution_context(request)
   File "/Users/patrick/Documents/github/strawberry-
 graphql/strawberry/strawberry/django/views.py", line 51, in
 get_execution_context
 data = self.parse_body(request)
   File "/Users/patrick/Documents/github/strawberry-
 graphql/strawberry/strawberry/django/views.py", line 42, in parse_body
 return json.loads(request.body)
   File "/Users/patrick/Documents/github/strawberry-
 graphql/strawberry/.venv/lib/python3.9/site-
 packages/django/http/request.py", line 320, in body
 int(self.META.get('CONTENT_LENGTH') or 0) >
 settings.DATA_UPLOAD_MAX_MEMORY_SIZE):
 ValueError: invalid literal for int() with base 10:
 
'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
 }}}

 after digging a bit it looks like we set the content_length to
 `bytes(len(data))`, which seems to be wrong, since it produces this
 string:

 {{{
 
'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
 }}}

 Code is here:
 
https://github.com/django/django/blob/d1791539a7d86739cd44c909fa8239cae7f85874/django/test/client.py#L543

 Also I did a patch for this which seems to work:
 https://github.com/django/django/pull/13632

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

[Django] #32163: Admin change password is not handled gracefully (error 500)

2020-11-02 Thread Django 
#32163: Admin change password is not handled gracefully (error 500)
-+-
   Reporter:  rsommerard |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  contrib.admin  |Version:  3.1
   Severity:  Normal |   Keywords:  admin, password
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Change the password via the admin form for a user and enter a password
 like `qwerty123**`, the server return a not handled gracefully error 500.
 With DEBUG=True, we can have more details:

 error at /admin/users/user/27/password/

 multiple repeat at position 10

 Request Method: POST
 Request URL:http://localhost:8000/admin/users/user/27/password/
 Django Version: 3.0.7
 Exception Type: error
 Exception Value:

 multiple repeat at position 10

 Exception Location: /usr/lib/python3.8/sre_parse.py in _parse, line
 671
 Python Executable:  /home/dave/.virtualenvs/my-project/bin/python
 Python Version: 3.8.5
 Python Path:

 ['/home/dave/my-project',
  '/home/dave/my-project/django',
  '/usr/lib/python38.zip',
  '/usr/lib/python3.8',
  '/usr/lib/python3.8/lib-dynload',
  '/home/dave/.virtualenvs/my-project/lib/python3.8/site-packages']

 Server time:Mon, 2 Nov 2020 17:35:25 +0100

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

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

Re: [Django] #27451: syndication feed may crash with AmbiguousTimeError

2020-11-02 Thread Django 
#27451: syndication feed may crash with AmbiguousTimeError
-+
 Reporter:  Markus Holtermann|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.syndication  |  Version:  1.10
 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 Claude Paroz):

 Replying to [comment:2 Tobias McNulty]:
 > I am not sure about a fix, but we did see another one of these over the
 weekend during the time change:
 https://sentry.io/share/issue/ea6b31e26e164a03903f499ca7f87b29/

 It looks like this one could be fixed by making item_pubdate an aware
 datetime in the first place.

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

Re: [Django] #32162: Invalid 'Content-Length' header, and printing request body raises exception in POST requests using AsyncTestClient

2020-11-02 Thread Django 
#32162: Invalid 'Content-Length' header, and printing request body raises 
exception
in POST requests using AsyncTestClient
-+-
 Reporter:  tmiller02|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Testing framework|  Version:  3.1
 Severity:  Normal   |   Resolution:
 Keywords:  AsyncTestClient, | Triage Stage:
  AsyncRequestFactory|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by tmiller02):

 * component:  Uncategorized => Testing framework


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

[Django] #32162: Invalid 'Content-Length' header, and printing request body raises exception in POST requests using AsyncTestClient

2020-11-02 Thread Django 
#32162: Invalid 'Content-Length' header, and printing request body raises 
exception
in POST requests using AsyncTestClient
-+-
   Reporter:  tmiller02  |  Owner:  nobody
   Type:  Bug| Status:  new
  Component: |Version:  3.1
  Uncategorized  |   Keywords:  AsyncTestClient,
   Severity:  Normal |  AsyncRequestFactory
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 POST requests that are created using the AsyncTestClient do not seem to
 have a valid 'Content-Length' header. In addition, attempting to print the
 body of a POST request raises an exception (seemingly related to the
 invalid 'Content-Length').

 These issues can be demonstrated using AsyncRequestFactory:

 {{{
 >>> from django.test import AsyncRequestFactory
 >>> rf = AsyncRequestFactory()
 >>> post_request = rf.post('/submit/', {'foo': 'bar'})
 >>> print(post_request.headers)
 {'Host': 'testserver', 'Content-Length':
 
'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00',
 'Content-Type': 'multipart/form-data; boundary=BoUnDaRyStRiNg', 'Cookie':
 ''}
 >>> print(post_request.body)
 ValueErrorTraceback (most recent call
 last)
 /opt/my_project/venv/lib64/python3.6/site-packages/django/http/request.py
 in body(self)
 318 # Limit the maximum request data size that will be
 handled in-memory.
 319 if (settings.DATA_UPLOAD_MAX_MEMORY_SIZE is not None
 and
 --> 320 int(self.META.get('CONTENT_LENGTH') or 0) >
 settings.DATA_UPLOAD_MAX_MEMORY_SIZE):
 321 raise RequestDataTooBig('Request body exceeded
 settings.DATA_UPLOAD_MAX_MEMORY_SIZE.')
 322
 ValueError: invalid literal for int() with base 10:
 
'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0
 }}}

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

Re: [Django] #32156: Add __class_getitem__ to support runtime type parameters for more classes

2020-11-02 Thread Django 
#32156: Add __class_getitem__ to support runtime type parameters for more 
classes
-+-
 Reporter:  Brady Kieffer|Owner:  Brady
 |  Kieffer
 Type:  New feature  |   Status:  assigned
Component:  Utilities|  Version:  2.2
 Severity:  Normal   |   Resolution:
 Keywords:  types, mypy, | Triage Stage:
  django-stubs   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Brady Kieffer):

 Hi Carlton,

 Thanks for the speedy response. I guess I just want to preface everything
 here by saying I pretty squarely fall into the bucket of being a user of
 both `Django` + `django-stubs`. I definitely agree that the code is a bit
 boilerplate-y. I don't actually think this is a mypy issue, it's more
 about how we choose to reconcile the true implementation of Django with
 third party libraries attempting to type it in a simple manner. So, when
 it comes to:

 {{{
 @classmethod
 def __class_getitem__(cls, *args, **kwargs):
 return cls
 }}}

 I tend to agree that it's pretty annoying that we have to modify Django to
 make it usable with `django-stubs`. In defense of `mypy` and typing in
 general, there's a more idiomatic approach to this problem by defining a
 class as a `Generic` ([https://mypy.readthedocs.io/en/stable/generics.html
 #defining-generic-classes docs for Generics here]). I _believe_ the reason
 that adding `Generic` as a base for `QuerySet` + `Manager` was avoided
 because it could have an impact downstream but, I don't really know why
 this was decided. So, `mypy` would recommend we use `Generic`, which we
 likely will not, and it sort of leaves open the question of what should we
 reasonably expect to do with Django **if** we want to support third party
 typing libraries. I'm not super opinionated, but I would definitely rather
 not have to monkeypatch every codebase that uses django-stubs if it can be
 avoided. If we do go down this path though, I would agree that your second
 point will likely never be satisfied.

 Type checking is really cool, and it's saved us from some very weird bugs.
 But, it definitely feels like we're in a weird middle ground where there
 isn't "the one perfect way" of doing it.

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

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

Re: [Django] #27451: syndication feed may crash with AmbiguousTimeError

2020-11-02 Thread Django 
#27451: syndication feed may crash with AmbiguousTimeError
-+
 Reporter:  Markus Holtermann|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.syndication  |  Version:  1.10
 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 Tobias McNulty):

 I am not sure about a fix, but we did see another one of these over the
 weekend during the time change:
 https://sentry.io/share/issue/ea6b31e26e164a03903f499ca7f87b29/

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

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

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

Comment (by Bob Whitelock):

 > The reason this happens is that custom result classes aren't used in the
 parallel processes, but instead RemoteTestResult, which mostly holds onto
 the result to send it back to the main process for display. In theory it's
 possible to change how that works, and might even allow the --debug-sql
 and --pdb options work with --parallel, but it might require a little
 thought.

 Thanks for the explanation, and that's interesting - the custom startTest
 method does appear to be called however, just after the test has actually
 started, so it does look like the custom result class is being used.
 Unless I'm misunderstanding what you mean?

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

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

Re: [Django] #32159: AsyncTestClient does not respect extra headers. (was: AsyncTestClient does not allow setting request headers as documented for TestClient via HTTP_* kwargs)

2020-11-02 Thread Django 
#32159: AsyncTestClient does not respect extra headers.
-+-
 Reporter:  Ryan Vinzent |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Testing framework|  Version:  3.1
 Severity:  Release blocker  |   Resolution:
 Keywords:  AsyncTestClient, | Triage Stage:  Accepted
  AsyncRequestFactory|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * cc: Andrew Godwin, Carlton Gibson (added)
 * severity:  Normal => Release blocker
 * stage:  Unreviewed => Accepted


Comment:

 Thanks for this report. It looks that we should update the
 [https://asgi.readthedocs.io/en/latest/specs/www.html#http-connection-
 scope scope headers] not the main scope with `extra`, see
 
[https://github.com/django/django/blob/d1791539a7d86739cd44c909fa8239cae7f85874/django/test/client.py#L534-L547
 AsyncRequestFactory.generic()]. Andrew, Can you confirm?

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

Re: [Django] #31335: [mysql] Renaming a foreign key field that's also included in an index fails with "Cannot drop index 'foo_idx': needed in a foreign key constraint"

2020-11-02 Thread Django 
#31335: [mysql] Renaming a foreign key field that's also included in an index 
fails
with "Cannot drop index 'foo_idx': needed in a foreign key constraint"
-+-
 Reporter:  Stephen Finucane |Owner:  Sanskar
 |  Jaiswal
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  3.0
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * needs_tests:  0 => 1


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

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

Re: [Django] #31850: test_extraction_warning (i18n.test_extraction.BasicExtractorTests) fails with xgettext 0.21.

2020-11-02 Thread Django 
#31850: test_extraction_warning (i18n.test_extraction.BasicExtractorTests) fails
with xgettext 0.21.
-+-
 Reporter:  Michał Górny |Owner:  Max
 Type:   |  Smolens
  Cleanup/optimization   |   Status:  closed
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Michał Górny):

 That was fast. Thank you!

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

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

Re: [Django] #31850: test_extraction_warning (i18n.test_extraction.BasicExtractorTests) fails with xgettext 0.21.

2020-11-02 Thread Django 
#31850: test_extraction_warning (i18n.test_extraction.BasicExtractorTests) fails
with xgettext 0.21.
-+-
 Reporter:  Michał Górny |Owner:  Max
 Type:   |  Smolens
  Cleanup/optimization   |   Status:  closed
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Mariusz Felisiak):

 Replying to [comment:13 Michał Górny]:
 > Would it be possible to backport this into 2.2, 3.0 and 3.1 branches?

 Backported.

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

Re: [Django] #31850: test_extraction_warning (i18n.test_extraction.BasicExtractorTests) fails with xgettext 0.21.

2020-11-02 Thread Django 
#31850: test_extraction_warning (i18n.test_extraction.BasicExtractorTests) fails
with xgettext 0.21.
-+-
 Reporter:  Michał Górny |Owner:  Max
 Type:   |  Smolens
  Cleanup/optimization   |   Status:  closed
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"e893c0ad8b0b5b0a1e5be3345c287044868effc4" e893c0ad]:
 {{{
 #!CommitTicketReference repository=""
 revision="e893c0ad8b0b5b0a1e5be3345c287044868effc4"
 [2.2.x] Fixed #31850 -- Fixed BasicExtractorTests.test_extraction_warning
 with xgettext 0.21+.

 "format string with unnamed arguments cannot be properly localized"
 warning is not raised in xgettext 0.21+.

 This patch uses a message that causes an xgettext warning regardless of
 the version.

 Backport of 07a30f561661efae1691ff45d10ec6014b395b58 from master
 }}}

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

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

Re: [Django] #31850: test_extraction_warning (i18n.test_extraction.BasicExtractorTests) fails with xgettext 0.21.

2020-11-02 Thread Django 
#31850: test_extraction_warning (i18n.test_extraction.BasicExtractorTests) fails
with xgettext 0.21.
-+-
 Reporter:  Michał Górny |Owner:  Max
 Type:   |  Smolens
  Cleanup/optimization   |   Status:  closed
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"e707a1bd9a485319421414f2d171c3faca9cd58c" e707a1bd]:
 {{{
 #!CommitTicketReference repository=""
 revision="e707a1bd9a485319421414f2d171c3faca9cd58c"
 [3.1.x] Fixed #31850 -- Fixed BasicExtractorTests.test_extraction_warning
 with xgettext 0.21+.

 "format string with unnamed arguments cannot be properly localized"
 warning is not raised in xgettext 0.21+.

 This patch uses a message that causes an xgettext warning regardless of
 the version.

 Backport of 07a30f561661efae1691ff45d10ec6014b395b58 from master
 }}}

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

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

Re: [Django] #31850: test_extraction_warning (i18n.test_extraction.BasicExtractorTests) fails with xgettext 0.21.

2020-11-02 Thread Django 
#31850: test_extraction_warning (i18n.test_extraction.BasicExtractorTests) fails
with xgettext 0.21.
-+-
 Reporter:  Michał Górny |Owner:  Max
 Type:   |  Smolens
  Cleanup/optimization   |   Status:  closed
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"c506639b425ca876b2d9a633fc6410e917d45605" c506639b]:
 {{{
 #!CommitTicketReference repository=""
 revision="c506639b425ca876b2d9a633fc6410e917d45605"
 [3.0.x] Fixed #31850 -- Fixed BasicExtractorTests.test_extraction_warning
 with xgettext 0.21+.

 "format string with unnamed arguments cannot be properly localized"
 warning is not raised in xgettext 0.21+.

 This patch uses a message that causes an xgettext warning regardless of
 the version.

 Backport of 07a30f561661efae1691ff45d10ec6014b395b58 from master
 }}}

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

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

Re: [Django] #31850: test_extraction_warning (i18n.test_extraction.BasicExtractorTests) fails with xgettext 0.21.

2020-11-02 Thread Django 
#31850: test_extraction_warning (i18n.test_extraction.BasicExtractorTests) fails
with xgettext 0.21.
-+-
 Reporter:  Michał Górny |Owner:  Max
 Type:   |  Smolens
  Cleanup/optimization   |   Status:  closed
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Michał Górny):

 Would it be possible to backport this into 2.2, 3.0 and 3.1 branches?

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

Re: [Django] #29606: Validate the type of ALLOWED_HOSTS

2020-11-02 Thread Django 
#29606: Validate the type of ALLOWED_HOSTS
-+-
 Reporter:  rafis|Owner:  Octavio
 |  Peri
 Type:  New feature  |   Status:  assigned
Component:  Core (System |  Version:  master
  checks)|
 Severity:  Normal   |   Resolution:
 Keywords:  allowed_hosts| Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Adam (Chainz) Johnson):

 It needs only be in one place, as a system check. `runserver` runs system
 checks at startup already. IMO it should not be a deployment check, as
 `ALLOWED_HOSTS` affects use of `runserver` locally too if `DEBUG = False`.

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

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

Re: [Django] #32132: ManyToManyField does not respect the PositiveBigIntegerField in m2m intermediate table.

2020-11-02 Thread Django 
#32132: ManyToManyField does not respect the PositiveBigIntegerField in m2m
intermediate table.
-+-
 Reporter:  Kfir Breger  |Owner:  David
 |  Wobrock
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  models, orm  | 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):

 * 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/068.e55469e8f437de8eff40f56d990cc992%40djangoproject.com.