Re: [Django] #30266: Migrating a model's default primary key to a BigAutoField causes Postgres sequence to lose owner

[Django]

#30266: Migrating a model's default primary key to a BigAutoField causes 
Postgres
sequence to lose owner
-+-
 Reporter:  Dolan Antenucci  |Owner:  Dolan
 |  Antenucci
 Type:  Bug  |   Status:  assigned
Component:  Migrations   |  Version:  1.11
 Severity:  Normal   |   Resolution:
 Keywords:  postgres migration   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Dolan Antenucci):

 FYI: I'm hoping to get to the pending changes in the coming week. Will
 update once they're done

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.9423f8aa9a20a33abf55960a88b23362%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30301: `django.core.management.base.OutputWrapper` discards the `style_func` argument.

[Django]

#30301: `django.core.management.base.OutputWrapper` discards the `style_func`
argument.
-+-
 Reporter:  Adam Barnes  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Core (Management |  Version:  2.1
  commands)  |
 Severity:  Normal   |   Resolution:
 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
-+-
Changes (by Simon Charette):

 * 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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.98e94deb6f4d34699c56c8a757b850d1%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30301: `django.core.management.base.OutputWrapper` discards the `style_func` argument.

[Django]

#30301: `django.core.management.base.OutputWrapper` discards the `style_func`
argument.
-+-
 Reporter:  Adam Barnes  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Core (Management |  Version:  2.1
  commands)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Tim Graham):

 * has_patch:  0 => 1
 * type:  Uncategorized => Cleanup/optimization
 * stage:  Unreviewed => Accepted


Comment:

 [https://github.com/django/django/pull/11147 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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.9872a899442cd88ac445da4c484e4448%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30265: Fix reference to a tutorial number in "Advanced tutorial: How to write reusable app".

[Django]

#30265: Fix reference to a tutorial number in "Advanced tutorial: How to write
reusable app".
-+-
 Reporter:  Abhishek Bera|Owner:  Abhishek
 Type:   |  Bera
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Tim Graham ):

 In [changeset:"4a7bbace6bdfc3a4083df83bca3c456efbd66a53" 4a7bbace]:
 {{{
 #!CommitTicketReference repository=""
 revision="4a7bbace6bdfc3a4083df83bca3c456efbd66a53"
 [2.2.x] Fixed #30265 -- Fixed a tutorial number in Reusable App tutorial.

 Backport of ca67f39afa54e281705563834d3684e8b27844b6 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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/069.e3f6d5697640090a09aabac3de872279%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30265: Fix reference to a tutorial number in "Advanced tutorial: How to write reusable app".

[Django]

#30265: Fix reference to a tutorial number in "Advanced tutorial: How to write
reusable app".
-+-
 Reporter:  Abhishek Bera|Owner:  Abhishek
 Type:   |  Bera
  Cleanup/optimization   |   Status:  closed
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 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 Tim Graham ):

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


Comment:

 In [changeset:"ca67f39afa54e281705563834d3684e8b27844b6" ca67f39a]:
 {{{
 #!CommitTicketReference repository=""
 revision="ca67f39afa54e281705563834d3684e8b27844b6"
 Fixed #30265 -- Fixed a tutorial number in Reusable App tutorial.
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/069.ddab6824afb861dc2a4dbaa5b34ac73f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30300: Allow migrations directories without __init__.py files

[Django]

#30300: Allow migrations directories without __init__.py files
-+-
 Reporter:  Benjy Weinberger |Owner:  Benjy
 |  Weinberger
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  2.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Benjy Weinberger):

 Re the use case:

 It seems unnecessary to insist on an empty `__init__.py` just to preserve
 a (stale) check for `__file__`, when they are otherwise not required in
 Python 3.

 And https://code.djangoproject.com/ticket/29091 implies that this should
 be allowed.

 Context is: We've just finished migrating our codebase to all-python 3,
 and nuked all our `__init__py` files. We are now upgrading to Django 2.1,
 and noticing the various places where they're still de-facto required by
 Django. This particular case seemed unnecessary and easy to fix.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.af22320a1aec36d2e08825e9883a307a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29697: Complex query crashes with "missing FROM-clause entry for table"

[Django]

#29697: Complex query crashes with "missing FROM-clause entry for table"
-+-
 Reporter:  Dmitry   |Owner:  Can
 |  Sarıgöl
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

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


Comment:

 Fixed in f19a4945e1191e1696f1ad8e6cdc6f939c702728.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.c13ec3e4187fb2dfbbf9191ec34dce3a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #30301: `django.core.management.base.OutputWrapper` discards the `style_func` argument.

[Django]

#30301: `django.core.management.base.OutputWrapper` discards the `style_func`
argument.
-+-
   Reporter:  Adam   |  Owner:  nobody
  Barnes |
   Type: | Status:  new
  Uncategorized  |
  Component:  Core   |Version:  2.1
  (Management commands)  |
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+-
 
https://github.com/django/django/blob/c296e55dc6a697c7e4d4be92b954633cda4a79b1/django/core/management/base.py#L99

 I would have assumed that line should read `self.style_func = style_func`.
 If it's correct to be discarding the provided `style_func` arg, and
 setting the attribute on `self` to be `None`, the argument shouldn't be
 provided.

 Of course, I'm not particularly familiar with this inner working of Django
 yet, so it's possible this is entirely intentional for some reason I don't
 yet know, in which case, a comment explaining the discarding wouldn't go
 amiss.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/048.4e14c73c4ebc97cbf33aa060737132d0%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30300: Allow migrations directories without __init__.py files

[Django]

#30300: Allow migrations directories without __init__.py files
-+-
 Reporter:  Benjy Weinberger |Owner:  Benjy
 |  Weinberger
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  2.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Benjy Weinberger):

 The "or otherwise" refers to namespace packages being either implicit
 (lacking an __init__.py) or explicit (an __init__.py containing an old-
 style namespace package incantation).

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.a99e42c576c4c312d84aa0a1a39770ff%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30289: ManyToManyField Admin Inlines do not respect user permissions

[Django]

#30289: ManyToManyField Admin Inlines do not respect user permissions
-+
 Reporter:  Jayen Ashar  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  2.1
 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
-+

Comment (by Carlton Gibson):

 Sample project attached: migrate db; load fixture.json. Log in to admin as
 `readonly` with password `1234567890abc`.

 Navigate to Issue > Report admin. You can adjust the M2M. You shouldn't be
 able to.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.0a6300cea0ce2b8e276cbe0eab301bca%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30289: ManyToManyField Admin Inlines do not respect user permissions

[Django]

#30289: ManyToManyField Admin Inlines do not respect user permissions
-+
 Reporter:  Jayen Ashar  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  2.1
 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 Carlton Gibson):

 * Attachment "ticket_30289.zip" added.

 Zip with sample project. load `fixture.json` to populate database
 Username: readonly Password:1234567890abc

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.8e6acd35c946f5ea6fc820ee6498da67%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30289: ManyToManyField Admin Inlines do not respect user permissions

[Django]

#30289: ManyToManyField Admin Inlines do not respect user permissions
-+
 Reporter:  Jayen Ashar  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  2.1
 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 Carlton Gibson):

 * severity:  Normal => Release blocker
 * stage:  Unreviewed => Accepted


Comment:

 OK, yes. Fleshing it out I can reproduce this against 2.1.7 with the
 models and inline provided.

 A user with only the view permission for **both** Report and Photo can
 edit the M2M in the inline.

 When the M2M is handled as a normal field, rather than an inline, the
 behaviour is correct.

 Elevating to a Release Blocker as a regression and/or a bug in the new
 view permissions feature.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.1897beb092706cdc4f34ac7f3f1c0de6%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29177: Unmanaged models with ForeignKeys do not get those fields serialized into their migration state when CreateModel happens.

[Django]

#29177: Unmanaged models with ForeignKeys do not get those fields serialized 
into
their migration state when CreateModel happens.
--+
 Reporter:  Keryn Knight  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Migrations|  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  1
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Simon Charette):

 Sergey,

 > Unmanaged models should not work in migrations by their nature.

 Is there a reason for that? How would the migration framework know how to
 generate references from managed models to unmanaged ones then (e.g. a
 foreign key)? The migration framework has supported managed model
 references for a while and even
 [https://docs.djangoproject.com/en/2.1/howto/writing-migrations/#changing-
 an-unmanaged-model-to-managed documents how to move an unmanaged model to
 a managed one].

 > You can make direct import of this model in migrations and use it.

 Direct model imports in migrations will break over time if the model
 definition happen to change and won't work when mixed up with
 state/migration models. The
 [https://docs.djangoproject.com/en/2.1/topics/migrations/#historical-
 models documentation warns about this pattern].

 I still believe this is a legitimate bug.

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

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

Re: [Django] #30300: Allow migrations directories without __init__.py files (was: Allow migrations directories without __init__.py files.)

[Django]

#30300: Allow migrations directories without __init__.py files
-+-
 Reporter:  Benjy Weinberger |Owner:  Benjy
 |  Weinberger
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  2.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Old description:

> Background: In python 3 a package with no `__init__.py` is implicitly a
> namespace package, so it has no `__file__` attribute.
>
> The migrate command currently checks for existence of a `__file__`
> attribute on the `migrations` package. This check was introduced in
> https://code.djangoproject.com/ticket/21015, because the `__file__`
> attribute was used in migration file discovery.
>
> However, in https://code.djangoproject.com/ticket/23406 migration file
> discovery was changed to use `pkgutil. iter_modules ()`, instead of
> direct filesystem access.   `pkgutil. iter_modules()` uses the package's
> `__path__` list, which exists on implicit namespace packages.
>
> As a result, the `__file__` check is no longer needed, and in fact
> prevents `migrate` from working on namespace packages (implicit or
> otherwise).
>

> Related work: https://code.djangoproject.com/ticket/29091

New description:

 Background: In python 3 a package with no `__init__.py` is implicitly a
 namespace package, so it has no `__file__` attribute.

 The migrate command currently checks for existence of a `__file__`
 attribute on the `migrations` package. This check was introduced in
 #21015, because the `__file__` attribute was used in migration file
 discovery.

 However, in #23406 migration file discovery was changed to use
 `pkgutil.iter_modules ()`, instead of direct filesystem access. `pkgutil.
 iter_modules()` uses the package's `__path__` list, which exists on
 implicit namespace packages.

 As a result, the `__file__` check is no longer needed, and in fact
 prevents `migrate` from working on namespace packages (implicit or
 otherwise).

 Related work: #29091

--

Comment (by Tim Graham):

 What's the use case? When `makemigrations` generates the first migration,
 it adds an `__init__.py` file.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.65a4f40672136cb228162955c9453a78%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30236: UsernameField should use autocapitalize="none"

[Django]

#30236: UsernameField should use autocapitalize="none"
-+-
 Reporter:  Clayton Daley|Owner:
 Type:   |  pmisteliac
  Cleanup/optimization   |   Status:  closed
Component:  contrib.auth |  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:"9410db968388820e43aa453a640dd4720fff0c0f" 9410db96]:
 {{{
 #!CommitTicketReference repository=""
 revision="9410db968388820e43aa453a640dd4720fff0c0f"
 Fixed #30236 -- Made UsernameField render with autocapitalize="none" HTML
 attribute.

 This prevents automatic capitalization, which is the default behavior in
 some browsers.
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/070.e98e31b927d924259bdeceb337d51c39%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30294: HttpResponse doesn't handle memoryview objects

[Django]

#30294: HttpResponse doesn't handle memoryview objects
-+-
 Reporter:  Roger Hunwicks   |Owner:  sage
 Type:  New feature  |   Status:  closed
Component:  HTTP handling|  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
-+-
Changes (by Tim Graham ):

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


Comment:

 In [changeset:"9aa56cb0d5dede7fc176a46c745dfd3dacdad773" 9aa56cb]:
 {{{
 #!CommitTicketReference repository=""
 revision="9aa56cb0d5dede7fc176a46c745dfd3dacdad773"
 Fixed #30294 -- Allowed HttpResponse to accept memoryview content.
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.25d9424d8b9389f8a3bb5b72ebe2550b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30252: ImageField's to_python() stores reference to closed Image object

[Django]

#30252: ImageField's to_python() stores reference to closed Image object
+--
 Reporter:  Felix Dreissig  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  Forms   |  Version:  2.1
 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 Tim Graham):

 * component:  File uploads/storage => Forms


Comment:

 The original commit is 8b7347220f3d86b46f5f87270c6cdcb9960895fd. As you
 can see there, the non-image data attributes like `format`, `height`, and
 `width` are available without reopening the image. Does your purposed
 change affect performance? An alternative could be to clarify that
 subclasses need to reopen the image to access certain methods.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/061.e0d012e23f1bfb8ad39890983f96337f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #28373: TIME_ZONE value in DATABASES settings is not used for date lookup

[Django]

#28373: TIME_ZONE value in DATABASES settings is not used for date lookup
-+-
 Reporter:  Victor Talpaert  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  settings ORM lookup  | Triage Stage:  Accepted
  mysql timezone |
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * needs_better_patch:  0 => 1
 * version:  1.11 => master
 * 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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.6739ea230c7e252fb3d32c5c1019503a%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30290: Documentation should make clear that values on DecimalField is better to be passed as strings

[Django]

#30290: Documentation should make clear that values on DecimalField is better 
to be
passed as strings
-+-
 Reporter:  Alexandros   |Owner:  nobody
  Kanterakis |
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  2.1
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Tim Graham):

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


Comment:

 Yea, I don't think using strings is a best practice in the first place, so
 let's not get into the discussion.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.20de230858f68094361b90a328562056%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30236: UsernameField should use autocapitalize="none"

[Django]

#30236: UsernameField should use autocapitalize="none"
-+-
 Reporter:  Clayton Daley|Owner:
 Type:   |  pmisteliac
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.auth |  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 felixxm):

 * 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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/070.f238e6c991d79dd19233737b52710dd2%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29177: Unmanaged models with ForeignKeys do not get those fields serialized into their migration state when CreateModel happens.

[Django]

#29177: Unmanaged models with ForeignKeys do not get those fields serialized 
into
their migration state when CreateModel happens.
--+
 Reporter:  Keryn Knight  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Migrations|  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  1
  Needs tests:  0 |  Patch needs improvement:  1
Easy pickings:  0 |UI/UX:  0
--+

Comment (by Sergey Yurchenko):

 Unmanaged models should not work in migrations by their nature.
 You can make direct import of this model in migrations and use it.
 I think it is expected behaviour not a bug.

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

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

Re: [Django] #30290: Documentation should make clear that values on DecimalField is better to be passed as strings

[Django]

#30290: Documentation should make clear that values on DecimalField is better 
to be
passed as strings
-+-
 Reporter:  Alexandros   |Owner:  nobody
  Kanterakis |
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  Version:  2.1
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Carlton Gibson):

 I'm kind of sympathetic to this, because it may well be the first instance
 in which beginners come across this kind of ''computer weirdness''.

 However... I'm not sure the model field reference is the place to teach
 this kind of thing **and** we already like to the ''FloatFields vs
 DecimalFields'' discussion, and from there to the `decimal` docs.

 This discussion is a bit advanced for the situation in mind, so I wonder
 if linking **instead** to the
 [https://docs.python.org/3/tutorial/stdlib2.html#decimal-floating-point-
 arithmetic Decimal Floating Point Arithmetic section of the Python
 Tutorial] (which itself links back to the `decimal` docs) wouldn't be a
 win?

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.078ce19613b941074867000b6c03afd0%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30300: Allow migrations directories without __init__.py files. (was: migrate silently ignores apps whose migrations directory doesn't have an __init__.py)

[Django]

#30300: Allow migrations directories without __init__.py files.
-+-
 Reporter:  Benjy Weinberger |Owner:  Benjy
 |  Weinberger
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  2.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.7b5a3c4b4b548aeb1993c12d5031aec9%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30300: migrate silently ignores apps whose migrations directory doesn't have an __init__.py

[Django]

#30300: migrate silently ignores apps whose migrations directory doesn't have an
__init__.py
-+-
 Reporter:  Benjy Weinberger |Owner:  Benjy
 |  Weinberger
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  2.1
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * type:  Bug => New feature
 * stage:  Unreviewed => Accepted


Comment:

 Hi Benjy. Thanks for the report — and the test case in the PR! Unless
 something comes up in review, this seems reasonable to me.

 I'm going to call it a new feature, since this behaviour will never have
 worked I think.

 >... (implicit or otherwise)

 I don't quite follow the `or otherwise` there?

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.9a7c8909b93d843e1d603d304103%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.