Re: [Django] #31819: Django + Django REST Framework generates API errors with swagger

2020-07-22 Thread Django
#31819: Django + Django REST Framework generates API errors with swagger
-+-
 Reporter:  Perry Harrington |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (Other) |  Version:  3.0
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  swagger regex| Triage Stage:
  javascrip rest openapi |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

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


Comment:

 Hi Perry. This isn't in scope for Django: differences between language
 implementations of regex isn't something we're going to address.

 The particular issue with DRF OpenAPI schema generation should (at least
 in part) be addressed by [https://github.com/encode/django-rest-
 framework/pull/7389/ this PR, which was merged into DRF]. That will be
 part of DRF 3.12, which is pending, but has been delayed by (let us just
 call it) 2020, and will be released some time soon. In the meantime you
 can install the latest master using
 [https://pip.pypa.io/en/stable/reference/pip_install/#vcs-support pip's
 VCS support].

 If you find there are further changes needed, please open a new issue or
 preferably a PR on the DRF repo: it is appropriate there that we'll do
 what we can to map between the required formats when generating the
 OpenAPI schema.

 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/065.533aa8533665ec964f9ca873d861debb%40djangoproject.com.


Re: [Django] #31812: The `model` attribute of image fields doesn't point to concrete model. (was: Possible unintentional consequence of #31701: The `model` attribute of image fields has changed in 3.2

2020-07-22 Thread Django
#31812: The `model` attribute of image fields doesn't point to concrete model.
-+-
 Reporter:  Matthias Kestenholz  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Release blocker  |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * cc: Sultan (added)
 * severity:  Normal => Release blocker
 * stage:  Unreviewed => Accepted


Comment:

 Thanks for the report! I think we should restore `contribute_to_class()`
 but with `attname`:
 {{{
 diff --git a/django/db/models/fields/files.py
 b/django/db/models/fields/files.py
 index b064202ee3..e10a5bb6d9 100644
 --- a/django/db/models/fields/files.py
 +++ b/django/db/models/fields/files.py
 @@ -299,6 +299,10 @@ class FileField(Field):
  file.save(file.name, file.file, save=False)
  return file

 +def contribute_to_class(self, cls, name, **kwargs):
 +super().contribute_to_class(cls, name, **kwargs)
 +setattr(cls, self.attname, self.descriptor_class(self))
 +
  def generate_filename(self, instance, filename):
  """
  Apply (if callable) or prepend (if a string) upload_to to the
 filename,
 }}}

 Regression in a93425a37f4defdb31d4ca96bb3bf6da21f0b5ce.

 Reproduced at f65454801bfa13fc043fee0aca8f49af41380683.

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


Re: [Django] #31819: Django + Django REST Framework generates API errors with swagger

2020-07-22 Thread Django
#31819: Django + Django REST Framework generates API errors with swagger
-+-
 Reporter:  drwonky  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Other) |  Version:  3.0
 Severity:  Normal   |   Resolution:
 Keywords:  swagger regex| Triage Stage:
  javascrip rest openapi |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by drwonky):

 Here's a comparison of the regex APIs for Python and Javascript:

 Python:

 \Z

 Matches only at the end of the string.

 $

 Matches the end of the string or just before the newline at the end of
 the string, and in MULTILINE mode also matches before a newline. foo
 matches both ‘foo’ and ‘foobar’, while the regular expression foo$ matches
 only ‘foo’. More interestingly, searching for foo.$ in 'foo1\nfoo2\n'
 matches ‘foo2’ normally, but ‘foo1’ in MULTILINE mode; searching for a
 single $ in 'foo\n' will find two (empty) matches: one just before the
 newline, and one at the end of the string.


 Javascript:

 $

 Matches the end of input. If the multiline flag is set to true, also
 matches immediately before a line break character. For example, /t$/ does
 not match the "t" in "eater", but does match it in "eat".

 PHP:

  \Z
 end of subject or newline at end (independent of multiline mode)

  A dollar character ($) is an assertion which is TRUE only if the current
 matching point is at the end of the subject string, or immediately before
 a newline character that is the last character in the string (by default).
 Dollar ($) need not be the last character of the pattern if a number of
 alternatives are involved, but it should be the last item in any branch in
 which it appears. Dollar has no special meaning in a character class.

 The meaning of dollar can be changed so that it matches only at the very
 end of the string, by setting the PCRE_DOLLAR_ENDONLY option at compile or
 matching time. This does not affect the \Z assertion.

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


Re: [Django] #31819: Django + Django REST Framework generates API errors with swagger

2020-07-22 Thread Django
#31819: Django + Django REST Framework generates API errors with swagger
-+-
 Reporter:  drwonky  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Core (Other) |  Version:  3.0
 Severity:  Normal   |   Resolution:
 Keywords:  swagger regex| Triage Stage:
  javascrip rest openapi |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by drwonky):

 * cc: drwonky (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/065.f3fe2eeff7dacc012839ea35faf1313b%40djangoproject.com.


[Django] #31819: Django + Django REST Framework generates API errors with swagger

2020-07-22 Thread Django
#31819: Django + Django REST Framework generates API errors with swagger
-+-
   Reporter:  drwonky|  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Core   |Version:  3.0
  (Other)|   Keywords:  swagger regex
   Severity:  Normal |  javascrip rest openapi
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 The Django Validators use the syntax \Z to designate an end of line,
 similar to the more conventional $ marker.

 This swagger ticket gives context to the following: https://github.com
 /swagger-api/swagger-editor/issues/1601

 Javascript uses the $ as the end anchor, this has slightly different
 semantics to the intended \Z anchor in Python.

 The problem is that swagger chokes on this syntax, and looking at the code
 it comes directly from the Python regexes being exported to the openapi
 spec.

 I propose 2 possible solutions:

 1. Change the Django regexes to use the $ anchor, this may have unintended
 behavior.  The \Z regex is not valid as an anchor in Javascript.
 2. Run all of the python regexes through a simple replace, changing \Z for
 $

 I'm open to any other suggestions, but as I see it now, the yaml produced
 from Django regexes is not compliant with Javascript and javascript
 validators by extension.

 I can manually edit yaml files, but I'd like to have a dynamic API
 endpoint for schema definitions.

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

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


Re: [Django] #31815: CheckConstraint() with unicode parameters crashes on PostgreSQL.

2020-07-22 Thread Django
#31815: CheckConstraint() with unicode parameters crashes on PostgreSQL.
-+-
 Reporter:  JSAustin |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  encoding utf-8   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * Attachment "tests-31815.diff" added.

 Regression test.

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


Re: [Django] #31815: CheckConstraint() with unicode parameters crashes on PostgreSQL. (was: Can't Create PostgreSQL Database Constraints with non latin-1 encodings)

2020-07-22 Thread Django
#31815: CheckConstraint() with unicode parameters crashes on PostgreSQL.
-+-
 Reporter:  JSAustin |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  encoding utf-8   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * cc: Simon Charette (added)
 * version:  3.0 => master
 * stage:  Unreviewed => Accepted


Comment:

 Thanks for this ticket. I attached a regression test. The following patch
 (based on [https://github.com/psycopg/psycopg2/issues/331 discussion])
 fixes this issue for me:
 {{{
 diff --git a/django/db/backends/postgresql/schema.py
 b/django/db/backends/postgresql/schema.py
 index 7687c37fe7..b4b6f0dabe 100644
 --- a/django/db/backends/postgresql/schema.py
 +++ b/django/db/backends/postgresql/schema.py
 @@ -39,7 +39,10 @@ class DatabaseSchemaEditor(BaseDatabaseSchemaEditor):
  if isinstance(value, str):
  value = value.replace('%', '%%')
  # getquoted() returns a quoted bytestring of the adapted value.
 -return psycopg2.extensions.adapt(value).getquoted().decode()
 +adapted = psycopg2.extensions.adapt(value)
 +if isinstance(value, str):
 +adapted.encoding = 'utf-8'
 +return adapted.getquoted().decode()

  def _field_indexes_sql(self, model, field):
  output = super()._field_indexes_sql(model, field)
 }}}

 Can you confirm that it works for you?

 Reproduced at f65454801bfa13fc043fee0aca8f49af41380683.

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


Re: [Django] #31817: sanitize_address() raises TypeError for bytestrings. (was: 3.1rc1 injection: TypeError in sanitize_address)

2020-07-22 Thread Django
#31817: sanitize_address() raises TypeError for bytestrings.
--+--
 Reporter:  Mike Edmunds  |Owner:  nobody
 Type:  Bug   |   Status:  closed
Component:  Core (Mail)   |  Version:  3.1
 Severity:  Normal|   Resolution:  wontfix
 Keywords:| Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by felixxm):

 * cc: Florian Apolloner (added)
 * status:  new => closed
 * resolution:   => wontfix


Comment:

 Thanks for this report, however `sanitize_address()` is an internal,
 undocumented method that expects strings. Moreover there is no need to
 pass encoded display names or to force encoding on them, e.g.
 {{{
 >>> sanitize_address(('Name', 't...@example.com'), 'utf-8')
 'Name '
 >>> sanitize_address(('gęśla jaźń', 't...@example.com'), 'utf-8')
 '=?utf-8?b?Z8SZxZtsYSBqYcW6xYQ=?= '
 }}}
 works as expected. You will get a similar error from
 
[https://docs.python.org/3/library/email.headerregistry.html#email.headerregistry.Address
 email.headerregistry.Address()] on Python 3.6.11+, 3.7.8+, and 3.8.4+:
 {{{
 >>> Address(display_name='Name'.encode('utf-8'), username='to',
 domain='example.com')
 Traceback (most recent call last):
   File "", line 1, in 
   File "/usr/local/lib/python3.8/email/headerregistry.py", line 35, in
 __init__
 inputs = ''.join(filter(None, (display_name, username, domain,
 addr_spec)))
 TypeError: sequence item 0: expected str instance, bytes found
 }}}

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


Re: [Django] #31818: Allow `startproject` to ignore patterns / folders

2020-07-22 Thread Django
#31818: Allow `startproject` to ignore patterns / folders
-+-
 Reporter:  Mateusz Kurowski |Owner:  nobody
 Type:  New feature  |   Status:  closed
Component:  Core (Management |  Version:  master
  commands)  |
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  startproject,| Triage Stage:
  ignore pattern |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

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


Comment:

 Duplicate of #31627.

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


Re: [Django] #31816: StreamingHttpResponse docs incorrectly specifies strings. (was: StreamingHttpResponse docs incorrectly specifies strings)

2020-07-22 Thread Django
#31816: StreamingHttpResponse docs incorrectly specifies strings.
--+
 Reporter:  Lincoln   |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Documentation |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  1 |UI/UX:  0
--+
Changes (by felixxm):

 * easy:  0 => 1
 * stage:  Unreviewed => Accepted


Comment:

 Agreed, there is a typo, ''"It should be given an iterator that yields
 **bytestrings** as content."'' is a correct form. Would you like to
 provide a 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/070.6bd16b7cd98eb05a824e00b501622194%40djangoproject.com.


[Django] #31818: Allow `startproject` to ignore patterns / folders

2020-07-22 Thread Django
#31818: Allow `startproject` to ignore patterns / folders
-+-
   Reporter:  Mateusz|  Owner:  nobody
  Kurowski   |
   Type:  New| Status:  new
  feature|
  Component:  Core   |Version:  master
  (Management commands)  |   Keywords:  startproject,
   Severity:  Normal |  ignore pattern
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 https://docs.djangoproject.com/en/dev/ref/django-admin/#startproject

 We could allow ignoring certain folders, in my example the problem happens
 with virtual env folder that is in the root of my custom project template.

 For example:

 --ignorepath=venv

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

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


[Django] #31817: 3.1rc1 injection: TypeError in sanitize_address

2020-07-22 Thread Django
#31817: 3.1rc1 injection: TypeError in sanitize_address
+
   Reporter:  Mike Edmunds  |  Owner:  nobody
   Type:  Bug   | Status:  new
  Component:  Core (Mail)   |Version:  3.1
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 The code below works in 3.1b1 (and earlier released versions), but results
 in a TypeError in 3.1rc1:

 {{{
 $ python manage.py version
 3.1rc1
 $ python manage.py shell
 >>> from django.core.mail.message import sanitize_address
 >>> sanitize_address(("Name".encode('utf-8'), "t...@example.com"), 'utf-8')
 Traceback (most recent call last):
   File "", line 1, in 
 sanitize_address(("Name".encode('utf-8'), "t...@example.com"), 'utf-8')
   File "/opt/virtualenvs/python3/lib/python3.8/site-
 packages/django/core/mail/message.py", line 99, in sanitize_address
 address_parts = nm + localpart + domain
 TypeError: can't concat str to bytes
 }}}

 Expected behavior:

 {{{
 $ python manage.py version
 3.1b1
 $ python manage.py shell
 >>> from django.core.mail.message import sanitize_address
 >>> sanitize_address(("Name".encode('utf-8'), "t...@example.com"), 'utf-8')
 '=?utf-8?q?Name?= '
 }}}

 (Python 3.6, 3.7, 3.8)

 This usage comes from the django-anymail package (which I maintain). I
 realize sanitize_address is not technically a documented Django API, and
 I'm sure I could find another approach for the particular case this
 breaks. But I was concerned about it appearing between beta and RC. (FWIW,
 a quick GitHub search turns up several other apparent uses of
 sanitize_address in the wild, some with the encoding parameter specified
 as above.)

 Related to the changes for #31784.

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


Re: [Django] #31816: StreamingHttpResponse docs incorrectly specifies strings

2020-07-22 Thread Django
#31816: StreamingHttpResponse docs incorrectly specifies strings
-+-
 Reporter:  Lincoln  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  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
-+-
Description changed by Lincoln:

Old description:

> In the docs for `StreamingHttpResponse`
> [https://docs.djangoproject.com/en/dev/ref/request-response
> /#streaminghttpresponse-objects]
>
> It says that "It should be given an iterator that yields strings as
> content."
>
> But in the class there is
>
> {{{
> def getvalue(self):
> return b''.join(self.streaming_content)
> }}}
>
> So I think the docs should specify that it be given an iterator of
> bytestrings instead.

New description:

 In the docs for `StreamingHttpResponse`
 [https://docs.djangoproject.com/en/dev/ref/request-response
 /#streaminghttpresponse-objects]

 It says that "It should be given an iterator that yields strings as
 content."

 But in the class there is

 {{{
 def getvalue(self):
 return b''.join(self.streaming_content)
 }}}

 So I think the docs should specify that it be given an iterator of
 bytestrings instead.

 That line of the docs hasn't changed since 2012 when it was added. I
 suspect that back then "strings" meant python2 strings.

--

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


[Django] #31816: StreamingHttpResponse docs incorrectly specifies strings

2020-07-22 Thread Django
#31816: StreamingHttpResponse docs incorrectly specifies strings
+
   Reporter:  Lincoln   |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Documentation |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 |
+
 In the docs for `StreamingHttpResponse`
 [https://docs.djangoproject.com/en/dev/ref/request-response
 /#streaminghttpresponse-objects]

 It says that "It should be given an iterator that yields strings as
 content."

 But in the class there is

 {{{
 def getvalue(self):
 return b''.join(self.streaming_content)
 }}}

 So I think the docs should specify that it be given an iterator of
 bytestrings instead.

-- 
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/055.d544fdd5d65ed9254847a3e49d3fef9a%40djangoproject.com.


Re: [Django] #31814: CACHE_MIDDLEWARE_ALIAS default is missing quotation marks.

2020-07-22 Thread Django
#31814: CACHE_MIDDLEWARE_ALIAS default is missing quotation marks.
-+-
 Reporter:  Mateusz Kurowski |Owner:  Mateusz
 Type:   |  Kurowski
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
  CACHE_MIDDLEWARE_ALIAS |
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:"f4b7996e9b05a6158482da937723700872429847" f4b7996e]:
 {{{
 #!CommitTicketReference repository=""
 revision="f4b7996e9b05a6158482da937723700872429847"
 [3.0.x] Fixed #31814 -- Fixed typo in docs/ref/settings.txt.

 Backport of f65454801bfa13fc043fee0aca8f49af41380683 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.d3a91fc8817c86cae30f14ff3c515cee%40djangoproject.com.


Re: [Django] #31814: CACHE_MIDDLEWARE_ALIAS default is missing quotation marks.

2020-07-22 Thread Django
#31814: CACHE_MIDDLEWARE_ALIAS default is missing quotation marks.
-+-
 Reporter:  Mateusz Kurowski |Owner:  Mateusz
 Type:   |  Kurowski
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
  CACHE_MIDDLEWARE_ALIAS |
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:"252166404144e33c599738e2d73df749d5d1d400" 2521664]:
 {{{
 #!CommitTicketReference repository=""
 revision="252166404144e33c599738e2d73df749d5d1d400"
 [3.1.x] Fixed #31814 -- Fixed typo in docs/ref/settings.txt.

 Backport of f65454801bfa13fc043fee0aca8f49af41380683 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.77d2caf6c8d0feac49a1b9cb6fb26469%40djangoproject.com.


Re: [Django] #31814: CACHE_MIDDLEWARE_ALIAS default is missing quotation marks.

2020-07-22 Thread Django
#31814: CACHE_MIDDLEWARE_ALIAS default is missing quotation marks.
-+-
 Reporter:  Mateusz Kurowski |Owner:  Mateusz
 Type:   |  Kurowski
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
  CACHE_MIDDLEWARE_ALIAS |
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:"f65454801bfa13fc043fee0aca8f49af41380683" f654548]:
 {{{
 #!CommitTicketReference repository=""
 revision="f65454801bfa13fc043fee0aca8f49af41380683"
 Fixed #31814 -- Fixed typo in docs/ref/settings.txt.
 }}}

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


Re: [Django] #31814: CACHE_MIDDLEWARE_ALIAS default is missing quotation marks. (was: documentation CACHE_MIDDLEWARE_ALIAS `default` missing quotation marks)

2020-07-22 Thread Django
#31814: CACHE_MIDDLEWARE_ALIAS default is missing quotation marks.
-+-
 Reporter:  Mateusz Kurowski |Owner:  Mateusz
 Type:   |  Kurowski
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
  CACHE_MIDDLEWARE_ALIAS |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * has_patch:  0 => 1
 * stage:  Unreviewed => Accepted


Comment:

 Thanks.

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

 For the future reference, ticket is not required for typos.

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


Re: [Django] #31813: PASSWORD_RESET_TIMEOUT and PASSWORD_RESET_TIMEOUT_DAYS

2020-07-22 Thread Django
#31813: PASSWORD_RESET_TIMEOUT and PASSWORD_RESET_TIMEOUT_DAYS
-+-
 Reporter:  Mateusz Kurowski |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  3.0
 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 felixxm):

 * resolution:  fixed => invalid


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


Re: [Django] #31814: documentation CACHE_MIDDLEWARE_ALIAS `default` missing quotation marks

2020-07-22 Thread Django
#31814: documentation CACHE_MIDDLEWARE_ALIAS `default` missing quotation marks
-+-
 Reporter:  Mateusz Kurowski |Owner:  Mateusz
 Type:   |  Kurowski
  Cleanup/optimization   |   Status:  assigned
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
  CACHE_MIDDLEWARE_ALIAS |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mateusz Kurowski):

 * owner:  nobody => Mateusz Kurowski
 * 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/064.abe936d663dd187ad26d12a6e915de91%40djangoproject.com.


[Django] #31814: documentation CACHE_MIDDLEWARE_ALIAS `default` missing quotation marks

2020-07-22 Thread Django
#31814: documentation CACHE_MIDDLEWARE_ALIAS `default` missing quotation marks
-+-
   Reporter:  Mateusz|  Owner:  nobody
  Kurowski   |
   Type: | Status:  new
  Cleanup/optimization   |
  Component: |Version:  master
  Documentation  |   Keywords:
   Severity:  Normal |  CACHE_MIDDLEWARE_ALIAS
   Triage Stage: |  Has patch:  0
  Unreviewed |
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/049.eeccb07126591359dcfecf92f83aa3f5%40djangoproject.com.


Re: [Django] #31813: PASSWORD_RESET_TIMEOUT and PASSWORD_RESET_TIMEOUT_DAYS

2020-07-22 Thread Django
#31813: PASSWORD_RESET_TIMEOUT and PASSWORD_RESET_TIMEOUT_DAYS
-+-
 Reporter:  Mateusz Kurowski |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  3.0
 Severity:  Normal   |   Resolution:  fixed
 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 Mateusz Kurowski):

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


Comment:

 fixed in 3.1 sorry

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

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


[Django] #31813: PASSWORD_RESET_TIMEOUT and PASSWORD_RESET_TIMEOUT_DAYS

2020-07-22 Thread Django
#31813: PASSWORD_RESET_TIMEOUT and PASSWORD_RESET_TIMEOUT_DAYS
+
   Reporter:  Mateusz Kurowski  |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Documentation |Version:  3.0
   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 |
+
 There are 2 settings but only PASSWORD_RESET_TIMEOUT_DAYS is 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/049.fbcac9987765c57a380838666a482e52%40djangoproject.com.


Re: [Django] #24763: Docs incorrectly state that DoesNotExist is in django.core.exceptions

2020-07-22 Thread Django
#24763: Docs incorrectly state that DoesNotExist is in django.core.exceptions
+
 Reporter:  Sylvain Fankhauser  |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  Documentation   |  Version:  1.8
 Severity:  Normal  |   Resolution:  fixed
 Keywords:  | Triage Stage:  Accepted
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:"f026d761d63ecd10b937b8009b0ad59673f772b5" f026d761]:
 {{{
 #!CommitTicketReference repository=""
 revision="f026d761d63ecd10b937b8009b0ad59673f772b5"
 [3.0.x] Refs #24763 -- Moved DoesNotExist to Model class docs.

 Backport of b5f0efa19c82d274082bcde8a8acae5038667614 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.1612b51d9e3a43f517921fc6e215b3e5%40djangoproject.com.


Re: [Django] #24763: Docs incorrectly state that DoesNotExist is in django.core.exceptions

2020-07-22 Thread Django
#24763: Docs incorrectly state that DoesNotExist is in django.core.exceptions
+
 Reporter:  Sylvain Fankhauser  |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  Documentation   |  Version:  1.8
 Severity:  Normal  |   Resolution:  fixed
 Keywords:  | Triage Stage:  Accepted
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:"77abe9881657b31124dfa326aa38f7159d0d1c50" 77abe988]:
 {{{
 #!CommitTicketReference repository=""
 revision="77abe9881657b31124dfa326aa38f7159d0d1c50"
 [3.1.x] Refs #24763 -- Moved DoesNotExist to Model class docs.

 Backport of b5f0efa19c82d274082bcde8a8acae5038667614 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.bf57955c9335bece54a29e1c3be05df0%40djangoproject.com.


Re: [Django] #24763: Docs incorrectly state that DoesNotExist is in django.core.exceptions

2020-07-22 Thread Django
#24763: Docs incorrectly state that DoesNotExist is in django.core.exceptions
+
 Reporter:  Sylvain Fankhauser  |Owner:  nobody
 Type:  Bug |   Status:  closed
Component:  Documentation   |  Version:  1.8
 Severity:  Normal  |   Resolution:  fixed
 Keywords:  | Triage Stage:  Accepted
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:"b5f0efa19c82d274082bcde8a8acae5038667614" b5f0efa1]:
 {{{
 #!CommitTicketReference repository=""
 revision="b5f0efa19c82d274082bcde8a8acae5038667614"
 Refs #24763 -- Moved DoesNotExist to Model class docs.
 }}}

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


Re: [Django] #31807: Whether support more secure method to generate session id

2020-07-22 Thread Django
#31807: Whether support more secure method to generate session id
--+--
 Reporter:  dotuser   |Owner:  nobody
 Type:  New feature   |   Status:  closed
Component:  contrib.sessions  |  Version:  2.2
 Severity:  Normal|   Resolution:  wontfix
 Keywords:| Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--

Comment (by felixxm):

 > `secrets` doesn't change any behavior or add security for now[1][2].

 Yes I know, but do we need more? Session keys have 32 chars, so =~ 165
 bits.

 > So, for security or cryptographic use case in session id, any others
 plan to support a more secure method?

 Do you have any proposition?

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


Re: [Django] #31811: Add optional timing outputs to the test runner

2020-07-22 Thread Django
#31811: Add optional timing outputs to the test runner
-+-
 Reporter:  Ahmad A. Hussein |Owner:  Ahmad A.
 |  Hussein
 Type:  New feature  |   Status:  assigned
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  timing, test runner  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Ahmad A. Hussein):

 * has_patch:  0 => 1


Comment:

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

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

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


Re: [Django] #31807: Whether support more secure method to generate session id

2020-07-22 Thread Django
#31807: Whether support more secure method to generate session id
--+--
 Reporter:  dotuser   |Owner:  nobody
 Type:  New feature   |   Status:  closed
Component:  contrib.sessions  |  Version:  2.2
 Severity:  Normal|   Resolution:  wontfix
 Keywords:| Triage Stage:  Unreviewed
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--

Comment (by dotuser):

 Replying to [comment:1 felixxm]:
 > Django 3.0+ uses `secrets`, see #27635.

 `secrets` doesn't change any behavior or add security for now[1][2]. So,
 for security or cryptographic use case in session id, any others plan to
 support a more secure method?

 > I'm not sure if I understand your proposal (using `secrets` in Django
 2.2?), we didn't accept #27635 for Django 2.2 because it supports Python
 3.5. Also Django 2.2. is in extended support and we will not add any new
 features to it.

 Sorry... since I'm making app with Django 2.2.X, so I filled ticket with
 this version. If have plans to support, it will be a great features
 because of builtin support in latest master or Django 3.0+ and then I'll
 try to migrate latest version

 [1] https://code.djangoproject.com/ticket/27635#comment:3
 [2] https://docs.python.org/3/library/secrets.html#secrets.SystemRandom

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


[Django] #31812: Possible unintentional consequence of #31701: The `model` attribute of image fields has changed in 3.2 (master) to reference the abstract model

2020-07-22 Thread Django
#31812: Possible unintentional consequence of #31701: The `model` attribute of
image fields has changed in 3.2 (master) to reference the abstract model
-+-
   Reporter:  Matthias   |  Owner:  nobody
  Kestenholz |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  master
  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  |
-+-
 In Django 3.1 and before, one could use the `model` attribute of image
 fields to find the concrete model the image field belongs to.

 This isn't possible in 3.2 anymore, and I bisected the change to the fix
 of #31701.

 I found this while investigating a CI failure of django-imagefield https
 ://travis-ci.org/github/matthiask/django-imagefield/jobs/710794644

 I'm not sure whether this is a bug or whether it is an intentional change.
 If it is the later, is there an alternative to find the concrete model an
 image field belongs to? I'm classifying this as a bug because the change
 made model and field introspection harder than it was before. Also, since
 behavior changed #31701 may possibly not be classified as a
 cleanup/optimization anymore...

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


Re: [Django] #29887: Add support for pymemcache

2020-07-22 Thread Django
#29887: Add support for pymemcache
--+
 Reporter:  Adrian Turjak |Owner:  (none)
 Type:  Cleanup/optimization  |   Status:  new
Component:  Core (Cache system)   |  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 Claude Paroz):

 * owner:  Maina Nick => (none)
 * status:  assigned => new


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

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


Re: [Django] #31810: HttpRequest.headers doesn't contain headers without HTTP prefix.

2020-07-22 Thread Django
#31810: HttpRequest.headers doesn't contain headers without HTTP prefix.
---+--
 Reporter:  bcail  |Owner:  nobody
 Type:  Uncategorized  |   Status:  closed
Component:  HTTP handling  |  Version:  master
 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 bcail):

 Thanks felixxm. Did this change since django 2.2? On django 2.2, when I
 pass a custom header in the request, it does show up in request.headers,
 even though I'm not putting an HTTP_ prefix on the header. Is it showing
 up in request.headers because django is adding HTTP_ to the custom header?
 I do see that django added HTTP_ to the header in request.META, but in
 request.headers it shows without the HTTP_.

 It feels like if django is adding HTTP_ to the header, then the test
 client should also add HTTP_ to the header?

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


Re: [Django] #31811: Add optional timing outputs to the test runner

2020-07-22 Thread Django
#31811: Add optional timing outputs to the test runner
-+-
 Reporter:  Ahmad A. Hussein |Owner:  Ahmad A.
 |  Hussein
 Type:  New feature  |   Status:  assigned
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  timing, test runner  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * stage:  Unreviewed => Accepted


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


[Django] #31811: Add optional timing outputs to the test runner

2020-07-22 Thread Django
#31811: Add optional timing outputs to the test runner
-+-
   Reporter:  Ahmad A.   |  Owner:  nobody
  Hussein|
   Type:  New| Status:  new
  feature|
  Component:  Testing|Version:  master
  framework  |
   Severity:  Normal |   Keywords:  timing, test runner
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Add timing outputs for things like database creation, database cloning,
 time to run tests, and total time elapsed.
 Example format:
 - Took X to build DB.
 - Took Y to clone
 - Took Z to run tests
 - Total time.

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


Re: [Django] #31811: Add optional timing outputs to the test runner

2020-07-22 Thread Django
#31811: Add optional timing outputs to the test runner
-+-
 Reporter:  Ahmad A. Hussein |Owner:  Ahmad A.
 |  Hussein
 Type:  New feature  |   Status:  assigned
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  timing, test runner  | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Ahmad A. Hussein):

 * owner:  nobody => Ahmad A. Hussein
 * 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/066.3242521746ac7a1436c03296744e783a%40djangoproject.com.


Re: [Django] #31262: Support dictionaries in Field.choices for named groups.

2020-07-22 Thread Django
#31262: Support dictionaries in Field.choices for named groups.
-+-
 Reporter:  Tom Forbes   |Owner:  Tom
 |  Forbes
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * needs_docs:  0 => 1
 * easy:  1 => 0


Comment:

 Hi Tom: as per comments on the PR, my main (only really) concern is the
 phrasing on the checks and docs: it's minor but I think if we can be super
 precise/clear we'll save a lot of confusion.

 Other than that I quite like it: using a dictionary does look much
 cleaner.
 Let's see if we can pin down the wording.
 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/061.1223946ab5ef4d06245bf270b791e383%40djangoproject.com.


Re: [Django] #31805: MySQL Schema tests fail when table names are case-insensitive.

2020-07-22 Thread Django
#31805: MySQL Schema tests fail when table names are case-insensitive.
-+-
 Reporter:  Ahmad A. Hussein |Owner:  felixxm
 Type:  Bug  |   Status:  closed
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  mysql, schema,   | Triage Stage:  Ready for
  windows|  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:"eb815938750bed7e4f8f9ec1974d60e4994a9421" eb815938]:
 {{{
 #!CommitTicketReference repository=""
 revision="eb815938750bed7e4f8f9ec1974d60e4994a9421"
 [2.2.x] Fixed #31805 -- Fixed SchemaTests.tearDown() when table names are
 case-insensitive.

 Backport of fd53db842c35c994dbd54196dd38a908f3676b1a 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/066.531d2734b2a98a7db5a425c59e5fec27%40djangoproject.com.


Re: [Django] #31805: MySQL Schema tests fail when table names are case-insensitive.

2020-07-22 Thread Django
#31805: MySQL Schema tests fail when table names are case-insensitive.
-+-
 Reporter:  Ahmad A. Hussein |Owner:  felixxm
 Type:  Bug  |   Status:  closed
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  mysql, schema,   | Triage Stage:  Ready for
  windows|  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:"dcb27ead84a91e8d38a183cfc2f7640141eb40f8" dcb27ead]:
 {{{
 #!CommitTicketReference repository=""
 revision="dcb27ead84a91e8d38a183cfc2f7640141eb40f8"
 [3.0.x] Fixed #31805 -- Fixed SchemaTests.tearDown() when table names are
 case-insensitive.

 Backport of fd53db842c35c994dbd54196dd38a908f3676b1a 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/066.02685bf65c5f4f08501f3095d4068c9f%40djangoproject.com.


Re: [Django] #31805: MySQL Schema tests fail when table names are case-insensitive.

2020-07-22 Thread Django
#31805: MySQL Schema tests fail when table names are case-insensitive.
-+-
 Reporter:  Ahmad A. Hussein |Owner:  felixxm
 Type:  Bug  |   Status:  closed
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  mysql, schema,   | Triage Stage:  Ready for
  windows|  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:"2ff2084cfdac5c49261a091f5094feed96d0de4c" 2ff2084c]:
 {{{
 #!CommitTicketReference repository=""
 revision="2ff2084cfdac5c49261a091f5094feed96d0de4c"
 [3.1.x] Fixed #31805 -- Fixed SchemaTests.tearDown() when table names are
 case-insensitive.

 Backport of fd53db842c35c994dbd54196dd38a908f3676b1a 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/066.56906518e83e40fadcf31e83d13d79c8%40djangoproject.com.


Re: [Django] #31805: MySQL Schema tests fail when table names are case-insensitive.

2020-07-22 Thread Django
#31805: MySQL Schema tests fail when table names are case-insensitive.
-+-
 Reporter:  Ahmad A. Hussein |Owner:  felixxm
 Type:  Bug  |   Status:  closed
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  mysql, schema,   | Triage Stage:  Ready for
  windows|  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:"fd53db842c35c994dbd54196dd38a908f3676b1a" fd53db8]:
 {{{
 #!CommitTicketReference repository=""
 revision="fd53db842c35c994dbd54196dd38a908f3676b1a"
 Fixed #31805 -- Fixed SchemaTests.tearDown() when table names are case-
 insensitive.
 }}}

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


Re: [Django] #31805: MySQL Schema tests fail when table names are case-insensitive.

2020-07-22 Thread Django
#31805: MySQL Schema tests fail when table names are case-insensitive.
-+-
 Reporter:  Ahmad A. Hussein |Owner:  felixxm
 Type:  Bug  |   Status:  assigned
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  mysql, schema,   | Triage Stage:  Ready for
  windows|  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * stage:  Accepted => Ready for checkin


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

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


Re: [Django] #31805: MySQL Schema tests fail when table names are case-insensitive.

2020-07-22 Thread Django
#31805: MySQL Schema tests fail when table names are case-insensitive.
-+-
 Reporter:  Ahmad A. Hussein |Owner:  felixxm
 Type:  Bug  |   Status:  assigned
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  mysql, schema,   | Triage Stage:  Accepted
  windows|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Carlton Gibson):

 I see this on Windows 10 with MySQL 8.


 {{{
 ...
 MySQLdb._exceptions.OperationalError: (1050, "Table 'integerpk' already
 exists")

 ...
 Ran 131 tests in 42.172s

 FAILED (errors=2, skipped=18)
 Destroying test database for alias 'default'...
 (django) PS C:\Users\carlt\src\django\tests> django-admin.exe shell
 --settings=test_mysql
 Python 3.7.5 (tags/v3.7.5:5c02a39a0b, Oct 15 2019, 00:11:34) [MSC v.1916
 64 bit (AMD64)] on win32
 Type "help", "copyright", "credits" or "license" for more information.
 (InteractiveConsole)
 >>> from django.db import connection
 >>> connection.features.ignores_table_name_case
 True
 }}}

 The adjustment in Mariusz´ PR fixes the failure.

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


Re: [Django] #31805: MySQL Schema tests fail when table names are case-insensitive.

2020-07-22 Thread Django
#31805: MySQL Schema tests fail when table names are case-insensitive.
-+-
 Reporter:  Ahmad A. Hussein |Owner:  felixxm
 Type:  Bug  |   Status:  assigned
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  mysql, schema,   | Triage Stage:  Accepted
  windows|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

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


Comment:

 Thanks Carlton for confirmation!

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


Re: [Django] #31805: MySQL Schema tests fail when table names are case-insensitive. (was: MySQL Schema tests fail on Windows)

2020-07-22 Thread Django
#31805: MySQL Schema tests fail when table names are case-insensitive.
-+-
 Reporter:  Ahmad A. Hussein |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  mysql, schema,   | Triage Stage:  Accepted
  windows|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * status:  closed => new
 * component:  Database layer (models, ORM) => Testing framework
 * has_patch:  0 => 1
 * resolution:  needsinfo =>
 * stage:  Unreviewed => Accepted


Comment:

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

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

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


Re: [Django] #31757: Adjust default SECRET_KEY to use `dj::insecure` prefix and add matching deployment system check.

2020-07-22 Thread Django
#31757: Adjust default SECRET_KEY to use `dj::insecure` prefix and add matching
deployment system check.
--+
 Reporter:  Carlton Gibson|Owner:  kosc
 Type:  New feature   |   Status:  assigned
Component:  Core (System checks)  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Shai Berger):

 Replying to [comment:4 felixxm]:
 > Replying to [comment:2 René Fleschenberg]:
 > > Shai Berger suggested an alternative approach: Marking the string as
 insecure by making it an instance of a custom str subclass
 >
 > Prefix is fine, IMO.

 Missed this earlier... prefix is fine IMO too.

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

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


Re: [Django] #31797: MariaDB 10.4 SchemaTests failures

2020-07-22 Thread Django
#31797: MariaDB 10.4 SchemaTests failures
-+-
 Reporter:  Tom Forbes   |Owner:  felixxm
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  MariaDB  | Triage Stage:  Accepted
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:"1a81d34e70bdffbb563e053c3178ab885436c00c" 1a81d34]:
 {{{
 #!CommitTicketReference repository=""
 revision="1a81d34e70bdffbb563e053c3178ab885436c00c"
 [3.0.x] Fixed #31797 -- Skipped schema tests on specific MariaDB versions.

 test_alter_not_unique_field_to_primary_key() test is affected by
 https://jira.mariadb.org/browse/MDEV-19598 on MariaDB 10.4.4 to 10.5.1.

 test_alter_pk_with_self_referential_field() test is affected by
 https://jira.mariadb.org/browse/MDEV-22775 on MariaDB 10.4 series
 from 10.4.13.
 Backport of c071c408d72330b422c124a6bdd85a68acae9566 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/061.a714725617b2ebe0d1bd145898ffe5c7%40djangoproject.com.


Re: [Django] #31797: MariaDB 10.4 SchemaTests failures

2020-07-22 Thread Django
#31797: MariaDB 10.4 SchemaTests failures
-+-
 Reporter:  Tom Forbes   |Owner:  felixxm
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  MariaDB  | Triage Stage:  Accepted
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:"7a3fa3af68809e71d18fedc673ab64152e8940b9" 7a3fa3af]:
 {{{
 #!CommitTicketReference repository=""
 revision="7a3fa3af68809e71d18fedc673ab64152e8940b9"
 [3.1.x] Fixed #31797 -- Skipped schema tests on specific MariaDB versions.

 test_alter_not_unique_field_to_primary_key() test is affected by
 https://jira.mariadb.org/browse/MDEV-19598 on MariaDB 10.4.4 to 10.5.1.

 test_alter_pk_with_self_referential_field() test is affected by
 https://jira.mariadb.org/browse/MDEV-22775 on MariaDB 10.4 series
 from 10.4.13.
 Backport of c071c408d72330b422c124a6bdd85a68acae9566 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/061.978557aded354a4e8d643f4f8c47e87b%40djangoproject.com.


Re: [Django] #31797: MariaDB 10.4 SchemaTests failures

2020-07-22 Thread Django
#31797: MariaDB 10.4 SchemaTests failures
-+-
 Reporter:  Tom Forbes   |Owner:  felixxm
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  MariaDB  | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by GitHub ):

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


Comment:

 In [changeset:"c071c408d72330b422c124a6bdd85a68acae9566" c071c408]:
 {{{
 #!CommitTicketReference repository=""
 revision="c071c408d72330b422c124a6bdd85a68acae9566"
 Fixed #31797 -- Skipped schema tests on specific MariaDB versions.

 test_alter_not_unique_field_to_primary_key() test is affected by
 https://jira.mariadb.org/browse/MDEV-19598 on MariaDB 10.4.4 to 10.5.1.

 test_alter_pk_with_self_referential_field() test is affected by
 https://jira.mariadb.org/browse/MDEV-22775 on MariaDB 10.4 series
 from 10.4.13.
 }}}

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


Re: [Django] #31765: schema.tests.SchemaTests.test_db_table fails on MacOS

2020-07-22 Thread Django
#31765: schema.tests.SchemaTests.test_db_table fails on MacOS
-+-
 Reporter:  Tom Forbes   |Owner:  Tom
 |  Forbes
 Type:  Bug  |   Status:  closed
Component:  Uncategorized|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

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


Comment:

 In [changeset:"80a8be03d9321669a239dbced8ac48a4e7e1" 80a8be0]:
 {{{
 #!CommitTicketReference repository=""
 revision="80a8be03d9321669a239dbced8ac48a4e7e1"
 Fixed #31765 -- Disabled bundled SQLite renaming atomic references on
 macOS 10.15.
 }}}

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


Re: [Django] #27807: Overriding username validators doesn't work as documented

2020-07-22 Thread Django
#27807: Overriding username validators doesn't work as documented
-+-
 Reporter:  johnrork |Owner:  Shekhar
 |  Nath Gyanwali
 Type:  Bug  |   Status:  assigned
Component:  contrib.auth |  Version:  1.10
 Severity:  Normal   |   Resolution:
 Keywords:  validation auth  | Triage Stage:  Accepted
  login forms username   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * 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.79af48d876f841d136031a3ee367b591%40djangoproject.com.


Re: [Django] #31757: Adjust default SECRET_KEY to use `dj::insecure` prefix and add matching deployment system check.

2020-07-22 Thread Django
#31757: Adjust default SECRET_KEY to use `dj::insecure` prefix and add matching
deployment system check.
--+
 Reporter:  Carlton Gibson|Owner:  kosc
 Type:  New feature   |   Status:  assigned
Component:  Core (System checks)  |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Carlton Gibson):

 * 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/071.0ff53ba2560365a9cb3fdea37724570a%40djangoproject.com.


Re: [Django] #30114: ValidationError sometimes raised for valid UUIDs with mod_wsgi

2020-07-22 Thread Django
#30114: ValidationError sometimes raised for valid UUIDs with mod_wsgi
-+-
 Reporter:  Jerry Vinokurov  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  validationerror, | Triage Stage:
  uuid   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

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


Comment:

 Hi @treager — sorry you're hitting problems here, but I can't see anything
 that pins down an issue in Django. (There's just too many variables in the
 two set-ups you describe to see that that's the case.)

 Please see the comments and links preceding
 [https://code.djangoproject.com/ticket/30114#comment:4 Keryn's
 conclusion]:

 > AFAIK there was nothing in Django at fault, and nothing Django could do
 to fix or even warn about it.

 Then, you decribe this:

 > ... is an UUID object but not of instance uuid.UUID as described above.

 In normal play, how is this possible?:

 What we need to be able to address this (if there's an issue in Django) is
 a minimal reproduce project that shows this coming up.

 I hope that makes sense. 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/069.73453720a0f8daa6c1598228423e165e%40djangoproject.com.


Re: [Django] #26167: Support for Functional Indexes (aka Indexes on Expressions)

2020-07-22 Thread Django
#26167: Support for Functional Indexes (aka Indexes on Expressions)
-+-
 Reporter:  Alex Rothberg|Owner:  Hannes
 |  Ljungberg
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  db-indexes   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

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