Re: [Django] #32791: Documentation unclear on custom user models

[Django]

#32791: Documentation unclear on custom user models
-+-
 Reporter:  Matthew Somerville   |Owner:  Nishant
 |  Sagar
 Type:  Uncategorized|   Status:  closed
Component:  Documentation|  Version:  3.2
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

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


Comment:

 Hi Matthew — thanks for the report.

 I have to say we need to go back to the DevelopersMailingList for this.
 There are as many opinions as there are developers: ranging from "use the
 default model, or you end up using your auth model as a random data bin"
 to "we should update the default template to create the subclass, so users
 don't find this advise until too late" to ... — if we could agress the
 canonical advice then a rewrite might be on the cards.

 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/064.8477899be42172d949e1eeef0fe59190%40djangoproject.com.

Re: [Django] #32798: StreamingHttpResponse raises SynchronousOnlyOperation in ASGI server

[Django]

#32798: StreamingHttpResponse raises SynchronousOnlyOperation in ASGI server
+
 Reporter:  Ralph Broenink  |Owner:  nobody
 Type:  Bug |   Status:  new
Component:  HTTP handling   |  Version:  3.2
 Severity:  Normal  |   Resolution:
 Keywords:  ASGI, async | 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):

 * cc: Andrew Godwin (added)
 * keywords:   => ASGI, async
 * stage:  Unreviewed => Accepted


Comment:

 Yes, this won't work. It's not the streaming response (the block this is
 raised from explicitly handles that) but rather the ORM call.

 > This is not expected behaviour, and appears not to be documented.

 I think (currently) it is the expected behaviour. It's covered in the
 [https://docs.djangoproject.com/en/3.2/topics/async/#async-safety Async
 safety] section of the Asynchronous support docs.

 Hmmm 🤔 but yes, it's a limitation on the async wrapping of synchronous
 views… I'll accept for now because I can't quite see a better place to pin
 it. It's likely this will not be resolved until we have a better async
 story for the ORM, but that's not yet at the ticketed stage. (If we had
 such a ticket open, I'd say it's a duplicate of that.)

 I'll cc Andrew so it crosses his radar as a target use-case.

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

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

Re: [Django] #24121: Provide a better repr() experience

[Django]

#24121: Provide a better repr() experience
--+
 Reporter:  Keryn Knight  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Core (Other)  |  Version:  dev
 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
--+
Description changed by Mariusz Felisiak:

Old description:

> For a long time, Django has shipped with the debug 500 handler, which
> defaults to a view where "local vars" for every stack frame can be
> expanded and inspected to see the internal state at the various points in
> the stack trace.
>
> Between that renderer, the heavy usage of `django-debug-toolbar`, which
> ships with a template context inspector, and my preference throwing `pdb`
> everywhere, there is a notable lack of a good `repr()` experience in much
> of Django, both in debugging public API (that is, the bits a user will
> use and encounter), and internals that might be exposed, or could
> otherwise be served better by having a repr that says something more than
> it's address/id.
>
> A couple of previous tickets have addressed this in minor, one off ways -
> #23167, #22906, #22531 - but as I've begun collecting places they could
> supply useful info as I spot them in my stuff, they've become a
> hodgepodge across a number of modules.
>
> For example, a couple I've got implemented:
> {{{
> 
>
>  loadname=admin/change_list.html>
>
> 
> }}}
> All of which, IMHO, provide a more useful context in which to evaluate
> state.
>
> The branch I have implemented my reprs in is in no way merge ready yet,
> partially because there's no tests, and it'd need rebasing & squashing,
> but also because there are some parts I'd like to see reprs on but
> haven't landed on a good way to do so.
> An example being the concept of a `Loader`, which currently has no repr()
> and thus shows up as `` which at least
> tells us which loader is being referenced. Given the convention so far
> for reprs() is just the class name (rather than module + class), the fact
> all Loaders (and now Engines) all share the same class name means in
> exposing more useful internal state we lose knowledge of the loader in
> question's module namespace.
>
> As I write this, I've got at least rudimentary (as in, it was possibly to
> replace the 0x... with at least one object-state variable) reprs for:
> * ~~`StaticNode`~~ added in e6406853c326ea9210d07766138d2b193c6d1fba
> * `BlockTranslateNode`
> * ~~`URLNode`~~ added in d3ecef26b9fda02b88f925a800ae38dd5873c878
> * ~~`Token`~~ added in 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`Lexer`~~ added in 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`Parser`~~ added in 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`FilterExpression`~~ added in
> 179ee13eb37348cd87169a198aec18fedccc8668
> * ~~`MiddlewareMixin`, `RedirectFallbackMiddleware`, `MessageMiddleware`,
> `RemoteUserMiddleware`, `CsrfViewMiddleware`~~ added in
> dc86a25a677d05703e0bb021b178e44412cea7e9
> * ~~`Col`~~ added in 7171bf755b0c4be85ddbcc164eaf87164c131021
> * ~~`Lookup`~~ added in d3d95d645fc9f36355d27598475612de43587db1
> * `BaseDatabaseWrapper` [https://github.com/django/django/pull/14111 PR]
> * `SQLCompiler` [https://github.com/django/django/pull/14111 PR]
> * `JoinPromoter` [https://github.com/django/django/pull/14111 PR]
> * ~~`HttpResponse`, `HttpResponseRedirect`, `HttpResponseNotAllowed`~~
> added in c96f11257baf43188ff9daeddab3221992925c85
> * ~~`LazySettings`, `Settings`, and `UserSettingsHolder`~~ added in
> 9c40f01a66bd15457e10a0bbf28c803968b5dabb
> * ~~`GeoIP2`~~ added in d4b10a725614322769a419180039771634a06571
> * ~~`PermWrapper`~~ added in 22da686ca93e99f8091334f66d7199bc29b85c83
> * `SessionStorage`
> * `CookieStorage`
> * `FallbackStorage`
> * `ChangeList`
> * `AdminForm`
> * `InlineAdminFormSet`
> * ~~`SimpleTemplateResponse`~~ added in
> c96f11257baf43188ff9daeddab3221992925c85
> * ~~`TemplateResponse`~~ added in
> c96f11257baf43188ff9daeddab3221992925c85
> * `AdminSite` [https://github.com/django/django/pull/14417 PR]
> * `ModelAdmin` [https://github.com/django/django/pull/14417 PR]
> * ~~`Origin`~~ added in 4f4f770f77c5d720484c0a71f6a19b9affcc7e28
> * ~~`Template`~~ added in 4f4f770f77c5d720484c0a71f6a19b9affcc7e28
> * `BlockContext`
> * `IncludeNode`
> * `Engine` [https://github.com/django/django/pull/14460 PR]
> * ~~`OrderedSet`~~ added in afb0eb8bb3e1c6f7ea842d2cede684eb4aec3f3d
>

> If accepted, this ticket could just track whatever I can end up getting
> reviewed/merged, or it could be a meta-ticket for accepting as a
> principle, and I could spin off tickets for more targete

Re: [Django] #24121: Provide a better repr() experience

[Django]

#24121: Provide a better repr() experience
--+
 Reporter:  Keryn Knight  |Owner:  nobody
 Type:  New feature   |   Status:  new
Component:  Core (Other)  |  Version:  dev
 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
--+

Comment (by Mariusz Felisiak ):

 In [changeset:"c609d5149c9295207cd7b2e8154e7b80a18d834a" c609d514]:
 {{{
 #!CommitTicketReference repository=""
 revision="c609d5149c9295207cd7b2e8154e7b80a18d834a"
 Refs #24121 -- Added __repr__() to Engine
 }}}

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

Re: [Django] #32800: CsrfViewMiddleware unnecessarily masks CSRF cookie

[Django]

#32800: CsrfViewMiddleware unnecessarily masks CSRF cookie
-+-
 Reporter:  Chris Jerdonek   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  CSRF |  Version:  dev
 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 Mariusz Felisiak):

 * cc: Shai Berger, Florian Apolloner (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/067.30e32ddd79740d599d427720df489e5a%40djangoproject.com.

Re: [Django] #32799: Inconsistency regarding the default value of CharField

[Django]

#32799: Inconsistency regarding the default value of CharField
---+--
 Reporter:  Adam Sołtysik  |Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  Migrations |  Version:  3.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 Adam Sołtysik):

 > With your proposition we would remove an important feature from
 migrations and we wouldn't give users a chance to decide on their own

 Actually, my proposition is just to make migrations use the same default
 value that objects use, when there is no explicit default value given. The
 questioner could still work the same if that's more consistent with other
 fields. My use case was a migration edited by hand, which crashed due to
 nulls, when I expected it to use empty 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/065.e7cd9a59850ef045d6a0015dad6ea1dd%40djangoproject.com.

Re: [Django] #32799: Inconsistency regarding the default value of CharField

[Django]

#32799: Inconsistency regarding the default value of CharField
---+--
 Reporter:  Adam Sołtysik  |Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  Migrations |  Version:  3.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 Mariusz Felisiak):

 > The same could apply to migrations. Since there's only one possible
 value for "no data" for the existing rows, it's probably better to use
 that than to ask for that value or crash.

 It's not the same to use the empty string for a new row and to update
 **all existing** rows without asking for a value. With your proposition we
 would remove an important feature from migrations and we wouldn't give
 users a chance to decide on their own, which they have when creating a new
 object.

 Again, please start a discussion on DevelopersMailingList if you don't
 agree.

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

Re: [Django] #32799: Inconsistency regarding the default value of CharField

[Django]

#32799: Inconsistency regarding the default value of CharField
---+--
 Reporter:  Adam Sołtysik  |Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  Migrations |  Version:  3.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 Adam Sołtysik):

 > Except for the fact that currently blank=True can be used with char
 fields instead of a default value for the migration to work properly, even
 though blank parameter is said ​in the documentation to matter for form
 validation only.

 I've found there was already a ticket about this: #27197, and a discussion
 on the mailing list: https://groups.google.com/g/django-
 developers/c/upbDlFgtCHs/discussion, but without any resolution.

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

Re: [Django] #30685: Optimize QuerySet.count() with distinct()

[Django]

#30685: Optimize QuerySet.count() with distinct()
-+-
 Reporter:  Adam Sołtysik|Owner:  (none)
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * owner:  Ivaylo Donchev => (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/065.ecce97c0c69dc86eea319e582feb071b%40djangoproject.com.

Re: [Django] #32799: Inconsistency regarding the default value of CharField

[Django]

#32799: Inconsistency regarding the default value of CharField
---+--
 Reporter:  Adam Sołtysik  |Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  Migrations |  Version:  3.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 Adam Sołtysik):

 > IMO these are two different scenarios.

 The point is to make these two different scenarios work consistently, not
 to break the principle of least astonishment. When model objects behave
 like they have a valid default value, it's surprising that migrations
 behave like there's no valid default.

 > For a string-based field with null=False you have one possible values
 for "no data" i.e. the empty string that's why Django uses it when value
 is not provided for a non-nullable string-based field.

 The same could apply to migrations. Since there's only one possible value
 for "no data" for the existing rows, it's probably better to use that than
 to ask for that value or crash.

 > Migrations asks for a default value for existing rows when adding a non-
 nullable field to the model, and does it consistently for all type of
 fields.

 Except for the fact that currently `blank=True` can be used with char
 fields instead of a default value for the migration to work properly, even
 though `blank` parameter is said
 [https://docs.djangoproject.com/en/3.2/ref/models/fields/#blank in the
 documentation] to matter for form validation only.

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

Re: [Django] #32795: Reject requests earlier if the non-cookie CSRF token is missing or has the wrong format

[Django]

#32795: Reject requests earlier if the non-cookie CSRF token is missing or has 
the
wrong format
-+-
 Reporter:  Chris Jerdonek   |Owner:  Chris
 Type:   |  Jerdonek
  Cleanup/optimization   |   Status:  assigned
Component:  CSRF |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"ffdee8d2645227748ae4061f21fc48cca4d75c22" ffdee8d2]:
 {{{
 #!CommitTicketReference repository=""
 revision="ffdee8d2645227748ae4061f21fc48cca4d75c22"
 Refs #32795 -- Added CsrfViewMiddleware tests for rejecting invalid or
 missing tokens.

 This also improves test names for test_process_request_no_csrf_cookie
 and test_process_request_csrf_cookie_no_token. The logic being tested
 is actually in process_view() rather than process_request(), and it's
 not necessary to include the method name.
 }}}

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

Re: [Django] #32795: Reject requests earlier if the non-cookie CSRF token is missing or has the wrong format

[Django]

#32795: Reject requests earlier if the non-cookie CSRF token is missing or has 
the
wrong format
-+-
 Reporter:  Chris Jerdonek   |Owner:  Chris
 Type:   |  Jerdonek
  Cleanup/optimization   |   Status:  closed
Component:  CSRF |  Version:  dev
 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:"55775891fbfd8679b75336aa2f15ff9190e9f7a8" 55775891]:
 {{{
 #!CommitTicketReference repository=""
 revision="55775891fbfd8679b75336aa2f15ff9190e9f7a8"
 Fixed #32795 -- Changed CsrfViewMiddleware to fail earlier on badly
 formatted tokens.
 }}}

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

Re: [Django] #32319: Add support to HashedFilesMixin for ES modules

[Django]

#32319: Add support to HashedFilesMixin for ES modules
-+-
 Reporter:  gilmrjc  |Owner:  gilmrjc
 Type:  New feature  |   Status:  assigned
Component:  contrib.staticfiles  |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"781b44240a06f0c868254f40f36ce46c927f56d1" 781b4424]:
 {{{
 #!CommitTicketReference repository=""
 revision="781b44240a06f0c868254f40f36ce46c927f56d1"
 Refs #32319 -- Changed HashedFilesMixin to use named groups in patterns.
 }}}

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

Re: [Django] #32319: Add support to HashedFilesMixin for ES modules

[Django]

#32319: Add support to HashedFilesMixin for ES modules
-+-
 Reporter:  gilmrjc  |Owner:  gilmrjc
 Type:  New feature  |   Status:  closed
Component:  contrib.staticfiles  |  Version:  dev
 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:"91e21836f667c784a8a63ab1f18d81f553e679cb" 91e21836]:
 {{{
 #!CommitTicketReference repository=""
 revision="91e21836f667c784a8a63ab1f18d81f553e679cb"
 Fixed #32319 -- Added ES module support to ManifestStaticFilesStorage.
 }}}

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

Re: [Django] #32799: Inconsistency regarding the default value of CharField

[Django]

#32799: Inconsistency regarding the default value of CharField
---+--
 Reporter:  Adam Sołtysik  |Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  Migrations |  Version:  3.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
---+--
Changes (by Mariusz Felisiak):

 * status:  new => closed
 * resolution:   => wontfix
 * component:  Database layer (models, ORM) => Migrations
 * type:  Uncategorized => New feature


Comment:

 IMO these are two different scenarios. The Django convention is to use the
 empty string, not `NULL`. For a string-based field with `null=False` you
 have one possible values for "no data" i.e. the empty string that's why
 Django uses it when value is not provided for a non-nullable string-based
 field.

 Migrations asks for a default value for **existing** rows when adding a
 non-nullable field to the model, and does it consistently for all type of
 fields. Folks can always type `''`, it's not much of a burden.

 You can start a discussion on DevelopersMailingList if you don't agree.

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

Re: [Django] #24462: Add a new QuerySet operation to use current results as a subquery

[Django]

#24462: Add a new QuerySet operation to use current results as a subquery
-+-
 Reporter:  trosos   |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  distinct order_by| Triage Stage:  Accepted
  subquery   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Jameel Al-Aziz):

 I believe we have a similar need, but for difference reasons.

 We have a JSONB postgres column and want to `jsonb_array_elements`
 followed by filtering. Because `jsonb_array_elements` expands into a set
 of columns, you cannot apply a `where` clause filter on the function
 column. A simple solution is to use `jsonb_array_elements` in a subquery
 and then filter the resulting subquery.

 Another use case for sub-querying is being able to apply filters on union
 queries. Our actual use case involves both `jsonb_array_elements` and
 `UNION`s.

 A sample query that I'm trying to write with querysets (but so far have
 been unable to) is:
 {{{
 select *
 from (
 select id, jsonb_array_elements(json_data->'some_array') as elem
 from foo as foo1
 union
 select id, jsonb_array_elements(json_data->'other_array') as elem
 from foo as foo2
 ) as foo_w_elems
 where (elem->>'subfield')::int in (
 select id
 from bar
 where expires_at >= CURRENT_TIMESTAMP
 )
 }}}

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

Re: [Django] #32800: CsrfViewMiddleware unnecessarily masks CSRF cookie

[Django]

#32800: CsrfViewMiddleware unnecessarily masks CSRF cookie
-+-
 Reporter:  Chris Jerdonek   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  CSRF |  Version:  dev
 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 Chris Jerdonek:

Old description:

> I noticed that `CsrfViewMiddleware` unnecessarily masks the CSRF cookie.
> See, for example:
> https://github.com/django/django/blob/d270dd584e0af12fe6229fb712d0704c232dc7e5/django/middleware/csrf.py#L91
>
> My understanding of the [http://breachattack.com/ BREACH attack] is that
> the vulnerability comes from not masking the CSRF token in the response
> body (e.g. what is included in the HTML). Masking the cookie itself
> doesn't help with this. (Django also
> [https://github.com/django/django/blob/d270dd584e0af12fe6229fb712d0704c232dc7e5/django/middleware/csrf.py#L308-L309
> doesn't change the mask] of the cookie with each request, so the mask
> wouldn't help in this regard anyways.)
>
> Some advantages of not masking the cookie are: It would simplify the code
> in `CsrfViewMiddleware` because it would remove some complexity and
> operations that aren't needed for security. Currently, masking the CSRF
> cookie is a red herring for someone wanting to understand the various
> security  features. Also, not masking the cookie would make requests and
> responses smaller when `CSRF_USE_SESSIONS` is false or when true and
> cookie-based sessions are used. This is because masking doubles the
> length of the string.

New description:

 I noticed that `CsrfViewMiddleware` unnecessarily masks the CSRF cookie.
 See, for example:
 
https://github.com/django/django/blob/d270dd584e0af12fe6229fb712d0704c232dc7e5/django/middleware/csrf.py#L91

 My understanding of the [http://breachattack.com/ BREACH attack] is that
 the vulnerability comes from not masking the CSRF token in the response
 body (e.g. what is included in the HTML). Masking the cookie itself
 doesn't help with this. (Django also
 
[https://github.com/django/django/blob/d270dd584e0af12fe6229fb712d0704c232dc7e5/django/middleware/csrf.py#L308-L309
 doesn't change the mask] of the cookie with each request, so the mask
 wouldn't help in this regard anyways.)

 Some advantages of not masking the cookie are: It would simplify the code
 in `CsrfViewMiddleware` because it would remove some complexity and
 operations that aren't needed for security. Currently, masking the CSRF
 cookie is a red herring for someone wanting to understand the various
 security  features. Also, not masking the cookie would make requests and
 responses smaller when `CSRF_USE_SESSIONS` is false or when true and
 cookie-based sessions are used. This is because masking doubles the length
 of the string.

 This can be changed fairly easily while (1) continuing to respect masked
 cookie values, and (2) not forcing session stores to update their cookie
 in its unmasked form if they are currently storing it masked.

--

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

[Django] #32800: CsrfViewMiddleware unnecessarily masks CSRF cookie

[Django]

#32800: CsrfViewMiddleware unnecessarily masks CSRF cookie
+
   Reporter:  Chris Jerdonek|  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  CSRF  |Version:  dev
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 I noticed that `CsrfViewMiddleware` unnecessarily masks the CSRF cookie.
 See, for example:
 
https://github.com/django/django/blob/d270dd584e0af12fe6229fb712d0704c232dc7e5/django/middleware/csrf.py#L91

 My understanding of the [http://breachattack.com/ BREACH attack] is that
 the vulnerability comes from not masking the CSRF token in the response
 body (e.g. what is included in the HTML). Masking the cookie itself
 doesn't help with this. (Django also
 
[https://github.com/django/django/blob/d270dd584e0af12fe6229fb712d0704c232dc7e5/django/middleware/csrf.py#L308-L309
 doesn't change the mask] of the cookie with each request, so the mask
 wouldn't help in this regard anyways.)

 Some advantages of not masking the cookie are: It would simplify the code
 in `CsrfViewMiddleware` because it would remove some complexity and
 operations that aren't needed for security. Currently, masking the CSRF
 cookie is a red herring for someone wanting to understand the various
 security  features. Also, not masking the cookie would make requests and
 responses smaller when `CSRF_USE_SESSIONS` is false or when true and
 cookie-based sessions are used. This is because masking doubles the length
 of the string.

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

[Django] #32799: Inconsistency regarding the default value of CharField

[Django]

#32799: Inconsistency regarding the default value of CharField
-+-
   Reporter:  Adam   |  Owner:  nobody
  Sołtysik   |
   Type: | Status:  new
  Uncategorized  |
  Component:  Database   |Version:  3.2
  layer (models, ORM)|
   Severity:  Normal |   Keywords:
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 Let's assume I want to add a `CharField` to a model:

 {{{
 class Test(Model):
 # other fields
 name = CharField(max_length=20)
 }}}

 This field is non-nullable and has no default value. However, when an
 object is created, the field gets an empty string automatically:

 {{{
 >>> Test().name
 ''
 }}}

 When such an object is saved, an empty string will be saved to the
 database. The same happens when I call `Test.objects.create()`.

 On the other hand, when I create a migration, Django asks me to provide a
 default. If I omit a default value and try to execute the migration, there
 will be `IntegrityError` due to the `NOT NULL` constraint.

 So the question is: why does `CharField` behave differently in the
 contexts of Python objects and migrations? The same goes also for
 `FileField`, but not e.g. for non-nullable `IntegerField` (it won't get a
 value of `0` automatically).

 Changing the behaviour of objects with `CharField` would be a breaking
 change, but for consistency, I think that migrations should also infer the
 empty string as the default value, even when there is no `default=''` or
 `blank=True`.

 Possibly related: #23405.

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

Re: [Django] #32796: Reject requests earlier if the CSRF cookie token has the wrong format

[Django]

#32796: Reject requests earlier if the CSRF cookie token has the wrong format
-+-
 Reporter:  Chris Jerdonek   |Owner:  Chris
 Type:   |  Jerdonek
  Cleanup/optimization   |   Status:  assigned
Component:  CSRF |  Version:  dev
 Severity:  Normal   |   Resolution:
 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 Chris Jerdonek):

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

Re: [Django] #32796: Reject requests earlier if the CSRF cookie token has the wrong format

[Django]

#32796: Reject requests earlier if the CSRF cookie token has the wrong format
-+-
 Reporter:  Chris Jerdonek   |Owner:  Chris
 Type:   |  Jerdonek
  Cleanup/optimization   |   Status:  assigned
Component:  CSRF |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Chris Jerdonek):

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

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

[Django] #32798: StreamingHttpResponse raises SynchronousOnlyOperation in ASGI server

[Django]

#32798: StreamingHttpResponse raises SynchronousOnlyOperation in ASGI server
--+
   Reporter:  Ralph Broenink  |  Owner:  nobody
   Type:  Bug | Status:  new
  Component:  HTTP handling   |Version:  3.2
   Severity:  Normal  |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+
 When using a ASGI-compliant server, such as Daphne,
 StreamingHttpResponse's iterator will be executed in an asynchronous
 context, preventing database queries from being performed (raising
 SynchronousOnlyOperation). This is not expected behaviour, and appears not
 to be documented.

 *Steps to reproduce*
 1. Create a simple project and app. Set-up for use with Channels. We are
 not going to use this component and the bug does seem to originate from
 Django itself, but Channels ensures that runserver is ASGI-compliant.
 2. Create the following view:

 {{{
 from django.contrib.contenttypes.models import ContentType
 from django.http import StreamingHttpResponse

 def test_view(request):
 def generate():
 yield "hello\n"
 list(ContentType.objects.all())
 yield "bye\n"
 return StreamingHttpResponse(generate(), content_type="text/plain")
 }}}

 3. Open the page served by test_view
 4. Observe the following trace:

 {{{
 Exception inside application: You cannot call this from an async context -
 use a thread or sync_to_async.
 Traceback (most recent call last):
   File "venv/lib/python3.8/site-packages/channels/staticfiles.py", line
 44, in __call__
 return await self.application(scope, receive, send)
   File "venv/lib/python3.8/site-packages/channels/routing.py", line 71, in
 __call__
 return await application(scope, receive, send)
   File "venv/lib/python3.8/site-packages/django/core/handlers/asgi.py",
 line 168, in __call__
 await self.send_response(response, send)
   File "venv/lib/python3.8/site-packages/django/core/handlers/asgi.py",
 line 242, in send_response
 for part in response:
   File "channelstest/testapp/views.py", line 9, in generate
 list(ContentType.objects.all())
   File "venv/lib/python3.8/site-packages/django/db/models/query.py", line
 287, in __iter__
 self._fetch_all()
   File "venv/lib/python3.8/site-packages/django/db/models/query.py", line
 1303, in _fetch_all
 self._result_cache = list(self._iterable_class(self))
   File "venv/lib/python3.8/site-packages/django/db/models/query.py", line
 53, in __iter__
 results = compiler.execute_sql(chunked_fetch=self.chunked_fetch,
 chunk_size=self.chunk_size)
   File "venv/lib/python3.8/site-
 packages/django/db/models/sql/compiler.py", line 1152, in execute_sql
 cursor = self.connection.cursor()
   File "venv/lib/python3.8/site-packages/django/utils/asyncio.py", line
 24, in inner
 raise SynchronousOnlyOperation(message)
 django.core.exceptions.SynchronousOnlyOperation: You cannot call this from
 an async context - use a thread or sync_to_async.
 }}}

 This error is probably caused by the fact that Django 3 now actively
 prevents this kind of error (it would have gone undetected in Django 2)
 and the fact that the iterator is called in an asynchronous context in
 handlers/asgi.py.

 As mentioned above, this issue should at the very least be documented in
 the documentation, but preferably should be resolved altogether.

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

Re: [Django] #32791: Documentation unclear on custom user models

[Django]

#32791: Documentation unclear on custom user models
-+-
 Reporter:  Matthew Somerville   |Owner:  Nishant
 |  Sagar
 Type:  Uncategorized|   Status:  assigned
Component:  Documentation|  Version:  3.2
 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 Nishant Sagar):

 * owner:  nobody => Nishant Sagar
 * 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.61fb88fe948476bc4bb8fb2f46433055%40djangoproject.com.

Re: [Django] #32796: Reject requests earlier if the CSRF cookie token has the wrong format

[Django]

#32796: Reject requests earlier if the CSRF cookie token has the wrong format
-+-
 Reporter:  Chris Jerdonek   |Owner:  Chris
 Type:   |  Jerdonek
  Cleanup/optimization   |   Status:  assigned
Component:  CSRF |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Chris Jerdonek):

 * owner:  nobody => Chris Jerdonek


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

Re: [Django] #32797: model_ngettext incorrectly tries to translate already translated words

[Django]

#32797: model_ngettext incorrectly tries to translate already translated words
-+-
 Reporter:  Maciej Olko  |Owner:  Maciej
 |  Olko
 Type:  Bug  |   Status:  assigned
Component:  contrib.admin|  Version:  3.2
 Severity:  Normal   |   Resolution:
 Keywords:  i18n, gettext,   | Triage Stage:
  ngettext   |  Unreviewed
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-
Changes (by Mariusz Felisiak):

 * cc: Claude Paroz (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.92c39a2afff2598248698d4a2bd3c58f%40djangoproject.com.

Re: [Django] #32795: Reject requests earlier if the non-cookie CSRF token is missing or has the wrong format

[Django]

#32795: Reject requests earlier if the non-cookie CSRF token is missing or has 
the
wrong format
-+-
 Reporter:  Chris Jerdonek   |Owner:  Chris
 Type:   |  Jerdonek
  Cleanup/optimization   |   Status:  assigned
Component:  CSRF |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * stage:  Accepted => Ready for checkin


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

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

Re: [Django] #32319: Add support to HashedFilesMixin for ES modules

[Django]

#32319: Add support to HashedFilesMixin for ES modules
-+-
 Reporter:  gilmrjc  |Owner:  gilmrjc
 Type:  New feature  |   Status:  assigned
Component:  contrib.staticfiles  |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * needs_better_patch:  1 => 0
 * stage:  Accepted => Ready for checkin
 * needs_tests:  1 => 0
 * needs_docs:  1 => 0


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

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